7 einfache Gewohnheiten der Top-1-%-Ingenieure
(engineercodex.substack.com)- „Wie Elite-Coder bessere Leistungen erbringen als andere Coder“
Sei ein Ingenieur, kein Coder (Be an engineer, not a coder)
- Engineering bedeutet, Probleme zu lösen
- Die besten Ingenieure betrachten Code als Mittel zum Zweck
- Es macht zwar Spaß, Code zu schreiben, aber Code ohne Ziel zu schreiben, hat keinen Sinn. Stattdessen wird Code genutzt, um Lösungen für Nutzer zu entwerfen
- Coding strebt nach Kreativität! Kreativität entsteht oft unter Einschränkungen. Fügt man die „Einschränkung“ eines klaren zu lösenden Problems hinzu, haben Ingenieure die Freiheit, Lösungen auf die aus ihrer Sicht passende Weise zu erkunden und zu entwickeln
- Die besten Ingenieure sind produktorientiert und stellen vor allem das Lösen von Problemen für Menschen an erste Stelle, was direkt zum nächsten Punkt führt
Code für Menschen, nicht für Computer (Code for the human, not the computer)
„Jeder Idiot kann Code schreiben, den ein Computer versteht. Gute Programmierer schreiben Code, den Menschen verstehen.“ - Martin Fowler
- Code ist nicht nur für Computer da, sondern auch für Menschen
- Code ist für die Ingenieure im selben Team, die ihn lesen, warten und darauf aufbauen
- Code ist für Nutzer gedacht: für kleine Kinder mit einem Smartphone, für Entwickler, die eine API aufrufen, und für einen selbst
- Die besten Ingenieure haben den Wert von Code immer im Hinblick auf alle Nutzer bewertet
- Wenn auch nur einer ihrer Kunden nicht zufrieden war, ging dieser Code nicht in Produktion
Sich vom Code selbst lösen (Detach from the code itself)
- Herausragende Ingenieure hängen nicht am Code selbst
- Sie haben keine Angst davor, auch zu 90 % fertigen Code zu löschen und neu anzufangen, wenn das Endergebnis insgesamt besser wird
- Sie nehmen Feedback aktiv an, weil Code nichts Persönliches ist
- Code ist nicht perfekt. Niemand interessiert sich für perfekten Code. Interessant ist nur Code, der etwas verändert
- Der beste Weg, sich selbst beizubringen, nicht am Code zu hängen, ist die Erkenntnis: „In 20 Jahren wird der Großteil deines Codes wahrscheinlich technische Schuld sein, nicht mehr genutzt werden oder neu geschrieben worden sein“
Konsistente Standards verwenden (Use consistent standards)
- Halte dich beim Schreiben von Code an konsistente Standards und einen einheitlichen Coding-Stil
- Konsistenz hilft sowohl deinem zukünftigen Ich als auch deinem Team dabei, Code leichter zu lesen und zu verstehen
- Mit einem konsistenten Styleguide lassen sich sowohl das Team als auch die Codebasis leichter skalieren
- So schaffen es Unternehmen wie Meta oder Google, schnell viel Code auszuliefern, ohne dass ihre Codebasis mit der Zeit unlesbar oder unwartbar wird
- Alle Unternehmen mit herausragender Leistung haben Styleguides verinnerlicht, ihre Vorteile verstanden und sich so weit wie möglich daran gehalten
- Google hat einige seiner Styleguides als Open Source veröffentlicht
- Meta hat für einen Teil seiner Open-Source-Projekte einen C++-Styleguide
- Tipp: Es lohnt sich auf jeden Fall, Zeit zu investieren, um Linter und Formatierung für dein Team einzurichten
Schreibe einfachen Code (Write simple code)
- Jeder Elite-Ingenieur, den ich kenne, erzeugte Code, der in der Erstellung vielleicht komplex war, am Ende aber leicht zu lesen und zu verstehen blieb
- Meine beste Beschreibung dafür ist, dass ihr Code „ästhetisch zufriedenstellend“ war
- Ihr Code war sauber, strukturiert und logisch (clean, organized, and logical)
- Jede im Code getroffene Entscheidung hatte einen Sinn, und wenn nicht, war sie im Code gut dokumentiert
- Eine gute Methode, sauberen Code zu schreiben, ist das Befolgen von Prinzipien wie den SOLID-Prinzipien. Sie wurden ursprünglich mit Blick auf OOP (objektorientierte Programmierung) entworfen, lassen sich aber auch auf allgemeine Programmierung ausweiten
- Single Responsibility: Eine Klasse sollte nur eine einzige Verantwortung haben
- Open-Closed: Softwareobjekte (Klassen, Module usw.) sollten für Erweiterungen offen, aber für Änderungen geschlossen sein, um vorhersehbaren und wartbaren Code zu ermöglichen
- Liskov Substitution: Untertypen sollten den Basistyp ersetzen können, ohne die Korrektheit des Programms zu beeinträchtigen
- Interface Segregation: Code sollte nicht von einer riesigen Schnittstelle abhängen, die er gar nicht vollständig nutzt. Stattdessen sollten Pakete kleinere, spezifische Interfaces enthalten und importieren können
- Dependency Inversion: Höherstufige Module sollten nicht von niedrigstufigen Modulen abhängen; beide sollten von Abstraktionen abhängen, um ein flexibleres und stärker entkoppeltes Systemdesign zu fördern
- Ein Beispiel dafür ist Naming: Gute Namen enthalten keine magischen Werte, schaffen klare Unterscheidungen und drücken beschreibende Funktionsnamen sowie leicht verständliche Variablen aus
Keine Überraschungen zulassen (Don’t allow surprises)
- Code sollte keine unerwarteten Ergebnisse erzeugen. Das gelingt, indem man Code-Prinzipien befolgt und geeignete Tests schreibt
- Guter Code ist vorhersehbar
- Tests stärken die Klarheit und Vorhersehbarkeit von Code und geben Sicherheit. Mit guter automatisierter Testabdeckung kann ein Team Code ändern, ohne Angst zu haben, unbemerkte Bereiche zu beschädigen
- Einige Testarten
- Unit-Tests für einzelne Komponenten und isolierte Funktionen
- Integrationstests für das Zusammenspiel mehrerer Komponenten
- End-to-End-Tests, die die Funktion des Gesamtsystems aus Nutzersicht bewerten
- Tests sollten einfach sein. Wenn man einen fehlgeschlagenen Test liest, sollte leicht erkennbar sein, was schiefgelaufen ist
- Ebenso wichtig ist es zu wissen, was man nicht testen sollte
- Wenn zum Beispiel der Aufwand für End-to-End-Tests größer ist als der tatsächliche Nutzen des Programms, sollten Tests durch sorgfältige Dokumentation, Monitoring und Benachrichtigungen an die richtigen Personen (z. B. Code-Owner) ersetzt werden
- Außerdem sollten Tests keine Implementierungsdetails im Code prüfen, etwa bestimmte CSS-Selektoren im Frontend-Code, oder sich nur auf Datenattribute oder Screenshot-Tests stützen
Häufig kommunizieren (Communicate often)
- Großartige Systeme entstehen nicht im Alleingang. Großartige Ingenieure durchlaufen Design-Reviews, holen Feedback ein und überarbeiten frühe Entwürfe ihres Codes immer wieder
- Jeder hat Wissenslücken, die andere füllen können. Neue Perspektiven helfen oft dabei, Code klarer zu machen oder neue Ansätze aufzuzeigen, auf die man vorher nicht gekommen wäre
- Die besten Ingenieure haben keine Angst davor, Zeit in Zusammenarbeit zu investieren, um bessere Endergebnisse zu erzielen, und legen großen Wert auf Kommunikation und Kollaboration
- Das kann so einfach sein wie ein Ping an ein Teammitglied für eine schnelle Dokumentenprüfung oder das Hinzufügen von Code-Reviewern zu einem wichtigen Pull Request
Schnell ... und langsam coden (Code fast… and slow)
- Die besten Ingenieure, die ich kenne, schließen Projekte schnell ab, coden aber langsam
- Klingt seltsam, oder?
- Alle oben genannten Prinzipien und Gewohnheiten erhöhen den Zeitaufwand in der ersten Phase des Codings. Gleichzeitig ermöglichen sie es Ingenieuren, den Projektfortschritt Schritt für Schritt voranzubringen
- Indem man Zeit in Standards, sauberes Testen, Prinzipien und häufige Kommunikation investiert, spart man langfristig deutlich mehr Zeit
- Ich habe das selbst als Praktikant und Junior-Ingenieur erlebt, und viele andere Ingenieure ebenso: Wenn man hektisch drei Schritte nach vorn machen will, stößt man auf ein Hindernis und macht am Ende fünf Schritte zurück
Regeln nicht blind befolgen (Don’t follow rules blindly)
- Die oben genannten „Regeln“ und „Prinzipien“ sind nur Richtlinien. Nicht alles passt sauber und perfekt in diese Vorgaben
- Manchmal ist der Code, den man schreibt, ein Quadrat, das nicht in den Kreis passt — und das ist in Ordnung
- In solchen Fällen sollte dokumentiert werden, warum der Code auf eine bestimmte Weise geschrieben wurde
- Sonst könnte dein zukünftiges Ich oder jemand anderes später auf den Code schauen und denken: „Wow, damals war ich wirklich dumm. Warum entspricht das nicht unserem Standard?“
- Und dann investiert diese Person 20 Stunden darin, alles standardkonform umzuschreiben, nur um am Ende zur gleichen Schlussfolgerung zu kommen wie zuvor
- Die Realität der Softwareentwicklung ist, dass nicht jeder Code sauber sein oder Regeln perfekt befolgen kann
- Aber es kann konsistenten, sauberen, leicht verständlichen, testbaren und wertvollen Code geben
- Weitere Muster, die ich bei den besten Ingenieuren beobachtet habe
- Sie verfügen über tiefes Domänenwissen in mindestens einem Bereich. Alle Ingenieure, die ich mir notiert habe, wurden Experten, weil sie sich auf bestimmte Gebiete wie Frontend-Infrastruktur, verteilte Systeme oder saubere UI konzentrierten, und genau deshalb stehen sie heute in ihrem Bereich ganz oben
- Sie vermarkten sich selbst häufig und angemessen. Diese Ingenieure haben sich nicht an unauffälligen Orten versteckt. Jeder, der mit ihren Teamkollegen zusammenarbeitete, kannte ihren Wert und ihre Fachkenntnis — als Ergebnis angemessener Selbstvermarktung und der Arbeit an einflussreichen Projekten
11 Kommentare
Ich habe gute Einblicke gewonnen. Vielen Dank :)
Ein guter Artikel!
Technik ist wichtig, aber es erinnert mich wieder einmal daran, dass es letztlich darauf ankommt, Produkte zu schaffen, die den Menschen wirklich nützen!!!
Vielen Dank für den guten Artikel!
Wenn man genauer hinsieht, sind es zwar 7 Gewohnheiten, aber der Inhalt zählt 9, haha.
Ich habe auch nachgezählt ... ich glaube, ganz hinten und ganz vorne sind einfach nur der Titel! Haha
Wow, dem Großteil davon kann ich zustimmen – ein toller Beitrag, haha.
Einer der besten Inhalte dieser Art, die ich bisher gesehen habe
Wenn man es ein wenig verallgemeinert, ist das ein guter Text, der allen helfen kann.
Das ist inzwischen eher eine Übersetzung als eine Zusammenfassung, aber ... vielen Dank für die großartige Zusammenfassung.
Ein Text, den man immer wieder lesen kann.
Stimmt wirklich, haha. Ich werde das auch immer wieder lesen.