Was ich aus der Programmierung mitnahm...

[Gast Java1408]

Mahlzeit 😁

Einige von euch kennen mich aus meinen Berichten zu meiner Umschulung zum FIAE. In meinem Kurs befinden sich rund 30 Teilnehmer, von denen genau zwei Vorkenntnisse im Bereich Programmierung haben. Ich bekomme immer wieder mit, wie so manch angehender FI regelrecht Panik vor der Programmierung hat. Auch im Internet liest man immer wieder, wie unsicher der eine oder andere Azubi / Umschüler in Bezug auf dieses Thema ist. Und ich kann es verstehen. Als ich meinen ersten Quellcode sah, glaubte ich, dass man für sowas 20 Jahre Studium braucht und wollte direkt aufgeben. Ich habe mich dennoch herangetastet und wurde mehr als nur einmal überrascht. Nicht nur, dass die Programmierung anders war als ich es erwartet hatte, sie hat auch mich selbst verändert. In meinem Beitrag soll es darum gehen, was genau mich überraschte, wie mich die Programmierung veränderte, wie ich den Einstieg fand und wie ich die Programmierung wahrnehme.

Mathematik ist ein Albtraum

Auch ich dachte immer, dass Programmierung fast ausschließlich mit Mathematik zu tun hat. Mich persönlich hätte das nicht so sehr gestört, denn ich war in Mathematik immer sehr gut (scheiß Einserschüler). Ich konnte aber auch verstehen, wenn absolute Mathehater von Programmierung nicht viel halten. Zu meiner Überraschung kam ich noch nie in eine Situation, in der ich komplexe Mathematik anwenden musste. Das Gegenteil war der Fall. Ich stellte fest, dass man sich auf kreative Art enorm entfalten kann. Man erfindet etwas und die eigene Geisteskraft bestimmt darüber, was man da erschafft. Das kann ein Spiel mit unendlich vielen Möglichkeiten sein, genauso gut aber auch eine besonders kreative Art, irgendwelche Probleme durch Automatisierung zu lösen. Es gibt also nicht diesen einen Weg, den man zur Lösung eines Problems finden muss. Würde man mich heute fragen, ob man in der Programmierung sehr gut in Mathe sein muss, dann würde ich antworten, dass man stattdessen Fantasie und Vorstellungskraft benötigt. Je kreativer, desto besser. Dieser aufregende Teil der Programmierung bleibt einem aber verschlossen, wenn man sich nicht darauf einlässt und versucht, dieses Thema möglichst zu meiden. Das kennt man aus der Mathematik. Viele hassen Mathe nicht, weil sie es nicht verstehen können, sondern weil sie negative Erfahrungen damit verbinden.

Ich sitze nicht gerne frustriert vor der IDE

Mein größter Fehler war, dass ich es mir schwieriger gemacht habe als es eigentlich ist. Ich saß blöd vor der Kiste und habe stundenlang überlegt, wie ich eigentlich anfange. Hätte ich mir in dieser Zeit mal einen Stift, ein Blatt Papier und etwas Süßkram geholt. In meinem Kopf schwirrte immer noch die Vorstellung darüber herum, wie das Ergebnis meiner Idee aussehen soll. Kein Wunder, dass es bzw. ich nicht sofort funktionierte.

Möchte ich z. B. ein neues Spiel programmieren, dann erfinde ich den Spielablauf komplett neu. Ich überlege mir Zusammenhänge, Regeln, Spielfiguren, Attribute dieser Spielfiguren und vieles mehr, was ich dann z. B. als Mindmap auf Papier bringen kann. Die Gesamtheit all dieser Überlegungen macht dann Version 1 meines Spiels aus. Aus dieser Mindmap kann ich eine Gliederung in einzelne Komponenten erstellen, aus der ich wiederum genaue Ablaufpläne machen kann. Dann ist der Bauplan des Spiels fertig. Nun muss dieser nur noch in irgendeiner Programmiersprache Stück für Stück aufgebaut werden und fertig ist das neue Spiel. Dieses Vorgehen macht daraus auch kein Hexenwerk mehr. Man kann die Sprache noch nicht so gut? Auch kein Problem, denn man weiß ja jetzt, wie man anfangen muss und was man braucht. Die kurze Recherche zu den Besonderheiten der Sprache ist es wert. Man wendet es an, lernt es und weiß es beim nächsten Mal ohne vorherige Recherche.

