Programmiersprache oder doch Chinesisch?

Softwareentwicklung aus der Sicht des Anfängers …

Ich bin jetzt seit über sechs Monaten Auszubildende bei Flavia und muss sagen, dass ich mir meinen Einstieg in die Berufswelt ungefähr genau so vorgestellt habe.

Eine undramatische Entscheidung

Vor einem Jahr noch saß ich in einem Vorlesungssaal in der Ing-Schule an der Willhelmshöher Allee in Kassel und habe keinen Sinn gefunden in dem, was der Dozent uns vemitteln wollte. Fast schon unerreichbar schien das Ziel, welches er mit seinen Vorträgen und Anektdoten verfolgte. Noch dazu waren diese Themen und Bereiche ganz anders als die, die ich von den Münchner Unis gewohnt war und mir wurde klar, dass ich scheinbar in den zwei Semestern Java kaum was gelernt hatte – oder zumindest nichts Anwendbares. Er benutzte eine mir unbekannte IDE, die praktisch von alleine arbeitete, ganz anders als Notepad++ oder Eclipse. In München wurde von Powerpoint-Folien weitgehend abgelesen, was jedermans Motivation zur Teilnahme an den Vorlesungen unter den Gefrierpunkt sinken lies. Nach dem ersten Semester waren die 40 Leute meiner Studiengruppe auf lediglich 20 pro Vorlesung geschrumpft. Man kann ja schließlich die online gestellten Scripts und Folien zuhause selber durchlesen. Und mit dem Willen für solche Vorlesung in die Uni zu fahren, schrumpfte auch der Wille für Hörsaal-Übungen die teilweise sehr langen Fahrzeiten in Kauf zu nehmen. Bei einer Lehrzeit von circa drei Stunden pro Tag, lohnte sich die Hin- und Rückreise von zusammen gerechnet drei Stunden fast nicht. Die besten Situationen waren dann die, die beim Ausfallen einer Vorlesung, für die man sich extra nach München hinein begab, entstanden. Damit wäre die Zeit im unsinnig, wenig lehrreichen Herumsitzen für den Tag eingelöst. Natürlich füllt man dann die verlorenen Stunden mit anfälligen Projekten und Übungen, aber dafür muss man nicht zwingend eineinhalb Stunden nach München gondeln. Umziehen war keine Option, dank meines “nahen” Wohnortes, auf Grund dessen meine Chance auf ein Zimmer in einem Studentenwohnheim bei 0,001% lag.

Da spielte mir meine damalige private Lebenssituation genau in die Karten und schob mich in Richtung: “Na dann zieh ich doch einfach in eine andere Stadt, möglichst weit weg von den Eltern!”

Letztendlich landete ich in Kassel, müde von den Vorlesungen und der Suche nach Erfüllung und Bestätigung im eigenen Tun, beschloss ich mich auf eine Ausbildungsstelle bei Flavia zu bewerben. Und schon eine Woche nach meinem Entschluss wurde mir die Ausbildung zugesagt.

Somit wären wir bei dem Ende der dramatisch undramatischen Geschichte wie ich zu Flavia kam und dem Anfang meiner Ausbildung zum Anwendungsentwickler.

Das erste Mal

Das erste mal in einem richtigen Job ist eine große neue Erfahrung. Regelmäßigkeit in das vorher so unregelmäßige Leben zu bekommen ist ein, so wie ich finde, sehr positiver Lebenswandel, der zu Selbstdisziplin zwingt.

Ich wurde an den Computer gesetzt und bekam eine Java-Aufgabe namens „Getränkeautomat“ – die Logik eines Getränkeautomaten, mit Münzeinwurf und Geld-, Getränkeausgabe sowie Nachfüllen der Zustände. Meine wenig helfende Javaerfahrung brachte mich dazu mich das erste mal wirklich richtig mit Java zu beschäftigen, statt nur die Lösungen der Übungen herunterzutippen, die teilweise schon vorgegeben waren. Von Anfang an ein Programm zu schreiben, mit Nichts als Vorlage, ist eben was ganz anderes als eine schrittweise Vorgabe der Lösung. Das motiviert dann natürlich auch, „das Ding“ eigenständig durchzuziehen. Zwei Wochen brauchte ich für die Haupt- und die Bonusaufgaben. Letztere sollten dazu beitragen, meinen Anfängerstil zu korrigieren. Aus if-Abfragen und In-Class-Arrays wurden while- und for-Schleifen beziehungsweise Maps und Enums. Von letzterem hatte ich noch nicht einmal etwas gehört. Aus Konsolenausgaben wurden JUnit-Tests. Aus einfachen Strukturen wurden algorithmische, persönliche Meisterleistungen. Gefühlte zwei Semester, ein Jahr Uni, lernte ich innerhalb von zwei Wochen. Klar brauchte ich dafür länger, aber dafür verhalf mir die Aufgabe endlich zu nützlichem Wissen – ein richtiges, einigermaßen professionelles Programm zu entwickeln, das immer mehr verbessert werden konnte.

