Ein Brief an jeden neuen Software-Engineer über die Dinge, die mir in meinem ersten Jahrzehnt niemand gesagt hat. Keine generischen Ratschläge — konkrete Gewohnheiten, die sich aufaddieren, mit Belegen aus den 15 Jahren Shipping, die dem Schreiben vorangingen. Wenn ich zurückgehen und das meinem 22-jährigen Ich in die Hand drücken könnte, das beim HAKEEM National EHR-Projekt in Amman anfing — ich würde es tun.

Eins: Lies den Code, bevor du ihn schreibst

Die einzige Gewohnheit mit dem größten Hebel in deinem ersten Jahrzehnt ist, Code zu lesen, den du nicht geschrieben hast — in einer Production-Codebase, mit Absicht. Nicht überfliegen. Wirklich lesen — Datei für Datei, Funktion für Funktion, “Warum ist das hier?” bei jeder Verzweigung.

Jede Senior-Engineerin, die ich respektiere, hat eine Version dieser Gewohnheit. Klingt offensichtlich. Ist das Erste, was Juniors überspringen, weil Lesen sich weniger produktiv anfühlt als Schreiben. Ist es nicht. Schreiben, ohne gelesen zu haben, führt dazu, dass du Funktionen neu erfindest, die in der Codebase bereits existieren, Abstraktionen erzeugst, die mit bestehenden konfligieren, und Designs vorschlägst, die Constraints verletzen, die die ursprünglichen Autoren in die Form des Codes eingebettet haben.

Plane eine volle Woche in deinem ersten Monat in einer neuen Codebase nur fürs Lesen ein. Dein Manager denkt, du produzierst nichts. Drei Monate später ist dein Output dramatisch besser als der von Peers, die diesen Schritt übersprungen haben. Zinseszins.

Zwei: Schreib auf, was du lernst

Jede Codebase hat Invarianten, die nirgendwo dokumentiert sind. Jedes Team hat Konventionen, die in drei Köpfen leben. Jedes Production-System hat seltsame Ecken, die beim Lernen im Incident-Modus entdeckt wurden.

Schreib sie auf, wenn du sie findest. Nicht in einer privaten Datei — im gemeinsamen Knowledge-Store (das Repo-Docs, das Team-Wiki, das README des jeweiligen Moduls). Das Schreiben zwingt dich zu artikulieren, was du gelernt hast, und dabei kommen Dinge hoch, die du nicht wirklich verstanden hast. Es bedeutet auch, dass die nächste Person die Woche überspringen kann, die du gerade verbracht hast.

Ich sag’s direkt: Du baust dir einen Ruf als hilfreicher Engineer schneller durch Dokumentieren als durch Shippen. Shippen UND dokumentieren baut eine Karriere. Nur shippen ohne dokumentieren produziert Tickets.

Drei: Die Eine-Stunde-Regel fürs Fragen

Wenn du eine Stunde feststeckst, frag. Nicht drei Stunden. Eine.

Jede Senior-Engineerin war schon da: du starrst einen halben Tag auf den Bildschirm, kein Fortschritt, und dann hat jemand 30 Sekunden gebraucht, um deine Frage zu beantworten. Dieser halbe Tag war verschwendet. Du hast nichts gelernt, was eine gezielte Frage nicht auch vermittelt hätte. Du hast in diesem halben Tag auch nichts produziert — das Team hat also für dein Schweigen bezahlt.

Das Gegenargument ist “ich will erst mehr versuchen.” Der Instinkt ist richtig, die Kalibrierung ist meistens falsch. Eine Stunde. Dann fragen. Wenn du dich schämst zu fragen, frag trotzdem. Die Scham ist eine Reputationssteuer, die deutlich kleiner ist als die Steuer eines Junior- Engineers, der halbtageweise verschwindet.

Vier: Wenn du debuggst, kommentiere

Wenn du an etwas Vertracktem debuggst, sag laut (oder in einem Terminal-Scratch-File, oder in einem Slack-Scratch-Kanal), was du denkst. “Ich denke, X passiert wegen Y. Wenn das stimmt, sollte Z beobachtbar sein. Ich prüf Z. Hmm, Z ist nicht beobachtbar. Also liegt X nicht an Y. Was sonst könnte X verursachen?”

Das ist kein Theater. So vermeidest du, im Kreis zu laufen. Die kommentierte Version des Debuggings bringt Annahmen ans Licht, die du sonst still gemacht hättest. Als Nebeneffekt wird dein Debugging zur Post-Incident-Story, die du anderen erzählen kannst — enormer Mehrwert fürs Team.

Fünf: Ein Test ist billiger als der Bug, den er verhindert

Jede Junior-Engineerin, die ich je begleitet habe, hatte dieselbe Versuchung im ersten Jahr: den Test überspringen, “weil ich sicher bin, dass das funktioniert.” Die ehrliche Wahrheit: Du bist nie sicher. Niemand ist das. Der Test ist der Beweis, dass es funktioniert. Ohne Test ist “es funktioniert” ein Bauchgefühl — und Bauchgefühle überstehen die nächste Engineerin nicht, die diese Funktion anfasst.