Ich wusste aus der Mathematik, dass methodisches und strukturiertes Vorgehen zur Lösung von mathematischen Problemen führt. In der Programmierung ist es genauso. Es reicht nicht, eine Programmiersprache zu lernen, weil dieser wichtige Schritt einen erst dazu befähigt, Anwendungen zu entwickeln. Wer keine Vorstellung darüber hat, was er eigentlich konkret haben will, der wird seine Idee auch nicht umsetzen können. Die Programmierung hat mich hier verändert. In allerlei Lebensbereichen versuche ich ohne groß darüber nachzudenken, größere Probleme in Teilprobleme zu zerlegen. Ebenso fiel mir auf, dass man es sowieso die ganze Zeit macht, ohne groß darüber nachzudenken. Plant man beispielsweise eine Feier, dann wird alles um die Feier herum in kleinere Aufgaben zerlegt. Fragen der Mahlzeiten, der Getränke, der Musik, der Zeitplanung, des Ortes und viele weitere werden geklärt und am Ende entsteht die fertige Feier. Auch Einsatzkräfte (Feuerwehr, Polizei, Rettungsdienst) teilen ihre Probleme in Teilprobleme auf (z. B. Spurensicherung). Dazu genügt der einfache Blick in das Thema Erste Hilfe. Auch Algorithmen begegnen uns im Alltag ständig. Abläufe der Einsatzkräfte sind festgelegt, es gibt Gesetze für die unterschiedlichsten Anwendungsfälle, Prozesse in Unternehmen folgen einem Plan und als Gewohnheitstier eignet man sich den einen oder anderen Algorithmus selbst an.

Warum also gegen die Programmierung wehren? Das Konzept erleben wir jeden Tag. Wir müssen uns in der Programmierung nur daran erinnern. Schaut man sich die Fortschritte der Menschheit an, dann fällt auf, dass eine Gliederung von Problemen in Teilprobleme ein bewährtes Muster ist. Eine endliche Folge von Schritten führte zum Ergebnis des Faustkeils. Eine endliche Folge von Schritten führte zum ersten Feuer. Unglaublich viele Menschen haben über Generationen hinweg auf diese Weise gelebt und gearbeitet. Wie wahrscheinlich ist es also, dass man selbst dazu nicht in der Lage ist?

Alleine arbeite ich effizienter

Ich war nie ein wahrer Teamplayer. Ich war im Fußballverein, mochte die anderen aber nicht. In der Schule zählte ich auch nicht zu den beliebtesten (außer in Mathe, da mochten mich plötzlich alle). Gruppenarbeiten erlebte ich immer gleich. Die anderen waren entweder faul oder nicht zu gebrauchen. Ich wollte Dinge lieber alleine machen. Ist das schlimm? Ich finde es absolut in Ordnung, wenn man von Natur aus oder auch aus der sozialen Erfahrung heraus kein Teamplayer ist. "Teamwork" ist wichtig, liest man überall und natürlich auch in der IT. Sicher schreibt es auch jeder schön in die Bewerbung, denn es sind ja alle teamfähig, weil es eben gefragt ist. Meine Erfahrungen zeigten mir stattdessen immer wieder, dass ich alleine bessere Ergebnisse hervorbringen konnte. Ich war so und habe es in Ordnung gefunden. Als Programmierer hätte ich mich damals eingeschlossen und in Ruhe meinen Code getippt. Mit der Programmierung änderte sich meine Einstellung grundlegend und sicher nicht, weil Arbeitgeber Teamfähigkeit ja besonders toll finden. Ich verstelle mich auch für einen Arbeitsplatz nicht.

