Die Fata Morgana der Produktivität

• Der legendäre Facebook-Engineer Bob veröffentlichte Facebook Groups und erzielte bei Hackathons immer wieder Ergebnisse – auch ohne ausgefeilte Entwicklungsumgebung
• Er nutzte nur das standardmäßige Sublime Text und printf-Logs; die Syntaxhervorhebung war ungenau, Live Reloading und Debugger gab es ebenfalls nicht
• Die Entwickler in seinem Umfeld hingegen betrachteten komplexe Tool-Konfigurationen wie Vim-Syntaxhervorhebung und Snippets, tmux, mosh, hphpd-Shortcuts und Git-Aliasse als Kern ihrer Produktivität
• Für Bobs Hackathon-Sieg waren weniger Editor-Einstellungen entscheidend als vielmehr Produktgespür und Intuition – also die Fähigkeit zu beurteilen, was gebaut werden sollte
• Neue Arbeitsweisen können Veränderungen bewirken, doch letztlich entstehen Ergebnisse dadurch, das richtige Problem zu lösen

---

Der Unterschied zwischen komplexen Tools und tatsächlichen Ergebnissen

• Bob war ein produktiver Engineer, der Facebook Groups veröffentlichte, und eine legendäre Figur, die bei Hackathons immer wieder Ergebnisse lieferte
• Ein Kollege, der damals stark auf Produktivität fokussiert war, nutzte eine selbst erstellte Vim-Syntaxhervorhebung und Snippets für Hack, Facebooks PHP-Dialekt
  • Er ließ tmux über mosh laufen und hatte dazu maßgeschneiderte hphpd-Shortcuts sowie Git-Aliasse konfiguriert
• Bobs Arbeitsweise war im Gegensatz dazu äußerst schlicht
  • Er nutzte Sublime Text ohne zusätzliche Konfiguration, wodurch ungefähr die Hälfte der Codefarben falsch angezeigt wurde
  • Statt Live Reloading oder Debugger setzte er printf in den Code und wartete darauf, dass Logs erschienen
• Bei diesem Hackathon gewann Bob; soweit erinnerlich, handelte es sich bei seiner Arbeit um eine Funktion, die Kauf- und Verkaufsbeiträge in Facebook Groups unterstützte
  • Diese Funktion entwickelte sich später zu Facebook Marketplace

Wie man arbeitet oder was man baut

• Wer sich auf komplexe Tools konzentriert, kann sich im Wie der Arbeitsweise verlieren und das Was – den eigentlichen Gegenstand der Arbeit – aus dem Blick verlieren
• Der Kern von Bobs hoher Produktivität lag nicht in seinen Editor-Einstellungen, sondern in Produktgespür und Intuition
• Auf X tauchen täglich neue Arbeitsweisen auf, die so wirken, als könnten sie alles verändern; einige davon haben tatsächlich das Potenzial, Veränderungen zu bewirken
• Das Wichtigste ist jedoch nicht das Tool oder die Arbeitsweise selbst, sondern das richtige Problem zu lösen

[GN⁺]

Hacker-News-Kommentare