Danach war das erste Mal Webdesign an der Reihe, was mich schon immer interessiert hatte. HTML und CSS waren für mich nichts weiter als Wikipedia-Einträge und Kommentare meiner Dozenten. Doch damit zauberte ich eine Woche später schon Websites, was ich nie für möglich gehalten hätte. Wobei „zaubern“ im herkömmlichen Sinne nicht zutreffend ist, denn einen einfachen <h1> und <p> Text ausgeben und die Farben und Formen ändern konnte man nicht mit dem vergleichen, was erfahrene Kollegen auf eine leere Seite „bombten“.

Ich kam trotzdem in eine Projektgruppe, die für die einmaleins.de Seite von Flavia zuständig war. Meine Erfahrung reichte für das, was gemacht werden sollte, noch lange nicht aus. Denn das war wieder eine ganz andere Programmiersprache namens PHP, die meine Kollegen scheinbar ohne jegliche Schwierigkeiten routiniert herunter hackten. Zu dieser einschüchternden Überwältigung wurde in den ersten Tagen auch noch debugged, bei dem ich ungefähr so nützlich sein konnte, wie ein ausgeschalteter Bildschirm informativ war. Ich wusste wenig von den unverständlichen Kommandos, die sie der, scheinbar für alle komplett verständlichen, Konsole gaben. Dafür führte mich mein damaliges Team in Gerrit ein. Mit viel Geduld auch in die Benutzung des Terminals, dass ich doch tatsächlich auf meinem kleinen Mac fand. Am Ende der Woche bekam ich eine CSS-Aufgabe: Ich sollte Rating-Boxes mit CSS erstellen und programmieren. Mit Formen hatte ich da auch kaum Probleme. Nur mit den Funktionen, die diese Dinger nützlich machen sollten. Ich wusste nicht, dass man mit CSS tatsächlich Funktionen einbringen konnte. So etwas wie :before, :after oder :focus hatte ich noch nie gesehen. Dadurch dauerte die Aneignung des Wissens durch Google länger als die Aufgabe selbst, die ich letztendlich mit etwas Hilfe schaffte. Das war der Grund, wieso ich dann die folgenden Wochen Webdesignaufgaben bekam, wie den Mausparcours, den Nachbau einer Landingpage oder eines UI-Kits. Meine letzte Aufgabe war, den Getränkeautomat zu virtualisieren. Eine browser-abhängige Benutzeroberfläche die ich erstellen und stylen sollte. Da es keine Vorgaben gab, war ich um so motivierter, meine Kreativität mit vollem Erfolg einzubringen! Die letzten zwei Tage meines Projekts sollte ich CSS und HTML auch noch mit JavaScript ergänzen. Was auch komplett neu war: Wie bindet man JavaScript ein, wie schreibt man Variablen oder wie sehen verschiedenen Schreibstile von Funktionen aus:

//Diese Weise war mir bekannt
function i (){}

//Diese eher weniger
var i = function(){}

Ein Tag verbrachte ich mit den Grundlagen der Programmiersprache. Wobei das vermutlich nicht einmal die Grundlagen waren, sondern die Grundlagen der Grundlagen. Trotzdem musste ich am letzten Tag des Projekts, ein Tag später, alles umschreiben und mit jQuery verkürzen. Faszinierend: Aus circa 100 Zeilen wurden weniger als 25.

Oh, Worklogger

Wie man sich vielleicht denken kann, reichte diese Minuswissen noch lange nicht aus, um auf die gewaltige Lawine namens Worklogger, ein internes Abrechnungssystem, vorbereitet zu sein. Denn ich erkannte keine der mir bekannten Schreibstile wieder, weder in CSS noch in Javascript, geschweige denn in HTML. Massen an Workframes kamen hinzu, obwohl ich noch nicht einmal Grundkenntnisse der Basissprachen, die mir helfen konnten, besaß. Begriffe wie AngularJS, MomentJS, Bootstrap oder Lodash flogen mir um die Ohren, die mein fragwürdiges Wissen über JavaScript komplett überflüssig machten. Eine Controller.js war für mich so logisch wie ein auf Chinesisch verfasster Roman. Ich war mir noch nicht einmal sicher, ob man den Text von links nach rechts las oder doch von rechts nach links. Zum Glück segnete mich mein Projektleiter anfänglich mit Webdesigntickets, wie zum Beispiel den Druckvorlagen oder einfaches Styling von Tabellen oder Buttons.

