stefan.macke

Wir haben in unserem Einstellungstest auch ein paar "Programmieraufgaben", da viele Bewerber schon Vorkenntnisse haben und wir das berücksichtigen wollen. Aber Voraussetzung zum Antritt der Ausbildung ist das nicht. Im Gegenteil: Oft haben wir uns für Bewerber entschieden, die vorher noch gar nicht programmiert haben.
Wenn man vor der Ausbildung schon programmieren können muss (!), würde ich das als Bewerber hinterfragen. Denn es kann ja nicht Voraussetzung für eine Ausbildung sein, die dort zu vermittelnden Inhalte bereits zu beherrschen. Wenn man sich als Bewerber selbst mit der Materie auseinandersetzt, weil es Spaß macht, ist das natürlich etwas anderes.

Die ganze Geschichte mit der hybriden App ist irrelevant, wenn das hier dein einziger Use-Case ist. Daten aus einer Excel-Datei lesen und eine Art "Filter" mit einem einzigen Eingabefeld zu bauen (so interpretiere ich den Text) ist viel zu wenig. Das Ganze macht etwas den Eindruck, als solle unbedingt eine hybride App entwickelt werden (vielleicht weil das gerade super modern ist), aber die eigentliche Anforderung dahinter ist winzig. Da müsstest du dir sicher die Frage gefallen lassen, ob dieses Projekt den Aufwand wert war.

Was macht man denn bei dieser Vorbereitung? Alte Prüfungen durchgehen? Oder werden da Lehrveranstaltungen durchgeführt?

Die  Verordnung über die Berufsausbildung im Bereich der Informations- und Telekommunikationstechnik gibt dir die Antwort:

Ich hätte ein paar Punkte:
Darfst/musst du die Zeit für die Projektdokumentation mit einplanen? 3h um ein paar Attribute zu definieren? 1h um einen simplen ConnectionString zu konfigurieren? 5h für eine Kostenkalkulation? Wasserfall und agil?

Etwas OT, aber ich bin der Meinung, dass eine gute Ausbildung, auch über die Bedürfnisse des Betriebs hinaus, die beste Werbung ist, die ein Unternehmen haben kann, was seine Fachkräfte von morgen angeht.
Viele Unternehmen verschenken enorm viel Potenzial, wenn sie ihre Azubis nur als billige Arbeitskräfte missbrauchen.
Sowohl technologisch (ein gut ausgebildeter Azubi wird nach 3 Jahren ganz andere Dinge leisten können, wie ein mäßig Ausgebildeter) wie auch personalpolitisch (ein gut ausgebildeter Azubi dürfte weit lieber im Unternehmen bleiben wollen, als ein schlecht ausgebildeter).
Von daher bin ich der Überzeugung, dass Unternehmen sich gerade beim Thema Ausbildung mehr Mühe geben sollten, als es viele heutzutage tun.

Naja, ich verlange ja nicht von jedem Prüfling, mich zu belustigen. Ich möchte nur - gerade bei der Präsentation - darauf hinarbeiten, dass sich das alte Klischee von langweiligen Folien mit Ladebalken und CI endlich verändert! Du sprichst es schon an: Auf Konferenzen trägt heute niemand mehr so vor! Also warum lernen die Azubis so einen Mist!? Wo wird in Unternehmen mit Ladebalken gearbeitet? Habe ich (!) noch nie gesehen. Das scheint also auch nur für die Prüfung "gestellt" zu sein...
Ich bin in der vorteilhaften Position, dass ich seit meiner Bewerbung für die Ausbildung keine Bewerbung mehr schreiben musste. Aber ich sitze auf der Gegenseite und lese Bewerbungen. Und in beiden Fällen würde ich persönlich dafür plädieren, sich - analog zur Projektpräsentation - von der "grauen Masse" abzuheben. Und da war die Github-Idee tatsächlich ernst gemeint. Bei mir (natürlich kann ich nicht für andere sprechen) würde das sehr gut ankommen. Und wenn ich mich selbst bewerben würde, sähe dieses Dokument sicherlich auch nicht so aus wie die Anschreiben, die hier im Forum häufig diskutiert werden.
Seit meiner eigenen IHK-Präsentation 2006 habe ich alle Präsentationen so gehalten. Inkl. meiner eigenen Masterarbeit. Ich lebe diesen Stil also selbst und mache auch keine Abstriche bei Prüfungsleistungen. Ich würde sogar soweit gehen zu sagen, dass ich mich inzwischen schämen würde, wenn ich Textfolien präsentieren müsste. Das ist im beruflichen Kontext (interne Präsentationen vor Chefs usw.) genauso wie auf Konferenzen usw. Und dass dieser Stil auch bei IHK-Prüfungen sehr gut (im Sinne von 100%) ankommt, zeigen die Beispiele auf meiner Website. Sie enthalten zwar keine Star-Wars-Referenzen, aber ich würde mich nicht scheuen, solche einzubauen, wenn sie sinnvoll (!) sind. Wie ich schon schrieb: Es geht nicht um eine Belustigung, sondern um die Unterstützung der fachlichen Inhalte!
Da gebe ich dir recht. Aber es gibt ja auch viele gute Azubis, die sehr gut präsentieren können, und die ihre Folien schon von sich aus spannend gestalten. Und die möchte ich in ihrer (guten) Wahl unterstützen. Und alle anderen möchte ich zumindest anregen, mal darüber nachzudenken, ob es nicht auch anders geht.
 Genau mein Reden!
Korrekt, die Präsi ist nicht 90 Minuten lang. Aber aus eigener Erfahrung kann ich dir sagen, dass du dich definitiv um die Aufmerksamkeit der Prüfer sorgen solltest. Nach 8 Stunden Präsentationseinheitsbrei an einem vollen Prüfungstag geht die Aufmerksamkeit ganz sicher deutlich nach unten. Denn die Prüfer sind ja auch nur Menschen.

Mh... und wer sagt, dass man Sachlichkeit nicht mit Humor kombinieren darf. Warum müssen Prüfungen langweilig sein? Weil "man" das so macht? Oder weil das Gehirn langweilige Inhalte besser aufnimmt? Wenn man sein Thema beherrscht und das auch durch den Inhalt der Präsentation (ich wiederhole mich) deutlich wird, warum soll man dann nicht auch mal eine witzige Einlage bringen? Wie gesagt, es geht nicht darum, mit lustigen Folien von völliger technischer Ahnungslosigkeit abzulenken.
Ich sage auch nicht, dass jede Folie aus animierten GIFs bestehen soll (was ich durchaus schon einmal in einem - übrigens richtig coolen - Fachvortrag gesehen habe). Man sollte vielleicht einfach das richtige Maß finden. Weder nur Text und die geforderte "Sachlichkeit", noch ausschließlich lustige Bildchen. Die gute Mischung macht's!
Du schaust dir also ernsthaft gerne "sachliche" (ich übersetze das jetzt für mich einfach mit "langweilige") Präsentationen an, die dich nicht involvieren oder visuell stimulieren? Wenn das so ist, kann ich wenig dazu sagen. Über Geschmack kann man nicht streiten. Nur wenn ich mich auf den großen (technischen) Konferenzen da draußen umschaue, scheint die Mehrheit der Zuschauer stimuliert und inspiriert werden zu wollen. Und sollen wir unsere Azubis nicht auf das wahre Leben vorbereiten? Besteht der Alltag da draußen wirklich aus Textwüsten und humorlosen Präsentationen? Ich hoffe nicht! Und wenn doch, ist es - meiner Meinung nach - Zeit das zu ändern.

Du hast die <ironie>-Tags vergessen. Hoffe ich.

Richtig cool wäre natürlich auch mal, anstatt des Lebenslaufs nur den Link zum Github-Repo anzugeben
Wenn das Repo mehrere Projekte enthält, würde ich sie individuell "verlinken" bei dem jeweils dazu passenden Text. Durch den Kontext ist die Chance vielleicht höher, dass auch mal jemand reinschaut. Weist du z.B. schon im Anschreiben auf ein perfekt zum Unternehmen passendes Projekt hin, schreib direkt den Link daneben. Wenn du irgendwo deine "Skills" auflistet, kannst du das mit passenden Links untermauern. Oder falls du ein "Resume" (häufig im amerikanischen Raum verwendet) nutzt, gehören die Links direkt zu den jeweiligen "Accomplishments", um zu "beweisen", dass du das alles wirklich gemacht hast.

Wie schon so oft muss ich leider wieder dagegen halten: Kaufmännische Inhalte sind Kernbestandteil der Ausbildung zum Fachinformatiker für Anwendungsentwicklung (und auch aller anderen IT-Berufe). Auch wenn viele Forenteilnehmer das (warum auch immer) nicht wahrhaben wollen. Ob die Gewichtung sinnvoll ist, darüber lässt sich sicherlich streiten.
Welche Aussagekraft fehlt dir denn hier? Die Botschaft ist: Das Projekt amortisiert sich nach einiger Zeit und führt langfristig zu einer Kosteneinsparung im Unternehmen. Das ist doch genau die richtige Aussage, wenn die Entwicklerin in Zukunft noch ein Gehalt erwartet.
Da hast du völlig recht. Ich hätte am liebsten auch zu jedem technischen Detail etwas gelesen, aber da die Abschlussarbeit (bei unserer IHK) auf 15 Seiten beschränkt ist, war dafür leider kein Platz. In einer Bachelor- oder Masterarbeit kann man sich bestimmt intensiv mit solchen Inhalten auseinandersetzen, aber für die Projektdoku muss man einfach Abstriche machen und eine sinnvolle Auwahl der Themen treffen.
 
