Berufsschule? Sinnlos!

[thereisnospace]

Klasse Beitrag Whiz-zarD, dem ich größtenteils erfahrungsgemäß (welches sich auf ca. 2,5 Jahre Berufsausbildung beschränkt) zustimmen kann.

Schon am Anfang hatte ich mit meinem Ausbilder ein Gespräch über den Rahmenlehrplan, wo er mir auch schnell mitgeteilt hat, dass er seit Jahren mit dem Bundesministerium für Bildung im Gespräch steht und versucht denen mitzuteilen, dass die Ausbildungsordnung einfach veraltet und nicht mehr zeitgemäß ist. Da ich selbst im öffentlichen Dienst arbeite, weiß ich aber wie lang sich solche Prozesse ziehen können, bis letztendlich etwas verändert wird.

Berufsschultechnisch denke ich mit gemischten Gefühlen zurück. Wir hatten durchaus einige Lehrer, die es drauf hatten. Einer davon saß schon seit längerer Zeit im Prüfungssausschuss und hat uns optimal auf die Prüfungen vorbereitet und trotzdem hilfreichen und guten Unterricht gemacht.

Wenn man dann aber in Netzwerktechnik hingesetzt wird und gesagt wird "Öffnet mal Wireshark und analysiert die Pakete" ohne wirkliche Aufgabe ist es auch nicht zielführend.

Grundsätzlich lässt sich aber als Anwendungsentwickler sagen, dass die im Berufsschulunterricht vermittelten Programmiertechniken nicht den heutigen Standard entsprechen und erst recht nicht sauberer Programmierung. Uns wurde zwar das Mehrschichtenmodell oder UML-Diagramme beigebracht, aber dann wurde im nächsten Zug in die View Programmierlogik eingehakt. Das ist durchaus verbesserungswürdig.

[stefan.macke]

vor 2 Stunden schrieb Whiz-zarD:

...und die Kernkompetenz eines Entwicklers ist die Softwareentwicklung und nicht das Ausloten der Wirtschaftlichkeit.

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.

Zitat

Als Beispiel nehme ich mal diese Abschlussarbeit, die mit 100% bewertet wurde. Die Abschnitte "Projektkosten" und "Amortisationsdauer" lesen sich wie ein Standardtext, den man in jeder Abschlussarbeit reinknallen könnte. Diese Texte haben überhaupt keine Aussagekraft.

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.

Zitat

Viel wichtiger wären doch technische Aspekte. In einem Nebensatz wird erwähnt, dass die Daten historisiert abgelegt werden sollen. Da werde ich als Entwickler doch sehr hellhörig, weil die Historisierung gar nicht trivial ist. Schon gar nicht in einer relationalen Datenbank. Da hätte ich schon ein Kapitel erwartet, dass sich mit diesem Thema auseinandersetzt.

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...

Bearbeitet 27. Dezember 2016 von stefan.macke
Doppelter Absatz

[Tician]

vor einer Stunde schrieb Whiz-zarD:

Sorry aber das, was ich von dir in diesem Forum gesehen habe, war keine objektorientierte Programmierung. Nur weil man eine objektorientierte Sprache verwendet, heißt es noch lange nicht, dass man auch Objektorientierung anwendet

Exakt, wir lernen es, weswegen die Ausssage hier auch nichts zu suchen hat, das ich es nicht anwenden kann ist mein Problem

Du beziehst dich nur auf FIAE'ler, aber was denkst du erwartet man programmiertechnisch von einem FISI wie mir später?

Kein Lehrer und auch keine Schule ist perfekt, man muss sich anpassen und wenn ich etwas nicht verstehe frage ich meinen Ausbilder oder belese mich in Büchern oder über google.

[Whiz-zarD]

vor 3 Stunden schrieb stefan.macke:

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.

Du kannst es so oft schreiben, wie du willst und trotzdem wird es nicht richtiger.
Mag sein, dass es Bestandteil der Ausbildung ist (was ich auch durchaus für angemessen halt), es sollte aber kein Kernbestandteil sein und genau das meine ich, dass die Prioritäten falsch gesetzt werden. Die Softwareentwicklung ist schon ein sehr komplexes Thema und ich finde FIAEler sollten dann nicht noch zusätzlich ein halber Kaufmann werden, denn dafür gibt es schon die Informatikkaufmänner. Viel mehr sollte man sich hier auf den technischen Aspekt konzentrieren und genau das passiert auch in der Wirtschaft, wie ich z.B. schon mit SCRUM angesprochen habe. Mag sein, dass es viele kleine Firmen gibt, wo ein Entwickler dies benötigt aber nur aufgrund solcher Firmen den kaufmännischen Teil als ein Kernbestand der Ausbildung zu machen, halte ich schlichtweg für falsch.

