Ratschläge für neue Softwareentwickler, die all die anderen Ratgeber-Essays bereits gelesen haben
(buttondown.email)- Zu Beginn der Karriere sollte man auch bekannte Entwicklerratschläge nicht einfach übernehmen, sondern zuerst prüfen, ob sie zur eigenen Situation passen; für viele Behauptungen im Softwarebereich gibt es wenig belastbare Belege
- Ideen, die einem gefallen, kann man selbst ausprobieren; solange man Kolleginnen und Kollegen nicht behindert, sind Irrwege und Experimente Teil des Lernprozesses
Debugging: The 9 Ruleswird als leicht zugänglicher Einstieg empfohlen, der eine Debugging-Kompetenz behandelt, die Bücher für Einsteiger oft auslassen- „Der richtige Weg“ oder „Best Practices“ entstehen häufig aus bestimmten Fehlschlägen und historischen Entwicklungen; man sollte die Technik selbst von ihrer Art der Verbreitung unterscheiden
- Wer früh versteckte Funktionen von Tools, die Arbeit anderer Abteilungen und verschiedene Arten der Programmierung kennenlernt, findet leichter die passende Softwarearbeit für sich
Wie man mit Ratschlägen umgeht
- Viel gelesene Entwicklerratschläge verbreiten sich oft nicht deshalb, weil die Autorinnen oder Autoren herausragende Programmierer sind, sondern weil sie gut schreiben
- Man muss nicht jeden Rat automatisch ablehnen, sollte aber sorgfältig prüfen, wie er auf die eigene Situation anwendbar ist
- Behauptungen über „objektive Wahrheiten“ in der Softwareentwicklung sollte man vorsichtig aufnehmen; wissenschaftlich untersucht ist nicht viel, und Studienergebnisse sind meist nicht eindeutig
- Man muss sich nicht übermäßig davor fürchten, das „Falsche“ zu lernen
- Wenn einem die Idee von jemandem gefällt, kann man sie selbst ausprobieren
- Solange man Kolleginnen und Kollegen nicht aktiv behindert, kann es am Ende trotzdem zu Lernen führen, selbst wenn man später feststellt, dass man es anders hätte machen sollen
- Debugging: The 9 Rules ist ein Buch, das neuen Entwicklerinnen und Entwicklern empfohlen wird
- Es ist gut lesbar und behandelt mit Debugging eine wichtige Fähigkeit, die andere Bücher für „Programmieranfänger“ kaum abdecken
- Man kann es auch in der Bibliothek ausleihen oder die Firma bitten, es zu kaufen
Die Grenzen des „richtigen Wegs“ und von Best Practices
- Irgendwann kann man glauben, den „Right Way“ des Programmierens entdeckt zu haben, und überzeugt sein, dass das Feld besser würde, wenn alle so arbeiten würden
- Als Beispiele werden Test-Driven Development, funktionale Programmierung, Lisp und formale Methoden genannt
- Es ist schwer zu vermeiden, sich für eine solche Methode zu begeistern, und das kann sich gut anfühlen; wichtig ist aber, die eigene Identität nicht zum „Right Way Guy“ zu machen
- Mit der Zeit lernt man, dass Programmieren mit jeder Methode frustrierend und unordentlich sein kann und dass man auch ohne diese Methode hervorragende Software bauen kann
- Wenn man mehrere „Right Ways“ kennt, kann man sie passend zum Problem kombinieren
- Der erste „Right Way“, dem man begegnet, kommt meist von jemandem, der sich dieser Methode vollständig verschrieben hat
- Später sollte man dieser Person nicht zu sehr die Schuld geben und die eigentliche Technik nicht mit der Art verwechseln, wie diese Person sie bewirbt
- Viele Ideen müssen etwas angepasst werden, um zusammen mit anderen Ideen nützlich zu sein, statt in ihrer reinen Form eingesetzt zu werden
- Wie Julia Evans sagt: „Hinter jeder Best Practice steckt eine Horrorgeschichte“
- Wenn man eine Best Practice nicht versteht, kann man nach dem Fehlschlag suchen, aus dem sie entstanden ist
- Wenn dieser Fehlschlag für die eigene Situation irrelevant ist, ist es in Ordnung, einen anderen Weg zu wählen
- Viele Best Practices und Konventionen sind pfadabhängig
- Man folgt ihnen, weil es der eigene Mentor so gemacht hat, und dieser Mentor folgte ihnen, weil es dessen früherer Mentor so gemacht hat
- Verfahren, die entstanden sind, um Probleme der Vergangenheit zu lösen, können heute weniger relevant sein
- Konventionen, die wie plausible nachträgliche Erklärungen klingen, können genau das sein; wenn man nachforscht, lässt sich ihre Entstehung oft nachvollziehen
Wie man ein breiteres Praxisgefühl entwickelt
- Spazierengehen wird als Gewohnheit vorgeschlagen, die hilft, Gedanken zu ordnen
- Die meisten verwendeten Tools haben eine verborgene Tiefe
- Man muss Programmiersprachen, Git, JIRA und ähnliche Tools nicht auf Expertenniveau beherrschen
- Es wird aber empfohlen, 5 bis 10 Minuten zu investieren, um herauszufinden, was damit noch möglich ist
- Gespräche mit Menschen aus anderen Abteilungen im Unternehmen erweitern das Verständnis der Arbeit
- Man kann mit Support, Fachdomäne, Vertrieb und anderen Bereichen sprechen
- Wenn Zeit vorhanden ist und man leicht darum bitten kann, wird auch vorgeschlagen, ihre Arbeit einmal zu begleiten
- Zu Beginn der Karriere ist es hilfreich, möglichst viele Arten der Programmierung auszuprobieren
- Dafür muss man nicht unbedingt den Job wechseln; die meisten Unternehmen betreiben mehrere Arten von Programmierung gleichzeitig
- In einer Webentwicklungsfirma kann man Frontend, Backend, Betrieb, Datenbankarbeit und anderes ausprobieren
- Das hilft beim Lernen, aber noch wichtiger ist, dass es die Chance erhöht, die Softwarearbeit zu finden, die man wirklich mag
- Enthalten ist ein persönliches Beispiel: Der erste Job im Frontend war anstrengend, später wurde die Person nach einem Wechsel ins Backend glücklicher
- Weil sich der Softwarebereich ständig verändert, hat der Rat, sich nicht von Framework-Trends mitreißen zu lassen, sondern sich auf Grundlagenkompetenzen zu konzentrieren, seine Berechtigung
- Durch Internet, Open Source, Konferenzen und Ähnliches verbreiten sich Informationen im Softwarebereich sehr schnell
- Da die Hürden für das Teilen von Ideen niedrig sind, kann selbst ein persönliches Projekt, das nur eine Person nutzt, so wirken, als wüssten viele Menschen davon
- Ein erheblicher Teil der Technologien, von denen man hört, kann eine kleine Nutzerbasis haben und nicht breit übernommen werden
- Wenn das Interesse groß ist, kann man Early Adopter werden; wenn nicht, ist es auch in Ordnung, ein paar Jahre zu warten und zu sehen, was tatsächlich Bestand hat
- Niemand kann die Zukunft vorhersagen, und auch die Gegenwart ist ein Ergebnis, das schwer vorherzusagen war
- Man sollte sein Bestes geben, im Einklang mit den eigenen Werten leben und den Prozess genießen
1 Kommentare
Hacker-News-Meinungen
Ich habe kürzlich in einem Hobbyprojekt mit einem Junior und einem etwas weniger juniorigen Entwickler zusammengearbeitet, und beide waren auf den „richtigen Weg“ fixiert.
Für einen Discord-Bot plus Rust-Code mit etwa 300 Zeilen, den nur wir selbst betreiben würden, verlangten sie vollständige Dokumentation, getrennte VMs für QA und „Betrieb“, systemd-Deployment, ein Template-System für ein paar Strings und sogar eine ORM-Schicht für vier SQL-Queries.
Das Projekt wäre höchstens von ungefähr zehn Leuten genutzt worden, und das war nur die Hälfte der Anforderungen für das „0.3“-Release; außerdem planten sie noch stärkeres Overengineering, weshalb ich aus dem Projekt ausgestiegen bin.
In meinen ersten Programmierjahren war ich selbst einige Jahre lang so jemand, aber ich habe gelernt, dass es in der Informatik viel Tieferes gibt als Best Practices oder Code Style und dass am Ende funktionierender Code zählt.
Gemeint ist, dass man unverhältnismäßig viel Aufmerksamkeit auf belanglose Details statt auf das Kernproblem richtet; dazu gibt es die Analogie, dass ein Genehmigungsausschuss für ein Kernkraftwerk das Kraftwerk selbst beiseitelässt und nur über die Farbe des Fahrradschuppens daneben diskutiert.
Auch in diesem Fall wirkt der Fokus auf getrennte QA-/Produktions-VMs, systemd-Deployment, Templates für ein paar Strings und ein ORM für ein paar SQL-Queries bei einem Projekt für zehn Nutzer wie ein klassischer Fall des Gesetzes der Trivialität.
Solche Themen sind gerade für Junior-Entwickler leicht zu verstehen und zu diskutieren, weshalb sie sich stärker einmischen; die wirklich schwierigen Kernfunktionen werden dadurch leicht vernachlässigt.
Allerdings halte ich es nicht für übermäßige Beschäftigung mit Nebensächlichkeiten, die sinnvollen Teile eines Projekts ordentlich zu dokumentieren.
Dinge wie das Schreiben einer systemd-Unit oder der Einsatz eines ORM kosten weniger Zeit, als man denkt, helfen später aber ziemlich, wenn jemand anderes hineinschaut oder beitragen möchte.
Es ist einfacher, das zu erledigen, solange der Kontext noch im Kopf ist; wenn ein Projekt erst einmal größer geworden ist, bleiben solche Aufräumarbeiten fast immer liegen.
Gerade weil es ein Hobbyprojekt war, wollten sie vielleicht einfach alles ordentlich machen, Tools lernen und Zufriedenheit daraus ziehen.
Am Anfang gibt es eine Szene, in der sie einen Router für 50 Dollar kaufen müssen; als eine Figur vorschlägt, den vorhandenen Router zu reparieren, antworten die anderen fast noch vor dem Ende des Satzes: „haben wir versucht“.
Das zeigt, dass sie einander so gut kennen und so viel Zeit miteinander verbringen, dass sie einander fast die Gedanken lesen können.
Als dann aber jemand zum Kauf eines neuen Routers „yes“ sagt, antwortet ein anderer, dass „aye“ nötig sei.
Die Wortwahlregel für Abstimmungen in ihrem Nebengeschäft ist also extrem strikt; es spielt keine Rolle, ob sie einander so nahestehen, dass sie die Sätze des anderen beenden, ob es nur um einen 50-Dollar-Router geht oder ob die Einnahmen aus dem Nebengeschäft unbedeutend sind.
Die Regel verlangt aye.
Manche der auf den „richtigen Weg“ fixierten Leute wirken wie Menschen, die erfolgreich Wissen kopiert haben, das in sozialer kollektiver Intelligenz gespeichert ist, aber nicht wirklich verstehen, was in ihrem eigenen Kopf passiert.
Es hat den Vorteil, bewährte Methoden zu erben, statt sie mühsam selbst entdecken zu müssen, aber den Nachteil, dass man buchstäblich nicht versteht, in welchen Situationen diese Methoden scheitern.
Im Regiekommentar heißt es, diese Szene sei bewusst so platziert worden, um zu zeigen, dass einige Figuren die Regeln zu ernst nehmen und andere sie nicht ernst genug nehmen.
Der Grund, warum man anderen solche Cargo-Cult-Praktiken empfiehlt, scheint ähnlich zu sein: Je mehr Leute ihnen folgen, desto größer ist die Wahrscheinlichkeit, dass man selbst nicht derjenige ist, der scheitert, wenn die Praxis katastrophal versagt.
Ich sehe solche Fälle heutzutage viel zu oft und nenne solche Leute kluge Juniors. Es spielt keine Rolle, ob sie ein Jahr oder 20 Jahre Erfahrung haben.
Ein kluger Junior kennt die meisten Design Patterns und hat auch The Mythical Man-Month gelesen, rennt aber mit einem glänzenden neuen Hammer herum und sucht nach etwas, das wie ein Nagel aussieht, weil er neue Technologien, Sprachen oder Frameworks ausprobieren will.
Dabei trifft er seltsame Entscheidungen, weil er nicht versteht, welche Kraft eine gut optimierte alte Datenbank bieten kann.
Mit 20 Jahren Erfahrung habe ich oft gesehen, wie solche Projekte nach fünf bis zehn Jahren enden, wenn mehr als die Hälfte des ursprünglichen Teams weg ist; man behält die Teile mit echtem Wert und schneidet die nutzlose Hälfte heraus.
Wir betreiben keinen Entwickler-Kindergarten, der um jeden Preis Spaß haben will, sondern arbeiten für Unternehmen, die zahlen und stabile, relativ schnelle Ergebnisse erwarten.
Spitzentechnologie einzusetzen oder Neues auszuprobieren, nur um Langeweile zu vermeiden, hat langfristig öfter Dinge kaputtgemacht, als sie verbessert.
Man sollte Technologien einführen, die das ganze Team verstehen und beherrschen kann, nicht solche, die nur ein gelangweilter Superstar kennt.
Wenn man seinen Lebenslauf mit möglichst vielen Technologien füllen will, kann man das in solchen Firmen tun, und solche Orte haben auch ihren Wert.
Allerdings bleiben solche Leute ohnehin oft nicht lange, sodass auch der gesamte Mehrwert fraglich ist. Für manche mag es langweilig sein, aber ich nenne das professionelles Vorgehen.
Wenn das Ziel eines Side Projects ist, Firmen dazu zu bringen, sich mein GitHub anzusehen, wirkt es dadurch auch überzeugender.
Dokumentation ist sehr wichtig. Ich habe einige ziemlich einfache Projekte mit weniger als 300 Zeilen, darunter Bots und Web-Scraper, die ich heute nicht mehr ausführen kann, weil ich sie nicht dokumentiert habe.
Der Raspberry Pi, auf dem sie liefen, ist gestorben, und ich habe keine Ahnung, wie ich den headless virtuellen Framebuffer wieder zum Laufen bringen oder einen obskuren Fehler debuggen soll, zu dem Suchanfragen keine brauchbaren Ergebnisse liefern.
Hätte ich sie containerisiert oder wenigstens den Einrichtungsprozess dokumentiert, hätte ich dieses Problem nicht.
Guter Text, und ich wünschte, mehr Leute würden ihn lesen.
In 15 Jahren Arbeit mit Software, besonders im Bereich Datenmanagement, habe ich genau das gelernt.
Auch das Kesamutti Sutta, das ich aus einem Theravada-buddhistischen Hintergrund kenne, hat mir sehr geholfen.
Darin geht es darum, nichts einfach zu befolgen, nur weil man es wiederholt gehört hat, weil es Tradition ist, ein Gerücht, in den Schriften steht, auf Vermutungen, Axiomen oder plausibler Logik beruht, auf einer Voreingenommenheit gegenüber lange gehegten Vorstellungen, weil jemand kompetent wirkt oder weil es der Lehrer sagt.
Der Rat, etwas erst dann anzunehmen, wenn man selbst erkennt: „Dies ist heilsam, nicht tadelnswert, wird von Weisen gelobt und führt, wenn man es praktiziert, zu Nutzen und Glück“, war in meinem Leben sehr nützlich, auch nachdem ich seit der Mittelstufe Atheist geworden war.
Es gibt auch die Behauptung, jemand habe die Übersetzung verzerrt, damit sie rationalistischer wirkt.
Falls das stimmt, wäre das schade. Denn ich wollte gern glauben, dass Buddha ein so „erleuchteter“ Mensch war.
https://fakebuddhaquotes.com/do-not-believe-in-anything-simply-because-you-have-heard-it/
Ich stimme dem Teil zu, dass man sich nicht zu sehr sorgen sollte, „getäuscht worden“ zu sein oder „etwas Falsches gelernt“ zu haben.
Habe ich TDD gelernt, als es im Trend lag? Ja. Nutze ich heute TDD? Nein. Hat TDD mir trotzdem beigebracht, besseren Code zu schreiben? Ja.
Dasselbe gilt für Sprachen, die ich beruflich nicht mehr nutze. Alles lehrt einen etwas.
Man kann den guten Mittelweg nicht finden, ohne auf beiden Seiten ein wenig darüber hinauszugehen.
Wenn bereits Code vorhanden ist und man ihn erweitern will, ist es sinnvoll, ein paar Tests rund um die Nutzung zu schreiben.
Wenn es noch keinen Code gibt, man aber die Struktur im Kopf hat und Teile abgrenzen kann, die man zuerst bauen und testen kann, ist es ebenfalls sinnvoll.
Das ist kein TDD im reinen Sinn, sondern eher testunterstützte Entwicklung, aber man nutzt damit den Geist von TDD.
Auch schlechte Dinge zu lernen ist ein wichtiger Teil davon, zu verstehen, welche Ansätze besser oder schlechter sind.
Das heißt nicht, dass TDD an sich schlecht ist, aber es kann schlecht werden, wenn man sich übermäßig daran klammert.
Letztlich passt das auch zur allgemeinen Vorstellung, dass „Fehler der Weg zum Lernen sind“.
Solche Leitlinien und Prinzipien sind generell gut zu kennen, aber problematisch wird es, wenn Leute sie wie eine Religion behandeln.
Ideologen sind in unserer Branche wirklich eine Plage.
Kurz, treffend und sofort einleuchtend.
Guter Text und guter Rat.
Wenn die Honeymoon-Phase vorbei ist, lernt man am Ende, dass Programmieren frustrierend und chaotisch ist, egal welche „richtige Methode“ man verwendet, und dass man auch hervorragende Software bauen kann, ohne dieser Methode zu folgen.
Mit der Zeit lernt man Dutzende weitere „richtige Methoden“ kennen und mischt sie passend zum Problem.
Allerdings scheint es mir, dass in den letzten Jahren viele Entwickler in einer Fixierung auf die richtige Methode feststecken und ihr Wissen und ihre Perspektive nicht erweitern.
Falls das stimmt, ist das traurig, und ich weiß nicht genau, woran es liegt.
Vielleicht liegt es daran, dass es wegen der heute kürzeren Aufmerksamkeitsspannen schwieriger ist, Wissen effizient zu erweitern, und dass die aktuelle Position zu bequem geworden ist.
Oder daran, dass die Anreize zu groß sind, nur ein bestimmtes Framework zu lernen, während es zu wenig Anreiz gibt, grundlegendes Wissen darüber zu erwerben, wie es intern funktioniert.
Dadurch bleibt keine Zeit, aus der aktuellen Arbeit Lehren zu ziehen, und wenn diese Lehren ankommen, sind sie wahrscheinlich schon weg.
Gleichzeitig können sie es sich nicht leisten, sich nicht auf neue Hype-Technologien zu konzentrieren.
Dieser Trend bremst Wachstum erheblich.
Mein 1-Cent-Rat lautet: Zustand ist der Feind. Man sollte Zustand überall reduzieren, wo es möglich ist.
Das umfasst nicht nur Zustand im Code, sondern auch die Anzahl der Dinge, die man im Kurzzeitgedächtnis halten muss, um Arbeit zu erledigen, sowie projektspezifische Details, die man sich merken muss.
Zustand ist der Feind. Wenn man etwas aus First Principles herleiten kann, sollte man immer versuchen, genau das zu tun.
Ein Teil davon geht über Ratschläge nur für Programmierer hinaus.
Der erste Punkt ist etwas, über das alle nachdenken sollten. Viele Autoren und Essayisten werden nicht gelesen, weil sie Experten für das jeweilige Thema sind, sondern weil sie gut schreiben können.
Man sollte auch spazieren gehen.
Es ist gut, verschiedene Arten von Arbeit auszuprobieren und auch andere Rollen im Unternehmen kennenzulernen.
Besonders in großen Unternehmen kann die eigene Arbeit etwas sein, das irgendwo später wieder korrigiert oder umgangen werden muss; wenn man es selbst ändert, kann es für alle einfacher werden.
Der erste Punkt ist auch ein Grund, warum man skeptisch gegenüber dem sein sollte, was man auf Video-Sharing-Diensten wie YouTube lernt.
Wenn jemand vertrauenswürdig spricht und Ideen professionell präsentiert, nehmen Menschen diese Ideen ernst, selbst wenn sie fehlerhaft sind.
In einer Welt, in der sich herausgestellt hat, dass manche „Essayisten“ im Grunde nur Wikipedia-Artikel und Reddit-Posts vorlesen, braucht man die Haltung, plausible Darstellung und Korrektheit voneinander zu trennen.
Punkt 10 würde ich ebenfalls weiter ausbauen. Wenn man mit den beteiligten Menschen spricht, erkennt man besser, welches Problem die Software oder Entwicklungsarbeit lösen soll, und findet auch Schmerzpunkte, die man selbst nicht gesehen hat.
Mit sehr wenigen Ausnahmen schreibt man Software nicht um ihrer selbst willen, sondern um Probleme zu lösen.
Sie können irgendwo im Internet oder im Training eine „richtige“ Antwort gelesen haben und sie überzeugend wiederholen, ohne zu prüfen, ob sie tatsächlich wahr ist.
Ich mag das im Text empfohlene Debugging-Buch so sehr, dass ich mehrere Exemplare gekauft und verschenkt habe.
Ich habe es Freunden, Praktikanten, Data Scientists und sogar Führungskräften gegeben, und alle, die es gelesen haben, waren dankbar.
Es enthält einige gute, einfache Techniken zum Lösen von Problemen in großen technischen Systemen und ist deshalb für fast jeden nützlich.
Es ist leicht zu lesen und interessant, und es enthält viele „War Stories“, die Ratschlägen, die sonst trocken wirken könnten, Farbe und Kontext geben.
https://debuggingrules.com/
Die Aussage „Die Leute hören mir nicht zu, weil ich ein guter Programmierer bin, sondern weil ich gut schreiben kann“ bedeutet nicht nur, dass man beim Lesen von Texten guter Autorinnen und Autoren vorsichtig sein sollte; sie gilt auch für die Art, wie wir an unsere Arbeit herangehen.
Wer gut schreibt, kann in der Regel auch besser mit anderen Menschen umgehen.
Für Softwareentwickler sind Schreiben und Kommunikation Kernbestandteile der Arbeit.
Anfängern wird empfohlen, über erlebte Schwierigkeiten, Experimente und Denkprozesse zu schreiben.
Wenn möglich, sollte man auch Essays schreiben. Später in der Karriere wird das zu einer wirklich nützlichen Fähigkeit.
Eine Aussage lässt sich Anfängern nur schwer richtig erklären: „Deine Arbeit besteht nicht darin, Code zu schreiben.“
Wir verwenden Code als Werkzeug, um Probleme zu lösen.
Code ist ein Mittel zum Zweck, nicht der Zweck selbst.
Wenn man um des Codes willen programmiert, führt das zu falschen Ergebnissen.
Man sollte sich auf Problemlösung konzentrieren; wenn nicht klar ist, welches Problem der eigene Code löst, sollte man mit dem Programmieren aufhören und das zuerst herausfinden.
Je nach Unternehmen kann es auch E-Mail sein.
Fragen zu beantworten, zusammenzuarbeiten und die Richtung von Team und Organisation zu beeinflussen, fühlt sich wie Arbeit an; doch Kommunikation ist, genau wie Code, ein Werkzeug, um etwas Nützliches zu schaffen, und nicht selbst das Nützliche.
Die meiste Software, selbst Code, der als „Code um des Codes willen“ geschrieben wurde, löst meiner Ansicht nach irgendein Problem.
Viele Programmierer wissen das zumindest unbewusst und schreiben deshalb solchen Code.
Das eigentliche Problem liegt darin, dass andere Menschen, etwa die Business-Leute im Anzug, wollen, dass dieser Code ein anderes Problem löst.
Allerdings muss dieser Code der richtige Code sein.
Allgemeiner erklärt man es als „Business-Probleme durch den Einsatz von Softwaresystemen lösen“.
Wenn man es Juniors so sagt, richten sie den Fokus auf geschäftliche Anforderungen und können die Aussagen von MBAs, Managern oder PMs kritisch beurteilen, um das Richtige zu tun.
Aber schon die Tatsache, dass es Software gibt, die man an VCs verkaufen kann, hat einen Wert.
Deshalb wird man manchmal wirklich dafür bezahlt, Code zu schreiben.