5 Dinge, die man als angehender Software Engineer lernt
Man liebt und hasst den Job gleichzeitig. Wenn du dir vorstellst, dass Programmierer nur sauberen, funktionierenden Code schreiben, ist deine Vorstellungskraft beeindruckend. Programmieren ist eigentlich eine mühsame Beschäftigung. Die Anzahl der Codezeilen ist manchmal umgekehrt proportional zu der Zeit, die aufgewendet wird, um über die Komplexität eines bestimmten Problems nachzudenken und die Lösung zu finden. Manchmal besteht der effektivste Code aus zwei Zeilen, und eine Aufgabe mit dem unscheinbaren Titel "Einfache Änderungen an der Benutzeroberfläche" dauert bei einem Back End acht Tage - und eine einzige neue Spalte in einer Tabelle ist das sichtbare Resultat. Das ist keine Übertreibung, sondern passiert wirklich so.
Vielleicht war man ja der Auffassung, dass Softwareentwicklung ein bequemer, stressfreier, gut bezahlter Bürojob ist. Wenn man eine nur kurze Zeit diese Arbeit macht, sieht man schnell, dass höchstens „es ist ein Bürojob“ stimmt. Vielleicht ist es eine Frage der inneren Einstellung, aber oft kann man kaum das Büro verlassen, wenn der Code nicht ansatzweise funktioniert. Man braucht kleine Erfolgserlebnisse, „1:0 für mich.“ Alternativ hat man ja auch die Unterstützung der Arbeitskollegen. Etwas funktioniert nicht? Naja, Pech gehabt. QA wird ohne zu zögern auf Reject drücken. Wir müssen uns auch durch unsere Fehler verbessern, und nach einer Zeit wird man viele Sachen lernen. Man wird eine Vielzahl technischer Fähigkeiten erwerben, die wahre Bedeutung von Teamarbeit erfahren und einige Dinge über sich selbst entdecken.
Hier sind die häufigsten Dinge, auf die man innerhalb einiger Monate als Software Developer stoßt.
Projektgröße
Während des Studiums gibt es einige Projekte auszuarbeiten. Abgesehen von der Dissertation gibt es aber in diesen Jahren des Studiums mehrere mehr oder weniger komplexe Arbeiten. Aber keine von ihnen ist in der Regel auch nur annähernd wie die Systeme, an denen man in der Arbeitswelt tüftelt. Um ein Produkt zu entwickeln, arbeiten womöglich 57 Personen mit Code. Es gibt fast 200 Repositories. Der Excerpt des Projekts, an dem gearbeitet wird - eine administrative Funktion des Hauptprodukts - ist so umfangreich, dass man monatelang keine Gelegenheit hat, einen Blick in alle Dateien und Funktionen zu werfen.
Auch nur die geeignete Stelle im Code zu finden, an der man mit dem Bugfixing beginnt, nimmt zunächst mehr Zeit in Anspruch als das Ausbessern des Bugs selbst. Schlussfolgerungen: Tastaturkürzel in einem Editor, Fuzzy-Search oder Plugins für gewisse Tools sind ein absolutes Muss.
Mittendrin anfangen
Wir sollten alles von vorne beginnen - selbst ein Kind in einem Kindergarten wird einem das sagen. Leider ist das nicht immer möglich.
Man beginnt bei einer Firma zu arbeiten. Hier arbeitet man an einem Code, an dem jemand seit mehreren Jahren arbeitet – womöglich sogar mehrere Personen. Wir fügen neue Funktionen hinzu, reparieren die Fehler, der alte Code muss überarbeitet werden, ein anderer Code-Block sollte gelöscht werden. Es ist völlig anders, als während des Studiums ECTS für bestandene Lehrveranstaltungen zu erhalten - wo wir ein fertiges Problem bekommen und dann eine Lösung entwerfen und implementieren.
Es unterscheidet sich auch völlig von der Agenturarbeit, wo Websites oder Applikationen speziell für den Kunden angefertigt werden. Das Budget ist festgelegt, es gibt eine Vision des gewünschten Effekts und eine begrenzte Zeit. Nach dem einen Projekt kommt gleich das nächste. Jedes Projekt wird von Anfang an gestartet - man wählt die passenden Tools oder erstellt ein Konzept und los geht’s.
Bei einer größeren Firma kommt man mittendrin zum IT Projekt der Firma dazu. Und man wird im Großen und Ganzen gesehen auch immer in der Mitte bleiben.
Wann um Hilfe bitten und wie Probleme lösen?
Ein Gespür für den richtigen Zeitpunkt WANN man um Hilfe bittet, ist ein entscheidender Teil eines Junior Developers. Einerseits möchte man nicht derjenige sein, der unaufhörlich die dummen Fragen stellt. Anderseits möchte man ja auch nicht einen Haufen Zeit mit Problemen verschwenden, nur weil man sich stillschweigend nicht fragen traut.
Oft hört man während Praktika, dass man sich zuerst 20 Minuten mit einem Problem auseinandersetzen sollte. Vielleicht findet man ja die Lösung. Wenn nicht, dann kann man ruhig fragen, bevor noch mehr Zeit verloren geht. Schwierig wird es allerdings, wenn man nach den 20 Minuten nicht mal richtig weiß, WAS man denn überhaupt fragen soll.
Für solche Fälle gibt es die Methode des Gummienten-Debuggings. Ja wirklich! Mit einer Quietscheente zu sprechen mag vielleicht ein Witz sein, aber der Grundgedanke ist, dass man jemandem, der überhaupt keine Ahnung vom Programmieren hat, den Code oder das Problem erklären soll. Alleine bloß durch den Versuch einer simplen Erklärung wird man meistens das Problem aus einer neuen Perspektive sehen.
Und dann, wenn man einem anderen Entwickler das Problem zeigt, muss man wieder eine konkrete Erklärung bieten. Schließlich hilft es auch nicht viel, wenn sich jemand anderes dein inkohärentes Gelaber anhört. Auf diese Weise kommt man der Lösung schon näher. Man würde es nicht glauben!
Das Aufschreiben der Schritte oder das Erstellen von Flussdiagrammen kann zur Problemlösung hilfreich sein. Es ist auch eine gute Grundlage für Diskussionen mit einem anderen Entwickler, wenn man Hilfe bei etwas braucht.
Aber man sollte sich nicht allzu viel den Kopf über etwas zerbrechen. Zuerst kurz mit dem Thema beschäftigen, dann kann man ja ruhig fragen. Vernünftige Fragen tun niemandem weh. Oft fehlen einem als Neuling in der Firma ja auch spezifische Informationen, auf die man alleine nie gekommen wäre.
Ratschläge, Tipps, nützliche Informationen oder interessante Codefragmente zu sammeln, kann auch sehr hilfreich sein. Wenn wieder ein ähnliches Problem auftritt, kann man bereits mit vorherigen Lösungen vergleichen. Und in späterer Folge - wenn ein Teamkollege ein ähnliches Problem hat, kann man irgendwann ja auch selbst aushelfen.
Glaub an dich
Frisch aus der Uni fehlt vielleicht aufgrund der mangelnden Berufserfahrung noch ein gewisses Maß an Selbstvertrauen. Und obendrein kennt man dann vielleicht noch ein paar Leute, die so versiert mit einer Programmiersprache sind. Hilft auch nicht mit dem Selbstvertrauen. Sowas lässt einen ja glauben, dass man es nicht mal wert ist eine einfache IF Bedingung zu implementieren.
Aber es gibt Unmengen an Sprachen, Frameworks, Methoden und weiter Nuancen. Es ist nicht möglich, alles zu wissen. Es ist vollkommen in Ordnung, zum ersten Mal etwas zu hören oder ein Werkzeug zu sehen und nicht sicher zu sein, wie man es benutzt.
Das Studium und das praktische Wissen? Die stärksten hands-on Projekte während des Studiums der Softwareentwicklung waren in etwa so realitätsnah wie das Spiel Need for Speed für die Führerscheinprüfung hilfreich ist.
Es ist gut sich darüber im Klaren zu sein, dass es in Ordnung ist, etwas nicht zu wissen. Wichtiger als Unmengen an Daten und Programmiersprachen im Kopf zu haben, ist es, die optimalste Lösung finden zu können. Und noch wichtiger: Auch wenn man es nicht weiß, man will es trotzdem unbedingt wissen. Man kann lernen und es macht es einfacher, von erfahrenen Menschen umgeben zu sein. Das Rad muss nicht neu erfunden werden. Ein Wissenstransfer und Tipps für Best Practices sind das, was man erfährt, wenn man mitten in ein aktives IT Projekt einsteigt. Dann gilt es, seine Fähigkeiten zu entwickeln, um so gut wie möglich zum Team beizutragen. Apropos ...
Du wirst nie aufhören zu lernen
Es gibt so viele wissenswerte Technologien, dass man als Programmierer nie aufhören wird, Neues zu lernen. Es bedeutet nicht, dass man alle je erfundenen Sprachen kennen sollte. Ich bezweifle auch, dass ich eines schönen Morgens alle in JavaScript/Python/Ruby integrierten Funktionen rezitieren kann. Es ist jedoch gut, verschiedene Sprachen, Technologien und Tools zu kennen, aus denen man auswählen kann – je nach den momentanen Anforderungen. Es ist immer gut, auf dem neuesten Stand bei den Sprachen und Tools, die man gerne verwendet zu sein.
Bevor ich meinen Job anfing, schien es mir möglich, sauberen, logischen Code schreiben und komplexe Websites erstellen zu können. Als ich mein Studium beendet hatte, dachte ich, ich könnte ganz komplexe Querys in SQL ausführen, oder ich könnte eine riesige Datenbank entwerfen. Wahrscheinlich kann ich es immer noch - theoretisch, mit Bleistift und Papier.
Wie immer – man sieht etwas Neues, lernt es kennen, studiert es und sieht, dass das alles nur die Spitze des Eisbergs war.
In der IT kann man nicht sagen:
Alles klar, ich werde jetzt ein einziges Mal richtig Ruby on Rails lernen und dann arbeite ich damit bis zur Pension.
Sowas geht sicher nicht. Der IT-Markt ändert sich schnell. Neue Technologien, Trends und Sprachen tauchen auf, entwickeln sich weiter und lassen keinen Platz für Langeweile.