In der Programmierung neigt man sich schon fast automatisch einen mehr oder weniger gesunden Perfektionismus an. Man möchte den eigenen Code und die Qualität der Anwendung selbst immer weiter verbessern (Refactoring) und stößt irgendwann an Grenzen, weil die eigenen Kenntnisse vielleicht nicht mehr ausreichen (z. B. weil man kein Frontend / Backend kann) oder man selbst (gefühlt) ständig Fehler übersieht (besonders schlimm bei Skriptsprachen, die einem so einiges verzeihen). Es wäre doch super, wenn einer oder mehrere dabei helfen könnten. Vier Augen sehen mehr als zwei und fehlende Kenntnisse kann ein anderer ausgleichen. Aus diesem Gedanke heraus habe ich meine Teamfähigkeit entwickelt. Ich sehe andere nicht mehr als Last, sondern vielmehr als Stütze, wenn ich etwas schlicht und ergreifend nicht kann oder einen Fehler einfach nicht finde. Ich habe viel im Leben gelernt und finde es absolut in Ordnung, wenn ich etwas nicht kann. Dafür kann ich andere Dinge, die andere wieder nicht können. Sicher mag es für den einen oder anderen unverständlich klingen, aber die Programmierung hat meine Persönlichkeit und meinen Umgang mit anderen Menschen verändert. Ich bin heute absolut teamfähig und will nicht außerhalb eines Teams arbeiten. Für mich ist es unbestreitbar, dass Teamfähigkeit die wichtigste Eigenschaft eines Entwicklers ausmacht. Das gilt vor allem dann, wenn das entwickelte Produkt nicht für ihn selbst gedacht ist.

Andere wissen meine Arbeit nicht zu schätzen

Auch Kritik sehe ich inzwischen anders. In meinen Augen gibt es (mit Ausnahme von schwachsinnigen Aussagen) keine negative Kritik. Ich betrachte alles als willkommen, was meine Arbeitsweise effizienter gestalten kann. Kritik an einer Anwendung von mir hiflt im besten Fall nur dabei, dass sie noch besser wird. Es gibt keinen nachvollziehbaren Grund, wieso man Kritik ablehnend gegenüberstehen sollte. Auch dieses Muster lässt sich auf die Realität übertragen, denn andere nehmen einen oft anders wahr als man selbst. Wahrnehmung ist individuell, resultiert aus Erfahrungen (Verknüpfungen im Gehirn) und das eigene Handeln zu hinterfragen gelingt nur schwer, wenn man sich immer im selben Kosmos bewegt. Deshalb halte ich Kritikfähigkeit für die zweitwichtigste Eigenschaft eines Entwicklers und sie ist genauso wie die Teamfähigkeit nicht unbedingt angeboren. Zum Glück hat man immer mindestens einen, der die eigene Software kritisiert: Der Compiler oder Interpreter.

Das Problem mit den Fehlermeldungen

Ständig diese nervigen Fehlermeldungen über Fehler in der Syntax. Die Anwendung will einfach nicht wie man selber will. Jeder Entwickler kennt es. Die einen beißen sich durch, die anderen geben auf. Die einen probieren herum, bis es funktioniert und... warte mal, da war doch etwas? Ja richtig, die Fehlermeldung. Ich war es damals gewohnt, einen Computer als Anwender (!) zu nutzen. Was machen Anwender in der Regel selten? Die Fehlermeldung lesen und verstehen. Sowas klickt man weg oder teilt es einem Support mit, wenn der danach fragt. Hier lag bei mir damals der Hund begraben. Ich bekam Fehlermeldungen und habe herumprobiert, bis es irgendwann lief. Warum es zuvor nicht ging, dann aber schon, war mir aber auch bei Erfolg nicht klar. Stundenlang saß ich an solchen Problemen. Absurd daran ist, dass es nur Syntaxfehler waren. Ich kannte die Regeln der Sprache noch nicht so gut und habe die Fehlermeldungen nicht versucht zu verstehen. Das konnte ja nichts werden. Als ich mich dann in die Fachliteratur vertiefte und begann, die Fehlermeldungen zu lesen und zu verstehen, lief vieles von selbst. Habe ich sie wirklich mal nicht verstanden, dann war mir aber auch klar, dass jemand anderes dieses Problem mit absoluter Sicherheit schon hatte, denn es waren Fehler in der Syntax. Heute glaube ich, dass ich dadurch mehr über eine bestimmte Sprache gelernt habe als durch die Fachliteratur. Besonders interessant war es dann, als die Fehler logischer Natur waren. Hat man sich wie ich bis spätestens hierhin nicht mit dem Thema Debugging beschäftigt, dann hat man eine weitere frustrierende Phase vor sich, aber (!) dafür lernt man dann auch sehr viel über die Fallstricke und Besonderheiten in einer bestimmten Sprache. Also eigentlich sehr praktisch, wenn man dadurch viel lernt. Wer das beschleunigen möchte: Beim Debugging findet man die Lösung. Hat eine Zahl einen unerwarteten Wert, dann sollte direkt die Frage nach dem Warum folgen.