vor 3 Stunden schrieb stefan.macke:

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.

Ja, Wow ... Und für diese Erkenntnis braucht man drei Seiten? Es ist bekannt, dass eine Automatisierung schneller ist, als eine manuelle Abarbeitung und somit kostengünstiger. Das kann ich auch in einem Satz formulieren und brauche keine drei Seiten.

vor 3 Stunden schrieb stefan.macke:

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.

Und wenn man den kaufmännischen Aspekt weglassen würde, wären bei der 100% Abschlussarbeit dafür 3 Seiten platz gewesen.

vor 3 Stunden schrieb stefan.macke:

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.

Für mich sind Datenstrukturen ein Teil der Grundlagen und diese werden konsequent ignoriert. Stattdessen versucht man wohl in den drei Jahren auch den letzen Deppen beizubringen, dass es keine if-Schleifen gibt. Den Azubis wird doch keine Grundlagen beigebracht. Vielfach habe ich schon gesehen, dass z.B. Geldbeträge als eine Fließkommazahl dargestellt werden. Das ist eine Todsünde! In der 100% Abschlussarbeit wird zwar richtigerweise decimal als Datentyp genommen aber ob dies dem Azubi klar war, lässt sich aus der Dokumentation nicht ableiten. Auch werden oft Arraylisten verwendet, obwohl fleißig neue Elemente rangehängt werden. Dass so etwas inperformant ist und dafür eine verkettete Listen genommen werden sollte, weiß keiner. Die Grundlagen sind also mehr, als nur die Syntax. Zu den Grundlagen gehört auch der Verständnis der bekannten Datenstrukturen und so ein Verständnis ist Programmiersprachenunabhängig. Eine verkettete Liste funktioniert unter C genauso wie unter C# oder Java. Mit dem Unterschied, dass man sie in C erst mal selbst implementieren muss, während man in C# die List<T> und in Java die LinkedList<T> verwenden kann.

vor 3 Stunden schrieb stefan.macke:

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.

DDD ist nicht auf Objektorientierung beschränkt. Genauso gut lässt sich DDD auf prozeduraler oder funktionaler Programmierung anwenden.

vor 3 Stunden schrieb stefan.macke:

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.

Und genau das meine ich ja mit "Defizite" und "Ein Blick über den Tellerrand". Nicht jede Firma verwendet DDD, TDD oder klassische Unit-Tests aber eine Berufsschule sollte sich deswegen nicht verschließen, sondern sollte den Azubis so etwas zeigen und auch üben. In meiner Ausbildung als Mechatroniker hatten wir so einen ähnlichen Fall. Ich hatte meiner Klasse zwei Mitschüler, die in ihrer Firma nicht mit SPS-Programmierung, Pneumatik oder Hydraulik in Kontakt kamen. Den Part hat dann die Schule übernommen und genau so sollte es auch bei der Softwareentwicklung sein. Einfach zu sagen: "Gibt es nicht, weil nicht alle Firmen dies einsetzen!" ist falsch. DDD und TDD sind Konzepte, die sich in den letzten Jahren sehr bewährt haben. Warum sollte man den Azubis dies nicht beibringen wollen? Der Weisheit letzter Schluss ist das mit Sicherheit noch lange nicht. Sicherlich sind auch irgendwann diese Konzepte überholt und gegen andere ausgetauscht aber wir leben im Jetzt und Jetzt haben sie eine große Bedeutung. Vor 15 Jahren hatten Pflichten- und Lastenhefte noch eine große Bedeutung. Heute schon lange nicht mehr und dennoch tut die IHK so, als wäre dies DAS Prinzip, was auf Ewigkeit bestand hält. 

vor 3 Stunden schrieb stefan.macke:

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.