Dein gelungener Rant über die schlechte Ausbildung der Anwendungsentwickler ist ansonsten nett zu lesen. Allerdings ist die Berufsschule sehrwohl dafür da, die Prüflinge auf die Prüfung vorzubereiten. Clean Code mit DDD und Tests wird dann hoffentlich in den Ausbildungsunternehmen vermittelt. Dort findet der Praxisteil der Ausbildung statt.
Dass Berufsschulen im Adaptieren neuer Konzepte nicht die schnellsten sind, ist sicherlich ein Problem. Aber auf der anderen Seite müssen die Schulen auch einer Vielzahl an Schülern mit unterschiedlichem Vorwissen Grundlagen der Programmierung beibringen. Und da kann es halt ein paar Wochen dauern, bis for und if durchgekaut sind. Dass die Azubis dafür u.a. Struktogramme oder Pseudocode lernen, liegt hauptsächlich daran, dass es nicht die eine Programmiersprache gibt, die alle Azubis können müssen und die dann in der Prüfung abgefragt wird. Aber das haben wir an anderer Stelle schon ausgiebig diskutiert.
Insgesamt solltest du deine Anforderungen an die Berufsschulausbildung vielleicht etwas zurückfahren. Man sollte von einer Ausbildung nicht die gleichen Inhalte erwarten, wie von einem Studium. Wobei auch bei letzterem in den meisten Fällen DDD und Unit-Tests sicherlich kein Lehrinhalt sind. Dort wird doch teilweise noch länger der alte Kram durchgekaut. Aber das möchte ich jetzt nicht weiter vertiefen
Ich halte es auch für sehr schwierig, Lerninhalte an aktuelle Entwicklungen in der IT anzupassen. Nehmen wir mal DDD als Beispiel: Das Konzept ist schon relativ alt (Eric Evans Buch ist von 2003), aber richtig Fahrt aufgenommen hat es erst in den letzten Jahren durch Microservices usw. Wer hätte das vorhersehen und vor 5 Jahren einen entsprechenden Lehrplan aufstellen können, der heute zeitgemäß ist? Und wer sagt überhaupt, dass DDD die "richtige" Art zu programmieren ist? Was ist mit den tausenden anderen Konzepten und Ideen der Softwareentwicklung? Würdest du bei einem Automobilzulieferer C-Code nach DDD entwickeln? Huch, C kennt ja nichtmal Objektorientierung! Da muss dann wohl doch eine andere Lösung her.
Ich habe ein wenig den Eindruck, dass du deine eigenen Erfahrungen und Qualitätsstandards auf alle anderen Entwickler überträgst. Doch da die Programmiersprachen, Anforderungen, Paradigmen usw. da draußen so unterschiedlich sind, geht das leider nicht. Ein (ernstgemeinter) Ratschlag: Frag deine IHK, ob sie noch Prüfer braucht! Mit deinem Engagement bist du in der Rolle genau richtig. Dann bekommst du aber auch mal einen Einblick in die Realität vieler Betriebe da draußen und entschärfst deine Meinung vielleicht etwas. Clean Code ist ein super Konzept. Genau wie Unit-Tests und Pair Programming. Aber wenn du dich da draußen mal umschaust, wirst du feststellen, dass nur ein Bruchteil der Unternehmen diese Ideen tatsächlich umsetzt.
Mir fällt es jedenfalls nicht schwer, nachzuvollziehen, warum die Objektorientierung immer noch das vorherrschende Paradigma in der IHK-Prüfung ist (und sicherlich auch in normalen IT-Studiengängen). Man setzt halt auf bewährte grundlegende Konzepte. Die konkrete Ausgestaltung und Ausschmückung mit Frameworks, Architekturideen, Sprachfeatures usw. obliegt dann den Ausbildungsbetrieben, die passend zu ihrer Sprache und Branche die Inhalte auswählen. Und auch da wird nicht immer der neuste Kram eingesetzt, sondern sehr oft auch uralte Sprachen und Frameworks. Denn das Update auf v2.0 oder den Rewrite in Haskell bezahlt den Unternehmen leider meistens kein Kunde...

Ein paar Ansätze hatte ich hier schon mal erwähnt. z.B. das Üben von DDD, indem z.B. die Schule bzw. der Lehrer als Kunde auftritt oder auch das Üben von TDD mit sog. Code-Katas. Selbst ich treffe mich ab und zu mit ein paar anderen Entwicklern und bearbeiten eine Kata (über eine Meetup-Gruppe). Man kann da sehr viel von den anderen Entwicklern lernen, weil man andere Sichtweisen und Entwicklungsstile kennenlernt. Wenn man gewisse Regeln definiert, dann hat auch jeder mal die Tastatur vor der Nase und nicht nur die dominanten, die eh alles viel besser können. 
Auch habe ich hier gelesen, dass ein Azubi OOP beigebracht bekommt, indem er in einer WinForms-Anwendung einen Button zum Springen bringt. Was ist denn das für eine Lernmethode? Wieso eine WinForms-Anwendung? Wenn überhaupt, dann sollte man mit einer Konsolenanwendung anfangen, da bei einer Anwendung mit einer grafischen Oberfläche schon zu viel Magie passiert, die im verborgenen bleibt. Um OOP zu lernen braucht man auch keine grafische Oberfläche. Dann sollte man den Azubis erklären, was (abstrakte) Klassen, Interfaces, Generics, etc. sind und dann auch mal ein bisschen unter die Haube schauen und zeigen, wie z.B. eine Liste funktioniert anstatt sich nur mit Arrays zu befassen. Im selben Atemzug kann man vielleicht auch noch erklären, was eine Referenz bzw. ein Zeiger ist. Vielleicht auch die Problematik mit Geldbeträgen erklären, da ich das Gefühl habe, dass selbst vielen Firmen diese Problematik nicht bewusst ist. Letztes Jahr gabs dazu auf der Developer Week in Nürnberg einen Vortrag dazu und dieser Vortrag war sehr gut besucht und viele waren doch sehr erstaunt. 
Auch sollte man was sinnvolles entwickeln und keine hüpfenden Buttons. In meiner Assistenten-Ausbildung hatten wir im zweiten Semester zur Übung u.a. einen Sudoku-Löser entwickelt. Dafür hatten wir eine Woche zeit. Zum Testen gab uns der Dozent einen Satz an Unittests, die der Löser bestehen musste. Darüber hinaus gab es noch einen zweiten Satz an Unittests, der erst bei der Abgabe zum Einsatz kam. Der beinhaltete "komplexere" Testszenarien. Das zielte eben halt darauf ab, dass wir uns selbst noch Gedanken machen sollten und selbst Unittests ausdenken und auch untereinander austauschen sollten. Entwickelt wurde dann im Pair-Programming und bei der Abgabe wurden dann Fragen zu unserem Code gestellt, um herauszufinden, ob beide tatsächlich den Code verstanden haben oder ob einer nur den Vortänzer macht und den anderen hinterher schleift. Auch benutzte die Schule ein Analyse-Tool, um herauszufinden, ob vielleicht nicht zwei oder mehrere Gruppen den selben Code abgeliefert haben. Der Code wurde dann in einer Quellcodeverwaltung gepflegt.
Wie wäre es auch mit einer größeren Projektarbeit bzw. eine Art Hackerspace? Das könnte man sogar mit den FISIs verbinden.
Wie wäre es auch, wenn man einen Gastredner in die Schule holt, der einen kleinen Vortrag zu einem bestimmten Thema hält? Erst neulich habe ich ein 3 Stunden Vortrag zu Microservice in Verbindung mit RabbitMQ angeschaut. Man muss ja das Thema nicht gleich verstehen und es muss nicht gleich sofort eine Klausur darüber geschrieben werden aber es hilft schon, wenn man schon von bestimmten Themen was gehört hat, damit man im Bilde ist, was es sonst noch so für Technologien gibt. Das Ganze kann auch freiwillig sein.
Da gibt es eigentlich so viele Ideen, wie man den Berufsschulunterricht gestalten könnte aber das größte Problem ist wohl, dass die Lehrer sich selbst damit überhaupt nicht auskennen. Was ich hier manches mal lese, habe ich das Gefühl, dass sie selbst nicht einmal wissen, wovon sie eigentlich reden und nur ein altes Lehrbuch stur abarbeiten. Man müsste wohl erst mal die Lehrer stetig fortbilden, damit sie auch im Bilde sind, was in der Wirtschaft wirklich abläuft bzw. Lehrer so ausbilden, sodass sie ihr Fach auch selbst verstehen.
Ich habe ja auch nichts dagegen, wenn die Azubis auch etwas BWL lernen aber ich finde, dass hier einfach die Priorität zu hoch liegt und die eigentliche Arbeit als FIAE/FISI zu kurz kommt. Ja, ich weiß, eigentlich soll der praktische Teil in den Firmen stattfinden aber die Firmen haben oft gar nicht die Möglichkeit die Azubis optimal auszubilden, da sie oft nicht das Know-How besitzen, um einen Azubi ausgiebig zu schulen. Ich finde, Berufsschulen könnten hier echt was bewirken, um einen Blick über den Firmen-Tellerrand zu wagen aber dafür muss das Personal - sprich die Lehrer - fachkundig sein. Wenn man OOP erklären möchte, dann sollte man nicht mit hüpfenden Buttons kommen.