Man muss so viel wissen

Ja und nein. Mich hat die Fülle an Informationen auch abgeschreckt. Ich habe meinen Einstieg mit JavaScript gefunden, in dem ich mir zuerst Tutorials ansah und recht zügig kleinere Algorithmen umsetzen konnte. Später kaufte ich mir das Buch Einstieg in JavaScript vom Rheinwerk-Verlag. Dieses Buch hat etwas mehr als 500 Seiten. Nun gibt es aber auch Bücher mit 1200 Seiten und mehr. Und ich befürchte, dass man auch danach nicht alles über diese Sprache weiß. Ich befürchte sogar, dass in allen Programmiersprachen niemand alles über diese eine Sprache weiß. Wie soll das bei der Vielzahl an Frameworks auch realisierbar sein? Muss man das denn überhaupt? Ich denke, man beherrscht eine Sprache genau dann, wenn man Anwendungen nach eigener Vorstellung umsetzen kann. Je länger man damit arbeitet, desto mehr eignet man sich im Laufe der Zeit an. Letztendlich kann man die Sprache bis ins kleinste Detail lernen und danach immer noch nicht programmieren, wenn die oben geschilderten Zusammenhänge nicht verinnerlicht wurden. Man befindet sich auf dem Holzweg, wenn man glaubt, man beherrscht Syntax und Semantik der Sprache, also kann man auch Anwendungen umsetzen. Hat man die oben geschilderten Zusammenhänge verstanden, dann kann man programmieren. Das Tolle daran ist, man muss nur einmal lernen zu programmieren. Die Sprache ist dann zweitrangig. Hat man ein Gefühl dafür entwickelt, wie man Projekte umsetzt und kennt die Grundlagen der Sprachen (z. B. Datentypen), dann kann man jede Programmiersprache lernen. Diese Fähigkeit ist die wichtigste überhaupt, denn es liegt in der Natur der Sache, dass wir uns immer fortbilden müssen. Wir brauchen die Fähigkeit, uns in neue Technologien einarbeiten und bekannte Muster darin einsetzen zu können.

Fazit

Für mich ist die Programmierung eine Kunst, die man nur erlernen kann, wenn man sie ausübt. Ohne malen wäre Leonardo da Vinci wohl auch nie so gut geworden. Die wichtigsten Skills sind meiner Meinung nach Teamfähigkeit, Kritikfähigkeit, Ehrgeiz und Lernwille. Sie hilft bei der kreativen Entfaltung und der weiteren Ausprägung der benötigten Skills. Die Methoden der Programmierung begegnen uns seit Generationen und es ist unwahrscheinlich, dass man sie nicht erlernen kann, obwohl man es wirklich möchte. Geht man strukturiert an ein Projekt heran, dann kann man es auch umsetzen.

Ich hoffe, mein Beitrag wird dem einen oder anderen dabei helfen, seinen Weg in die Programmierung zu finden und das negative Bild von der Programmierung abzulegen. Mindestens genauso cool fänd ich es, wenn andere in diesem Thread ebenso über ihre ersten Schritte (oder auch Krabbelversuche) berichten und er nicht -wie in Foren üblich- für Selbstdarstellung und "Battles" zweckentfremdet wird.

Java1408;

[hellerKopf]

Wann wird denn in deiner Umschulung der Kurs Programmieren stattfinden?
Da musst du uns dann berichten, wie die Durchführung in einer stark heterogen Gruppe so läuft.

[tkreutz2]

vor einer Stunde schrieb hellerKopf:

Da musst du uns dann berichten, wie die Durchführung in einer stark heterogen Gruppe so läuft.

Ein eigener Blog wäre dazu besser geeignet, dann sind die Texte in chronologischer Ordnung und das Thema Blog beinhaltet einen Lernfaktor. Hosting für einen Blog ist gar nicht so teuer, wenn jemand Spaß daran findet. Ein eigener Blog könnte auch spätere Bewerbungen aufwerten, wenn er gut gemacht ist. Aber das ist nur eine Idee am Rande.

@Java1408
Danke für den Beitrag 

[Gast Java1408]

