Was Entwickler produktiv macht

xguru · 2023-08-07T11:09:02+09:00

Viele Faktoren beeinflussen die Produktivität von Entwicklern Einige sind klar und leicht messbar, andere sind schwer zu messen und werden deshalb leicht übersehen Wissen, was gebaut werden soll (Knowing what to build) Das Falsche schnell zu bauen, ist überhaupt nicht produktiv man muss wissen, was Kunden verlangen, was für andere Teams akzeptabel ist (wie viele Indizes sind auf einer DB-Tabelle möglich, dürfen rechtlich nicht zulässige Informationen geteilt werden?), und was zuvor schon versucht wurde, aber nicht funktioniert hat Weniger Arbeit erledigen Es ist gut, Arbeit schnell abzuschließen, aber noch besser ist es, wenn man etwas gar nicht erst "tun muss" Unternehmensprozesse können beschäftigende "Busywork" hinzufügen, die die Produktivität senkt manchmal lassen sich Prozesse leicht so anpassen, dass mit deutlich weniger Aufwand derselbe Wert geliefert wird Ein gewisser Aufwand kann nötig sein, um "Keep the lights on (KTLO)" zu gewährleisten Das sind Aufgaben, die kontinuierlich erledigt werden müssen (z. B. Support-Tickets beantworten), aber ein Projekt nicht voranbringen Solche Arbeiten können in verschiedenen Kennzahlen produktiv aussehen (Anzahl abgeschlossener Tickets, Anzahl gemergter Commits), führen das Unternehmen aber nicht an einen besseren Ort Schnell reagierende Tools Entwickler nutzen ständig Tools: Editor, git, Build-System Die zusätzliche Zeit, die diese Tools verursachen, summiert sich je nach Nutzungshäufigkeit zu erheblichen Kosten Das kostet nicht nur Zeit pro Stunde, sondern unterbricht auch die Konzentration der Entwickler Wissen im Kopf der Entwickler Schwer zu messen Wenn alle anderen Bedingungen gleich sind, sind Entwickler mit mehr relevantem Wissen produktiver weil sie nicht tief in den Code eintauchen müssen, da sie wissen, wie er funktioniert, weil sie wissen, wie man die Tools benutzt, und welche Fallstricke zu vermeiden sind sie stellen die richtigen Fragen 10x-Entwickler gibt es, und sie sind "Menschen, die die Codebasis gut kennen" Das bedeutet, dass ein Team insgesamt nicht mehr besitzen sollte, als es kollektiv in seinen Köpfen behalten kann. (Ideal ist eine Bus Number größer als 1: Bus-Factor-Theorie) Es bedeutet auch, dass es vorteilhaft ist, die Häufigkeit von Ownership-Wechseln zu minimieren Niemand weiß mehr darüber als die Person, die es gebaut hat Idealerweise arbeiten Menschen, die ein System zum ersten Mal nutzen, mit denen zusammen und lernen von denen, die das System bereits gut kennen Es braucht klare Grenzen zwischen Systemen Saubere Interfaces mit einfacher Semantik bedeuten, dass man über die Eigenschaften eines Interfaces nachdenken kann, ohne das gesamte System dahinter kennen zu müssen Dokumentation ist ein guter Weg, Wissen zu vermitteln Besonders wichtig ist das, wenn Entwickler eine bestimmte Aufgabe erledigen müssen, mit der sie nicht vertraut sind Fehlt Dokumentation, müssen Entwickler selbst erforschen, wie die Aufgabe auszuführen ist, machen Fehler und müssen Dinge erneut tun oder warten, bis ein anderes Team Fragen beantwortet; das kann die Arbeit verlangsamen So kann aus einer einstündigen Aufgabe schnell eine zweitägige werden Wenn 100 Entwickler diese Arbeit erledigen müssen, kann die fehlende eine Seite Dokumentation Kosten in Höhe des Jahresgehalts eines Entwicklers verursachen Das bedeutet auch, dass die Spezialisierung zunehmen sollte Es ist unproduktiv, von allen Entwicklern zu verlangen, ein breites Spektrum an Aufgaben zu erledigen Eine Stunde, die in einen Prozess für ein bestimmtes Security-System oder Capacity Planning fließt, ist etwas anderes als eine Stunde, die man braucht, um die Domäne zur Problemlösung zu verstehen Nützliche Infrastruktur Infrastruktur sollte Hilfe sein, kein Hindernis Sie sollte auf vernünftige Weise eng auf alle zu erledigenden Aufgaben ausgerichtet sein Jeder Teil der Infrastruktur wird mit bestimmten Use Cases im Kopf entworfen, aber in Projekten gibt es manchmal Fälle außerhalb dieser Use Cases Dann ist es frustrierend, Dinge zu hören wie "Ihr müsst nur unsere Infrastruktur benutzen" oder "So etwas geht in unserer Infrastruktur nicht" Dann muss man um die Infrastruktur herumarbeiten oder Zeit in Meetings verschwenden, um Infrastrukturverantwortliche von Anforderungen zu überzeugen Geringe technische Schulden Bestehender Code passt nie perfekt zu der Aufgabe, die man gerade erledigen will Der ursprüngliche Autor des Codes hatte keine "Kristallkugel", um zu sehen, welche Änderungen später nötig sein würden Aber mancher Code lässt sich viel leichter ändern als anderer Die Antwort auf "Wie können wir X tun?" sollte nicht sein: "Wir müssen all das neu entwerfen" Wenn es viele technische Schulden gibt, erfordern selbst kleine Funktionsänderungen größere Änderungen am System Das Reduzieren technischer Schulden hilft, die Oberfläche zu minimieren, die man (a) verstehen und (b) ändern muss Projekte zum Abbau technischer Schulden müssen abgeschlossen werden Wenn man sie unterwegs aufgibt oder herabpriorisiert, kann das System am Ende schlechter sein als zuvor Niedrige Fehlerrate Wenn Tool-Ausführungen fehlschlagen, Builds scheitern, Deployments fehlschlagen oder es Regressionen durch Produktionsfehler gibt, ist Zeit verschwendet worden Wird die Wahrscheinlichkeit solcher Fehler gesenkt, steigt die Produktivität Neben den Ingenieuren, die den Fehler erleben, wird oft auch die Zeit des Teams verschwendet, dem das fehlerhafte System gehört (weil man den Fehler gemeinsam analysieren und beheben muss) Produktive Praktiken sind praktisch (Productive practices are practical) Der beste Weg zu lernen, wie man ein bestimmtes Problem löst, ist, einen Prototypen zu bauen Wenn die Umgebung Prototyping behindert, kann auch der produktivste Ansatz behindert werden Wenn Monitoring-Tools schwer zu benutzen sind, erstellen Entwickler weniger Dashboards, messen weniger und treffen Entscheidungen, die weniger datenbasiert sind Umgekehrt gilt: Wenn große Änderungen in kleinere Code-Reviews zerlegt werden, lassen sich Code leichter reviewen und Deployments einfacher durchführen Wie gut sich Ingenieure konzentrieren können Ingenieure arbeiten nach Produktionsplänen und müssen sich konzentrieren können Diese Konzentration kann durch Meetings und Unterbrechungen gestohlen werden Zu Unterbrechungen gehören auch langsame CLI-Befehle, langsame Tests und Aufgaben, bei denen man erst recherchieren muss, weil man nicht weiß, wie sie auszuführen sind Auch über zu viele Dinge in einer Woche nachdenken zu müssen, schadet der Fähigkeit, sich zu konzentrieren Bevorstehende Deadlines oder Fragen, auf die der Manager noch nicht geantwortet hat, belegen mentalen RAM, selbst wenn man sich auf etwas anderes konzentrieren will Arbeit zu Ende bringen 50 % zu bauen bedeutet nicht 50 % Produktivität, sondern 0 % Produktivität Nichts ist unproduktiver als Arbeit, die verworfen wird Manchmal ist es trotzdem die richtige Entscheidung, ein Projekt auf halbem Weg abzubrechen Gegen die Sunk-Cost-Fallacy anzukämpfen, ist manchmal richtig Es sollte aber kein dauerhaftes Muster geben, bei dem Prioritäten geändert werden, bevor ein Projekt abgeschlossen ist In so einem Fall kann die Produktivität eines Teams auf 0 sinken Fazit Man kann nicht immer ein Dashboard bauen, um all diese verschiedenen Faktoren zu messen, aber man kann verstehen, wie Dinge wie die oben genannten die Produktivität beeinflussen Die Lösung solcher Probleme kann die Menge der erledigten Arbeit stark erhöhen Einige Probleme lassen sich überraschend leicht beheben Wenn man ein paar Stunden in das Schreiben von Dokumentation investiert, kann das dem Unternehmen Tausende Stunden sparen Wenn man einen Baum schnell fällen will, sollte man zuerst das Sägeblatt schärfen