Ich fange anders herum an.
Ich gebe Dir nach wie vor in vielen Deiner Kritikpunkte Recht. Es wird häufig zu wenig auf Technologie, Methodik und Softwarequalität geachtet und das produziert in der Tat handfeste wirtschaftliche Nachteile. Brauchen wir nicht drüber reden und das erlebt denke ich jeder von täglich.
Nur: Was mir bei Deinen Beiträgen wenig fehlt, ist der konstruktive Ansatz. Du zählst seitenweise Missstände auf, mit welchen Du Dich "gefühlt jeden Tag" rumplagen darfst. Das ist gut und richtig. Aber wo sind die Lösungsansätze? Wie willst Du es besser machen?
"Neu machen" ist eine Lösung, aber in sehr vielen Fällen nicht praktikabel. Weder kann man die ganze IT Ausbildung von heute auf Morgen auf den Kopf stellen, noch 20 Jahre gewachsene Software eines Unternehmens über den Haufen werfen.
Wo ist also Deine Idee, Deine Vision wie es besser geht? Sprich: Der Kern Deiner Kritik.
Was müsste wer tun, damit Du zufrieden wärst?

Ich gebe @Whiz-zarD grundsätzlich in vielen Teilen Recht.
Allerdings geht er für mich zu weit und verliert das Augenmaß.
IT ist im Regelfall kein Selbstzweck sondern in erster Linie Erfüllungsgehilfe für andere Abteilungen von Unternehmen. Heute kann man auch mit IT selbst Geld verdienen, keine Frage, aber das sind zahlenmäßig die Ausnahmen. Gerade bei uns in Deutschland. Hier ist IT dazu da, die Verwaltung, die Buchhaltung, die Fertigung, das Lager und andere Abteilungen zu unterstützen bzw. zu automatisieren.
...
Wo ich Whizzard Recht gebe:
In der Tat wird während der Ausbildung zu wenig Wert auf aktuelle Technologien, Konzepte, technischen Background, ordentliche Präsentationen, usw. gelegt. Das war zu meiner Zeit (2004) schon so. Da hieß es im Betrieb salopp "Hier. Für XXX brauchen wir ein Programm. Mach mal fertig." und in der Schule "Das ist eine For-Schleife". Das dort am Ende keine High End Developer bei raus kommen sollte klar sein.
Heute ist das - leider - in weiten Teilen von Unternehmen und Schulen nicht groß anders, was ich so mitbekomme. Das ist in der Tat schade. Deswegen versuche ich unseren Azubis mehr an die Hand zu geben, wie es mir zu meiner Zeit wurde. Soweit gehe ich konform mit seiner Kritik. Mehr Kompetenz in diesen Bereichen wäre im Interesse aller.
...
ABER:
Klar sollte jedoch auch sein, dass man diese Kritik nicht zum Maßstab erheben kann.
Weder haben die meisten Unternehmen das nötige Knoff Hoff, noch haben sie überhaupt das nötige Umfeld (Kunden, Branchen, Verträge, usw.) um diese Dinge umsetzen zu können.
Wenn ich ein klassischer Software-Hersteller bin, der eine Standardsoftware programmiert, dann möchte ich diese weder alle 3 Jahre neu programmieren, noch möchte ich das Modul A prozedural, Modul B objektorientiert und Modul C nach DDD entwickelt wurde. In solchen Betrieben mag es für die Azubis schade sein, weil sie einiges verpassen, aber für das Unternehmen ist es verständlich, dass man lieber bei seiner Klassenbasierten halb-objektorientierten halb-prozeduralen Programmierung in C++ von anno 2000 bleibt, weil das bis heute die Code-Basis für das Produkt stellt.
Ähnliches, wenn Du Industrie-Anlagen programmierst. Die werden ebenfalls nicht alle 3 Jahre gewechselt. Oder Software für ein Auto-Bestandteil schreibst, Verwaltungssoftware für einen Konzern, etc. pp. In all diesen Bereichen gibt es Fristen und eine Haltbarkeit welche weitaus größer sind, wie die Intervalle, in welchen technische IT-Konzepte en vogue sind.
Gleichzeitig stellen diese Arten von Entwicklung aber Mengen-, Arbeitsplatz-, und finanziell gesehen den größten Teil der Software-Entwicklung in Deutschland. Da ist es verständlich, dass die IHK und auch die Universitäten hier nicht auf jeden modernen Zug aufspringen, sondern das unterrichten, was in weiten Teilen der Betriebe Praxis ist.
Die Universitäten / Fachhochschulen möchte ich hier allerdings etwas ausnehmen. Die sind in den meisten Fällen näher an der Zeit und Technik wie die IHK. Ein Studium ist und bleibt schlussendlich doch was anderes, wie eine Ausbildung.
...
Auch für die BWL-Anteile in der Ausbildung möchte ich eine Lanze brechen.
So nervig sie auch sein mögen, so wichtig sind diese Themen. Wie wir alle habe ich in meiner Laufbahn mehr wie einen "Fachidioten" kennen gelernt. Kollegen, welche gut programmieren konnten, aber keinen Blick für das drum herum hatten. Weder für die Kosten noch für den Sinn und Zweck dessen, was sie da tun.
Da nützt es nix, dass diese Kollegen prächtigen Code schreiben können, wenn die Dauer der Entwicklung die veranschlagte überschreiten, die Funktionalitäten nicht den Gewünschten entsprechen, oder der Entwickler später gar nicht versteht, wofür das Ganze eigentlich gedacht war und wie die Bedürfnisse des Anwenders sind.
Wie weiter oben erwähnt, ist der Großteil der IT - gerade in Deutschland - kein Selbstzweck, sondern Erfüllungsgehilfe für Industrie, Verwaltung und Co. Dementsprechend ist es wichtig, dass auch die IT das kleine 1x1 dieser Branchen versteht.
...
Von daher, als Fazit:
Ich kann verstehen, wenn Anwendungsentwickler darüber schimpfen, dass zu wenig in Schule und Unternehmen vermittelt wird. Da geht auch meiner Meinung nach eine Menge technisches Potenzial verloren, gerade auch für den Technologie-Standort Deutschland insgesamt.
Auf der anderen Seite is genau das für viele Bereich jedoch schlicht irrelevant. Da brauch man Leute, welche 08/15 Anforderungen in 08/15 Codes zu einem 08/15 Gehalt umsetzen können und das wars. Nicht umsonst werden Junior-Developer in den Stellenanzeigen der Online-Börsen gesucht wie der heilige Gral, während Senior Developer spürbar seltener gefragt sind.

Ich sehe schon, wir kommen nicht zusammen. Aber trotzdem muss ich ein paar Kommentare loswerden.
Es geht hier nicht nur um diese kleinen Firmen. Eine wirtschaftliche Betrachtung seiner Arbeit erwarte ich von jedem Anwendungsentwickler. Das krasse Gegenteil wäre nämlich der Tod für jedes Business: "Komm, wir programmieren einfach unser eigenes ORM. Microsoft hat unseren ganz speziellen Fall leider nicht im EF abgedeckt." "Was, dafür soll ich ein simples Excel-Makro verwenden, das in 15 Minuten zusammengeklickt ist? Nein, ich entwickle eine coole GUI in C# mit Office-Integration! Dauert max. 2 Wochen!" Und nichts anderes ist die Kosten-/Amortisationsrechnung in den Projektdokus. Die Prüflinge sollen sich bewusst werden, dass ihre Arbeit und ihre Entscheidungen das Unternehmen Geld kosten.
Wenn deinem Chef die Aussage "Geht schneller. Lohnt sich!" reicht, ist das ok. Mit vernünftiger Begründung hat das aber wenig zu tun. Wenn das "kleine Azubiprojekt" sich erst nach fünf Jahren amortisiert, sieht die Welt vielleicht schon ganz anders aus.
Das stimmt. Dann wären es aber leider auch keine 100% geworden
Da ich die Arbeit betreut habe: Ja, das war ihr klar. Und ich hoffe, dass andere Unternehmen das auch vermitteln.
Ich vermittle diese Inhalte meinen Azubis zwar, könnte aber in der Praxis (!) durchaus damit leben, wenn sie es nicht wüssten. Denn die genannten Optimierungen sind für 99% des Tagesgeschäfts nicht relevant. Bei einer Liste mit 100 Elementen interessiert sich niemand für die Nanosekunde weniger Laufzeit. Und irgendetwas muss ja auch noch für das Studium übrig bleiben. Seltsam, dass du noch nicht die O(n)-Notation gefordert hast
Das sehe ich genauso. Ich lasse in meiner Programmiereinführung auch immer eine verkettete Liste programmieren. Die Frage nach der Praxisrelevanz habe ich allerdings schon oben beantwortet.
Das "genauso gut" stelle ich mal zur Diskussion. Meiner Meinung nach ist der Fokus auf die OOP beim DDD schon deutlich zu spüren. Aber selbstverständlich gibt es ein paar grundlegende Konzepte, die auch mit anderen Paradigmen umgesetzt werden können.
Da bin ich völlig dabei. Ich fände es auch klasse, wenn moderne Inhalte in der Berufsschule gelehrt würden. Daran können wir aber leider wenig ändern. Ich hoffe, dass sich viele Azubis, die diesen Thread lesen, ein Beispiel daran nehmen und auf eigene Faust neue Sachen ausprobieren.
Ich glaube nicht, dass hier jemand sagt, dass diese Inhalte nicht gelehrt werden sollen. In der Praxis ist das nur leider sehr selten der Fall. Und zwar in der Schule wie in den Betrieben. Ich selbst lehre beides - sowohl im Unternehmen, als auch in meinen Vorlesungen. Eine andere Sache ist, diese Inhalte als allgemeingültig vorauszusetzen und in einer bundesweit einheitlichen Abschlussprüfung (ja, sorry Baden-Württemberg) abzufragen.
Da bist du meiner Meinung nach wohl etwas in deiner Welt gefangen. Schau dich mal in anderen Branchen (Versicherung, Bank, Automobil, öffentlicher Sektor usw.) um. Da wirst du ohne Pflichtenheft nicht weit kommen. Und Scrum ist auch bei Weitem noch nicht so etabliert wie man meinen könnte. Ich selbst habe jedes Jahr wieder Studierende aus großen und kleinen Unternehmen, die weder Scrum, XP, Unit-Tests oder DDD je gehört haben.
Das ist ein Problem des Dozenten. In einem vernünftigen Unterricht wird "ganz unten" angefangen. So kenne ich das auch aus Berufsschulen, Vorlesungen und der Ausbildung. Aber es ist in der Praxis wohl leider alles vertreten, was man sich vorstellen kann.
Hehe Der kaufmännische Anteil stört dich offensichtlich wirklich. Ich weiß aber gar nicht genau warum. Hast du so schlechte Erfahrungen mit ausgelernten FIAEs gemacht? Konnten die alle nur rechnen und nicht programmieren?
 