vor 2 Stunden schrieb hellerKopf:

Wann wird denn in deiner Umschulung der Kurs Programmieren stattfinden?
Da musst du uns dann berichten, wie die Durchführung in einer stark heterogen Gruppe so läuft.

Du liest ja meine Berichte immer. Deshalb glaube ich, dass es einfach in Vergessenheit geraten ist. Wir hatten schon zwei Wochen lang Programmierung. Es war der erste Kurs im Rahmen der Umschulung. Die Grundlagen der Programmierung (inklusive OOP) wurden zusammen mit Python unterrichtet. Für die Mehrheit der Teilnehmer war der Kurs nicht gerade einfach. Unter den angehenden FiSi wurde auch immerzu darüber gesprochen, dass man davon "ja eh nicht viel braucht" und einfach keinen Zugang zu diesem Thema findet. So mancher hat sogar vollkommen abgeschaltet (auch angehende FIAE). Meine Wahrnehmung ist also, dass manche beim Begriff Programmierung direkt abschalten, ähnlich wie es bei Mathematik ist. Deshalb der Beitrag. 😝

Ich weiß gar nicht, wie das in der Berufsschule ist. Wir hatten im September Programmierung und haben dieses Thema erst im nächsten Jahr wieder. Ich denke, der Nachteil daran ist, dass man vieles bis dahin schon vergessen haben könnte. Dafür hatten wir es zwei Wochen lang und das acht Stunden täglich. Wie wurde Programmierung denn bei euch in der Berufsschule unterrichtet? Regelmäßig oder auch immer mal wieder?

vor 49 Minuten schrieb tkreutz2:

Ein eigener Blog wäre dazu besser geeignet, dann sind die Texte in chronologischer Ordnung und das Thema Blog beinhaltet einen Lernfaktor. Hosting für einen Blog ist gar nicht so teuer, wenn jemand Spaß daran findet. Ein eigener Blog könnte auch spätere Bewerbungen aufwerten, wenn er gut gemacht ist. Aber das ist nur eine Idee am Rande.

Ein eigener Blog klingt sehr interessant. Darüber habe ich noch gar nicht nachgedacht. Um mich weiter in Sachen Front- und Backend zu vertiefen, hatte ich sowieso vor, eine Webpräsenz aufzubauen. Damit der Lerneffekt möglichst groß ist, wollte ich bis auf die Domain alles selber machen (ja, ich kenne die damit verbundenden Nachteile). Wenn es die Freizeit hergibt, werde ich vielleicht in einem Blog über meine Umschulung berichten und das Thema outsourcen. Da es dann aber über meinen vollen Namen laufen wird, würde ich den Link hier nicht veröffentlichen.

Vielleicht schildere ich hier dann meine Planung, wie ich diesen Blog umgesetzt habe und dokumentiere Stück für Stück, wie die einzelnen Komponenten zusammengeführt wurden. Würde meinen vorherigen Beitrag zumindest sehr gut ergänzen. Ich denke aber, dass ich das erst dann angehe, wenn wir Web Development haben und das wird noch dauern.

Bearbeitet 24. September 2022 von Java1408

[be98]

Auf dieser Seite gibt es ja auch einen Blog  Bereich. Dann  würde ich den vorschlagen 

[Whiz-zarD]

vor 2 Stunden schrieb Java1408:

Meine Wahrnehmung ist also, dass manche beim Begriff Programmierung direkt abschalten, ähnlich wie es bei Mathematik ist. Deshalb der Beitrag. 😝

Das ist ne Beobachtung, die ich schon seit zwei Jahrzehnten mache. Offenbar ist das für viele einfach Teufelszeug from outa space, mit dem man nichts zu tun haben möchte. Ich brauche nur sagen, dass ich Softwareentwickler bin und schon kommt von den Gesprächspartnern: "Aha. Da hab ich keine Ahnung von." und schon ist das Gespräch beendet.

Wenn man gerade mit der Programmierung anfängt, sollte man sich auch nicht gleich auf OOP stürzen. Das verkompliziert die Sache einfach nur. Zumal der wahre Vorteil von OOP meist nie wirklich erkannt und gelehrt wird. Darum feiere ich auch die neue Minimal-API in C#. Die ermöglicht mir jetzt, den neuen Azubis das Programmieren mit C# näher zu bringen, ohne schon mit verwirrenden Begriffen, wie statische (Main-)Methode und Klassen anfangen zu müssen. Der Azubi kann sich voll und ganz auf das wesentliche konzentrieren und das sind im ersten Schritt die Datentypen, Variablen und Kontrollstrukturen.