(jeremymikkola.com)

86 Punkte von xguru 2023-08-07 | 7 Kommentare | Auf WhatsApp teilen

Viele Faktoren beeinflussen die Produktivität von Entwicklern
Einige sind klar und leicht messbar, andere sind schwer zu messen und werden deshalb leicht übersehen

Wissen, was gebaut werden soll (Knowing what to build)

Das Falsche schnell zu bauen, ist überhaupt nicht produktiv
- man muss wissen, was Kunden verlangen,
- was für andere Teams akzeptabel ist (wie viele Indizes sind auf einer DB-Tabelle möglich, dürfen rechtlich nicht zulässige Informationen geteilt werden?),
- und was zuvor schon versucht wurde, aber nicht funktioniert hat

Weniger Arbeit erledigen

Es ist gut, Arbeit schnell abzuschließen, aber noch besser ist es, wenn man etwas gar nicht erst "tun muss"
Unternehmensprozesse können beschäftigende "Busywork" hinzufügen, die die Produktivität senkt
- manchmal lassen sich Prozesse leicht so anpassen, dass mit deutlich weniger Aufwand derselbe Wert geliefert wird
Ein gewisser Aufwand kann nötig sein, um "Keep the lights on (KTLO)" zu gewährleisten
Das sind Aufgaben, die kontinuierlich erledigt werden müssen (z. B. Support-Tickets beantworten), aber ein Projekt nicht voranbringen
Solche Arbeiten können in verschiedenen Kennzahlen produktiv aussehen (Anzahl abgeschlossener Tickets, Anzahl gemergter Commits), führen das Unternehmen aber nicht an einen besseren Ort