Ich fasse nochmal zusammen: Es gibt gute und schlechte Berufsschulen, Ausbilder/innen, Unternehmen, Studiengänge. Manche Azubis können schnell lernen, andere langsamer. Mancher findet die wirtschaftlichen Aspekte wichtig, mancher nicht. Solange die Voraussetzungen des Berufs so sind wie sie sind, können wir nur unser Bestes tun, um die Azubis auf die Prüfung vorzubereiten. Immerhin ist vor Kurzem eine Umfrage zur Neuausrichtung der IT-Berufe gestartet worden. Und wenn die Mühlen der Bürokratie schnell mahlen, können wir uns vielleicht schon zu 2025 auf einen eher technischen FIAE freuen. Bis dahin lasse ich meine Azubis weiterhin eine Amortisationsrechnung durchführen

Wie schon so oft muss ich leider wieder dagegen halten: Kaufmännische Inhalte sind Kernbestandteil der Ausbildung zum Fachinformatiker für Anwendungsentwicklung (und auch aller anderen IT-Berufe). Auch wenn viele Forenteilnehmer das (warum auch immer) nicht wahrhaben wollen. Ob die Gewichtung sinnvoll ist, darüber lässt sich sicherlich streiten.
Welche Aussagekraft fehlt dir denn hier? Die Botschaft ist: Das Projekt amortisiert sich nach einiger Zeit und führt langfristig zu einer Kosteneinsparung im Unternehmen. Das ist doch genau die richtige Aussage, wenn die Entwicklerin in Zukunft noch ein Gehalt erwartet.
Da hast du völlig recht. Ich hätte am liebsten auch zu jedem technischen Detail etwas gelesen, aber da die Abschlussarbeit (bei unserer IHK) auf 15 Seiten beschränkt ist, war dafür leider kein Platz. In einer Bachelor- oder Masterarbeit kann man sich bestimmt intensiv mit solchen Inhalten auseinandersetzen, aber für die Projektdoku muss man einfach Abstriche machen und eine sinnvolle Auwahl der Themen treffen.
 
Dein gelungener Rant über die schlechte Ausbildung der Anwendungsentwickler ist ansonsten nett zu lesen. Allerdings ist die Berufsschule sehrwohl dafür da, die Prüflinge auf die Prüfung vorzubereiten. Clean Code mit DDD und Tests wird dann hoffentlich in den Ausbildungsunternehmen vermittelt. Dort findet der Praxisteil der Ausbildung statt.
Dass Berufsschulen im Adaptieren neuer Konzepte nicht die schnellsten sind, ist sicherlich ein Problem. Aber auf der anderen Seite müssen die Schulen auch einer Vielzahl an Schülern mit unterschiedlichem Vorwissen Grundlagen der Programmierung beibringen. Und da kann es halt ein paar Wochen dauern, bis for und if durchgekaut sind. Dass die Azubis dafür u.a. Struktogramme oder Pseudocode lernen, liegt hauptsächlich daran, dass es nicht die eine Programmiersprache gibt, die alle Azubis können müssen und die dann in der Prüfung abgefragt wird. Aber das haben wir an anderer Stelle schon ausgiebig diskutiert.
Insgesamt solltest du deine Anforderungen an die Berufsschulausbildung vielleicht etwas zurückfahren. Man sollte von einer Ausbildung nicht die gleichen Inhalte erwarten, wie von einem Studium. Wobei auch bei letzterem in den meisten Fällen DDD und Unit-Tests sicherlich kein Lehrinhalt sind. Dort wird doch teilweise noch länger der alte Kram durchgekaut. Aber das möchte ich jetzt nicht weiter vertiefen
Ich halte es auch für sehr schwierig, Lerninhalte an aktuelle Entwicklungen in der IT anzupassen. Nehmen wir mal DDD als Beispiel: Das Konzept ist schon relativ alt (Eric Evans Buch ist von 2003), aber richtig Fahrt aufgenommen hat es erst in den letzten Jahren durch Microservices usw. Wer hätte das vorhersehen und vor 5 Jahren einen entsprechenden Lehrplan aufstellen können, der heute zeitgemäß ist? Und wer sagt überhaupt, dass DDD die "richtige" Art zu programmieren ist? Was ist mit den tausenden anderen Konzepten und Ideen der Softwareentwicklung? Würdest du bei einem Automobilzulieferer C-Code nach DDD entwickeln? Huch, C kennt ja nichtmal Objektorientierung! Da muss dann wohl doch eine andere Lösung her.
Ich habe ein wenig den Eindruck, dass du deine eigenen Erfahrungen und Qualitätsstandards auf alle anderen Entwickler überträgst. Doch da die Programmiersprachen, Anforderungen, Paradigmen usw. da draußen so unterschiedlich sind, geht das leider nicht. Ein (ernstgemeinter) Ratschlag: Frag deine IHK, ob sie noch Prüfer braucht! Mit deinem Engagement bist du in der Rolle genau richtig. Dann bekommst du aber auch mal einen Einblick in die Realität vieler Betriebe da draußen und entschärfst deine Meinung vielleicht etwas. Clean Code ist ein super Konzept. Genau wie Unit-Tests und Pair Programming. Aber wenn du dich da draußen mal umschaust, wirst du feststellen, dass nur ein Bruchteil der Unternehmen diese Ideen tatsächlich umsetzt.
Mir fällt es jedenfalls nicht schwer, nachzuvollziehen, warum die Objektorientierung immer noch das vorherrschende Paradigma in der IHK-Prüfung ist (und sicherlich auch in normalen IT-Studiengängen). Man setzt halt auf bewährte grundlegende Konzepte. Die konkrete Ausgestaltung und Ausschmückung mit Frameworks, Architekturideen, Sprachfeatures usw. obliegt dann den Ausbildungsbetrieben, die passend zu ihrer Sprache und Branche die Inhalte auswählen. Und auch da wird nicht immer der neuste Kram eingesetzt, sondern sehr oft auch uralte Sprachen und Frameworks. Denn das Update auf v2.0 oder den Rewrite in Haskell bezahlt den Unternehmen leider meistens kein Kunde...

