- In großen Tech-Unternehmen arbeiten viele Ingenieure aufgrund kurzer Betriebszugehörigkeit und häufiger Reorganisationen an Codebasen, mit denen sie nicht vertraut sind
- Ein erheblicher Teil der Codeänderungen wird in der Praxis von Ingenieuren auf „Anfänger“-Niveau innerhalb der ersten 6 Monate nach dem Einstieg vorgenommen
- Einige erfahrene „Old Hands“ gleichen Qualitätsprobleme aus, stoßen aber wegen Überlastung und informeller Verantwortung an ihre Grenzen
- Unternehmen priorisieren Mobilität der Belegschaft und Lesbarkeit/Überschaubarkeit (legibility) stärker als Fachwissen, und die daraus entstehende Qualitätsminderung ist ein bewusster Preis
- Letztlich ist die Grundursache für schlechten Code unabhängig von den individuellen Fähigkeiten einzelner Ingenieure ein strukturelles Problem: Arbeit in unbekannten Systemen unter hohem Lieferdruck
Die Struktur, durch die in Großunternehmen schlechter Code entsteht
- Große Tech-Unternehmen stellen mit hohen Gehältern fähige Ingenieure ein, doch die Betriebszugehörigkeit liegt oft nur bei 1 bis 2 Jahren
- Aktienvergütungen (share grants) werden oft erst nach 4 Jahren vollständig unverfallbar, wodurch das Gehalt danach faktisch auf die Hälfte sinkt
- Es gibt teils jährliche Refreshes, diese sind aber nicht garantiert, weshalb sich Ingenieure häufig für einen Wechsel entscheiden
- Rechnet man interne Wechsel mit ein, bleiben Ingenieure selten länger als 3 Jahre in derselben Codebasis
- Reorganisationen (re-orgs) finden jährlich oder sogar noch häufiger statt
- Gleichzeitig bestehen Codebasen oft über 10 Jahre oder länger, sodass die meisten Ingenieure ein neues System gerade erst kennenlernen
- Dadurch wird ein erheblicher Teil der Codeänderungen von Anfängern innerhalb der ersten 6 Monate nach dem Einstieg vorgenommen
Die Rolle und die Grenzen der „Old Hands“
- Einige Ingenieure bleiben lange genug in einem bestimmten System, um tiefes Fachwissen aufzubauen
- Sie können Probleme im Code Review früh erkennen
- Diese Struktur ist jedoch informell und nicht institutionalisiert
- Unternehmen haben wenig Interesse daran, langfristige Expertise zu erhalten, und versetzen erfahrene Kräfte oft in andere Teams
- Erfahrene Kräfte sind dauerhaft überlastet
- Ihnen fehlt die Zeit, alle Änderungen selbst zu prüfen
- Wenn ihre eigene Arbeitsleistung sinkt, drohen ihnen im Zweifel sogar Nachteile
Die Realität des durchschnittlich produktiven Ingenieurs
- Der durchschnittlich produktive Ingenieur in einem Großunternehmen hat typischerweise folgende Merkmale
- Er ist gut genug, um den Einstellungsprozess zu bestehen, kennt sich aber mit einer neuen Codebasis oder Sprache noch nicht gut aus
- Gleichzeitig arbeitet er unter überlappenden Deadlines mehrerer Projekte
- Das Ergebnis ist eine Struktur, in der Menschen in einem termingetriebenen Umfeld statt in einem qualitätsgetriebenen Umfeld ihr Bestes geben
- Beispiel: Ein Anfänger behebt einen Bug in unbekanntem Code mit einem Workaround, ein erfahrener Ingenieur schaut kurz darauf und gibt die Änderung frei
- Jahre später taucht dieser Code wieder auf und man fragt sich: „Warum wurde so etwas geschrieben?“
Warum Unternehmen diese Struktur aufrechterhalten
- Großunternehmen gewichten interne Sichtbarkeit/Überschaubarkeit (legibility) höher als Produktivität
- Sie bevorzugen eine Struktur, in der jederzeit erkennbar ist, wer woran arbeitet und wer beliebig umsetzbar ist
- Das ist eine bewusste Entscheidung zulasten von Expertise und Codequalität
- Unternehmen nehmen den Verlust an Erfahrung in Kauf, um bei Problemen Personal schnell neu zu verteilen und flexibel zu bleiben
- Gerade in einer Situation, in der schnelle Pivots in neue Bereiche wie AI wichtig geworden sind, funktioniert diese Strategie aus Unternehmenssicht vorteilhaft
- In einem solchen Umfeld lässt es sich jedoch kaum vermeiden, dass viele Ingenieure unter Zeitdruck in ihnen unbekannten Systemen arbeiten
Die Grenzen des einzelnen Ingenieurs und „reines/unreines“ Engineering
- Einzelne Ingenieure haben keine Macht, diese Struktur zu verändern
- Stand 2025 hat sich das Machtzentrum von Ingenieuren zum Management verschoben
- Das Beste, was Einzelne tun können, ist, in einem bestimmten Bereich zu einem „Old Hand“ zu werden und ein Mindestmaß an Qualität zu sichern
- Zu starkes Eingreifen birgt jedoch das Risiko, wegen zu geringer Leistung (PIP) bewertet zu werden
- Der Text stellt den Unterschied zwischen „reinem (pure)“ und „unreinem (impure)“ Engineering heraus
- Reines Engineering: unabhängige technische Projekte, etwa die Entwicklung von Programmiersprachen
- Unreines Engineering: die reale Arbeitsumgebung, in der man in unbekannten Systemen terminorientiert arbeitet
- Die meisten Ingenieure in Großunternehmen gehören zum unreinen Engineering, und in diesem Kontext ist schlechter Code ein unvermeidliches Nebenprodukt
- Wenn das System ausreichend funktioniert, gilt das Projekt als Erfolg
Fazit: Die unbekannte Codebasis als strukturelle Ursache
- Großunternehmen haben die Macht, Ingenieure frei zu versetzen, und das ist eine bewusste Unternehmensentscheidung trotz des Verlusts an Expertise
- Die Verantwortung für schlechten Code liegt nicht bei Einzelnen, sondern in der Organisationsstruktur und der Art des Personaleinsatzes
- Selbst wenn sich die Fähigkeiten aller Ingenieure verdoppeln würden, würden Fehler in unbekannten Codebasen weiterhin auftreten
- Die eigentliche Grundursache ist eine Struktur, in der „die meisten Ingenieure den Großteil ihrer Arbeit in Code erledigen müssen, mit dem sie nicht vertraut sind“
- Auf Beispiele für schlechten Code hinzuweisen kann bei Verbesserungen helfen, doch nicht die Ingenieure, sondern das System ist das eigentliche Ziel von Kritik
Noch keine Kommentare.