Schnell reagierende Tools

Entwickler nutzen ständig Tools: Editor, git, Build-System
Die zusätzliche Zeit, die diese Tools verursachen, summiert sich je nach Nutzungshäufigkeit zu erheblichen Kosten
Das kostet nicht nur Zeit pro Stunde, sondern unterbricht auch die Konzentration der Entwickler

Wissen im Kopf der Entwickler

Schwer zu messen
Wenn alle anderen Bedingungen gleich sind, sind Entwickler mit mehr relevantem Wissen produktiver
- weil sie nicht tief in den Code eintauchen müssen, da sie wissen, wie er funktioniert,
- weil sie wissen, wie man die Tools benutzt, und welche Fallstricke zu vermeiden sind
- sie stellen die richtigen Fragen
- 10x-Entwickler gibt es, und sie sind "Menschen, die die Codebasis gut kennen"
Das bedeutet, dass ein Team insgesamt nicht mehr besitzen sollte, als es kollektiv in seinen Köpfen behalten kann. (Ideal ist eine Bus Number größer als 1: Bus-Factor-Theorie)
- Es bedeutet auch, dass es vorteilhaft ist, die Häufigkeit von Ownership-Wechseln zu minimieren
- Niemand weiß mehr darüber als die Person, die es gebaut hat
- Idealerweise arbeiten Menschen, die ein System zum ersten Mal nutzen, mit denen zusammen und lernen von denen, die das System bereits gut kennen
Es braucht klare Grenzen zwischen Systemen
- Saubere Interfaces mit einfacher Semantik bedeuten, dass man über die Eigenschaften eines Interfaces nachdenken kann, ohne das gesamte System dahinter kennen zu müssen
Dokumentation ist ein guter Weg, Wissen zu vermitteln
- Besonders wichtig ist das, wenn Entwickler eine bestimmte Aufgabe erledigen müssen, mit der sie nicht vertraut sind
- Fehlt Dokumentation, müssen Entwickler selbst erforschen, wie die Aufgabe auszuführen ist, machen Fehler und müssen Dinge erneut tun oder warten, bis ein anderes Team Fragen beantwortet; das kann die Arbeit verlangsamen
- So kann aus einer einstündigen Aufgabe schnell eine zweitägige werden
- Wenn 100 Entwickler diese Arbeit erledigen müssen, kann die fehlende eine Seite Dokumentation Kosten in Höhe des Jahresgehalts eines Entwicklers verursachen
Das bedeutet auch, dass die Spezialisierung zunehmen sollte
- Es ist unproduktiv, von allen Entwicklern zu verlangen, ein breites Spektrum an Aufgaben zu erledigen
- Eine Stunde, die in einen Prozess für ein bestimmtes Security-System oder Capacity Planning fließt, ist etwas anderes als eine Stunde, die man braucht, um die Domäne zur Problemlösung zu verstehen