Ich sehe schon, wir kommen nicht zusammen. Aber trotzdem muss ich ein paar Kommentare loswerden.
Es geht hier nicht nur um diese kleinen Firmen. Eine wirtschaftliche Betrachtung seiner Arbeit erwarte ich von jedem Anwendungsentwickler. Das krasse Gegenteil wäre nämlich der Tod für jedes Business: "Komm, wir programmieren einfach unser eigenes ORM. Microsoft hat unseren ganz speziellen Fall leider nicht im EF abgedeckt." "Was, dafür soll ich ein simples Excel-Makro verwenden, das in 15 Minuten zusammengeklickt ist? Nein, ich entwickle eine coole GUI in C# mit Office-Integration! Dauert max. 2 Wochen!" Und nichts anderes ist die Kosten-/Amortisationsrechnung in den Projektdokus. Die Prüflinge sollen sich bewusst werden, dass ihre Arbeit und ihre Entscheidungen das Unternehmen Geld kosten.
Wenn deinem Chef die Aussage "Geht schneller. Lohnt sich!" reicht, ist das ok. Mit vernünftiger Begründung hat das aber wenig zu tun. Wenn das "kleine Azubiprojekt" sich erst nach fünf Jahren amortisiert, sieht die Welt vielleicht schon ganz anders aus.
Das stimmt. Dann wären es aber leider auch keine 100% geworden
Da ich die Arbeit betreut habe: Ja, das war ihr klar. Und ich hoffe, dass andere Unternehmen das auch vermitteln.
Ich vermittle diese Inhalte meinen Azubis zwar, könnte aber in der Praxis (!) durchaus damit leben, wenn sie es nicht wüssten. Denn die genannten Optimierungen sind für 99% des Tagesgeschäfts nicht relevant. Bei einer Liste mit 100 Elementen interessiert sich niemand für die Nanosekunde weniger Laufzeit. Und irgendetwas muss ja auch noch für das Studium übrig bleiben. Seltsam, dass du noch nicht die O(n)-Notation gefordert hast
Das sehe ich genauso. Ich lasse in meiner Programmiereinführung auch immer eine verkettete Liste programmieren. Die Frage nach der Praxisrelevanz habe ich allerdings schon oben beantwortet.
Das "genauso gut" stelle ich mal zur Diskussion. Meiner Meinung nach ist der Fokus auf die OOP beim DDD schon deutlich zu spüren. Aber selbstverständlich gibt es ein paar grundlegende Konzepte, die auch mit anderen Paradigmen umgesetzt werden können.
Da bin ich völlig dabei. Ich fände es auch klasse, wenn moderne Inhalte in der Berufsschule gelehrt würden. Daran können wir aber leider wenig ändern. Ich hoffe, dass sich viele Azubis, die diesen Thread lesen, ein Beispiel daran nehmen und auf eigene Faust neue Sachen ausprobieren.
Ich glaube nicht, dass hier jemand sagt, dass diese Inhalte nicht gelehrt werden sollen. In der Praxis ist das nur leider sehr selten der Fall. Und zwar in der Schule wie in den Betrieben. Ich selbst lehre beides - sowohl im Unternehmen, als auch in meinen Vorlesungen. Eine andere Sache ist, diese Inhalte als allgemeingültig vorauszusetzen und in einer bundesweit einheitlichen Abschlussprüfung (ja, sorry Baden-Württemberg) abzufragen.
Da bist du meiner Meinung nach wohl etwas in deiner Welt gefangen. Schau dich mal in anderen Branchen (Versicherung, Bank, Automobil, öffentlicher Sektor usw.) um. Da wirst du ohne Pflichtenheft nicht weit kommen. Und Scrum ist auch bei Weitem noch nicht so etabliert wie man meinen könnte. Ich selbst habe jedes Jahr wieder Studierende aus großen und kleinen Unternehmen, die weder Scrum, XP, Unit-Tests oder DDD je gehört haben.
Das ist ein Problem des Dozenten. In einem vernünftigen Unterricht wird "ganz unten" angefangen. So kenne ich das auch aus Berufsschulen, Vorlesungen und der Ausbildung. Aber es ist in der Praxis wohl leider alles vertreten, was man sich vorstellen kann.
Hehe Der kaufmännische Anteil stört dich offensichtlich wirklich. Ich weiß aber gar nicht genau warum. Hast du so schlechte Erfahrungen mit ausgelernten FIAEs gemacht? Konnten die alle nur rechnen und nicht programmieren?
 
Ich fasse nochmal zusammen: Es gibt gute und schlechte Berufsschulen, Ausbilder/innen, Unternehmen, Studiengänge. Manche Azubis können schnell lernen, andere langsamer. Mancher findet die wirtschaftlichen Aspekte wichtig, mancher nicht. Solange die Voraussetzungen des Berufs so sind wie sie sind, können wir nur unser Bestes tun, um die Azubis auf die Prüfung vorzubereiten. Immerhin ist vor Kurzem eine Umfrage zur Neuausrichtung der IT-Berufe gestartet worden. Und wenn die Mühlen der Bürokratie schnell mahlen, können wir uns vielleicht schon zu 2025 auf einen eher technischen FIAE freuen. Bis dahin lasse ich meine Azubis weiterhin eine Amortisationsrechnung durchführen

Ich sehe schon, wir kommen nicht zusammen. Aber trotzdem muss ich ein paar Kommentare loswerden.
Es geht hier nicht nur um diese kleinen Firmen. Eine wirtschaftliche Betrachtung seiner Arbeit erwarte ich von jedem Anwendungsentwickler. Das krasse Gegenteil wäre nämlich der Tod für jedes Business: "Komm, wir programmieren einfach unser eigenes ORM. Microsoft hat unseren ganz speziellen Fall leider nicht im EF abgedeckt." "Was, dafür soll ich ein simples Excel-Makro verwenden, das in 15 Minuten zusammengeklickt ist? Nein, ich entwickle eine coole GUI in C# mit Office-Integration! Dauert max. 2 Wochen!" Und nichts anderes ist die Kosten-/Amortisationsrechnung in den Projektdokus. Die Prüflinge sollen sich bewusst werden, dass ihre Arbeit und ihre Entscheidungen das Unternehmen Geld kosten.
Wenn deinem Chef die Aussage "Geht schneller. Lohnt sich!" reicht, ist das ok. Mit vernünftiger Begründung hat das aber wenig zu tun. Wenn das "kleine Azubiprojekt" sich erst nach fünf Jahren amortisiert, sieht die Welt vielleicht schon ganz anders aus.
Das stimmt. Dann wären es aber leider auch keine 100% geworden
Da ich die Arbeit betreut habe: Ja, das war ihr klar. Und ich hoffe, dass andere Unternehmen das auch vermitteln.
Ich vermittle diese Inhalte meinen Azubis zwar, könnte aber in der Praxis (!) durchaus damit leben, wenn sie es nicht wüssten. Denn die genannten Optimierungen sind für 99% des Tagesgeschäfts nicht relevant. Bei einer Liste mit 100 Elementen interessiert sich niemand für die Nanosekunde weniger Laufzeit. Und irgendetwas muss ja auch noch für das Studium übrig bleiben. Seltsam, dass du noch nicht die O(n)-Notation gefordert hast
Das sehe ich genauso. Ich lasse in meiner Programmiereinführung auch immer eine verkettete Liste programmieren. Die Frage nach der Praxisrelevanz habe ich allerdings schon oben beantwortet.
Das "genauso gut" stelle ich mal zur Diskussion. Meiner Meinung nach ist der Fokus auf die OOP beim DDD schon deutlich zu spüren. Aber selbstverständlich gibt es ein paar grundlegende Konzepte, die auch mit anderen Paradigmen umgesetzt werden können.
Da bin ich völlig dabei. Ich fände es auch klasse, wenn moderne Inhalte in der Berufsschule gelehrt würden. Daran können wir aber leider wenig ändern. Ich hoffe, dass sich viele Azubis, die diesen Thread lesen, ein Beispiel daran nehmen und auf eigene Faust neue Sachen ausprobieren.
Ich glaube nicht, dass hier jemand sagt, dass diese Inhalte nicht gelehrt werden sollen. In der Praxis ist das nur leider sehr selten der Fall. Und zwar in der Schule wie in den Betrieben. Ich selbst lehre beides - sowohl im Unternehmen, als auch in meinen Vorlesungen. Eine andere Sache ist, diese Inhalte als allgemeingültig vorauszusetzen und in einer bundesweit einheitlichen Abschlussprüfung (ja, sorry Baden-Württemberg) abzufragen.
Da bist du meiner Meinung nach wohl etwas in deiner Welt gefangen. Schau dich mal in anderen Branchen (Versicherung, Bank, Automobil, öffentlicher Sektor usw.) um. Da wirst du ohne Pflichtenheft nicht weit kommen. Und Scrum ist auch bei Weitem noch nicht so etabliert wie man meinen könnte. Ich selbst habe jedes Jahr wieder Studierende aus großen und kleinen Unternehmen, die weder Scrum, XP, Unit-Tests oder DDD je gehört haben.
Das ist ein Problem des Dozenten. In einem vernünftigen Unterricht wird "ganz unten" angefangen. So kenne ich das auch aus Berufsschulen, Vorlesungen und der Ausbildung. Aber es ist in der Praxis wohl leider alles vertreten, was man sich vorstellen kann.
Hehe Der kaufmännische Anteil stört dich offensichtlich wirklich. Ich weiß aber gar nicht genau warum. Hast du so schlechte Erfahrungen mit ausgelernten FIAEs gemacht? Konnten die alle nur rechnen und nicht programmieren?
 
Ich fasse nochmal zusammen: Es gibt gute und schlechte Berufsschulen, Ausbilder/innen, Unternehmen, Studiengänge. Manche Azubis können schnell lernen, andere langsamer. Mancher findet die wirtschaftlichen Aspekte wichtig, mancher nicht. Solange die Voraussetzungen des Berufs so sind wie sie sind, können wir nur unser Bestes tun, um die Azubis auf die Prüfung vorzubereiten. Immerhin ist vor Kurzem eine Umfrage zur Neuausrichtung der IT-Berufe gestartet worden. Und wenn die Mühlen der Bürokratie schnell mahlen, können wir uns vielleicht schon zu 2025 auf einen eher technischen FIAE freuen. Bis dahin lasse ich meine Azubis weiterhin eine Amortisationsrechnung durchführen