Ich habe ja nichts dagegen, dass den Azubis die Objektorientierung beigebracht wird aber man zäumt das Pferd oft von Hinten auf. Ich höre oder lese oft folgendes: "So, jetzt lernen wir Objektorientierung! Startet dafür jetzt alle Visual Studio und öffnet ein neues WinForms-Projekt" ... Das ist schon ein Zeichen für mich, dass man nichts über Objektorientierung lernt sondern nur mit der IDE rumspielt, wenn man schon so hoch in der Abstraktion anfängt. Dass im Hintergrund eine Endlosschleife läuft, die dafür sorgt, dass die grafische Oberfläche immer neu gezeichnet wird und die Events auslöst, wird nicht mal erwähnt. Gern genommen wird auch die allseits beliebte Entwicklung eines Taschenrechners. Aus meiner Sicht für ein Anfänger viel zu kompliziert, wenn man auch die Rechenregel "Punkt- vor Strichrechnung" und Klammersetzung einhalten möchte, denn da sind Konzepte wie z.B. die Polnische Notation oder Binäre Bäume sehr hilfreich. Auch wird dann hier das Konzept der Vererbung benötigt.

Für mich sind also schon die angeblich grundlegenden Konzepte falsch gewählt. "Grundlagen" heißt offenbar, dass man die Hälfte verschweigt und den Rest dann nur noch überfliegt. Man muss bedenken, dass man hier Softwareentwickler ausbilden möchte und nicht Tante Emma mal im groben zeigen möchte, wie man programmiert. Daher sollte man den Azubis auch ein Grundverständnis vermitteln, was eigentlich wirklich passiert und wenn man das alles mal berücksichtigt, dann merkt man, dass da überhaupt kein Platz für einen kaufmännischen Teil ist und wenn man endlich diese Erkenntnis erlangt hat, dann ist man wohl endlich auf dem richtigen Weg.

vor 2 Stunden schrieb Tician:

Du beziehst dich nur auf FIAE'ler, aber was denkst du erwartet man programmiertechnisch von einem FISI wie mir später?

Ja, ich beziehe mich nur auf den FIAEler, da die Softwareentwicklung nun mal mein Hauptberuf ist. Zu den FISIs muss ich aber auch sagen, dass ich es für falsch halte, dass die FIAEler und die FISIs sehr häufig die selben Kurse in der Berufsschule haben. Beide sollten zwar Grundlagen in der Programmierung, der Shellskripte, den Datenbanken und der Netzwerktechnik haben aber dann sollten sich schon die Wege trennen. Ein FISI wird nicht großartig irgendeine Software mit Java und einer grafischen Oberfläche, die Daten in Echtzeit auswertet, schreiben und das habe ich bis jetzt noch in keiner Firma gesehen, dass dies erwartet wird. Genauso wird ein FIAEler kaum ein Windows- oder Linux Server mit Active Directory, Firewall, Proxy, DNS, DMZ und sonstigem Kram aufsetzen. Es ist zwar Nett, wenn ein FISI mehr über Softwareentwicklung und ein FIAEler mehr über die Server-Administration weiß aber das ist kein KO-Kriterium, wenn man es nicht weiß.

Bearbeitet 27. Dezember 2016 von Whiz-zarD
Typo

[Thanks-and-Goodbye]

vor einer Stunde schrieb Whiz-zarD:

Du kannst es so oft schreiben, wie du willst und trotzdem wird es nicht richtiger.

Fakt ist: der kaufmännische Anteil an der Ausbildung ist im Rahmenlehrplan festgeschrieben.

http://www.gesetze-im-internet.de/itktausbv/anlage_2_teil_a.html

Wenn du daran was ändern willst: kündige deinen Job, geh in die Bundespolitik und wirke als Abgeordneter an der Bildungspolitik mit.

[JimTheLion]

Die Leute die den Ausbildungsplan entwickelt haben, sind der Meinung Wirtschaft gehört dazu. Da muss aber eigentlich auch niemand Angst haben, dass der Wirtschaftsteil so viel Zeit in Anspruch nimmt, dass man die wichtigen Dinge deshalb nicht lernt.

Die Azubis die sich wirklich für die z.B. Softwareentwicklung interessieren machen in der Berufsschule den Wirtschaftsteil mit und legen dann im Betrieb oder privat richtig los. 

Diejenigen die nach 3 Jahren Ausbildung immer noch Probleme haben die Syntax für eine Schleife auf Papier zu bringen, wären auch nicht besser, wenn sie stattdessen ein 3-jähriges Praktikum als Softwareentwickler unter Erich Gamma mitgemacht hätten.

 