Nützliche Infrastruktur

Infrastruktur sollte Hilfe sein, kein Hindernis
Sie sollte auf vernünftige Weise eng auf alle zu erledigenden Aufgaben ausgerichtet sein
Jeder Teil der Infrastruktur wird mit bestimmten Use Cases im Kopf entworfen, aber in Projekten gibt es manchmal Fälle außerhalb dieser Use Cases
- Dann ist es frustrierend, Dinge zu hören wie "Ihr müsst nur unsere Infrastruktur benutzen" oder "So etwas geht in unserer Infrastruktur nicht"
- Dann muss man um die Infrastruktur herumarbeiten oder Zeit in Meetings verschwenden, um Infrastrukturverantwortliche von Anforderungen zu überzeugen

Geringe technische Schulden

Bestehender Code passt nie perfekt zu der Aufgabe, die man gerade erledigen will
- Der ursprüngliche Autor des Codes hatte keine "Kristallkugel", um zu sehen, welche Änderungen später nötig sein würden
- Aber mancher Code lässt sich viel leichter ändern als anderer
Die Antwort auf "Wie können wir X tun?" sollte nicht sein: "Wir müssen all das neu entwerfen"
Wenn es viele technische Schulden gibt, erfordern selbst kleine Funktionsänderungen größere Änderungen am System
Das Reduzieren technischer Schulden hilft, die Oberfläche zu minimieren, die man (a) verstehen und (b) ändern muss
Projekte zum Abbau technischer Schulden müssen abgeschlossen werden
- Wenn man sie unterwegs aufgibt oder herabpriorisiert, kann das System am Ende schlechter sein als zuvor

Niedrige Fehlerrate

Wenn Tool-Ausführungen fehlschlagen, Builds scheitern, Deployments fehlschlagen oder es Regressionen durch Produktionsfehler gibt, ist Zeit verschwendet worden
Wird die Wahrscheinlichkeit solcher Fehler gesenkt, steigt die Produktivität
Neben den Ingenieuren, die den Fehler erleben, wird oft auch die Zeit des Teams verschwendet, dem das fehlerhafte System gehört (weil man den Fehler gemeinsam analysieren und beheben muss)

Produktive Praktiken sind praktisch (Productive practices are practical)

Der beste Weg zu lernen, wie man ein bestimmtes Problem löst, ist, einen Prototypen zu bauen
Wenn die Umgebung Prototyping behindert, kann auch der produktivste Ansatz behindert werden
Wenn Monitoring-Tools schwer zu benutzen sind, erstellen Entwickler weniger Dashboards, messen weniger und treffen Entscheidungen, die weniger datenbasiert sind
Umgekehrt gilt: Wenn große Änderungen in kleinere Code-Reviews zerlegt werden, lassen sich Code leichter reviewen und Deployments einfacher durchführen