Ich sehe schon, wir kommen nicht zusammen. Aber trotzdem muss ich ein paar Kommentare loswerden.
Es geht hier nicht nur um diese kleinen Firmen. Eine wirtschaftliche Betrachtung seiner Arbeit erwarte ich von jedem Anwendungsentwickler. Das krasse Gegenteil wäre nämlich der Tod für jedes Business: "Komm, wir programmieren einfach unser eigenes ORM. Microsoft hat unseren ganz speziellen Fall leider nicht im EF abgedeckt." "Was, dafür soll ich ein simples Excel-Makro verwenden, das in 15 Minuten zusammengeklickt ist? Nein, ich entwickle eine coole GUI in C# mit Office-Integration! Dauert max. 2 Wochen!" Und nichts anderes ist die Kosten-/Amortisationsrechnung in den Projektdokus. Die Prüflinge sollen sich bewusst werden, dass ihre Arbeit und ihre Entscheidungen das Unternehmen Geld kosten.
Wenn deinem Chef die Aussage "Geht schneller. Lohnt sich!" reicht, ist das ok. Mit vernünftiger Begründung hat das aber wenig zu tun. Wenn das "kleine Azubiprojekt" sich erst nach fünf Jahren amortisiert, sieht die Welt vielleicht schon ganz anders aus.
Das stimmt. Dann wären es aber leider auch keine 100% geworden
Da ich die Arbeit betreut habe: Ja, das war ihr klar. Und ich hoffe, dass andere Unternehmen das auch vermitteln.
Ich vermittle diese Inhalte meinen Azubis zwar, könnte aber in der Praxis (!) durchaus damit leben, wenn sie es nicht wüssten. Denn die genannten Optimierungen sind für 99% des Tagesgeschäfts nicht relevant. Bei einer Liste mit 100 Elementen interessiert sich niemand für die Nanosekunde weniger Laufzeit. Und irgendetwas muss ja auch noch für das Studium übrig bleiben. Seltsam, dass du noch nicht die O(n)-Notation gefordert hast
Das sehe ich genauso. Ich lasse in meiner Programmiereinführung auch immer eine verkettete Liste programmieren. Die Frage nach der Praxisrelevanz habe ich allerdings schon oben beantwortet.
Das "genauso gut" stelle ich mal zur Diskussion. Meiner Meinung nach ist der Fokus auf die OOP beim DDD schon deutlich zu spüren. Aber selbstverständlich gibt es ein paar grundlegende Konzepte, die auch mit anderen Paradigmen umgesetzt werden können.
Da bin ich völlig dabei. Ich fände es auch klasse, wenn moderne Inhalte in der Berufsschule gelehrt würden. Daran können wir aber leider wenig ändern. Ich hoffe, dass sich viele Azubis, die diesen Thread lesen, ein Beispiel daran nehmen und auf eigene Faust neue Sachen ausprobieren.
Ich glaube nicht, dass hier jemand sagt, dass diese Inhalte nicht gelehrt werden sollen. In der Praxis ist das nur leider sehr selten der Fall. Und zwar in der Schule wie in den Betrieben. Ich selbst lehre beides - sowohl im Unternehmen, als auch in meinen Vorlesungen. Eine andere Sache ist, diese Inhalte als allgemeingültig vorauszusetzen und in einer bundesweit einheitlichen Abschlussprüfung (ja, sorry Baden-Württemberg) abzufragen.
Da bist du meiner Meinung nach wohl etwas in deiner Welt gefangen. Schau dich mal in anderen Branchen (Versicherung, Bank, Automobil, öffentlicher Sektor usw.) um. Da wirst du ohne Pflichtenheft nicht weit kommen. Und Scrum ist auch bei Weitem noch nicht so etabliert wie man meinen könnte. Ich selbst habe jedes Jahr wieder Studierende aus großen und kleinen Unternehmen, die weder Scrum, XP, Unit-Tests oder DDD je gehört haben.
Das ist ein Problem des Dozenten. In einem vernünftigen Unterricht wird "ganz unten" angefangen. So kenne ich das auch aus Berufsschulen, Vorlesungen und der Ausbildung. Aber es ist in der Praxis wohl leider alles vertreten, was man sich vorstellen kann.
Hehe Der kaufmännische Anteil stört dich offensichtlich wirklich. Ich weiß aber gar nicht genau warum. Hast du so schlechte Erfahrungen mit ausgelernten FIAEs gemacht? Konnten die alle nur rechnen und nicht programmieren?
 
Ich fasse nochmal zusammen: Es gibt gute und schlechte Berufsschulen, Ausbilder/innen, Unternehmen, Studiengänge. Manche Azubis können schnell lernen, andere langsamer. Mancher findet die wirtschaftlichen Aspekte wichtig, mancher nicht. Solange die Voraussetzungen des Berufs so sind wie sie sind, können wir nur unser Bestes tun, um die Azubis auf die Prüfung vorzubereiten. Immerhin ist vor Kurzem eine Umfrage zur Neuausrichtung der IT-Berufe gestartet worden. Und wenn die Mühlen der Bürokratie schnell mahlen, können wir uns vielleicht schon zu 2025 auf einen eher technischen FIAE freuen. Bis dahin lasse ich meine Azubis weiterhin eine Amortisationsrechnung durchführen

Wie schon so oft muss ich leider wieder dagegen halten: Kaufmännische Inhalte sind Kernbestandteil der Ausbildung zum Fachinformatiker für Anwendungsentwicklung (und auch aller anderen IT-Berufe). Auch wenn viele Forenteilnehmer das (warum auch immer) nicht wahrhaben wollen. Ob die Gewichtung sinnvoll ist, darüber lässt sich sicherlich streiten.
Welche Aussagekraft fehlt dir denn hier? Die Botschaft ist: Das Projekt amortisiert sich nach einiger Zeit und führt langfristig zu einer Kosteneinsparung im Unternehmen. Das ist doch genau die richtige Aussage, wenn die Entwicklerin in Zukunft noch ein Gehalt erwartet.
Da hast du völlig recht. Ich hätte am liebsten auch zu jedem technischen Detail etwas gelesen, aber da die Abschlussarbeit (bei unserer IHK) auf 15 Seiten beschränkt ist, war dafür leider kein Platz. In einer Bachelor- oder Masterarbeit kann man sich bestimmt intensiv mit solchen Inhalten auseinandersetzen, aber für die Projektdoku muss man einfach Abstriche machen und eine sinnvolle Auwahl der Themen treffen.
 
Dein gelungener Rant über die schlechte Ausbildung der Anwendungsentwickler ist ansonsten nett zu lesen. Allerdings ist die Berufsschule sehrwohl dafür da, die Prüflinge auf die Prüfung vorzubereiten. Clean Code mit DDD und Tests wird dann hoffentlich in den Ausbildungsunternehmen vermittelt. Dort findet der Praxisteil der Ausbildung statt.
Dass Berufsschulen im Adaptieren neuer Konzepte nicht die schnellsten sind, ist sicherlich ein Problem. Aber auf der anderen Seite müssen die Schulen auch einer Vielzahl an Schülern mit unterschiedlichem Vorwissen Grundlagen der Programmierung beibringen. Und da kann es halt ein paar Wochen dauern, bis for und if durchgekaut sind. Dass die Azubis dafür u.a. Struktogramme oder Pseudocode lernen, liegt hauptsächlich daran, dass es nicht die eine Programmiersprache gibt, die alle Azubis können müssen und die dann in der Prüfung abgefragt wird. Aber das haben wir an anderer Stelle schon ausgiebig diskutiert.
Insgesamt solltest du deine Anforderungen an die Berufsschulausbildung vielleicht etwas zurückfahren. Man sollte von einer Ausbildung nicht die gleichen Inhalte erwarten, wie von einem Studium. Wobei auch bei letzterem in den meisten Fällen DDD und Unit-Tests sicherlich kein Lehrinhalt sind. Dort wird doch teilweise noch länger der alte Kram durchgekaut. Aber das möchte ich jetzt nicht weiter vertiefen
Ich halte es auch für sehr schwierig, Lerninhalte an aktuelle Entwicklungen in der IT anzupassen. Nehmen wir mal DDD als Beispiel: Das Konzept ist schon relativ alt (Eric Evans Buch ist von 2003), aber richtig Fahrt aufgenommen hat es erst in den letzten Jahren durch Microservices usw. Wer hätte das vorhersehen und vor 5 Jahren einen entsprechenden Lehrplan aufstellen können, der heute zeitgemäß ist? Und wer sagt überhaupt, dass DDD die "richtige" Art zu programmieren ist? Was ist mit den tausenden anderen Konzepten und Ideen der Softwareentwicklung? Würdest du bei einem Automobilzulieferer C-Code nach DDD entwickeln? Huch, C kennt ja nichtmal Objektorientierung! Da muss dann wohl doch eine andere Lösung her.
Ich habe ein wenig den Eindruck, dass du deine eigenen Erfahrungen und Qualitätsstandards auf alle anderen Entwickler überträgst. Doch da die Programmiersprachen, Anforderungen, Paradigmen usw. da draußen so unterschiedlich sind, geht das leider nicht. Ein (ernstgemeinter) Ratschlag: Frag deine IHK, ob sie noch Prüfer braucht! Mit deinem Engagement bist du in der Rolle genau richtig. Dann bekommst du aber auch mal einen Einblick in die Realität vieler Betriebe da draußen und entschärfst deine Meinung vielleicht etwas. Clean Code ist ein super Konzept. Genau wie Unit-Tests und Pair Programming. Aber wenn du dich da draußen mal umschaust, wirst du feststellen, dass nur ein Bruchteil der Unternehmen diese Ideen tatsächlich umsetzt.
Mir fällt es jedenfalls nicht schwer, nachzuvollziehen, warum die Objektorientierung immer noch das vorherrschende Paradigma in der IHK-Prüfung ist (und sicherlich auch in normalen IT-Studiengängen). Man setzt halt auf bewährte grundlegende Konzepte. Die konkrete Ausgestaltung und Ausschmückung mit Frameworks, Architekturideen, Sprachfeatures usw. obliegt dann den Ausbildungsbetrieben, die passend zu ihrer Sprache und Branche die Inhalte auswählen. Und auch da wird nicht immer der neuste Kram eingesetzt, sondern sehr oft auch uralte Sprachen und Frameworks. Denn das Update auf v2.0 oder den Rewrite in Haskell bezahlt den Unternehmen leider meistens kein Kunde...