• Die Trennung zwischen dem Handwerker, der Werkzeuge schont, und Menschen, die von Werkzeugen besessen sind, ist falsch. Gute Werkzeuge sind kein Spielzeug, sondern Mittel zum Zweck, und auch ich habe mehrere Tage darauf verwendet, Shell-Skripte, Emacs-Funktionen und Fenster-Layout-Tools zu bauen, die zu meinem Workflow passen
  Das Ergebnis war, dass Syntax-Highlighting, Code-Navigation und -Analyse, Bildschirmaufteilung und Git-Operationen mit nur wenigen Tastendrücken möglich wurden und ablenkende Elemente verschwanden. Man sollte in die Arbeitsumgebung investieren – etwa in Stuhl, Shell-Prompt und Editor –, sie dann aber, sobald alles bequem ist, vergessen und sich auf das eigentliche Problem konzentrieren
  Endloses Tuning von Werkzeugen kann allerdings ein Signal dafür sein, dass man mühsame und wenig spaßige Aufgaben vermeiden will; das ist kein so simples Problem, dass man einfach dem Werkzeug die Schuld geben könnte

  • Was macht man, wenn man in einem neuen Job einen neuen Tech-Stack und ein Windows-Laptop bekommt? Am Anfang meiner Karriere habe ich gelernt, mit den Standardwerkzeugen der vorgegebenen Umgebung effizient zu arbeiten, und tatsächlich konnte ich die Werkzeuge nur selten selbst auswählen. Auch plattformübergreifende Tools sind – abgesehen von der JetBrains-Produktfamilie – oft wenig konsistent
  • Das wirkt wie der Unterschied zwischen Samurai und Ninja. Samurai betrachteten das Schwert als Erweiterung ihrer Seele, während Ninja bei Bedarf auch Dinge damit aufhebelten. In der heutigen Wirtschaft passt die samuraihafte Sicht auf Werkzeuge nicht mehr
  • Es ist wichtig, Werkzeuge mit Freude zu benutzen. Auch wenn die Produktivität dadurch nicht um das Zehnfache steigt, ist entscheidend, dass man sich auf die Arbeit konzentrieren und den Prozess genießen kann
    Gerade Werkzeuge im LLM-Zeitalter zwingen einen dazu, ständig zwischen mehreren Agenten und Terminals hin- und herzuwechseln. Diese häufigen Kontextwechsel rauben einem Freude und Flow, daher hoffe ich, dass jemand eine Lösung findet
  • Es wirkt oft so, als wollten Einsteiger anerkannt und ernst genommen werden und würden deshalb notwendige Schritte überspringen. So zu wirken und tatsächlich so zu sein, sind aber zwei verschiedene Dinge, und während man Fähigkeiten aufbaut, muss man auch seinen Lebensunterhalt bestreiten
  • Sobald man eine Technik beherrscht, werden gute Werkzeuge selbst zu einer großen Freude. Umgekehrt können Erfahrene manchmal mit ungeeigneten Werkzeugen überraschend gute Ergebnisse erzielen

• Ich habe viele Techniker gesehen, die mehr Zeit mit der Optimierung ihrer Umgebungskonfiguration verbringen als mit dem eigentlichen Bauen, und ich selbst war auch so. Die Vorstellung, man müsse die Eingabegeschwindigkeit erhöhen, weil 90 % der Coding-Zeit aus Tippen bestünden, ist falsch; 90 % der Zeit sollten ins Denken gehen, und der Großteil davon ins Lesen

  • Software ist die konkret gewordene Lösung für ein Problem, daher muss man zuerst das zu lösende Problem definieren. Code ist ein Schnappschuss, der allen – auch dem zukünftigen Ich – den aktuellen Stand des Problemverständnisses sowie die Klarheit und Angemessenheit der Lösung zeigt
    Programmieren zum richtigen Zeitpunkt ist eher Tipparbeit, bei der eine bereits verstandene Lösung konkretisiert wird
  • Früher war ich besessen von Konfigurationen, aber seit ich AI nutze, baue ich coole Dinge, die ich vorher nicht hätte bauen können. Gleichzeitig schwinden mein Verständnis des zugrunde liegenden Codes und meine bisherigen Fähigkeiten langsam, und obwohl ich neue Techniken bewundere, lerne ich sie offenbar nicht wirklich tiefgehend
    In dem Sinn, dass AI die Einstiegshürde senkt, ist sie auch eine weitere Form der Umgebungsverbesserung. Als ich früher von einer QA-Rolle in die Entwicklung wechseln wollte und durch Europa reiste, um InterviewCake zu lernen, vergeudete ich ebenfalls Zeit damit, statt Probleme zu lösen meinen Editor zu konfigurieren
    Vielleicht ist das ein Symptom von ADHS. Nach einer medikamentösen Behandlung hat sich meine Produktivität zuletzt stark verändert, und ich hätte beinahe geweint bei dem Gedanken, die Hälfte meines Lebens damit vergeudet zu haben, Einstellungen zu perfektionieren, statt echte Arbeit zu erledigen
  • Zwischen tatsächlicher Produktivität und gefühlter Produktivität gibt es eine Lücke. Wenn man mit Vim oder Emacs souverän Code eintippt, fühlt man sich vielleicht wie ein Hacker, aber das heißt nicht, dass man produktiv ist. Selbst wenn man mit riesigen Tokenmengen Dutzende AI-Agenten dirigiert, ist nicht garantiert, dass das Ergebnis funktioniert oder ein Problem löst
  • Ich bin mir nicht sicher, ob für die meisten gewöhnlichen CRUD-Anwendungsentwickler das Verhältnis stimmt, 90 % der Zeit ins Denken und Lesen zu stecken
  • Denken und Tippen passieren oft gleichzeitig. Viele Menschen können über ein Problem leichter nachdenken, während sie Code schreiben und verändern, und das ist auch ein Grund, warum das Codeverständnis stark sinken kann, selbst wenn man den gesamten von einem LLM erzeugten Code liest

