Das Geständnis eines Informatikers mit Lücken
Während meines Studiums hielt ich mich für ziemlich großartig. Ohne zu ahnen, wie essenziell die CS-Grundlagen (Computer Science) wirklich sind, jagte ich nur den guten Noten (Credits) hinterher.
Ich besuchte fleißig meine Vorlesungen, gewann Preise bei Hackathons und „Capstone Design“-Wettbewerben. Wenn meine Kommilitonen über Code-Fehlern brüteten, stand ich daneben, gab Ratschläge und fühlte mich überlegen. Aber wenn ich heute ehrlich zurückblicke: Das, was ich damals produzierte, war bloß ‚Kinderkram‘.
Weil ich Schwierigkeiten hatte, eine echte Datenbank anzubinden, speicherte ich Daten einfach kommagetrennt in einer Textdatei (.txt). Anstatt einen Raspberry Pi zu nutzen, der ein echtes Verständnis des Betriebssystems erfordert hätte, nahm ich einen Arduino, der mit ein paar Zeilen Code irgendwie funktionierte. Die Professoren lobten die oberflächlich gut aussehenden Ergebnisse, und ich bildete mir ein, das sei mein wahres Können.
Auswendiglernen statt Verstehen: Der Beginn der Tragödie
Doch kaum betrat ich den Arbeitsmarkt, zerfiel dieses unbegründete Selbstvertrauen in tausend Teile. Es hagelte Absagen. Der Titel eines Wettbewerbssiegers konnte meine fehlenden Grundlagen nicht vertuschen.
Je größer die Angst wurde, desto mehr klammerte ich mich an oberflächliches Wissen. Verständnis war zweitrangig; ich lernte Musterantworten auswendig wie eine Maschine, nur um die Bewerbungsgespräche zu bestehen. Meine Bibel waren die „Top 100 Interview-Fragen“, die ich von diversen Tech-Blogs kopiert hatte.
Auf die Frage des Interviewers „Was ist der Unterschied zwischen TCP und UDP?“ antwortete ich wie ein Automat: „TCP ist verbindungsorientiert und garantiert Zuverlässigkeit, ist aber langsam. UDP ist verbindungslos und schnell, aber unzuverlässig.“
In Wahrheit hatte ich keine Ahnung, was ein Paket wirklich ist oder wie ein 3-Way-Handshake tatsächlich abläuft. Ironischerweise gelang es mir dank dieser mechanischen Merkfähigkeit, die Interviewer zu täuschen und einen Job zu ergattern. Ich hielt es für Glück. Ich ahnte nicht, dass dies der Beginn einer Tragödie war, in der mich das Karma von vier Jahren Studium mit voller Wucht treffen würde.
Überlebenskampf als Full-Stack-Entwickler im Startup
Ich landete in einem kleinen Team. Dort gab es keinen Luxus wie die Trennung zwischen ‚Frontend‘ und ‚Backend‘.
Vom ersten Tag an wurde ich von einem Tsunami aus Technologien überrollt. Ich dachte, es würde reichen, Java oder JavaScript zu können. Aber die Realität bestand aus dem schwarzen Bildschirm des Linux-SSH-Terminals, mysteriösen Docker-Containern, GitLab CI/CD-Pipelines sowie Spring Boot, Vue.js und Redis… All die Technologien, die ich im Studium mit „Das mache ich später“ aufgeschoben oder mit „Das muss man nicht wissen“ ignoriert hatte, griffen mich nun von allen Seiten an.
Das Wissen, das ich im Vorstellungsgespräch heruntergeleiert hatte, war in der Praxis nutzlos. Oder genauer gesagt: Ich wusste nicht, wie man es ‚anwendet‘. Um zu verstehen, warum mein Docker-Container ständig abstürzte (OOM) oder warum Redis den Speicher auffraß, hätte ich genau jene CS-Grundlagen gebraucht, die ich nur für das Interview auswendig gelernt hatte.
Ein Schloss auf Sand gebaut
Schlussendlich wurde ich zu einem ‚Copy-Paste-Entwickler‘, der Code wild zusammenkopierte (Strg+C, V). Die Funktionen liefen irgendwie, aber ich wusste nicht, warum.
- CORS Error: Warum lehnt mein Browser die Antwort des Servers ab? (Unwissenheit über HTTP-Header)
- OOM (Out Of Memory): Warum stirbt der Server, der eben noch lief, plötzlich ab? (Unwissenheit über Memory Leaks und Garbage Collection)
- Connection Refused: Lokal funktioniert es, aber warum nicht nach dem Deployment? (Unwissenheit über Port-Forwarding und Firewalls)
Da ich die Prinzipien hinter der Bequemlichkeit der Frameworks nicht kannte, war ich unfähig, Probleme zu lösen. Ich baute ein wackeliges Schloss aus ausgefallenen Frameworks auf einem Fundament aus fehlendem Basiswissen.
Re: Booting – Zurück zum Startpunkt
Deshalb habe ich beschlossen, wieder ganz von vorne anzufangen. Anstatt jetzt sofort noch ein glänzendes Projekt für mein Portfolio zu basteln, hielt ich es für dringender, die essentielle Frage zu klären: „Wie versteht und führt der Computer meinen Code eigentlich aus?“
Dieser Blog ist das Protokoll einer intensiven Aufarbeitung eines Absolventen, der außer seinem Diplom nichts vorzuweisen hat und nun die CS-Basics von Grund auf neu aufbaut. Es wird keine bloße Auflistung von Linux-Befehlen oder Docker-Installationsanleitungen sein. Stattdessen werde ich folgende Fragen stellen und versuchen, Antworten zu finden:
- Language & OS: Was passiert, bis mein Java-Code kompiliert ist und die CPU erreicht?
- Network: Welche Reise tritt ein Paket an, wenn ich im Browser Enter drücke?
- Virtualization: Was unterscheidet meinen Laptop von den Computern im Serverraum und warum brauchen wir Virtualisierung?
- DevOps: Wie kann ich meinen Code sicher und automatisch deployen?
Jenseits von localhost
Mein endgültiges Ziel ist es, Linux, Docker, CI/CD und Cloud-Umgebungen eigenhändig aufzubauen und zu steuern. Ich lade euch ein, meinen Weg zu beobachten: Raus aus dem sicheren Gewächshaus namens ‚localhost‘, hin zu einem Ingenieur, der auch in der rauen Wildnis der Server-Umgebungen überlebt.
Ich hoffe, dass diese Aufzeichnungen für diejenigen, die wie mein früheres Ich sagen „Das hatten wir in der Uni, aber ich habe es vergessen“, zu einem kleinen Wegweiser werden, der sie sagen lässt: „Ah, genau das hat der Professor damals gemeint!“