Wie schon so oft muss ich leider wieder dagegen halten: Kaufmännische Inhalte sind Kernbestandteil der Ausbildung zum Fachinformatiker für Anwendungsentwicklung (und auch aller anderen IT-Berufe). Auch wenn viele Forenteilnehmer das (warum auch immer) nicht wahrhaben wollen. Ob die Gewichtung sinnvoll ist, darüber lässt sich sicherlich streiten.
Welche Aussagekraft fehlt dir denn hier? Die Botschaft ist: Das Projekt amortisiert sich nach einiger Zeit und führt langfristig zu einer Kosteneinsparung im Unternehmen. Das ist doch genau die richtige Aussage, wenn die Entwicklerin in Zukunft noch ein Gehalt erwartet.
Da hast du völlig recht. Ich hätte am liebsten auch zu jedem technischen Detail etwas gelesen, aber da die Abschlussarbeit (bei unserer IHK) auf 15 Seiten beschränkt ist, war dafür leider kein Platz. In einer Bachelor- oder Masterarbeit kann man sich bestimmt intensiv mit solchen Inhalten auseinandersetzen, aber für die Projektdoku muss man einfach Abstriche machen und eine sinnvolle Auwahl der Themen treffen.
 
Dein gelungener Rant über die schlechte Ausbildung der Anwendungsentwickler ist ansonsten nett zu lesen. Allerdings ist die Berufsschule sehrwohl dafür da, die Prüflinge auf die Prüfung vorzubereiten. Clean Code mit DDD und Tests wird dann hoffentlich in den Ausbildungsunternehmen vermittelt. Dort findet der Praxisteil der Ausbildung statt.
Dass Berufsschulen im Adaptieren neuer Konzepte nicht die schnellsten sind, ist sicherlich ein Problem. Aber auf der anderen Seite müssen die Schulen auch einer Vielzahl an Schülern mit unterschiedlichem Vorwissen Grundlagen der Programmierung beibringen. Und da kann es halt ein paar Wochen dauern, bis for und if durchgekaut sind. Dass die Azubis dafür u.a. Struktogramme oder Pseudocode lernen, liegt hauptsächlich daran, dass es nicht die eine Programmiersprache gibt, die alle Azubis können müssen und die dann in der Prüfung abgefragt wird. Aber das haben wir an anderer Stelle schon ausgiebig diskutiert.
Insgesamt solltest du deine Anforderungen an die Berufsschulausbildung vielleicht etwas zurückfahren. Man sollte von einer Ausbildung nicht die gleichen Inhalte erwarten, wie von einem Studium. Wobei auch bei letzterem in den meisten Fällen DDD und Unit-Tests sicherlich kein Lehrinhalt sind. Dort wird doch teilweise noch länger der alte Kram durchgekaut. Aber das möchte ich jetzt nicht weiter vertiefen
Ich halte es auch für sehr schwierig, Lerninhalte an aktuelle Entwicklungen in der IT anzupassen. Nehmen wir mal DDD als Beispiel: Das Konzept ist schon relativ alt (Eric Evans Buch ist von 2003), aber richtig Fahrt aufgenommen hat es erst in den letzten Jahren durch Microservices usw. Wer hätte das vorhersehen und vor 5 Jahren einen entsprechenden Lehrplan aufstellen können, der heute zeitgemäß ist? Und wer sagt überhaupt, dass DDD die "richtige" Art zu programmieren ist? Was ist mit den tausenden anderen Konzepten und Ideen der Softwareentwicklung? Würdest du bei einem Automobilzulieferer C-Code nach DDD entwickeln? Huch, C kennt ja nichtmal Objektorientierung! Da muss dann wohl doch eine andere Lösung her.
Ich habe ein wenig den Eindruck, dass du deine eigenen Erfahrungen und Qualitätsstandards auf alle anderen Entwickler überträgst. Doch da die Programmiersprachen, Anforderungen, Paradigmen usw. da draußen so unterschiedlich sind, geht das leider nicht. Ein (ernstgemeinter) Ratschlag: Frag deine IHK, ob sie noch Prüfer braucht! Mit deinem Engagement bist du in der Rolle genau richtig. Dann bekommst du aber auch mal einen Einblick in die Realität vieler Betriebe da draußen und entschärfst deine Meinung vielleicht etwas. Clean Code ist ein super Konzept. Genau wie Unit-Tests und Pair Programming. Aber wenn du dich da draußen mal umschaust, wirst du feststellen, dass nur ein Bruchteil der Unternehmen diese Ideen tatsächlich umsetzt.
Mir fällt es jedenfalls nicht schwer, nachzuvollziehen, warum die Objektorientierung immer noch das vorherrschende Paradigma in der IHK-Prüfung ist (und sicherlich auch in normalen IT-Studiengängen). Man setzt halt auf bewährte grundlegende Konzepte. Die konkrete Ausgestaltung und Ausschmückung mit Frameworks, Architekturideen, Sprachfeatures usw. obliegt dann den Ausbildungsbetrieben, die passend zu ihrer Sprache und Branche die Inhalte auswählen. Und auch da wird nicht immer der neuste Kram eingesetzt, sondern sehr oft auch uralte Sprachen und Frameworks. Denn das Update auf v2.0 oder den Rewrite in Haskell bezahlt den Unternehmen leider meistens kein Kunde...

Wie schon so oft muss ich leider wieder dagegen halten: Kaufmännische Inhalte sind Kernbestandteil der Ausbildung zum Fachinformatiker für Anwendungsentwicklung (und auch aller anderen IT-Berufe). Auch wenn viele Forenteilnehmer das (warum auch immer) nicht wahrhaben wollen. Ob die Gewichtung sinnvoll ist, darüber lässt sich sicherlich streiten.
Welche Aussagekraft fehlt dir denn hier? Die Botschaft ist: Das Projekt amortisiert sich nach einiger Zeit und führt langfristig zu einer Kosteneinsparung im Unternehmen. Das ist doch genau die richtige Aussage, wenn die Entwicklerin in Zukunft noch ein Gehalt erwartet.
Da hast du völlig recht. Ich hätte am liebsten auch zu jedem technischen Detail etwas gelesen, aber da die Abschlussarbeit (bei unserer IHK) auf 15 Seiten beschränkt ist, war dafür leider kein Platz. In einer Bachelor- oder Masterarbeit kann man sich bestimmt intensiv mit solchen Inhalten auseinandersetzen, aber für die Projektdoku muss man einfach Abstriche machen und eine sinnvolle Auwahl der Themen treffen.
 
Dein gelungener Rant über die schlechte Ausbildung der Anwendungsentwickler ist ansonsten nett zu lesen. Allerdings ist die Berufsschule sehrwohl dafür da, die Prüflinge auf die Prüfung vorzubereiten. Clean Code mit DDD und Tests wird dann hoffentlich in den Ausbildungsunternehmen vermittelt. Dort findet der Praxisteil der Ausbildung statt.
Dass Berufsschulen im Adaptieren neuer Konzepte nicht die schnellsten sind, ist sicherlich ein Problem. Aber auf der anderen Seite müssen die Schulen auch einer Vielzahl an Schülern mit unterschiedlichem Vorwissen Grundlagen der Programmierung beibringen. Und da kann es halt ein paar Wochen dauern, bis for und if durchgekaut sind. Dass die Azubis dafür u.a. Struktogramme oder Pseudocode lernen, liegt hauptsächlich daran, dass es nicht die eine Programmiersprache gibt, die alle Azubis können müssen und die dann in der Prüfung abgefragt wird. Aber das haben wir an anderer Stelle schon ausgiebig diskutiert.
Insgesamt solltest du deine Anforderungen an die Berufsschulausbildung vielleicht etwas zurückfahren. Man sollte von einer Ausbildung nicht die gleichen Inhalte erwarten, wie von einem Studium. Wobei auch bei letzterem in den meisten Fällen DDD und Unit-Tests sicherlich kein Lehrinhalt sind. Dort wird doch teilweise noch länger der alte Kram durchgekaut. Aber das möchte ich jetzt nicht weiter vertiefen
Ich halte es auch für sehr schwierig, Lerninhalte an aktuelle Entwicklungen in der IT anzupassen. Nehmen wir mal DDD als Beispiel: Das Konzept ist schon relativ alt (Eric Evans Buch ist von 2003), aber richtig Fahrt aufgenommen hat es erst in den letzten Jahren durch Microservices usw. Wer hätte das vorhersehen und vor 5 Jahren einen entsprechenden Lehrplan aufstellen können, der heute zeitgemäß ist? Und wer sagt überhaupt, dass DDD die "richtige" Art zu programmieren ist? Was ist mit den tausenden anderen Konzepten und Ideen der Softwareentwicklung? Würdest du bei einem Automobilzulieferer C-Code nach DDD entwickeln? Huch, C kennt ja nichtmal Objektorientierung! Da muss dann wohl doch eine andere Lösung her.
Ich habe ein wenig den Eindruck, dass du deine eigenen Erfahrungen und Qualitätsstandards auf alle anderen Entwickler überträgst. Doch da die Programmiersprachen, Anforderungen, Paradigmen usw. da draußen so unterschiedlich sind, geht das leider nicht. Ein (ernstgemeinter) Ratschlag: Frag deine IHK, ob sie noch Prüfer braucht! Mit deinem Engagement bist du in der Rolle genau richtig. Dann bekommst du aber auch mal einen Einblick in die Realität vieler Betriebe da draußen und entschärfst deine Meinung vielleicht etwas. Clean Code ist ein super Konzept. Genau wie Unit-Tests und Pair Programming. Aber wenn du dich da draußen mal umschaust, wirst du feststellen, dass nur ein Bruchteil der Unternehmen diese Ideen tatsächlich umsetzt.
Mir fällt es jedenfalls nicht schwer, nachzuvollziehen, warum die Objektorientierung immer noch das vorherrschende Paradigma in der IHK-Prüfung ist (und sicherlich auch in normalen IT-Studiengängen). Man setzt halt auf bewährte grundlegende Konzepte. Die konkrete Ausgestaltung und Ausschmückung mit Frameworks, Architekturideen, Sprachfeatures usw. obliegt dann den Ausbildungsbetrieben, die passend zu ihrer Sprache und Branche die Inhalte auswählen. Und auch da wird nicht immer der neuste Kram eingesetzt, sondern sehr oft auch uralte Sprachen und Frameworks. Denn das Update auf v2.0 oder den Rewrite in Haskell bezahlt den Unternehmen leider meistens kein Kunde...