• Es gibt VC-finanzierte Unternehmen, die keine Produkte bauen können, die tatsächlich genutzt oder bezahlt werden. Um ihre Bewertung zu rechtfertigen, zeigen sie, wie beschäftigt und produktiv sie sind, und der AI-Hype könnte im selben Kontext stehen, insofern er sich ebenfalls stärker auf Produktivität und Methoden konzentriert als auf das, was überhaupt gebaut werden soll
  https://components.news/the-gamer-and-the-nihilist/ vergleicht solche nihilistischen Startups mit Game-Studios, die Produkte bauen, für die Menschen tatsächlich zahlen und die sie benutzen. In einer Wirtschaft, in der Produktivitäts-Apps fast 40 % der Product-Hunt-Ergebnisse ausmachen, fließt Arbeit mitunter eher darin, so auszusehen, als würde man etwas bauen, statt tatsächlich etwas zu bauen

  • Auch Game-Entwickler stecken gewaltige Anstrengungen in die Entwicklung von Werkzeugen, nur sind diese primär keine Texteditoren
  • Ich frage mich, wo in dieser Analogie Menschen einzuordnen sind, die unzählige Stunden damit verbringen, eher die perfekte Gaming-Umgebung als Spiele zu schaffen, oder Audio-Enthusiasten, die ihr Leben lang nach dem perfekten Equipment statt nach Musik suchen
  • Das ist weniger eine Blase als vielmehr eine seit Langem wiederholte Signalmanipulation. Das gab es schon immer und wird es auch weiterhin geben

• Ich baue oder nutze Produktivitätswerkzeuge nur so weit, dass ich nicht zurückfalle; alles darüber hinaus halte ich für eine Falle. Früher habe ich das einmal pro Quartal überprüft, aber seit AI verbringe ich 1–2 Tage pro Woche mit der Meta-Arbeit, Werkzeuge zu verbessern, und ich erwarte, dass das zurückgeht, sobald sich die entsprechenden Tools standardisieren
  Wenn das Bild vom Werkzeugexperten zu stark wird, verpasst man nicht nur tatsächlich wertvolle Arbeit, sondern gilt auch als jemand mit geheimen Produktivitätskniffen. Wenn der Unterschied dann doch nicht so groß ist wie erwartet, könnte auch anderen Urteilen weniger vertraut werden