OOP klingt am Anfang auch immer ganz simpel: "Wir wollen ein Auto modellieren, also haben wir die Klasse Auto." Ist alles schön und gut aber die meiste Zeit hat man es mit sehr abstrakten Gebilden zu tun, die in der realen Welt nicht existieren.

Ich denke, das größte Problem ist die gigantische Informationsflut, die das Internet ausgelöst hat und Anfänger auf der einen Seite mit einer vollkommen überzogenden Erwartungshaltung an die Sache ran gehen und andere wiederrum fühlen sich verunsichert. Die heutige Informationsflut hat aus meiner Sicht vieles verkompliziert. Es macht die Sache nicht einfacher, wenn man plötzlich die Auswahl von Tausend Sprachen und Millionen Frameworks hat. Wo soll ein Anfänger da anfangen? Zumal heute ja gleich alles sofort bunt sein muss. Es muss ja gleich eine große Smartphone-App sein, weil irgendwelche Marketing-Leute suggierieren, dass Smartphone-Apps auch von Kleinkindern programmiert werden können, weil das alles so einfach ist. Niemand gibt sich mehr mit Konsolenanwendungen zufrieden, obwohl was besseres zum lernen gibt es kaum. Man ist dort frei von Sprachfeatures, Patterns und Frameworks und kann sich voll und ganz auf die elementaren Dinge konzentrieren. Da aber alle sofort eine Smartphone-App basteln wollen, sind sie schnell mit Dingen konfrontiert, die sie nicht verstehen und da ist es auch schnell vorbei mit der Lust und dann entstehen auch solche Stories, dass doch alles so kompliziert sei, die dann die Runde machen.

Ich selber hab mit dem Programmieren angefangen, da war ich 7 oder 8 Jahre alt. Das war Anfang der 90er. Da gab's kein Internet und ich auch hatte im Freundes- und Familienkreis keinen, der sich damit auskannte. Mein Bruder hatte sich damals von seinem ersparten Geld ein C64 gekauft. Er hat damit gespielt und ich blätterte ein wenig im Handbuch rum. Ich hab kein Wort verstanden, was da drinnenstand. In diesem Alter ist das Lesen sowieso noch etwas schwierig. Aber es waren Screenshots von Quellcode drinnen und ich fragte mich, was passiert, wenn man es abtippt und startet und siehe da, es passierte etwas. Ich fand das cool und hab mich immer mehr dafür interessiert. Klar, in dem Alter und mit den wenigen Informationen, die man hatte, stieß man doch sehr schnell an seine Grenzen. Dennoch probierte ich vieles aus und hab auch versucht, ein Mathe-Trainer zu basteln. Ähnlich wie der Little Professor.

Ich hab mir da nie Gedanken um Mathematik gemacht. Selbst nicht mal, als ich damals mit QBasic angefangen hatte, ein kleines Framework für grafische Oberflächen zu entwickeln. Ein Button ist ein Rechteck und der Mausklick musste innerhalb dieses Rechteckes sein. Ja, kann man mit Hilfe von lineare Algebra, Triangulierung und sonstigen Kram ausrechnen ober man vergleicht einfach die einzelnen Ordinaten miteinander. Also einfach nur ein paar größer oder kleiner Vergleiche. Es muss nicht immer komplexe Mathematik sein.

[hellerKopf]

vor 3 Stunden schrieb Java1408:

Du liest ja meine Berichte immer. Deshalb glaube ich, dass es einfach in Vergessenheit geraten ist. Wir hatten schon zwei Wochen lang Programmierung. Es war der erste Kurs im Rahmen der Umschulung. Die Grundlagen der Programmierung (inklusive OOP) wurden zusammen mit Python unterrichtet.

Sorry, hab mich falsch ausgedrückt.
Ich meinte den Kursabschnitt, den du für nächstes Jahr ankündigst.

Die zwei Wochen am Anfang, wären ja der Wahnsinn, wenn es schon alles ist.
Wie man in die zwei Wochen auch OOP reinpressen kann, ist mir total unverständlich.
Das steht auch so in keiner ernsthaften Planung.
 