Schreib den Test. Vor allem für die Randfälle. Vor allem für die langweiligen Happy-Path-Fälle, die “offensichtlich funktionieren”. Die Tests, die du überspringst, sind die Tests, die die Bugs fangen, die du shipst.

Sechs: Mach die unspektakuläre Arbeit mit Absicht

Jedes Team hat Arbeit, die niemand will: einen flaky Test upgraden, ein verwirrendes Modul dokumentieren, ein brüchiges Script umschreiben, das On-Call-Übergabe-Template übernehmen. Meld dich freiwillig.

Drei Gründe:

  1. Du lernst das System auf eine Art, die Feature-Arbeit dir nicht beibringt.
  2. Du baust dir genau den Senior-Engineer-Ruf auf, der entsteht, wenn man Entropie reduziert. Das ist mehr wert als jedes einzelne Feature.
  3. Senior Engineers sind knapp. Jedes Team braucht sie. Sichtbaren Beweis zu bauen, dass du eine bist, ist der schnellste Weg, auch so behandelt zu werden.

Sieben: Dein erster Manager ist ein Datenpunkt, keine Kalibrierung

Wenn dein erster Manager gut ist, schätz das — und erkenne, dass er oder sie ein Ausreißer ist. Wenn dein erster Manager schlecht ist, ist das keine Kalibrierung auf Manager im Allgemeinen. Die meisten Senior Engineers, die ich kenne, haben die volle Bandbreite erlebt.

Die praktische Konsequenz: Triff keine langfristigen Karriereentscheidungen auf Basis der Meinung deines ersten Managers über dich. Das ist die Sicht einer einzigen Person, die selbst wahrscheinlich nicht als Manager ausgebildet wurde.

Und: Wenn dein erster Manager dir Ratschläge gibt, die falsch klingen, frag “inwiefern falsch?” statt ihn zu ignorieren oder blind anzunehmen. Die meisten Ratschläge von Erstmanagern sind verwischte Versionen von etwas wirklich Nützlichem. Entpacke das mit ihnen. Sie lernen dabei oft auch etwas.

Acht: Das Open-Source-Portfolio ist der Karriere-Cheat-Code

Jede Engineerin, die ich kenne, die am Ende in einer Rolle landete, die sie liebte, hatte einen sichtbaren Erfahrungsschatz. Nicht unbedingt ein populäres Projekt — sichtbar. Ein paar OSS-Contributions, ein kleines Tool, das sie geschrieben und dokumentiert hat, eine Reihe von Blog-Posts, ein Conference-Talk. Etwas, das — wenn ein Hiring-Manager nach ihnen googelt — ein kohärentes Bild ergibt: “Das ist die Form, wie diese Engineerin denkt.”

Du kannst eine exzellente Engineerin sein ohne all das. Du wirst weniger Chancen bekommen. Es ist, auf jeder Stufe, billiger, ein Portfolio zu haben als nicht. Fang eins an. Es muss keine große Sache sein. Ship ein kleines Tool. Schreib drei Posts. Contribute zu etwas, das du selbst nutzt.

Das aktuelle Ich, das diese Site shippt, die du gerade liest, ist zum Teil eine Neubestätigung genau dieses Ratschlags. Ich hab’s ein paar Jahre schleifen lassen. Ich fix das jetzt.

Neun: Die Compound-Skill ist Klarheit

Nicht Cleverness. Nicht Velocity. Nicht Tiefe. Klarheit.

Die Fähigkeit, eine Entscheidung in einem Satz zu erklären. Die Fähigkeit, eine Commit-Message zu schreiben, die das Warum beschreibt. Die Fähigkeit, eine Codebase so zu hinterlassen, dass die nächste Engineerin weiß, was vor sich geht. Die Fähigkeit, dem PM zu sagen, dass das Feature drei statt sechs Wochen dauert — und genau zu zeigen, warum.

Alles andere lernst du unterwegs. Klarheit addiert sich auf, und Engineers, die sie früh aufbauen, haben einen wachsenden Vorsprung gegenüber denen, die es nicht tun.

Zehn (die leise): Sei misstrauisch gegenüber deiner eigenen Begeisterung

Die teuersten Fehler, die ich beobachtet — und gemacht — habe, kommen daher, sich für eine Lösung zu begeistern, bevor das Problem richtig verstanden war. “Lass uns das neu schreiben.” “Lass uns dieses neue Framework nehmen.” “Lass uns das in Services aufteilen.” Begeisterung ist ein Signal, aber keine Entscheidungsfunktion. Wenn du Begeisterung für eine technische Wahl bemerkst, warte eine Woche. Schreib den Plan auf. Schlaf drüber. Bitte jemanden, der weniger begeistert ist als du, Löcher hineinzubohren.

Wenn die Begeisterung die Woche überlebt, war sie echt.

Wenn nicht, hast du dir Monate erspart.

Das war’s. Das ist der Brief. Er ist nicht vollständig, aber er ist ehrlich — und das, was ich mir gewünscht hätte, wenn es mir jemand mit 22 in die Hand gedrückt hätte. Wenn du gerade deinen ersten Job anfängst und jemand dich hierher geschickt hat, dann bin ich froh — und ich hoffe, ein Teil davon spart dir Zeit.