@Whiz-zarD

Vielleicht ist es auch einfach ein Problem, dass jeder unter 'Grundlagen' etwas anderes versteht. Wenn ich mir das Modulhandbuch für die Informatikstudiengänge der Fernuni Hagen ansehe, sehe ich ein paar Kurse die ich unter Grundlagen einordnen würde. Aber das kann man nicht alles in der Berufsschule unterbringen, da gibt es aber auch schon andere Ausbildungsformen für.

Es ist auch schwierig eine Grenze zu ziehen. Du fragst 'Wo sind die Datenstrukturen?', der nächste sagt 'Wo ist die Algorithmische Mathematik?' oder 'Warum Normalisierung, wo sind die NoSQL Datenbanksysteme, die sind schon eine weile im Trend'.

Bearbeitet 27. Dezember 2016 von PVoss

[stefan.macke]

Ich sehe schon, wir kommen nicht zusammen. Aber trotzdem muss ich ein paar Kommentare loswerden.

vor 3 Stunden schrieb Whiz-zarD:

Mag sein, dass es viele kleine Firmen gibt, wo ein Entwickler dies benötigt aber nur aufgrund solcher Firmen den kaufmännischen Teil als ein Kernbestand der Ausbildung zu machen, halte ich schlichtweg für falsch.

 

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.

Zitat

Ja, Wow ... Und für diese Erkenntnis braucht man drei Seiten? Es ist bekannt, dass eine Automatisierung schneller ist, als eine manuelle Abarbeitung und somit kostengünstiger. Das kann ich auch in einem Satz formulieren und brauche keine drei Seiten.

 

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.

Zitat

Und wenn man den kaufmännischen Aspekt weglassen würde, wären bei der 100% Abschlussarbeit dafür 3 Seiten platz gewesen.

 

Das stimmt. Dann wären es aber leider auch keine 100% geworden

Zitat

Vielfach habe ich schon gesehen, dass z.B. Geldbeträge als eine Fließkommazahl dargestellt werden. Das ist eine Todsünde! In der 100% Abschlussarbeit wird zwar richtigerweise decimal als Datentyp genommen aber ob dies dem Azubi klar war, lässt sich aus der Dokumentation nicht ableiten.

 

Da ich die Arbeit betreut habe: Ja, das war ihr klar. Und ich hoffe, dass andere Unternehmen das auch vermitteln.

Zitat

Auch werden oft Arraylisten verwendet, obwohl fleißig neue Elemente rangehängt werden. Dass so etwas inperformant ist und dafür eine verkettete Listen genommen werden sollte, weiß keiner.

 

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

Zitat

Die Grundlagen sind also mehr, als nur die Syntax. Zu den Grundlagen gehört auch der Verständnis der bekannten Datenstrukturen und so ein Verständnis ist Programmiersprachenunabhängig. Eine verkettete Liste funktioniert unter C genauso wie unter C# oder Java. Mit dem Unterschied, dass man sie in C erst mal selbst implementieren muss, während man in C# die List<T> und in Java die LinkedList<T> verwenden kann.

 

 

 

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.

Zitat

DDD ist nicht auf Objektorientierung beschränkt. Genauso gut lässt sich DDD auf prozeduraler oder funktionaler Programmierung anwenden.

 

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.

Zitat

Und genau das meine ich ja mit "Defizite" und "Ein Blick über den Tellerrand". Nicht jede Firma verwendet DDD, TDD oder klassische Unit-Tests aber eine Berufsschule sollte sich deswegen nicht verschließen, sondern sollte den Azubis so etwas zeigen und auch üben.

 

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.

Zitat

Einfach zu sagen: "Gibt es nicht, weil nicht alle Firmen dies einsetzen!" ist falsch. DDD und TDD sind Konzepte, die sich in den letzten Jahren sehr bewährt haben. Warum sollte man den Azubis dies nicht beibringen wollen?

 

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.

Zitat

Vor 15 Jahren hatten Pflichten- und Lastenhefte noch eine große Bedeutung. Heute schon lange nicht mehr und dennoch tut die IHK so, als wäre dies DAS Prinzip, was auf Ewigkeit bestand hält. 

 

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.

Zitat