[Gast Java1408]

vor 1 Stunde schrieb hellerKopf:

Wie man in die zwei Wochen auch OOP reinpressen kann, ist mir total unverständlich.
Das steht auch so in keiner ernsthaften Planung.
 

Das dachte ich mir auch. Es wurde aber auch am Ende der zwei Wochen von keinem erwartet, dass man programmieren kann und erst recht nicht, dass man die Sprache Python beherrscht. Bei mir passierte das aufgrund der Vorkenntnisse automatisch, was für dich sicher leicht nachzuvollziehen ist. Die nachfolgenden Kurse beinhalten das Thema OOP auch noch mal. Ging es wirklich nur darum, einen Eindruck zu gewinnen, dann finde ich es ok, wenn man OOP zumindest mal gesehen hat.

@Whiz-zarDDanke für deinen tollen Beitrag. Ich arbeite auch gerne mit Konsolenanwendungen (mag einfach das IT-Feeling 😅), kann aber auch die Ansprüche an eine grafische Oberfläche verstehen. Ich habe JavaScript ausschließlich auf Konsolenebene kennengelernt, weil im entsprechenden Tutorial HTML und CSS nicht besprochen wurden. Das passte mir auch sehr gut, denn so konnte ich mich wirklich auf die reine Programmierung konzentrieren. HTML und CSS kamen erst später und haben das Thema abgerundet. Ich stimme dir also zu, dass man auf Basis einer Konsolenanwendung besser lernt zu programmieren.

Nehmen wir an, ich schaue mir ein Tutorial über Web Development auf Youtube an. Dann kann ich ein bisschen JS, ein bisschen HTML und ein bisschen CSS. Das Tükische daran ist, dass das Thema IT-Sicherheit in solchen Videos oft nicht angesprochen wird. Ich kenne kein Youtube-Tutorial zur Programmierung, in der im Laufe der Videos beispielsweise das Thema "Validierung von Nutzereingaben" angesprochen wird. Werde ich nun vor eine Software gesetzt, dann kann das Ganze katastrophale Folgen haben. Vielleicht gibt es auch solche Tutorials, aber insgesamt sollte man das Thema mit Vorsicht genießen. Das Problem ist, dass einem dann ja immer signalisiert wird, man könne in kurzer Zeit eine Programmiersprache lernen und danach 60.000€ im Jahr verdienen. Letztendlich geht es dann auch nicht darum, dass man mir bei der Jobsuche helfen möchte, sondern darum, dass man mir irgendwelche Kurse andreht. Seit ich FIAE lerne wird mir zunehmend bewusst, wo mir schlicht und ergreifend Qualifikationen fehlen. Sicher kann man auch als Autodidakt in der Programmierung einsteigen, wenn man wirklich sehr gut ist, aber man hat nun mal oft Defizite, weil der Rest aus der IT fehlt und der ist ebenso wichtig. Bitte nicht falsch verstehen, es geht nicht darum, Quereinsteiger irgendwie schlecht zu machen. Sehr wohl geht es mir aber darum, auf die Qualität und Vollständigkeit solcher Kurse hinzuweisen. Ich möchte auch nicht behaupten, dass die Kurse immerzu schlecht sind. Das kann ich nicht beurteilen, denn ich habe nie an einem solchen Kurs teilgenommen.

Zum Thema Frameworks hatte ich auch etwas geschrieben, aber das wäre echt zu viel. Kurzfassung: Sehe ich genauso. Man muss sich nur mal React ansehen und mit JS vergleichen (Stichwort JSX).

[Gast Altair8800]

Meiner Meinung nach geht Programmieren lernen auch nicht in den paar Monaten einer Umschulung oder Ausbildung. Die, die es bei uns am Ende geschafft hatten, haben auch privat ganz viel gemacht und/oder Vorkenntnisse gehabt. OOP ist sehr abstrakt, ich habe Ewigkeiten kein OOP eingesetzt, oder "nur" zur Gruppierung/Kapselung von Aufgaben. Von den Klassen gab es dann allerdings auch oft nur eine Instanz, also reichte es oft alles statisch zu machen. Meist brachte mir OOP Wissen was wenn ich andere Frameworks/Bibliotheken nutzen wollte oder musste.