Sobald aber etwas in JavaScript zu coden war, vernebelte sich mein Verständnis von Programmierung. Direktive über Direktive, unverständliche, vorgegebene Methoden und Funktionen, die keinen Ursprung oder gleich mehrere Bedeutungen zu haben schienen. Bindings, selectors, models, Scopes, growls, errrors, Chains, maps, services. 東東，土豆，天氣 – es war erschlagend. Ein Ticket dauerte bei mir 10-Mal so lange wie bei anderen und die meisten konnte ich nicht alleine beenden, da sie doch mit Hilfe von Frameworks viiiiel kürzer gingen. Erst auf die Idee zu kommen, ein Framework zu benutzen, dauerte bei mir schon länger, weil ich davor überhaupt erst eine Logik in meinen eigens programmierten „Kram“ bringen musste. Dann wird einem auferlegt, dass man die Logik, die man kaum bis mittel versteht, auch noch auf eine andere, ähnliche Logik mit Hilfe von Lodash.js übertragen soll. Schwer ist es auch für mich zu erfassen, ob es sich bei gewissen Fällen um Backend- oder Frontend-Themen handelt. Ich habe keine Javaunterstützung in meiner IDE. Also ist es fast unmöglich, in diesen Dateien durchzublicken, da es länger dauert, die Quelle einer Methode zu finden als sie zu verstehen.

Es fällt mir jetzt, nach einem Monat Worklogger, noch immer schwer, die Komplexität des Programms zu fassen. Die Wurzeln einzelner Variablen sind so verzweigt, dass man viel Glück braucht, um den Ursprung zu finden. Es kostet auch viel Zeit, den Zweck individueller Funktionen zu finden, denn es gibt dazu keinerlei Dokumentation und Kommentare im Code nur sehr selten. Das Einzige was einem übrig bleibt ist Google, die Vergewaltigung der Suchfunktionen in Webstorm oder das Nerven der Teammitglieder, die einem auffallend gerne, motiviert und geduldig helfen.

Meiner Meinung nach ist Worklogger nicht sehr geeignet für so blutige Anfänger wie mich. Grundlagen sollte man nicht durch das Suchen von Ursprüngen der Funktionen, die dann 23878-Mal wo anders in einem vollkommen anderen Zusammenhang verwendet werden, aufbauen, sondern durch die wenigstens einmalige und durchgehende Entwicklung eines Programms. Ohne vorhandenen Boden kann man ein Glas auch nicht füllen. Jeden Tag bringt man sich immer nur ein bisschen bei. Die Lernmethode nach Versuch und Irrtum von Jennings und Holmes mag in vielen Situationen des Lebens hilfreich sein, in diesem Fall allerdings verzögert sich der erfolgreiche, kognitive Vorgang um Lichtjahre.

Sofern wurde es mir wohl nicht gerade erleichtert, mir Wissen anzueignen. Ich habe aber gehört, dass es bei den meisten Projekten gar nicht anders läuft. Es ist immer wieder neu sich in ein großes Projekt einzuarbeiten, manches ist sogar vielleicht in einer ganz anderen Programmiersprache geschrieben. Mit wachsender Erfahrung fällt es hoffentlich immer einfacher, sich einzuarbeiten. Mein MMIX-Professor aus München hat immer sowas gesagt wie “Kennst du eine, kennst du alle”. Und das als MMIXler, der Verbreiter eines eigens erfundenen Modellcomputers, den man kaum ausserhalb der Uni kennt (MMIX: http://mmix.cs.hm.edu/).

Gelernt ist gelernt

Dessen ungeachtet habe ich andererseits durch dieses Vorgehen viel gelernt. Langsam zwar, aber viel. Ich bin mir nicht sicher, in wie weit das Aufzählen meines Gelernten interessant sein sollte, aber das wichtigste, was mir bis hier hin aufgefallen ist, dass man mit Ehrgeiz und Google alles erreichen kann. Es gehört viel Frustration dazu, bis man sein Ziel erreicht, aber “Bist du nicht frustriert, machst du was falsch” waren die Leitworte der Einführungswoche im Studiengang Ingenieurwissenschaften an der TUM. So langsam denke ich, dass es keine treffendere Beschreibung für Informatik gibt. Dessen ungeachtet sind auch nur die kleinsten Fortschritte und Erfolge, und sei es auch nur eine richtige Ausgabe, tag-verbessernd. Darauf ist es Wert hinzuarbeiten, auf das Gefühl, das wohl jeder Programmierer kennt. Das Master-of-the-Universe-Gefühl wenn was funktioniert oder zumindest keine Fehler mehr wirft. Je mehr ich lerne beziehungsweise programmiere, desto öfters werde ich wohl dieses Gefühl haben.