Wie gut sich Ingenieure konzentrieren können

Ingenieure arbeiten nach Produktionsplänen und müssen sich konzentrieren können
Diese Konzentration kann durch Meetings und Unterbrechungen gestohlen werden
Zu Unterbrechungen gehören auch langsame CLI-Befehle, langsame Tests und Aufgaben, bei denen man erst recherchieren muss, weil man nicht weiß, wie sie auszuführen sind
Auch über zu viele Dinge in einer Woche nachdenken zu müssen, schadet der Fähigkeit, sich zu konzentrieren
Bevorstehende Deadlines oder Fragen, auf die der Manager noch nicht geantwortet hat, belegen mentalen RAM, selbst wenn man sich auf etwas anderes konzentrieren will

Arbeit zu Ende bringen

50 % zu bauen bedeutet nicht 50 % Produktivität, sondern 0 % Produktivität
Nichts ist unproduktiver als Arbeit, die verworfen wird
Manchmal ist es trotzdem die richtige Entscheidung, ein Projekt auf halbem Weg abzubrechen
- Gegen die Sunk-Cost-Fallacy anzukämpfen, ist manchmal richtig
- Es sollte aber kein dauerhaftes Muster geben, bei dem Prioritäten geändert werden, bevor ein Projekt abgeschlossen ist
- In so einem Fall kann die Produktivität eines Teams auf 0 sinken

Fazit

Man kann nicht immer ein Dashboard bauen, um all diese verschiedenen Faktoren zu messen, aber man kann verstehen, wie Dinge wie die oben genannten die Produktivität beeinflussen
Die Lösung solcher Probleme kann die Menge der erledigten Arbeit stark erhöhen
Einige Probleme lassen sich überraschend leicht beheben
- Wenn man ein paar Stunden in das Schreiben von Dokumentation investiert, kann das dem Unternehmen Tausende Stunden sparen
Wenn man einen Baum schnell fällen will, sollte man zuerst das Sägeblatt schärfen

7 Kommentare

kofmania 2023-08-07

Das ist ein Artikel mit vielen eher abschließenden Formulierungen.

laeyoung 2023-08-07

"Wenn die Dokumentation unzureichend ist, müssen Entwickler selbst herausfinden, wie sie eine Aufgabe ausführen sollen, machen Fehler, erledigen die Aufgabe erneut oder warten, bis ein anderes Team Fragen beantwortet — dadurch kann sich die Arbeit verlangsamen."

Es ist zwar keine Entwicklungsdokumentation, aber bei den Onboarding-Unterlagen unseres Unternehmens hat sich gezeigt, dass die Dokumente besser werden, wenn man die Eingearbeiteten bittet, sie nach einer Woche zu aktualisieren. Denn wenn man neu anfängt und keinerlei Informationen hat, wissen genau diese Personen in diesem Moment am besten, was man braucht.

Ich glaube auch, dass viele README.md-Dateien in Open-Source-Projekten auf GitHub vergleichsweise gut geschrieben sind, weil viele erste Nutzer vorbeikommen und Feedback geben.

2023-08-07

[Dieser Kommentar wurde ausgeblendet.]

devsepnine 2023-08-07

In letzter Zeit kommt einfach zu viel auf einmal rein, ich bin völlig durcheinander T_T

ahwjdekf 2023-08-07

Die Infrastruktur sollte kein Hindernis, sondern eine Hilfe sein --> aktuell trifft das bei Unternehmen in Korea unter dem Vorwand der Sicherheit leider überhaupt nicht zu.

hero512 2023-08-07

Ich verstehe das Gefühl, aber dieser Artikel wurde auf Englisch geschrieben. Auch bei Unternehmen im englischsprachigen Raum scheint die Situation ähnlich zu sein.

kuroneko 2023-08-07

Das wirkt eher wie eine Übersetzung als wie eine Zusammenfassung … Vielen Dank für die ausführliche Aufbereitung.