Mittlerweile finde ich DesignPattern und auch die ersten ArchitekturPattern sehr interessant, da ich auch Projekte vom Scratch in meinem jetzigen Job entwickle und da macht OOP etc. oft Sinn, aber auch nicht immer.

Allerdings einen Einsteiger gleich mit OOP zuzuballern halte für extrem demotivierend. Die Grundlagen sollte absolut sitzen um dann auch den Vorteil oder Nachteil von OOP überhaupt begreifen zu können. Man kann nämlich mit OOP ein simples Programm komplett künstlich aufblähen und mit "99" DesignPattern dann auf "200" Dateien verteilen, so dass am Ende keiner mehr durchblickt, aber theoretisch ist das Projekt für die nächsten 1000 Jahre für jede Veränderung anpassbar (um das mal alles hier etwas überspitzt darzustellen).

Von Tutorials schauen habe ich noch nie Programmieren gelernt, das half meist nur für einen ganz groben Überblickt. Programmieren lernt man durch Erfahrung, also Fehler machen bis der Arzt kommt in eigenen Projekten. Etwas Nachprogrammieren bringt einen nicht so viel und kann nur ein ganz grober Einstieg sein. Niemand wird nach 4 Wochen Fachbuch lesen, Udemy Masterclass Kurs machen oder durch YT-Tuts jumpen zum Programmierer. Vielleicht gibt es ja Genies die sowas schaffen, ich habe Jahre gebraucht um die Grundlagen wirklich zu kapieren und lerne immer noch jede Woche dazu. 

Zum Thema Mathematik: Über die Grundlagen hinaus habe ich nie Mathematik gebraucht, ein wenig Boolseche Algebra kann nützlich sein, aber ansonsten, Ne, nicht wirklich. Bei uns haben wir eine Menge Mathematiker, die kümmern sich um die Mathematische Modellierung von Problemen. Ich habe damit rein gar nichts zu tun. Ich mache den ganzen Kram dann nur benutzbar für den Anwender. Meist muss ich dabei nicht groß denken, da ich im Endeffekt "nur" Frameworks zusammen "klebe" und hier und da Datenbankabfrage erstelle. Die meiste Arbeit bei mir ist Recherche, Fehlersuche und Meetings vorbereiten, wo dann der Fortschritt besprochen wird und wir zusammen die nächsten Schritte planen. 

 

Bearbeitet 25. September 2022 von Altair8800

[Whiz-zarD]

vor 4 Stunden schrieb Altair8800:

Die Grundlagen sollte absolut sitzen um dann auch den Vorteil oder Nachteil von OOP überhaupt begreifen zu können.

Der Vorteil von OOP ja ist auch nicht Vererbung oder Polymorphie. Das kann auch C. Wenn auch nicht so komfortabel. Es wird sogar geraten Vererbung gar nicht oder nur sparsam einzusetzen, weil man in die Gefahr läuft, Basisklassen zu verkomplizieren, sodass sie für mehrere Sachen zuständig sind und bei Änderungen alles zusammenbricht, wie ein Kartenhaus. Stattdessen ist der Vorteil von OOP die Umkehrung der Abhängigkeiten. Also Inversion of Control, denn das ist mit prozeduralen Sprachen nicht möglich aber bis jetzt ist mir noch kein Tutorial oder Buch untergekommen, das genau dies erklärt. Das sowas möglich ist, erfährt man im Grunde nur beiläufig, wenn man auf die Begriffe SOLID und Clean Code stößt oder ein Framework verwendet, das dafür Techniken bereitstellt.

[hellerKopf]

Ich empfehle
https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines.html

 

oft sind die Regel auch auf andere Sprachen übertragbar.

[Gast Altair8800]

vor 4 Stunden schrieb Whiz-zarD:

Also Inversion of Control, denn das ist mit prozeduralen Sprachen nicht möglich aber bis jetzt ist mir noch kein Tutorial oder Buch untergekommen, das genau dies erklärt.

Sind halt oft einfach nur diese Auto ist Fahrzeug usw. Beispiele beschrieben, also Vererbung. Assoziationen wie Komposition oder Aggregation werden kaum beschrieben, genau wie Entwurfsmuster oder eben das ganze SOLID Prinzip.

Bearbeitet 25. September 2022 von Altair8800