Wie schon so oft muss ich leider wieder dagegen halten: Kaufmännische Inhalte sind Kernbestandteil der Ausbildung zum Fachinformatiker für Anwendungsentwicklung (und auch aller anderen IT-Berufe). Auch wenn viele Forenteilnehmer das (warum auch immer) nicht wahrhaben wollen. Ob die Gewichtung sinnvoll ist, darüber lässt sich sicherlich streiten.
Welche Aussagekraft fehlt dir denn hier? Die Botschaft ist: Das Projekt amortisiert sich nach einiger Zeit und führt langfristig zu einer Kosteneinsparung im Unternehmen. Das ist doch genau die richtige Aussage, wenn die Entwicklerin in Zukunft noch ein Gehalt erwartet.
Da hast du völlig recht. Ich hätte am liebsten auch zu jedem technischen Detail etwas gelesen, aber da die Abschlussarbeit (bei unserer IHK) auf 15 Seiten beschränkt ist, war dafür leider kein Platz. In einer Bachelor- oder Masterarbeit kann man sich bestimmt intensiv mit solchen Inhalten auseinandersetzen, aber für die Projektdoku muss man einfach Abstriche machen und eine sinnvolle Auwahl der Themen treffen.
 
Dein gelungener Rant über die schlechte Ausbildung der Anwendungsentwickler ist ansonsten nett zu lesen. Allerdings ist die Berufsschule sehrwohl dafür da, die Prüflinge auf die Prüfung vorzubereiten. Clean Code mit DDD und Tests wird dann hoffentlich in den Ausbildungsunternehmen vermittelt. Dort findet der Praxisteil der Ausbildung statt.
Dass Berufsschulen im Adaptieren neuer Konzepte nicht die schnellsten sind, ist sicherlich ein Problem. Aber auf der anderen Seite müssen die Schulen auch einer Vielzahl an Schülern mit unterschiedlichem Vorwissen Grundlagen der Programmierung beibringen. Und da kann es halt ein paar Wochen dauern, bis for und if durchgekaut sind. Dass die Azubis dafür u.a. Struktogramme oder Pseudocode lernen, liegt hauptsächlich daran, dass es nicht die eine Programmiersprache gibt, die alle Azubis können müssen und die dann in der Prüfung abgefragt wird. Aber das haben wir an anderer Stelle schon ausgiebig diskutiert.
Insgesamt solltest du deine Anforderungen an die Berufsschulausbildung vielleicht etwas zurückfahren. Man sollte von einer Ausbildung nicht die gleichen Inhalte erwarten, wie von einem Studium. Wobei auch bei letzterem in den meisten Fällen DDD und Unit-Tests sicherlich kein Lehrinhalt sind. Dort wird doch teilweise noch länger der alte Kram durchgekaut. Aber das möchte ich jetzt nicht weiter vertiefen
Ich halte es auch für sehr schwierig, Lerninhalte an aktuelle Entwicklungen in der IT anzupassen. Nehmen wir mal DDD als Beispiel: Das Konzept ist schon relativ alt (Eric Evans Buch ist von 2003), aber richtig Fahrt aufgenommen hat es erst in den letzten Jahren durch Microservices usw. Wer hätte das vorhersehen und vor 5 Jahren einen entsprechenden Lehrplan aufstellen können, der heute zeitgemäß ist? Und wer sagt überhaupt, dass DDD die "richtige" Art zu programmieren ist? Was ist mit den tausenden anderen Konzepten und Ideen der Softwareentwicklung? Würdest du bei einem Automobilzulieferer C-Code nach DDD entwickeln? Huch, C kennt ja nichtmal Objektorientierung! Da muss dann wohl doch eine andere Lösung her.
Ich habe ein wenig den Eindruck, dass du deine eigenen Erfahrungen und Qualitätsstandards auf alle anderen Entwickler überträgst. Doch da die Programmiersprachen, Anforderungen, Paradigmen usw. da draußen so unterschiedlich sind, geht das leider nicht. Ein (ernstgemeinter) Ratschlag: Frag deine IHK, ob sie noch Prüfer braucht! Mit deinem Engagement bist du in der Rolle genau richtig. Dann bekommst du aber auch mal einen Einblick in die Realität vieler Betriebe da draußen und entschärfst deine Meinung vielleicht etwas. Clean Code ist ein super Konzept. Genau wie Unit-Tests und Pair Programming. Aber wenn du dich da draußen mal umschaust, wirst du feststellen, dass nur ein Bruchteil der Unternehmen diese Ideen tatsächlich umsetzt.
Mir fällt es jedenfalls nicht schwer, nachzuvollziehen, warum die Objektorientierung immer noch das vorherrschende Paradigma in der IHK-Prüfung ist (und sicherlich auch in normalen IT-Studiengängen). Man setzt halt auf bewährte grundlegende Konzepte. Die konkrete Ausgestaltung und Ausschmückung mit Frameworks, Architekturideen, Sprachfeatures usw. obliegt dann den Ausbildungsbetrieben, die passend zu ihrer Sprache und Branche die Inhalte auswählen. Und auch da wird nicht immer der neuste Kram eingesetzt, sondern sehr oft auch uralte Sprachen und Frameworks. Denn das Update auf v2.0 oder den Rewrite in Haskell bezahlt den Unternehmen leider meistens kein Kunde...

Leider interpretiert jede IHK bzw. jeder Prüfungsausschuss die Vorgaben anders. Daher würde ich mich nicht auf deinen Ratgeber verlassen, sondern bei deiner IHK nachfragen.
Häufig gibt es ein Merkblatt, auf dem steht, welche Zielgruppe deine Präsentation haben soll/darf. Bei uns ist z.B. immer der Prüfungsausschuss die Zielgruppe und auf "simulierte Kunden" wird verzichtet (das wirkt doch immer sehr konstruiert). Andere IHKen geben aber explizit die Auwahl z.B. zwischen "Abteilungsleiter", "Kunden", "Kollegen" usw. vor. Halte dich an das, was deine IHK von dir verlangt und gestalte die Präsentation dann zielgruppengerecht (z.B. beim Abteilungsleiter die internen Kosten mit rein, beim Kunden nur die externen). Zu Beginn deiner Präsentation sagst du dann ganz deutlich, an wen sich der Vortrag richtet, damit die Prüfer mit diesem Hintergrund deine Leistung bewerten.
Das Gleiche gilt für die Inhalte der Präsentation: Hier ist z.B. bei uns gerade eine komplette Zusammenfassung der Projekts mit allen Phasen und Artefakten wichtig, da nicht alle Prüfer die Doku gelesen haben (ist zeitlich gar nicht machbar). Wenn deine IHK das anders haben will, halte dich daran. Aber auch das bekommst du nur heraus, wenn du nachfragst (oder auf der Website der IHK danach suchst). Scheu dich auch nicht davor, bei deiner IHK anzurufen, wenn du online keine Infos findest. Dafür sind die Damen und Herren da!

Leider interpretiert jede IHK bzw. jeder Prüfungsausschuss die Vorgaben anders. Daher würde ich mich nicht auf deinen Ratgeber verlassen, sondern bei deiner IHK nachfragen.
Häufig gibt es ein Merkblatt, auf dem steht, welche Zielgruppe deine Präsentation haben soll/darf. Bei uns ist z.B. immer der Prüfungsausschuss die Zielgruppe und auf "simulierte Kunden" wird verzichtet (das wirkt doch immer sehr konstruiert). Andere IHKen geben aber explizit die Auwahl z.B. zwischen "Abteilungsleiter", "Kunden", "Kollegen" usw. vor. Halte dich an das, was deine IHK von dir verlangt und gestalte die Präsentation dann zielgruppengerecht (z.B. beim Abteilungsleiter die internen Kosten mit rein, beim Kunden nur die externen). Zu Beginn deiner Präsentation sagst du dann ganz deutlich, an wen sich der Vortrag richtet, damit die Prüfer mit diesem Hintergrund deine Leistung bewerten.
Das Gleiche gilt für die Inhalte der Präsentation: Hier ist z.B. bei uns gerade eine komplette Zusammenfassung der Projekts mit allen Phasen und Artefakten wichtig, da nicht alle Prüfer die Doku gelesen haben (ist zeitlich gar nicht machbar). Wenn deine IHK das anders haben will, halte dich daran. Aber auch das bekommst du nur heraus, wenn du nachfragst (oder auf der Website der IHK danach suchst). Scheu dich auch nicht davor, bei deiner IHK anzurufen, wenn du online keine Infos findest. Dafür sind die Damen und Herren da!