Whiz-zarD

Die Frage ist ja, wer sind die Teilnehmer? Der Kurs richtet sich ja an blutige Anfänger. Sie wissen es nicht besser und dann kommt einer, der Wirtschaftsingenieurswesen studiert hat und erzählt einem was vom Pferd. Ich glaube auch nicht, dass der Kurs sich noch großartig angepasst wird. Der Typ scheint enormes Vertrauen in sich zu haben, denn mit Selbstlob geizt er nicht. Im Neudeutsch würde ich sagen, dass er ganz schön auf die Kacke haut. Ich habe nichts gegen Vereinfachung. Ich erwarte ja nicht, dass er auf die Gefahren von Fließkommawerten eingeht und warum man diese nicht für Geldbeträge nutzen sollte (zumindest nicht double und float; dafür gibt es in C# decimal) aber allein schon in diesen einem Video merkt man, dass er oft keine Ahnung hat, wovon er da eigentlich redet. Dann wird seine Sprechweise unsicher. Er macht Pausen und versucht das Thema schnell mit einem Halbsatz zu beenden. Kommentare sind immer so eine Sache. Ich garantiere dir, dass auch mit Kommentare das Tamagochi-Projekt zum Chaos geworden wäre. Es liegt nicht immer an den fehlenden Kommentaren, sondern an der Dokumentation. Kommentare helfen nicht, wenn man nicht weiß, wo man suchen muss. Mit Kommentaren bin ich auch immer sehr sparsam. Ich mache sie nur dort, wo ich es für nötig halte. Triviale Getter- und Setter bekommen keine Kommentare. Auch die Kommentare für Methoden sollten meiner Meinung sehr sparsam sein. Maximal zwei bis drei Sätze. Kommentare für Methoden sollten auch nie den Algorithmus erklären, denn irgendwann kommt der Zeitpunkt, wo man den Algorithmus anpassen muss und dann vergisst man mit Sicherheit den Kommentar anzupassen und schon laufen Kommentar und Implementierung auseinander. Viel wichtiger als Kommentare ist die Kommunikation und die Dokumentation.

Eine Ergänzung: Außerdem fehlt Generics komplett. Ich habe mir mal das Video "Einführung in Datentypen und was du in diesem Kapitel lernst" angeschaut. Der erzählt viel Stuss. Man merkt, dass er nur Halbwissen verfügt. z.B. weiß er nicht, dass Variablen nur in einem Sichtbarkeitsbereich haben und er meint, dass Variablen so lange im Speicher bleiben, bis wir sie löschen. Das ist falsch. Variablen mit einem primitiven (integrierten) Wertetyp verlieren ihre Gültigkeit, wenn der Programmfluss ihre Sichtbarkeit verliert. Variablen mit Klasseninstanzen räumt der Garbage Collector weg, wenn der Programmfluss ihre Sichtbarkeit verliert. Auch behauptet er, ein Integer-Wert könnte man nicht mit einem double-Wert addieren. Das ist falsch. Natürlich geht das. Das Resultat ist dann ein double-Wert. Der Unterschied zwischen double und float ist für ihn auch nur die Speichergröße. Auf die Genauigkeit geht er gar nicht ein. Nee, der Kurs ist selbst für 20 € noch zu teuer. Der Originalpreis von 95 € ist Wucher.

Ich persönlich würde vom udemy-kurs die Finger von lassen. Ich habe noch nie einen Einleitungstext mit so vielen Zeichensetzungs- und Grammatikfehlern gesehen. Auch ist er Autor wohl von sich selbst sehr überzeugt, obwohl er nicht mal ein softwareeentwickler ist, sondern sich das wohl alles selbst beigebracht hat. Außerdem macht er falsche Versprechungen, da er behauptet, dass man nach seinem Kurs Spiele in Unity entwickelt könnte aber er geht gar nicht auf Unity ein. Nee, das klingt für mich doch ein wenig unseriös.

Der berühmte Taschenrechner... Nein, ich halte die Entwicklung eines Taschenrechners nicht sinnvoll für einen Anfänger, denn so trivial ist sowas gar nicht. Meist handeln solche Beispiele nur von pseudo-taschenrechnern, die nur kettenaufgaben lösen können. Also nichts, was man im Alltag gebrauchen könnte. Das hinterlässt ein unzufriedenes Gefühl. Wenn dann noch eine grafische Oberfläche ins Spiel kommt, wird es dann ganz schlimm. Dann wird die Oberfläche mit der Berechnungslogik vermischt und dann bringt man es den Anfänger absichtlich falsch bei. Um einen richtigen Taschenrechner bauen zu können, braucht man schon ein bisschen mehr Wissen und das hat ein Anfänger noch nicht.

Das kommt mir sehr wenig vor. In einer Windows-Domäne kann man die Signatur direkt im AD hinterlegen und Outlook holt sie automatisch. Ich finde ganze Tutorials, die einem erklären, wie man es umsetzt. Das sind weniger als 10 Schritte und die sind sogar recht simpel. Dafür braucht man vielleicht ein Tag und dann läuft es.

Natürlich gibt es auch hier Diskussionsspielraum, ansonsten dürften viele Betriebe gar nicht ausbilden. Als Beispiel nenne ich meine Mechatroniker-Ausbildung. Einige Schulkollegen aus meiner damaligen Berufsschulklasse hatten in Firmen eine Mechatroniker-Ausbildung gemacht, die gar nicht die Möglichkeiten hatten, den Ausbildungsrahmenplan vollumfänglich einzuhalten. So ist im Ausbilungsrahmenplan z.B. von "Installieren und Testen von Hard- und Softwarekomponenten" die Rede aber sowas gibt es in Firmen nicht, die z.B. Kettensägen mit Verbrennungsmotoren bauen. Solche Firmen haben dann Wartungsverträge mit IT-Firmen. Die Azubis dürfen dann nicht mal in die Nähe der Server.

Das ist jetzt eine persönliche Vorliebe von mir, aber ich würde empfehlen, mit der Sprache C# anzufangen. Die Community Editon von Visual Studio ist ja kostenlos erhältlich und bietet alles, was man eigentlich so braucht. Java wäre auch möglich aber ich halte die Entwicklungsumgebungen nicht ganz für anfängertauglich. Ich hab das Buch zwar nicht gelesen, aber das Inhaltsverzeichnis und die Leseprobe lesen sich ganz vielversprechend und daher würde ich folgendes Buch empfehlen: Schrödinger programmiert C# Mit 750 Seiten ist es schon ein großer Brocken aber dadrinnen befinden sich sehr viele farbige Bilder und recht wenig Text auf den Seiten. Das lockert vielleicht das Lesen ein wenig auf. Einige werden wohl die Sprache Python empfehlen, weil sie sehr anfängerfreundlich sein soll aber ich muss gestehen, dass ich mit dieser Sprache bis jetzt kaum etwas gemacht habe und auch keine Literatur dafür empfehlen kann. Bücher, wie Clean Code würde ich auch noch keinen Anfänger in die Hand drücken wollen. Das würde ich erst machen, wenn die Person auch schon gewisse Erfahrungen gesammelt hat, auf die man aufbauen kann.

Eben. Ich sehe da auch keine Probleme. Schlechter Code kommt doch nur dadurch zustande, weil man es nicht besser weiß. Probleme bestehen doch nur, wenn der Azubi beratungsresistent ist. Ich kenne es selber. In der Firma, wo ich arbeite, schule ich inzwischen Senior Entwickler, obwohl ich erst vor knapp 5 Jahren dort als Junior Entwickler angefangen habe. Wir haben dort auch ein paar Spezies, die weiterhin Spaghetticode schreiben, weil sie der Meinung sind, sie seien die besten Entwickler der Welt und lassen sich eh nichts von einem etwas sagen, der ca. 20 Jahre jünger ist, als sie selbst. Die meisten Entwickler nehmen aber die Tipps, die ich denen gebe, zu Herzen. Sicherlich, viele von denen waren auch erst skeptisch, weil sie den Begriff "SOLID" zum ersten Mal gehört haben (obwohl sie schon seit über 20 Jahren als Entwickler tätig sind) und fassten es als neumodischen Schnick-Schnack auf und waren der Meinung, dass unsere Anwendung eh viel zu kompliziert sei und die Prinzipien hier nicht greifen können aber als ich denen ein paar Beispiele gezeigt hatte, wie man unsere Anwendung hätte besser strukturieren können, war denen auch klar, dass sie ihren Programmierstil radikal ändern müssen und da klappt es auch. Sicherlich, sie fallen manchmal in alte Muster zurück aber das liegt auch daran, dass sie mit den Prinzipien noch nicht so ganz vertraut sind aber das wird einem blutigen Anfänger auch so ergehen.

Für dich gibt es also nur zwei Arten von Azubis: Jemand, der keine Ahnung hat, aber lernwillig ist Jemand, der Vorkenntnisse hat aber beratungsresistent ist Gutes Schubladendenken...  Ich sehe das also anders. Als Azubi muss man nicht alles kennen oder können, aber er sollte schon vor der Ausbildung wissen, auf was er sich dort einlässt. Ich habe es selbst bei meiner Assistentenausbildung gemerkt, dass viele mit falschen Vorstellungen die Ausbildung anfangen. Da sitzen echt ein Haufen Leute, die meinen, dass sie nach der Ausbildung Facebook, Apple oder Microsoft hacken können. Ein Kommilitone dachte, Objektorientierung sei sowas, was man sonst in Hollywood-Filmen sieht: Programmierung mit grafischen "Objekten", die man per Drag'n'Drop durch die Gegend schiebt. Ja, er dachte, sowas wie die Programmiersprache Scratch sei professionelle Softwareentwicklung. Er hatte bis Dato nicht mal eine Zeile Code geschrieben oder gesehen. Die meisten meiner damaligen Kommilitonen haben schon nach dem zweiten Semester das Handtuch geworfen. Wir waren ca. 80 Schüler und ganze 6 (ich war einer davon) haben später auch den Abschluss gemacht. Diejenigen, die den Abschluss gemacht hatten, hatten auch schon Vorkenntnisse. Der Rest hatte sich im Vorwege keine Gedanken drum gemacht, was es heißt, Software zu entwickeln. Sie wollten halt "irgendwas mit Computern" machen. Ich finde es schon wichtig, dass der Azubi weiß, was er will und dass Softwareentwicklung nicht heißt, dass man nur ein paar Klicks macht und schon wäre man der nächste Steve Jobs oder Bill Gates oder hätte das nächste Call of Duty entwickelt. Ich programmiere schon, seit ich 7 oder 8 Jahre alt war. Damals angefangen auf einem C64 und mir hat es auch nicht geschadet. Im Gegenteil. Vorkenntnisse können helfen, die Dinge besser zu verstehen. Mein Code sah vor der Ausbildung auch nicht besonders toll aus. Ich habe aber jeden Tipp und Hinweis von den Dozenten dankend angenommen und auch versucht, ihn sofort umzusetzen, während die anderen Kommilitonen mit den Tipps nichts anfangen konnten, weil sie noch mit ihren "if-Schleifen" beschäftigt waren und nach dem zweiten Semester immer noch Spaghetticode schrieben. Denen hat man auch schon geraten, die Ausbildung abzubrechen, weil sie mit dem Stoff nicht hinterherkommen würden. Darum unterstütze ich auch solche Projekte, wie z.B. Jugend Hackt. Dort haben Jugendliche die Möglichkeit, Tipps, Anregungen und Erfahrungen von Softwareentwicklern, Dozenten und auch von anderen Jugendlichen zu erhalten und da kommen teilweise sehr witzige Projekte bei raus. Sicherlich, der produzierte Code ist nicht erste Sahne und die Projekte sind auch nicht bis ins letzte Detail durchdacht aber das erwarte ich eigentlich auch an einem Wochenende nicht. Vielmehr haben die Projekte den Charakter eines Prototypen aber who cares? Die Jugendlichen hatten Spaß und konnten dabei auch was lernen.

Viele Firmen unterziehen sich derzeit einen Wandel, da sie gemerkt haben, dass sie mit ihren alten Firmenkulturen nicht mehr weiterkommen. Gehe mal auf Konferenzen oder oder besuche mal User groups (z.B. auf meetup) und unterhalte dich mal dort mit den Entwicklern. Entweder hast du Entwickler, die auf ein ganzes Arsenal an Technologien setzen oder Entwickler, die noch einen Monolithen mit Legacy Code schreiben aber davon weg wollen. Die klassischen Desktop-Anwendungen geraten auch immer mehr in den Hintergrund. Selbst bei der klassischen Webentwicklung mit PHP bröckelt es gerade, da sog. Single-Page-Applikationen immer mehr in den Vordergrund rutschen. Darum wird verstärkt nach Entwicklern gesucht, die eben halt schon einen gewissen Wissensstand haben. Man darf auch nicht vergessen, dass frische Studiumabsolventen sich ebenfalls auf die Junior Entwickler-Stellen bewerben und darum halte ich die Chancen für nicht allzu hoch, dass ein FISI ein Job als Junior Entwickler findet. In den Stellenangeboten steht zwar häufig "Sie haben ein Studium der Informatik oder eines vergleichbaren Studiengangs bzw. eine IT-Ausbildung absolviert." aber ein Studiumabsolvent mit Kenntnissen in der Entwicklung wird wohl eher genommen, als jemand bei dem man quasi von Null anfangen müsste. Wie gesagt, ich habe schon einige Firmen gesehen, wo man beim Vorstellungsgespräch dem Chef der Entwicklungsabteilung gegenübersitzt und dann erst mal technische Fragen beantworten muss und ich hatte mich damals auch nur als Junior-Entwickler beworben. Er kann sich ja ruhig darauf bewerben und ich wünsche ihm auch viel Glück aber große Chancen sehe ich halt nicht. Es wird zwar immer gejammert, dass die Firmen keine Leute finden aber offenbar können die Firmen es sich leisten zu warten, bis sich mal der richtige bewirbt.

Ja, und daraus entsteht Legacy Code. Die Firmen sollten schon aus wirtschaftlichen Interesse daran interessiert sein, weitestgehend idealen Code zu schreiben. Zumindest so die Theorie... Es ist auch ein Irrglaube, wenn man denkt, dass schnellgeschriebener Code günstiger sei. Die Kosten kommen dann später im Test aber Tests werden vernachlässigt, weil sie zu teuer wären und der Kunde davon nichts hat ... Also liefert man lieber Bananen-Software aus. Ich arbeite selber in so einer Firma. Unsere Software ist auch so um die 15 Jahren am Markt und inzwischen hat sie den Status "unwartbar" erreicht, weil man eben nicht darauf geachtet hat, den Code sauber zu halten. Nächstes Jahr wird angefangen, sie komplett neuzuschreiben. Die Kunden meckern inzwischen auch schon über die schlechte Softwarequalität. Eigentlich kann die Firma sich nur glücklich schätzen, dass sie in einer Nische agiert, wo es keine Konkurrenz gibt. Für die Neuentwicklung wurden 4 Jahre eingeplant. Das sind Unsummen an Geld, die man hier verpulvert, nur weil man einfach nicht sauber arbeitet. Wir haben einen gigantischen Monolithen mit zig Millonen Lines of Code und Klassen im fünfstelligen Bereich, die teilweise sogar Lines of Code im fünfstelligen Bereich haben. Bei einer Klasse muss man sogar ReSharper (ist eine .Net-Anwendung) abschalten, wenn man die Klasse anschauen möchte, weil es sonst zu Abstürzen von Visual Studio kommen kann. Unittests gibt es auch keine. Es gibt nur ein paar Integrationstests, die zwar jede Nacht laufen aber, die schlagen zu 95% fehl, weil nur einer was einchecken muss und schon stimmen die Ergebnisse nicht mehr. Obwohl ich erst seit knapp 5 Jahren als Softwareentwickler arbeite, schule ich inzwischen im Unternehmen Entwickler, die schon seit über 20 Jahren tätig sind. Das ist doch einfach falsch. Davor habe ich in einigen anderen Unternehmen als Praktikant gearbeitet und dort sah es ähnlich aus, wie in der jetzigen Firma und da frage ich mich schon, was FIAEler eigentlich lernen? Ich habe auch das Gefühl, dass man in Berufsschulen falsche Prioritäten setzt. Es ist jetzt schon ein paar Jahre her, aber in einer Firma, wo ich als Praktikant gearbeitet habe, sagte ein FIAE-Azubi, dass in seiner Berufsschule die While-Schleife weggelassen wird, weil sie zu kompliziert sei. Was ist das denn für ein Unterricht? Da ist schon die Syntax einer Sprache für die Azubis zu kompliziert und dann lässt man es einfach weg? Wie kann man denn ein guter Entwickler werden, wenn man schon essentielle Probleme mit der Syntax hat? Als Junior Entwickler hat man zwar noch nicht so viel Erfahrung aber ein gewisses Grundwissen sollte schon vorhanden sein, denn ansonsten wäre eine Ausbildung witzlos, wenn man bei einem Junior Entwickler eh von Null anfangen müsste und ihm erklären muss, was eine While-Schleife ist. Nach einer dreijährigen Ausbildung sollte man schon sein Handwerk verstehen. Zwar nicht perfekt (das erreicht man sowieso nicht) aber wenigstens in einem ausbaufähigen Stadium.

Dann läuft doch irgendwas nicht richtig. Die Fragen, die ich stellte, sind Dinge, die ich in den ersten 3 Semestern in meiner Assistentenausbildung gelernt habe. Gut, SOLID wurde explizit so nicht genannt, aber die Dozenten haben uns es so beigebracht, quasi nach SOLID zu arbeiten. Zumindest erwarte ich von einem Junior Entwickler, dass er den Unterschied zwischen Array, ArrayList und einer LinkedList kennt. Das zeigt, dass er gewisse Kenntnisse über Zeiger hat. Auch ein Junior Entwickler sollte sein Handwerk verstehen und die Interna einer Programmiersprache in Grundzügen kennen. Ich erwarte ja nicht, dass er weiß, wie ein Garbage Collector arbeitet oder wie man einen Rot-Schwarz-Baum implementiert. Zumindest vom Garbage Collector sollte er mal was gehört haben. Er sollte aber einige Design Patterns, wie z.B. Factory Methods oder Singletons kennen und nein, das sind keine hohen Anforderungen. Das sind auch Anforderungen, die viele Firmen an einen Junior Entwickler stellen. Als ich mit meiner Assistentenausbildung fertig war und Berwerbungen schrieb, wurde ich von einigen Firmen getestet, wie mein Kenntnissstand ist. Da kamen diese Fragen auf, die ich stellte. Weitere Fragen waren z.B. wieso die Klasse String in Java und C# vor Vererbung schützt sei und warum man Strings nicht konkatenieren sollte. Auch wurden einige Fragen zu Datenbanken gestellt. Wie z.B. was eine Transaktion sei oder was Indizes seien.

Naja, wenn ich ein Arbeitgeber wäre und einen Anwendungsentwickler suche, würde ich doch schon stutzig werden, wenn ein FISI sich auf die Stelle bewirbt. NIchts für ungut aber ein FISI ist doch was anderes als ein FIAE. Mag sein, dass einige es so geschafft haben aber es macht ein Unterschied, ob man nur die Syntax einer Sprache kennt und irgendwas zusammenhacken kann oder wirklich was von Softwareentwicklung versteht. Wie sieht es denn mit deinen Kenntnissen aus? Wo liegt Unterschied zwischen einem Array, ArrayList und einer LinkedList? Welche Vor- und Nachteile haben diese Datenstrukturen? Kennst du gängige Design Patterns? Was ist SOLID? Mit Welcher Sprache würdest du denn entwickeln wollen?

gelöscht

Es kommt drauf an, in welche Entgeldgruppe du eingestuft wirst. Frisch ausgelernte fangen oft in Gruppe 5 an. Das wären laut derzeitigen Stand ohne Zulage 13,41 € pro Stunde. Bei 151,67 Stunden pro Monat (35 Stunden/Woche) sind das 2.033, 89 € Brutto pro Monat und 24.406,76 € Brutto pro Jahr. Wenn jetzt eine Zeitarbeitsfirma meint, dass man in Gruppe 4 anfängt, was derzeit 11,88 € pro Stunde (ohne Zulage) wären es 21.622,07 € Brutto pro Jahr. Laut Tarifvertrag wäre es sogar denkbar, dass ein frisch ausgebildeter mit Gruppe 3 anfängt, dann wären wir bei 20.439,04 € Brutto pro Jahr aber das macht eigentlich keine Zeitarbeitsfirma, da sie genau wissen, dass andere Zeitarbeitsfirmen eine höhere Gruppe anbieten.

Wenn du aber in den Code verstehen möchtest, dann bleibt dir nichts übrig. Trau dich ruhig. Du bist ein Azubi und das wissen deine Kollegen auch. Daher werden sie dir wohl nicht den Hals umdrehen, wenn du Fragen stellst. Aller Anfang ist nun mal schwer. Auch für jemanden, der schon seit Jahren in diesem Beruf arbeitet und dann in einer neuen Firma anfängt. In der Firma, wo ich arbeite, bekommen neue Entwickler auch erstmal mehrere interne Schulungen, um die Software zu verstehen. Da geht es auch um technische Dinge, wie z.B. wie das intern entwickelte Framework funktioniert. Bei mir hat das auch ca. ein halbes Jahr gedauert, bis ich die Software weitestgehend durchdrungen habe. Außerdem hat dein Chef ja auch schon erkannt, dass du Defizite hast. Also weiß er auch, worauf er sich da einlässt. Wie gesagt, trau dich einfach, nachzufragen, wenn du nicht weiterkommst.

Es wird doch hier immer argumentiert, dass der Fachinformatiker ein halber Kaufmann wäre, weil er Kosten, Risiken, etc. abschätzen können muss aber genau das musst du in allen anderen Berufen auch und das würde ja bedeuten, dass jeder Beruf ein halber Kaufmann wäre und deshalb sage ich, dass der Fachinformatiker kein Kaufmann ist, da er auch nur über das selbe Grundwissen wie jeder andere verfügt. Ich denke, dass einigen hier die Weitsicht fehlt und nicht über ihren eigenen Tellerrand hinausschauen. Dann würden sie auch merken, dass ihr Wissen über BWL gar nicht so groß ist, wie sie wohl vermuten. Mag sein, dass im Ausbildungsrahmenplan drinnen steht, dass der Fachinformatiker über gewisse Kaufmännische Erfahrung besitzen muss aber ich kenne keine duale Ausbildung, wo in der Berufsschule nicht das BWL-Grundwissen beigebracht wird, denn wie gesagt, das benötigt jeder Beruf, denn überall geht es um die Wirtschaftlichkeit.

Das lernst du in jedem x-beliebigen Beruf auch... Das würde ja dann bedeuten, dass der Mechatroniker auch ein kaufmännischer Beruf wäre, denn er muss ja Ahnung von Lieferzeiten, Marktpreisen, Kostenschätzung und Risiken haben ... Das kannst du jetzt mit jedem Beruf fortfahren.

Ich habe Links rausgesucht. Selbst die offizielle Beschreibung zu diesem Beruf verrät nichts über kaufmännische Fähigkeiten ... Komischerweise ist das Forum die einzige Quelle, die ich finde, wo dies wie ein Berseker behauptet wird, ohne offiziellen Quellen zu nennen. Wenn das nur darauf hinausläuft, dass man irgendwelche Kosten zusammenrechnen muss, dann ist jeder Beruf ein kaufmännischer Beruf ... Ja und? Ich habe damals als Mechatroniker als Zeitarbeiter gearbeitet und musste auch Angebote einholen, Preise vergleichen und musste Aufwände einschätzen. Ist der Mechatroniker nun plötzlich auch ein kaufmännischer Beruf? Das gehört nun mal zu einem Job dazu.

Eine tolle Antwort. Im Klartext: Dir fehlen die Argumente ...

Dann zeige mir doch mal, wo es steht ... Nirgends steht das. Selbst nicht mal Fachinformatiker, die schon seit über 10 Jahren in diesem Beruf arbeiten, die ich kenne, sehen es so ...

Selbst die Arbeitsagentur erwähnt beim Fachinformatiker nicht, dass er kaufmännische Fähigkeiten benötigt. Wie gesagt, dafür gibt es den Informatikkaufmann: https://berufenet.arbeitsagentur.de/berufenet/faces/index?path=null/kurzbeschreibung&dkz=7795 https://berufenet.arbeitsagentur.de/berufenet/faces/index?path=null/kurzbeschreibung&dkz=7856 https://berufenet.arbeitsagentur.de/berufenet/faces/index?path=null/kurzbeschreibung&dkz=7847 Auch die Unicum-Unternehmensgruppe weist daraufhin, dass es nicht nur den technischen Fachinformatiker gibt, sondern auch den Informatikkaufman: http://karriere.unicum.de/berufsorientierung/berufsbilder/ausbildung-der-it-branche Ich habe damals die Zeit miterlebt, als diese Berufe entstanden, weil das damals die Zeit war, wo ich mich auf einen Ausbildungsplatz beworben habe und niemand hat damals den Fachinformatiker als einen teils kaufmännischen Beruf angesehen, sondern immer als einen technischen Beruf.

Er ist im dritten Lehrjahr. Also fast ausgebildet. Da sollte man schon die Basics kennen.

Das ist schlichtweg falsch. In jedem Beruf lernt man etwas über BWL. Das habe ich damals in meiner Mechatroniker-Ausbildung und in meiner Ausbildung als Informatik-Assistent auch getan. Also stell es bitte nicht so hin, als sei der Fachinformatiker ein halber Kaufmann, denn das stimmt einfach nicht! Der Fachinformatiker wurde als praktizierender Facharbeiter ins Leben gerufen und zwar zur Anfangszeit der damaligen Dotcom-Blase (1997), als solche Facharbeiter noch rar waren. Der Fachinformatiker sollte genau den Missstand, dass eben viele Entwickler eigentlich nur Informatikkaufmänner waren, beheben. 1997 hatte man mehrere IT-Berufsfelder gebildet, die da waren: Fachinformatiker, Informatikkaufmann, IT-Systemkaufmann und IT-Systemelektroniker. Also Techniker und Kaufmänner hatte man von Anfang an getrennt.

Du solltest erst mal ehrlich zu dir selbst sein und dich wirklich fragen, ob der Beruf etwas für dich ist. Daheim hobbymäßig etwas vor sich hinwerkelt ist was anderes, als dies hauptberuflich zu tun. Ich spreche da aus Erfahrung, da ich schon eine Depression aus diesen Gründen hinter mir habe. Was hättest du denn erwartet? Ich habe bis jetzt noch keine Softwarefirma gesehen, die wie im Bilderbuch ihre Software pflegte. Ich habe bis jetzt noch keine Firma gesehen, die ihren Code kommentierte und dokumentierte. Überall hieß es: "Der Code sei historisch gewachsen." Also mit anderen Worten: Uns war es wichtiger, dass der Code schnell zurecht gefrickelt wird. Sowas wirst du immer wieder erleben aber warum ein großes Projekt mit vielen Klassen schlecht sein soll, ist mir irgendwie nicht so klar und wieso man nach technischen Problem nicht suchen kann, ist mir auch nicht klar. Sicherlich, Google wird dir kaum sagen, wie man z.B. einen Zins- und Tilgungsplan implementiert (wie in meinem Fall) aber vielleicht sind deine Arbeitspakete noch zu groß, um gezielt nach Antworten suchen zu können. Das ist vielleicht wie bei der Antwort der Frage "nach dem Leben, dem Universum und dem ganzen Rest". Das soll jetzt nicht heißen, dass es überhaupt keine Firmen gibt, die ihren Code sauber halten aber ich habe die Erfahrung gemacht, dass dies doch eher Ausnahmen sind und wie gesagt, bis jetzt habe ich noch keine Firma gesehen, die das gemacht hat und ich habe inzwischen einige Firmen sehen dürfen. Von Startup-Firmen bis hin zu Firmen, die schon seit 20 Jahren Software entwickeln. Mag ja alles sein, dass deine jetzige Firma nicht ganz so rosig ist aber wenn ich lese, dass du doch schnell das Handtuch wirfst, wenn es Probleme gibt, habe ich doch so meine Zweifel, dass der Beruf was für dich ist. Jeder hat mal Hochs- und Tiefs aber ich habe das Gefühl, dass du die Probleme eher in der Firma suchst, anstatt bei dir selbst. Vielleicht sehe ich es auch falsch aber so kommt es mir derzeit rüber.