Ich habe ja nichts dagegen, dass den Azubis die Objektorientierung beigebracht wird aber man zäumt das Pferd oft von Hinten auf. Ich höre oder lese oft folgendes: "So, jetzt lernen wir Objektorientierung! Startet dafür jetzt alle Visual Studio und öffnet ein neues WinForms-Projekt" ... Das ist schon ein Zeichen für mich, dass man nichts über Objektorientierung lernt sondern nur mit der IDE rumspielt, wenn man schon so hoch in der Abstraktion anfängt.

 

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.

Zitat

Man muss bedenken, dass man hier Softwareentwickler ausbilden möchte und nicht Tante Emma mal im groben zeigen möchte, wie man programmiert. Daher sollte man den Azubis auch ein Grundverständnis vermitteln, was eigentlich wirklich passiert und wenn man das alles mal berücksichtigt, dann merkt man, dass da überhaupt kein Platz für einen kaufmännischen Teil ist und wenn man endlich diese Erkenntnis erlangt hat, dann ist man wohl endlich auf dem richtigen Weg.

 

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

[Rabber]

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.

[Bockreiter]

vor 15 Stunden schrieb PVoss:

Die Leute die den Ausbildungsplan entwickelt haben, sind der Meinung Wirtschaft gehört dazu. Da muss aber eigentlich auch niemand Angst haben, dass der Wirtschaftsteil so viel Zeit in Anspruch nimmt, dass man die wichtigen Dinge deshalb nicht lernt.

Wer sitzt denn in den Arbeitsgremien, die die Rahmenlehrpläne ausarbeiten? Sind das IT-Firmen, deren Kerngeschäft die Softwareentwicklung ist oder doch eher Industrieunternehmen, bei denen die IT "nur" benötigt wird das Kerngeschäft zu betreiben?

Ich sitze hier bei einem produzierenden Mittelständler mit ca. 1200MAs (EU weit >2000MAs), Systemlandschaft ist in 40 Jahren historisch gewachsen. Hier gibt es noch eine AS400 für die Lagerprozesse/-verwaltung, zwei SAP Systeme und ein in RPG geschriebenes ERP für die betriebswirtschaftlichen Parts, ein eigenentwickeltes BDE System (c und c#) für die Produktion incl. hardwarenaher Implementierung für die einzeln Produktionsmaschinen, selbst erstellte Software für die Produktionsvorstufen. Nebenbei noch das ganze "sonstige" IT Geraffel: Webseiten (incl. Durchgriff auf die SAP Systeme), SharePoint incl. InfoPath-Formularen, Zeiterfassung mit eigener Anbindung an die verschiedenen Systeme (SAP HR/BDE/etc..), RFID-Scanner-Lösungen im Lager, EDI Anbindungen von Kunden, Lieferanten und ausländischer Standorten, etc... Neueste IT-Projekte sind androidbasierte Apps für Prozessoptimierungen mit Handscannern im Lager. 

Was soll ein FIAE denn alles lernen um in allen Bereichen eingesetzt werden zu können? OOP/DDD/unit test für die AS400? SAP ohne betriebswirtschaftliches Wissen? Kann/Soll ein FIAE überhaupt in allen IT Bereichen entwickeln oder wozu braucht es studierte ITler?

Ich bin selber im SAP-Bereich unterwegs, habe den BWL-Part bewusst nach der Ausbildung durch eine Weiterbildung vertieft. Ohne BWL Wissen ist hier das Konzeptionieren/Prozessmodelieren schwierig, der Part der eigentlichen "Entwicklung" stellt dann wieder andere Wissensanforderungen.

OOP/unit tests waren während meiner Ausbildung vor 15 Jahren in der Entstehungsphase, heute verwende ich sie auch bei der Entwicklung (man lernt immer dazu). Ein Update des Rahmenlehrplans wäre möglich/sinnvoll, wobei man dies unter 5.2 b ) Programmierlogik und Programmiermethoden anwenden und 6.4 Testverfahren schon heute unterbringen könnte. Der Rahmenlehrplan ist doch so offen formuliert, das der technische Fortschritt immer integrierbar ist.

 

MfG

Bockreiter

 

[Whiz-zarD]

vor 4 Stunden schrieb Errraddicator:

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.

Ja, ein Entwickler bestimmt nicht, wann sich etwas amortisiert hat, oder sich irgendwann etwas lohnt. Er sagt nur, wie komplex die Umsetzung ist und wie lange es dauert. Die Entscheidung der Wirtschaftlichkeit passiert an einer anderen Stelle. Der Entwickler kann mehrere Alternativen aufzählen aber entscheiden, was umgesetzt wird, macht ein anderer.