• Je weniger Zeit ich vor dem Computer verbracht habe, desto mehr habe ich geschafft, und als ich meine Monitore von drei auf einen reduziert habe, stieg meine Produktivität deutlich. Die meisten Probleme löse ich beim Gemüseschneiden oder Rasenmähen; nur weil man vor glänzender Technik sitzt, trifft man nicht automatisch schnellere oder bessere Entscheidungen
  Dass ich oft bessere Ergebnisse liefere als die Entwicklungsteams meiner Kunden, liegt auch daran, dass ich kein Festangestellter bin und mir erlauben kann, ausreichend innezuhalten und langsam nachzudenken. Produktivitätstheater wie der Druck, den Teams-Status auf Grün zu halten, führt in vielen Organisationen zu törichten Entscheidungen

  • 15 Jahre lang habe ich in zwei Firmen gearbeitet, deren Büros auf Klippen mit Blick auf den Ozean in La Jolla, Kalifornien, lagen. Ich dachte bei Spaziergängen an den Klippen und durch den Park über die Arbeit nach, und wenn ich mit Kollegen eine ernsthafte Diskussion führen wollte, für die kein Whiteboard nötig war, bat ich sie, mit mir spazieren zu gehen. Es lohnt sich, Rich Hickeys hammock talk noch einmal anzuhören
  • Beim Anblick des Benutzernamens frage ich mich, ob das der im Text erwähnte Bob ist

• Wenn ich darüber nachdenke, warum Produktivität überhaupt existiert, komme ich zu der Hypothese, dass sie ein Versuch ist, Schmerz zu reduzieren. Viele Performance-Optimierungen – auch die der Produktivität von Programmierern – werden oft zum Zufluchtsort von Ingenieuren, die dem Schmerz von Unklarheit im Problemraum, Organisationspolitik, Mehrdeutigkeit und dem Risiko des Scheiterns entgehen wollen
  Um aber reale Probleme zu lösen, muss man sich der Wirklichkeit stellen: die Workflows der Nutzer bis ins Langweilige detailliert prüfen, eine gemeinsame Strategie klar vorschlagen, um die Kooperation anderer zu gewinnen, und so weiter. Man muss den Schmerz selbst nicht glorifizieren, aber guten Ergebnissen wohnt ein Training wie bei Athleten inne, und man muss die Fähigkeit entwickeln, den für den Wettkampf nötigen Schmerz zu bewältigen

• Der Kern ist, wie leicht sich Anerkennung bekommen lässt. Glänzende Werkzeuge kann jeder sehen und bewundern, aber nur wenige erkennen in einem leeren Editor oder Skelettcode ein großartiges neues Produkt oder Feature. Deshalb sammelt sich Aufmerksamkeit bei gut sichtbaren Werkzeugen, während die schwierige und unklare Frage, was eigentlich gebaut werden soll, vernachlässigt wird
  Auf Werkzeuge wende ich Marie-Kondo-Kriterien an. Wenn ihre Nutzung keine Freude macht und mein Leben nicht einfacher macht, werfe ich sie weg; andernfalls behalte ich sie

• 2004 erhielt ein kleines Team, das überwiegend aus Junior-Entwicklern bestand, eine hervorragende und umfangreiche Java-Schulung. Vor der Schulung diskutierten wir verbissen und waren besessen von den Einstellungen von IntelliJ und Eclipse, doch der Dozent empfahl überraschenderweise, nur die grundlegenden JDK-Werkzeuge und Notepad zu verwenden
  Das Ziel war, uns beizubringen, was intern passiert, und außerdem meinte er, bei der Produktivität werde es vermutlich keinen großen Unterschied geben

• Der Grund, warum man von der Optimierung seiner Umgebung so besessen sein kann, ist, dass die Verbindung zwischen konzentrierter Anstrengung und Belohnung sichtbar, konkret und physisch ist. Abstraktes Lernen ist das nicht. Es gibt viel mehr Lernaufgaben als Stühle zu optimieren, also wäre es schön, Wege zu finden, damit sich auch abstraktes Lernen konkreter anfühlt

• Es geht nicht um Produktivität, sondern um den Spaß, mit Spielzeug zu spielen