Und wenn ich mich an mein Studium zurück erinnere würde ich sagen, dass höchstens 30 % der Informatiker annehmbar programmieren können. Daran kann es also auch nicht liegen.
Das Verhältnis von Informatik zu Programmierung ist .... schwierig. :-)
Jeder Informatik-Prof wird Dir sagen, das Informatikstudium ist kein Programmierkurs. Was auch stimmt. Ein Informatikstudium ist eher recht mathe-lastig. Klar lernt man auch viel über Algorithmen und Datenstrukturen. Die eigentliche Programmierung nimmt aber einen vergleichsweise kleinen Raum ein (gibt sogar Studenten die sind durch das Studium gekommen ohne eine Zeile Code zu schreiben).
Und das das so ist, ist auch nicht "Bug", sondern "Feature". :-)
Das Informatikstudium ist mit Absicht so ausgelegt. Und es ist auch nicht so das man das was man da lernt als Programmierer nicht gebrauchen kann. Aber es bildet halt nur einen Teil ab. Salopp gesagt: Wie Du nen ausgeklügelten Algorithmus hinzauberst lernst Du. Wie Du vermeidest das Du bei der Implementierung einen BufferOverflow einbaust eher nicht.
Wobei Sicherheit und Qualität grundsätzlich schon ein Thema sind. Beispielsweise durch den Bereich Softwareverifikation abgedeckt. Ein Verfahren, was gut funktioniert aber gleichzeitig auch aufwendig ist, das es in der Praxis eh keiner macht (auch wenn es bei funktionaler Programmierung tatsächlich auch praktisch in Teilen gut machbar ist; das Haskell-Umfeld hat dich dem so ein bisschen angenommen).
Kurzum: Du hast bei Informatik viel Theorie und eher weniger Praxis. Während man bei der Ausbildung zum Entwickler zwar viel Praxis hat aber tendenziell zu wenig Theorie.
Und was völlig illusorisch ist und auch keine Ausbildungsstätte leisten kann ist dann noch Wissen zu vermitteln von dem, was gerade angesagt ist. Weil das halt so schnelllebig ist, das man da gar nicht hinterher kommt das jeweilige Framework-of-the-week zu behandeln.
Das wäre auch alles noch gar nicht so dramatisch. Sich in Frameworks einzuarbeiten ist ansich kein Problem. Hier kommt auch wieder der Zeitfaktor zum tragen. Die Zeit sich in ein Framework einzuarbeiten und erst mal nur damit herumzuspielen, um zu gucken, wie es tickt und wie die Sachen funktionieren gibt Dir keiner.
Besonders schön zu beobachten an irgendwelchen hippen Startups die ein hippes Framework einsetzen um damit eine hippe App zu basteln.
Überhaupt ist Programmierung und Programmieren lernen und können sehr viel von Erfahrung geprägt. Das kennt jeder Entwickler der sich alten Code von sich selbst anschaut.
Dann werden irgendwelche "Komplexitaetsmonster-Frameworks" genutzt, nur weil man eine Funktion davon benoetigt. So schoen die ganzen Paketmanager auch sind, man weiss nie, welche Probleme man sich durch inkludierte Abhaengigkeiten einfaengt.
Ja. Haben wir ja mehr oder weniger regelmäßig. Das irgendwie die node-js Anwendung nicht mehr läuft weils irgendein Package nicht mehr gibt oder Malware reingezogen wird, weil bei all den um drei Ecken eingezogenen Abhängigkeiten gar keiner mehr nen Überblick hat (und haben kann).
Komplexität ist in der Tat generell ein großes Problem.
Aber teilweise fangen die Probleme schon im Kleinen an. Kompiliert mal jetzt irgendein Projekt. Egal ob Open-Source oder bei euch in der Firma. Schaut mal wieviel Warnings dabei so der Compiler ausspuckt. Die gibt er ja nicht umsonst. Die deuten ja tatsächlich auf ein potentielles Problem hin. Klar kann es im Einzelfall immer gute Gründe geben, warum trotz Warnung der Code so ok ist. Aber 99% der Warnings lassen sich halt nicht so begründen.
Ist nicht so schlimm. Fixen wir später. Wenn wir mal Zeit haben. Indianerehrenwort! :-)
Das Problem ist meiner Meinung nach u.a. die agile Softwareentwicklung. Da wird in einem Team auf die Schnelle ein Prototyp entwickelt und so lange daran rumgedoktert, bis der Kunde damit "zufrieden ist" und weiss, was er ueberhaupt will.
Wobei agile Softwareentwicklung halt auch vielfach falsch verstanden wird. Es reicht eben nicht irgendwen im Team zum Scrum-Prister zu ernennen und irgendwelche Prototypen hinzuschludern. :-)
Auch Prototyping ansich ist nicht verkehrt. Das wird erst dann zum Problem, wenn man den Prototyp mehr oder weniger 1:1 übernimmt um daraus das Produkt zu machen.
Ich bin auch eher jemand der nicht irgendwie einen Masterplan entwirft und den dann befolgt, sondern der iterativ entwickelt. Auch zumindest zu Anfang mit starken Prototyp-Charakter. Allerdings ist der Quelltext dann auch im Verlauf ständig relativ starken Änderungen unterworfen.
Der sieht jede Woche anders aus. :-)
Im Grunde wird das Programm (oder Programmmodul) rein von der Tipparbeit oder von den Lines-of-Code her gesehen nicht irgendwie 1x geschrieben, sondern eher 10x.
Aber auch so reicht bestehender Code ja hinten und vorne nicht. Wenn es noch darum geht, um zu gucken ob man eine Sache soundso lösen kannst, brauchst Du ja viele Sachen nicht. Sowas wie Fehlerbehandlung, Eingabeüberprüfung usw. Das hast du alles nicht in einem Programm was noch Prototypen-Charakter hat.
Interessanterweise sind das aber genau die Sachen, die in der Praxis am häufigsten zu Stolpersteinen für Programme werden.
Deswegen macht man aus der Not eine Tugend und bildet sich auf eigene Faust weiter. Sich von einem Arbeitgeber abhängig zu machen ist sowieso immer eine blöde Idee.
Logisch macht "man" das. Das ist ja auch gar nicht die Frage.
Die Frage ist eher, ob das so gut ist. Weil es (wir sind wieder beim Thema) eine Zeitfrage ist. Wenn Du den ganzen Tag im Büro zu tun hast, hast Du nicht unbedingt die Lust auch noch in der Freizeit Dich weiterzubilden bzw. kannst Du das machen, aber Dir fehlt halt die Zeit wirklich mal abzuschalten.
Das endet dann also oft daran, das Du in der Firma lernst. Und zwar in dem Du die neue Technologie beim aktuellen Projekt einsetzt. Nur bist Du dann in einer Phase in der Du das halt noch nicht beherrschst (wie oben schon ausgeführt). Aber Dein Code wird dann trotzdem produktiv eingesetzt und macht da dann Probleme.
Das der Arbeitgeber Weiterbildung ermöglicht soll jetzt auch nicht verstanden werden als "Der Arbeitgeber meldet seine Leute bei nem Volkshochschulkurs an von dem er meint der wäre ganz gut und die müssen das dann irgendwie absitzen".
Da gibts ja durchaus Möglichkeiten das nützlicher zu gestalten. Der wesentliche Punkt ist halt, das die Leute einen Zeitrahmen dafür kriegen, wo einem nicht das Management im Nacken sitzt weil der Sale dem Kunden irgendwelche neuen Features für dieses Quartal versprochen hat.
Auf der anderen Seite entwickeln viele Teams ihre eigenen Logging-, ORM-, Web- und sonstige Frameworks, wodurch sie mit viel Aufwand wenig nützliche Anwendungen abliefern.
Ja. Es macht sicher nicht Sinn alles selbst zu entwickeln. Es ist immer besser etwas Bewährtes zu nehmen was schon da ist. Wo sich jemand bereits Gedanken gemacht hat. Wo keine Kinderkrankheiten mehr drin stecken mit denen Du Dich herumplagen musst usw.
Mitunter ist es aber schwierig sich in dem Dschungel an Frameworks zurecht zu finden. Du hast sozusagen die Qual der Wahl. Also nimmst Du im Zweifel eher das, was alle nehmen. Wenns aber für viele Leute passt (zumindest irgendwie), dann ist das halt üblicherweise kein kleines, elegantes, überschaubares Framework, sondern eher ein allgemeines, Bloatiges. Am besten noch mit nem dutzend Abstraktionslayer, das wenn "unten" was schief geht Du auch wirklich chancenlos bist das wieder hinzubiegen. :-)
Man muss also schon ein bissl gucken. Das sind jetzt alles keine Sachen und Stolperfallen die man nicht irgendwie umschiffen kann. Aber auf dem Weg zur Lösung gibts halt ne Menge Pfade rechts und links, wo Du schnell mal falsch abbiegen kannst.
Die Wahrheit liegt wie üblich irgendwo in der Mitte.
Kann man so sagen. Und nu bitte 3€ ins Phrasenschwein. :-)