vor 4 Stunden schrieb Errraddicator:

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.

Und hier sehe ich das größte Problem vieler Softwarefirmen: Es wird kein Wert auf Weiterbildung gesetzt.
Ich habe es inzwischen schon in so manchen Firmen erlebt, dass man veraltete Techniken einsetzt, weil man sie schon immer eingesetzt hat und neumodischer Schnick-Schnack sowieso Teufelszeug ist und die Firmen verlieren dann den Anschluss, weil die Kunden sich nicht mehr mit einer augenkrebserzeugenden WinForms- oder Java-Desktop-Anwendung zufrieden geben, sondern eine Webanwendung haben wollen, die auch auf Tablets läuft.

Keiner möchte eine Software neu programmieren aber wenn man die Software nicht pflegt und einem ständigen Refactoring unterzieht, wird das aber irgendwann passieren. Irgendwann ist auch eine Code-Basis von anno 2000 veraltet und nicht mehr wirtschaftlich, wenn man sie nicht laufend verbessert und erneuert. Fürs Refactoring wird aber oft kein Budget freigegeben, weil der Kunde davon nichts hat. Solche Diskussionen führe ich gefühlt jeden Tag und irgendwann häufen sich die Beschwerden der Kunden, dass die Software fehleranfällig oder langsam ist und die Entscheidungen werden häufig von Leuten getroffen, die es eigentlich hätte besser wissen müssen.

Microservices sind derzeit auch so ein Thema: Die wurden nicht eingeführt, weil man es für Hip und Cool fand, sondern sie zwingen einem nach dem SOA-Paradigma zu arbeiten. Das klassische SOA hat einfach nicht funktioniert auch wenn die Idee gut war und heute immer noch ist. Auch bieten die Microservices einen Vorteil, den du als Nachteil genannt hast: Man ist von der Programmiersprache unabhängig. Es ist egal, ob Service A mit Java, Service B mit C# und Service C mit Cobol entwickelt wurde. Man hat die Möglichkeit, eine geeignete Sprache für die Aufgaben zu suchen. In der Praxis wird das zwar selten vorkommen aber die Möglichkeit besteht. 

vor 4 Stunden schrieb Errraddicator:

Ähnliches, wenn Du Industrie-Anlagen programmierst. Die werden ebenfalls nicht alle 3 Jahre gewechselt.

Ich habe früher Industrie-Anlagen programmiert. Nein, sie werden nicht alle 3 Jahre gewechselt aber es handelt sich hier auch nicht um eine Standard-Software. Die Software wird pro Anlage geschrieben und angepasst. Somit läuft pro Anlage eine komplett individuelle Software, die über mehrere Wochen optimiert wird. Der Umgang ist ein völlig anderer, als bei einer Standard-Software aber auch hier bleibt die Zeit nicht stehen. Es werden immer neue Techniken entwickelt. IoT und Big Data wird auch in der Industrie immer wichtiger. Das war vor 15 Jahren noch Utopia.

vor 4 Stunden schrieb Errraddicator:

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.

Ich arbeite derzeit bei einer Firma, die eine Software für Banken entwickelt. Banken galten immer als sehr konservativ und intern arbeiten sie wie eine Behörde. Da gibt es dann pro Jahr zwei oder drei Zeitfenster, von wenigen Wochen, in der neue Softwareversionen ausgerollt werden dürfen und selbst bei solchen Kunden erleben wir derzeit ein Umdenken. Das Wort "Cloud" durfte man vor einigen Jahren noch nicht mal in den Mund nehmen. Heute ziehen viele Kunden es schon in Erwägung, ihre Daten in die Cloud zu schieben. Von einem Kunden weiß ich, dass sie schon ihre Daten in eine Cloud outsourcen. Auch haben wir schon von dem einen oder anderen erfahren, dass sie ihre eigens entwickelte Desktop-Lösung gegen eine Microservice-Lösung austauschen wollen und wozu das Ganze? Weil die Banken immer schneller reagieren müssen. Nicht, weil der Markt so schnelllebig ist, sondern weil immer mehr Anforderungen, seitens der Regierung oder der EZB, an die Banken gestellt werden, die sie dazu zwingen, schneller zu handeln. Dazu gehören auch die o.g. Excel-Makros, die nun gegen eine revisionssichere Software-Lösung ausgetauscht werden müssen.

Das selbe Problem sehe ich auch in der Automobilbranche, wenn sie tatsächlich autonome Fahrzeuge auf den Markt bringen wollen. Softwarefehler müssen schnell erkannt und behoben werden. Wollen sie denn bei jedem Fehler eine Rückruf-Aktion starten, die die Fahrer dazu zwingt, in die Werkstatt fahren zu müssen? Da müssen noch geeignete Softwareverteilungsmechanismen gefunden werden.

vor 4 Stunden schrieb Errraddicator:

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.

Da ap­pel­lie­re ich einfach an den gesunden Menschenverstand. Ich habe selbst schon von Informatikkaufmännern Fehlentscheidungen gesehen, die echt nicht mehr feierlich waren und Jobs gekostet haben, was eigentlich nicht nötig getan hätte. 

Die Frage ist ja auch, lag es am Entwickler oder an den schwammig formulierten Anforderungen. Das Thema diskutiere ich auch gefühlt jeden Tag. Wenn einem Entwickler nicht klar ist, was er da eigentlich macht und wieso, dann ist es eher ein Anzeichen dafür, dass die Anforderungen nicht klar sind und das wiederum ist ein Anzeichen, dass nicht genügend kommuniziert wurde. Viele Firmen arbeiten immer noch nach dem Wasserfall-Modell, obwohl man schon seit 15 Jahren predigt, dass das Wasserfall-Modell in der IT-Branche nun mal nicht funktioniert. 

Bearbeitet 28. Dezember 2016 von Whiz-zarD

[Rabber]

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?

Bearbeitet 28. Dezember 2016 von Errraddicator

[Whiz-zarD]

vor 3 Stunden schrieb Errraddicator:

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?

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.

[Thanks-and-Goodbye]

Schon interessant, dass sich der Fragesteller nach dem Erstellen der Frage nicht mehr hat sehen lassen. So wichtig scheint die Frage dann wohl doch nicht gewesen zu sein,

[bigvic]

Jaja, aber die  Berufsschule ist immer wieder ein beliebtes Thema ... da kann jeder was zu sagen und mal so richtig abjammern Wirkt bestimmt befreiend und dann ist ja auch wieder geholfen.

[mqr]

Hallo Community,

leider gibt es viel zu wenig (Ex-) Schüler, die positives Feedback abgeben und sagen "Hey, ich gehe gerne in die Schule".

Man kann in der Schule leider nicht alles lehren/lernen, dazu ist die Zeit viel zu knapp. Hinzu kommt oft ein bunt zusammengewürfelter Haufen mit unterschiedlichen Ausgangssituationen und Anforderungen. Dabei sind Fragen zu klären wie: "Muss ich auch abwaschen und Kaffee kochen, ich trinke doch nur drei Tassen?". Die erste Stunde geht drauf, indem man die Verspätungen einträgt und Fragen wie: "Habt ihr schon angefangen?" beantwortet.

Irgendwann haben die Exschüler dann (hoffentlich) ausgelernt und müssen im Berufsleben feststellen, dass es doch ein paar winzige Lücken in ihrem Wissen gibt und sie sich daher mit knapp unter 120 k€pa zufrieden geben müssen. Wer ist schuld? Wie immer ein anderer. In diesem Fall hätte man in der Schule alles lernen müssen. Dass das aber kein Studium ist, ist leider oft nicht klar. Somit werden Themen nur angeschnitten und es wird gelehrt erfolgreich autodidaktisch lebenslang weiter zu lernen, Medien zu werten, recherchieren etc. und vor allen, was vielen zunächst fehlt, Teamarbeit. Warten bis man dran kommt, andere ausreden lassen etc. Im Studium ist das oft anders riesen Hörsäle und kein Raum für Fragen und Antworten aber auch dort wird "nur" möglichst breit aufgestellt und mit Studienabschluss kommt das Feeling "Jetzt hast Du es geschafft". Ein paar Wochen vielleicht, dann heißt es wieder Pustekuchen.

Im Club der Millionäre arbeitet man sich bis nach ganz oben, um im Club der Milliardäre wieder ganz unten von vorne anfangen zu dürfen. Alles eine Frage der Perspektive.

Grüße

Micha

 

[Striewe]

Guten Morgen,

ich habe diesen Thread nur überflogen, aber es juckt mir nun doch in den Fingern etwas dazu zu schreiben. Ich gebe zu ich habe ach oft gedacht was ich mit dem ganzen BWL-Krams machen soll, warum bei einem Kollegen im Projektangtrag die "fehlende Wirtschaftlichkeit" angemahnt wurde, was der ganze Mist in der Schule sollte.

Die schriftliche Prüfung liegt nun hinter mir und ich für meinen Teil hätte gar nicht gewusst wie ich ohne Schulstoff diese hätte bestehen sollen. Ich hab kein Abi, keine Fachhochschule und auch kein Studium (auch kein abgebrochenes Studium).

Mich als Fisi hat es auch ziemlich genervt das wir fast ein Schuljahr nur Java in der Schule hatten. Ich habe es so gehasst....Ja und ich hab auch nicht verstanden, warum nicht intensiver oder überhaupt zum Beispiel auf Shell-Programmierung eingegangen wird, warum auf HTML und nicht auf die CMS-Systeme? Dennoch: Ich denke schon das man wissen muss, auch als Fisi, wie eine Programmiersprache funktioniert. Ob es hier in BaWü, so stark und so intensiv wie in manchen Prüfungen bei uns Fisis, tatsächlichauch in der Form abgefragt werden muss, ist eine ganz andere Geschichte. Es ist wie es eben ist.

Aber wie will man nun ein guter Fisi werden wenn man nicht einmal versteht wie sich ein Angebot zusammen setzen muss?

Ich für meinen Teil musste in unserem Betrieb (kleiner Betrieb und Chef war erkrankt) durchaus schon ran und sehen das Kunden auch ihr Angebot bekommen haben und auch Besichtigungen und Einschätzungen (Kosten, Installation ...) durchführen.Dem Kunden ist es schnuppe was intern los ist und was nicht, der will das sein Projekt voran geht und nicht warten. Und bitte, was nützt es wenn ein Auftrag so falsch eingeschätzt wird, das ein vollbezahlter Fisi oder Anwendungsentwickler Stunden verballert und man dem Kunden davon vielleicht nur  2 Stunden in Rechnung stellen kann? Wie wollt ihr da Strom, Miete, Gehalt bezahlen? Das Geschrei wird aber mächtig sein wenn bei solchen Fehlplanungen kein Gehalt auf das Konto mehr wandern würde. Und irgendwie finde ich ist es ja nicht nur der kaufmännische Bereich, sondern eine Gesamtbasis, die auch irgendwo was mit Verantwortung tragen zu tun hat. Also ich weiß nicht, ich kann nicht immer eine Anfrage  zum Chef weiterleiten(der bei uns auch den Vertrieb macht). Ich muss tatsächlich Verantwortung für meine Aussagen, dem Kunden gegenüber, tragen.

Technisch fehlt es mir sicherlich noch hier und da, aber dennoch werde ich nach der Ausbildung ein wirklich gutes Gehalt vom Chef bekommen. Auch wenn ich kein Abi oder Studium oder so habe. Sondern weil er sich auf mich verlassen kann, er weiß das ich Verantwortung trage, das ich mich einlerne wo ich etwas nicht weiß und ich mir auch als Fisi nicht zu fein bin mal ein Angebot zu schreiben oder ein Paket anzunehmen.

Grüße Striewe

 

 

Bearbeitet 29. Dezember 2016 von Striewe

[lilith2k3]

Am 25.12.2016 um 16:17 schrieb Crim:

Mein Fazit aus zwei Jahren Berufsschule ist, dass ich absolut gar nichts gelernt habe, was in der Berufswelt direkt anwendbar ist. Wenn ich so programmieren würde, wie ich es in der Schule gelernt habe, könnte ich mir bald einen neuen Arbeitgeber suchen. Viele Themen, die angesprochen wurden sind extrem veraltet (wir haben tatsächlich 2 Wochen lang HTML Framesets behandelt).

Willkommen in #Neuland

Meine Berufsschulerfahrung in Kürze:

Ich so: »Wann lernen wir Design Patterns«

Lehrer so: »Was?«

Ich habe fast alles, was ich in der Berufsschule gelernt habe, erfolgreich nicht anwenden können. 

P.S.: Hashtags werden nicht ohne Magie unterstützt?

Bearbeitet 29. Dezember 2016 von lilith2k3