Programmieren ist größtenteils Denken (2014)
(agileotter.blogspot.com)- Das sichtbare Ergebnis in Form von Code ist nicht die gesamte Tagesarbeit, sondern eher das reine Endergebnis, das nach Lesen, Recherche, Debugging, Verifikation und Entscheidungen übrig bleibt
- In einer über viele Jahre hinweg gestellten informellen Frage an Programmierer war die häufigste Antwort darauf, wie lange es dauert, eine 6-stündige Änderung allein anhand des Diff erneut einzugeben, etwa 30 Minuten
- Dieses Verhältnis stammt nicht aus einer wissenschaftlichen Studie, sondern aus Umfragen und der Beobachtung von Diffs, dient aber als praktischer Maßstab, Programmierung als 1/12 Handlung, 11/12 Denken zu betrachten
- Softwareentwicklung ähnelt eher Designarbeit als fabrikmäßiger Herstellung, und die Reproduktion nach dem ersten Entwurf wird von Maschinen zu nahezu null Grenzkosten ausgeführt
- Wenn Management und Prozesse darauf optimiert werden, die Tippzeit zu erhöhen, führt das zu Fehlanreizen; wichtiger sind Umgebung und Formen der Zusammenarbeit, die die Qualität des Denkens verbessern
Wie lange es dauert, 6 Stunden Arbeit erneut einzugeben
- Die Annahme ist ein guter Tag mit kaum Meetings oder Unterbrechungen, an dem ein Programmierer 6 Stunden ernsthaft programmiert hat
- Vor dem Feierabend wurde ein Diff ausgegeben, doch über Nacht ging das Versionsverwaltungssystem kaputt, wurde aus dem Backup des Vortags wiederhergestellt, und die Tagesarbeit war verschwunden
- Der Kern der Frage ist, wie lange der Programmierer braucht, wenn man ihm das Diff gibt, um diese 6 Stunden Arbeit erneut in die Codebasis einzugeben
- Über viele Jahre hinweg wurde diese Frage auf Konferenzen, bei Kunden, unter Kollegen und an Programmierer gestellt, die man gerade erst kennengelernt hatte, und die häufigste Antwort war etwa 30 Minuten
- In 6 Stunden passen 30 Minuten zwölfmal hinein, daher führte diese Beobachtung zu der Formulierung, dass Programmieren 1/12 Handlung und 11/12 Denken ist
Charakter und Grenzen dieses Verhältnisses
- Diese Zahl stammt nicht aus einer streng wissenschaftlichen Untersuchung und auch nicht aus einer formalen Erhebung mit guter Dokumentation
- Ziel war nicht, ein statistisches oder mathematisches Gesetz der Programmierarbeit zu finden, sondern eine vernünftige Antwort auf eine vernünftige Frage
- Da kein Unternehmen tatsächlich versucht hat, die gesamte Tagesarbeit zu löschen, um das Experiment zu bestätigen oder zu widerlegen, bleibt die Grundlage bei Schätzungen und der Beobachtung täglicher Diffs
- Beim Blick auf viele Changelogs und Diffs zeigte sich, dass die reine Änderungsmenge an einem guten Tag meist bei 30 Minuten ± 10 Minuten lag
Tippen ist nicht der Engpass
- Der Satz „Tippen ist nicht der Engpass“ wird seit langer Zeit auf Stickern und in sozialen Medien wiederholt
- Für manche Programmierer kann das Tippen selbst durchaus ein Engpass sein, aber der Schlüssel zu schneller Codeproduktion ist meist nicht nur Tippgeschwindigkeit oder Werkzeugbeherrschung
- In einem langen Quora-Beitrag mit dem Titel „How do programmers code so quickly?“ erwähnte ein Antwortender Muskelgedächtnis, Werkzeugbeherrschung, Debugging-Fähigkeiten, Tippfähigkeiten und die Fähigkeit zur Informationssuche
- Bei schneller Codeproduktion sind Tippen und Werkzeuge jedoch eher Hilfsmittel; deutlich mehr Zeit entfällt darauf, zu entscheiden, was überhaupt zu tun ist
Der Unterschied zwischen Softwarefabrik und Designarbeit
- Bei der Herstellung physischer Produkte besteht der meiste sichtbare Aufwand aus Bewegung; Stahl wird gerollt, gestanzt, gepresst, gefräst, platziert und montiert, und genau das wirkt wie Arbeit
- Moderne Fabriken führen wie CNC-Maschinen präzise Bewegungen auf Basis abstrakter Modelle, also Daten, aus, und Menschen steuern diese Maschinen, statt direkt alles von Hand zu erledigen
- Die Fabrik auf der Softwareseite ist bereits fertig; Nutzer drücken auf „copy“ oder „download“ und erhalten eine bit-perfect copy
- Sobald das erste Modell existiert, liegen die Grenzkosten weiterer Vervielfältigung praktisch bei null, und Software ist ein intellektuelles Gut
- Uncle Bob Martin sagt seit langem, dass Softwareentwicklung keine Fertigungsarbeit, sondern Designarbeit ist und dass die Reproduktion nach dem ersten Entwurf von Maschinen zu nahezu null Kosten erledigt wird
- Programmierer, Tester, PO, Scrum Master und Softwaremanager entwerfen das Datenmodell, das die Grundlage für Kopien bildet, die Kunden und Community nutzen werden
Intellektuelle Arbeit ist schwer zu beobachten
- Das Denken aus dem Industriezeitalter versucht, Softwareentwicklung wie eine Fabrik aussehen zu lassen, und Entwickler stehen unter Druck, wie körperliche Arbeit auszusehen, selbst wenn das dem tatsächlichen Prozess schadet
- Intellektuelle Tätigkeit ist schwer zu beobachten und zu messen, und eine zu 80 % fertige Idee hat keine physische Form
- Es kann Experimente, proof-of-concept-Code oder Notizen geben, aber sie zeigen keinen präzisen Fertigstellungsgrad wie physische Arbeit
- Ein Stuhl in der Fertigung sieht am 50-%-Punkt ungefähr zu 50 % fertig aus, und wenn er fertig ist, sieht er wie ein fertiges Produkt aus
- Das Design eines Stuhls existiert vielleicht nicht einmal auf Papier, bevor es zu mehr als 70 % fortgeschritten ist, und vor Abschluss des Entwurfs ist oft nicht einmal klar, ob er tatsächlich zu 70 % fertig ist
Warum eine 30-Minuten-Änderung 6 Stunden Arbeit bedeuten kann
- 30 Minuten sind die Zeit, um das reine Endergebnis von Code zu reproduzieren, den man den ganzen Tag geschrieben, gelöscht, bearbeitet und neu erstellt hat, nicht der gesamte investierte Aufwand
- Programmierer bewerten und formulieren ständig Hypothesen, während sie Code schreiben, um Fehler und Sicherheitslücken zu vermeiden
- Der Code-Text enthält zur Laufzeit nur, was das Programm tun soll, nicht aber warum dieser Weg gewählt wurde, welche Auswirkungen er auf andere Teile des Systems hat oder welche Fehler eingebaut und später wieder entfernt wurden
- Der Großteil der eigentlichen Arbeit liegt nicht in der Änderung selbst, sondern darin, zu entscheiden, wie die Änderung erfolgen soll; und weil dazu bestehender Code verstanden werden muss, kostet undurchsichtiger Code oder ein verborgen schlechtes Design mehr Zeit
- Das Ergebnis der Arbeit eines Programmierers wird in eine gemeinsame Codebasis integriert und hat damit einen sozialen Kontext; auch anderen Programmierern, Testern und Ops-Verantwortlichen zu helfen, die Arbeit zu verstehen, erzeugt Kosten und Nutzen, die im Code nicht sichtbar sind
Codezeilen sind kein Maß für Fortschritt
- 6 Stunden intellektueller Arbeit können durch Lesen, Recherche, Entscheidungen, Bestätigung, Verifikation und Review in eine reine Änderung von 30 Minuten in der Codebasis münden
- Das bedeutet nicht zusätzliche Codezeilen; es gibt Fälle, in denen nach Bugfixes und neuen Features am Wochenende weniger Code vorhanden war als zu Wochenbeginn
- Ohne zu wissen, dass das höhere Management des Teams SLOC als Fortschrittsmetrik berichtete, gab es über mehrere Wochen hinweg Probleme wegen negativer Codezeilen
- Was Programmierer tatsächlich tun, ähnelt eher Lesen, Lernen, Verstehen, Vermuten, Recherchieren, Debuggen, Testen, Kompilieren, Ausführen sowie dem Aufstellen und Widerlegen von Hypothesen
- Ein großer Teil der Arbeit bleibt am Ende Denken und Entscheiden
Weniger zu schreiben kann schnellere Entwicklung bedeuten
- Eine Quora-Antwort lautete, dass man die Finger sehen kann, wie sie sich über die Tastatur bewegen, aber nicht die Zeit, in der mit Nutzern gesprochen, mit Kollegen über Probleme diskutiert, recherchiert und nachgedacht wird
- Ein anderer Antwortender sagte, dass es die Bereitstellung von Lösungen am stärksten beschleunigt, wenn man Kunden hilft, unnötiges Denken zu entfernen, das sie „Requirements“ oder „must have“ nennen
- Wieder ein anderer sagte, dass hervorragende Entwickler mehr als 90 % ihrer Arbeit erledigen, bevor sie die Tastatur überhaupt berühren, indem sie die Anforderungen verstehen und einen geeigneten Lösungsweg entwerfen
- Antworten wie „wissen, was man nicht schreiben sollte“, „weniger tun“, „in kleineren Schritten arbeiten“ und „zuerst herausfinden, was zu tun ist“ kehren immer wieder zurück
- Wer mehr tippt oder mehr kopiert und einfügt, könnte weniger gedacht und verstanden haben, was wiederum Fehler sowie den Aufwand anderer Programmierer beim Verstehen und Ändern erhöhen kann
Prozesse sollten für das Denken entworfen werden
- Wenn Programmieren zu 1/12 aus Handlung und zu 11/12 aus Denken besteht, sollte man Menschen nicht dazu drängen, 11/12 ihrer Zeit zu tippen
- Was gebraucht wird, sind Materialien, Umgebung und Prozesse, die die Qualität des Denkens verbessern
- Andernfalls optimiert man das System auf die falschen Effekte hin
- Produktivität kann steigen, wenn Systeme bewusst so gestaltet werden, dass gemeinsames Nachdenken über Software und leichteres Treffen von Entscheidungen möglich wird
- Man sollte durch Experimente im Arbeitsalltag herausfinden, wie sich ein System schaffen lässt, in dem Denken optimal unterstützt wird
1 Kommentare
Hacker-News-Meinungen
Die Aussage im Artikel, dass „wirklich herausragende Entwickler mehr als 90 % der Arbeit erledigen, bevor sie die Tastatur berühren“, stimmt manchmal, übersieht aber meiner Ansicht nach, dass Menschen nicht sehr viele Einschränkungen und Konzepte gleichzeitig im Kopf behalten können.
Der Bereich, in dem man ganz ohne Schreiben rein nachdenken kann, ist sehr begrenzt. Sobald mir auch nur ein möglicher Ansatz einfällt, greife ich daher fast sofort zur Tastatur, noch bevor ich ihn zu einem vollständig spezifizierten Design ausarbeite.
Wenn man echten Code schreibt und verschiedene Ansätze ausprobiert, stellt sich oft heraus, dass die Lösung, die man anfangs für die beste hielt, deutlich schlechter ist als eine, die weniger vielversprechend wirkte; nichts legt ein Problem so gut offen wie konkreter, lauffähiger Code.
Letztlich ist Coding ein Prozess, bei dem Ideen in Code materialisiert und überprüft werden. Man sollte das Schreiben von Code als Teil des Denkprozesses sehen, ähnlich wie beim Prototyping-Gedanken, dass man die erste Iteration wegwirft.
Der Legende nach dachte er etwa einen Monat über Git nach, stellte es dann in sechs Tagen fertig und ruhte am siebten Tag. Bei normalen Leuten, insbesondere bei mir, ist es eher eine Interaktion: überlegen, was man schreiben will, schreiben, testen, wieder nachdenken und Teile korrigieren.
Der Weg zur endgültig funktionierenden Version ist am Ende in gewissem Maß Kunst.
Sobald ich eine grobe Idee habe, beginne ich mit dem Code an den „klebrigen“ Stellen, an denen Probleme am wahrscheinlichsten erscheinen.
Man kann nicht alle Probleme im Voraus absehen, also muss man in der Praxis dagegenlaufen; diese Vorgehensweise führt oft dazu, dass viel Arbeit verworfen wird.
Bevor ich nicht sicher bin, dass ich auf dem richtigen Weg bin, schreibe ich kaum Dokumentation[0], weil ich so den Zustand verringern kann, den ich Concrete Galoshes[1] nenne.
[0] https://littlegreenviper.com/miscellany/evolutionary-design-...
[1] https://littlegreenviper.com/miscellany/concrete-galoshes/
Der einzige Weg, das zu lernen, ist viel praktische Programmierung und aktives Lernen; das bedeutet auch, denselben Tech-Stack immer wieder zu verwenden.
Ich bevorzuge es, beim selben Stack zu bleiben und mich auf das eigentliche Problem zu konzentrieren, aber der hier gemeinte „großartige Entwickler“ ist bei der Werkzeugwahl vermutlich ziemlich eindimensional.
Je älter ich werde, desto offensichtlicher wird, dass Architektur wichtiger ist als Mikroentscheidungen.
Mikrodetails kann man optimieren, Makroentscheidungen sind meist dauerhaft.
Oft entwerfe ich den Code innerhalb der Tests und lasse die Implementierung bis zu einem gewissen Grad dadurch leiten.
Ich stelle mir das Endergebnis im Kopf vor, schreibe dann Tests in einer Form, die ich für eine gute API für das System halte, und starte von dort.
Dadurch wird der Code im Grunde testbar, und über mehrere Runden Red → Green → Refactor gelangt man zu einem zufriedenstellenden Zustand.
Ich frage mich, ob andere auch so arbeiten.
Die beste Erklärung fand ich in Jonathan E. Steinharts Buch „The Secret Life of Programs“.
Darin heißt es, Computerprogrammierung bestehe aus zwei Schritten: 1. das Universum verstehen 2. es einem dreijährigen Kind erklären.
Gemeint ist: Man kann kein Programm schreiben, das etwas tut, was man selbst nicht versteht; man kann keine Rechtschreibprüfung bauen, wenn man die Rechtschreibregeln nicht kennt; und ohne Physikverständnis ist es schwer, ein gutes Action-Videospiel zu machen.
Um ein guter Programmierer zu werden, sollte man über alles andere so viel wie möglich lernen. Lösungen für Probleme kommen oft aus unerwarteten Richtungen, also sollte man nichts ignorieren, nur weil es im Moment irrelevant wirkt.
Der zweite Schritt besteht darin, das eigene Wissen einer Maschine zu erklären, die die Welt so streng sieht wie ein dreijähriges Kind.
Wenn man ein Kind fragt: „Wo sind deine Schuhe?“, kann es mit „dort“ antworten. Es hat die Frage beantwortet, aber nicht die eigentliche Absicht erschlossen, nämlich die Schuhe anzuziehen und hinauszugehen.
Kinder lernen mit der Zeit Flexibilität und Schlussfolgern, aber Computer werden wie Peter Pan niemals erwachsen.
Je nach Person und Problem passt eine andere Denkweise; wenn man lernt, auf verschiedene Arten zu denken und zu programmieren, hat man mehr Werkzeuge zur Auswahl.
Deshalb mag ich Behauptungen nicht, nach denen Programmieren zwangsläufig auf genau eine richtige Weise ablaufen müsse.
Auch die Aussage „Man kann nichts programmieren, was man nicht versteht“ ist nicht wahr; häufig schreibt man Software, um zu verstehen, wie etwas tatsächlich funktioniert.
Auch physikalische Modellierung zielt oft nicht auf vollständige Realitätsnähe, sondern ist eine Suche nach dem Gleichgewicht zwischen User Experience und Schwierigkeitsgrad eines Spiels.
Programmieren kann ein exploratives kognitives Werkzeug sein; das heißt nicht, dass der größte Teil des Denkens immer zuerst kommen muss.
Ich mag Generalisten und Autodidakten, aber sie sind keine zwingende erste Voraussetzung, um ein guter Programmierer zu werden.
Kinder haben nicht so sehr eine „strenge Weltsicht“, sondern erschließen nur nicht immer soziale Implikationen; und auch Computer können so programmiert werden, dass sie aus bekannten Fakten logische Schlussfolgerungen ziehen.
Ich habe Kindern unterschiedlichen Alters, auch Dreijährigen, Dinge erklärt, aber diese Erfahrung hatte überhaupt keine Ähnlichkeit mit Computerprogrammierung.
Ich bin ziemlich sicher, dass diese Zahl im Grunde stimmt, aber bisher hat noch kein Unternehmen zugestimmt, zum Beweis oder zur Widerlegung dieses Experiments einfach einen ganzen Arbeitstag zu löschen.
Früher, als ich noch viel geduldiger war, hatte ich einen Chef, der jeden Abend alle Code-Änderungen durchging und löschte, was ihm nicht gefiel.
Dieser Chef war der Meinung, Versionsverwaltung sei übermäßig kompliziert, und wollte als Firmenstandard einführen, dass man per Remote-Zugriff auf ein Netzlaufwerk bei ihm zu Hause arbeitet.
Deshalb kam es manchmal vor, dass man am nächsten Tag zur Arbeit kam und die Arbeit vom Vortag gelöscht war; am Ende wurde ich sehr gut darin, die Arbeit des Vortags neu zu erstellen, bis ich heimlich SVN installierte.
Selbst mit Tests für Edge Cases dauerte das selten länger als eine Stunde.
Nachdem ich im ersten Job eine Art Trauma davongetragen hatte, fragte ich im zweiten Job sofort, ob es ein Git-Repository gebe; mein Chef hielt Git für dasselbe wie Github und sagte, er wolle den Code nicht öffentlich machen.
Später wurden wir von einer größeren Firma übernommen und bekamen Zugang zum Intranet; dort fand ich eine GitLab-Instanz, versionierte und dokumentierte meinen Code, an dem ich größtenteils allein arbeitete, und richtete sogar einen GitLab Runner ein.
Ich hatte auch Schritt für Schritt dokumentiert, wie man den Code ausführt; als ich entlassen wurde und man mich bat, den Code zu übergeben, zeigte ich alles und erklärte, wie man es reproduziert, woraufhin mein Chef ziemlich beeindruckt war und sich bedankte.
Vielleicht habe ich in einem miesen Job doch einen kleinen positiven Einfluss hinterlassen, weil ich die Arbeitsweise durchgezogen habe, die ich für richtig hielt.
Bevor ich dieses GitLab fand, hatte ich auf einer Netzwerkfreigabe ein bare Git-Repository angelegt und dorthin gepusht.
Selbst mit guten Absichten ist es für ein Team fast immer ein Nettoverlust, wenn Manager sich in Code oder Reviews einmischen.
Ein guter Text, den man Nicht-Programmierern schicken kann.
So wie Programmierer Domänenwissen brauchen, müssen auch Menschen, die von Programmierern etwas bekommen wollen, Programmierung zumindest ein wenig verstehen.
Selbst ein winziger Diff kann wegen Debugging, Design und Lernen mehrere Stunden dauern.
Es ist leicht, von der Menge des Outputs unbeeindruckt zu sein, aber es ist etwas völlig anderes, sich etwas von jemandem erklären zu lassen, als selbst stundenlang mit dem Kopf gegen die Wand zu rennen, bis man es herausfindet.
Etwa: Man braucht Tage, um einen Ein-Zeilen-Commit zu finden, der die Performance um den Faktor 100 verbessert, und muss gleichzeitig im Sync-Meeting erklären, warum sich das Ticket nicht bewegt.
Deshalb ist Domänenwissen der Kernpunkt.
Ich habe im Finanzbereich gearbeitet, saß am Trading Desk, beobachtete mehrere Börsen und schrieb Code, der verschiedene Strategien implementierte.
Wenn man nicht weiß, was das Business tun soll, kann man auch nicht überlegen, was der Computer tun soll.
Aus dieser Perspektive kann es sinnvoll sein, Coder wie Übersetzer auszubilden.
Ein befreundeter Übersetzer von mir kennt Grammatik und Redewendungen mehrerer Sprachen gut und lernt neue Sprachen so, wie wir neue Programmiersprachen lernen; er hat aber auch viel Zeit investiert, um die Pharmaindustrie zu verstehen, und übersetzt inzwischen medizinische Dokumente.
Auch Anwälte und Buchhalter üben Berufe mit einer Sprachbarriere aus.
Wenn man zum Experten wird, lernt man die Sprache des Rechts, der Buchhaltung oder der Software; gute Experten geben ihre Antworten aber nicht in der Fachsprache, sondern in der Sprache des Business.
Ein weniger guter Anwalt nennt einem in juristischen Begriffen alle möglichen Ergebnisse und überlässt die Entscheidung dem Mandanten; ein guter Anwalt sagt, dass es zwar viele nebensächliche Möglichkeiten gibt, Kunden in praktisch derselben Lage aber wegen dieses Geschäftsziels alle X tun.
In meinem ersten Trading-Job hatte ein Trader ein Excel-VBA-Modul gebaut, mit dem er Aktien durchsuchte und Abläufe zum Finden von Handelszielen ausführte.
Es gab keine Versionsverwaltung, nur eine auf der Festplatte gespeicherte Datei; wenige Wochen nach dem Einstieg speicherte ein neuer Mitarbeiter die Datei, nachdem er das gesamte VBA-Modul gelöscht hatte, und es gab weder Backups noch Hilfe von der IT.
Der Trader lief rot an, beruhigte sich dann, akzeptierte die Realität, dass er ohnehin ein Backup hätte haben müssen und was er da überhaupt mit VBA machte, setzte sich hin und tippte alles wieder ein, als würde auf einem Terminalbildschirm aus den 80ern Zeichen für Zeichen erscheinen.
Mein Grundsatz ist, dass man zuerst Erfahrung in dieser Domäne haben muss, um eine gute Lösung zu bauen.
Derzeit verbringe ich den Großteil meiner Zeit damit, Erfahrung in einer neuen Domäne zu sammeln, und sitze neben Domänenexperten, um das nötige Wissen schnell aufzubauen.
Sie bevorzugen eher einen Software Engineer, der 15 Jahre lang Buchhaltungssoftware gebaut hat, gegenüber jemandem mit meinem Hintergrund, und lassen diese Person dann 30 Minuten mit einem Buchhalter sprechen.
Man sieht immer wieder Vorschriften, wonach Programmierung unbedingt auf eine bestimmte Weise funktionieren müsse, aber die Arten der Arbeit unterscheiden sich je nach Teilgebiet stark.
Statt zu versuchen, eine perfekte einheitliche Methodik zu lernen oder zu lehren, die für alle Bereiche gilt, halte ich es für besser, einen Werkzeugkoffer mit verschiedenen Ansätzen und Methoden zu haben und zu verstehen, in welchen Situationen sie jeweils gut passen.
Deshalb konzentriert man sich auf allgemeine Programmierfähigkeiten, die sich branchenübergreifend übertragen lassen.
Ähnliches steht auch am Anfang von Bjarnes PPP-Buch[0]
Sinngemäß: „Selbst die besten Programmierer – gerade die besten Programmierer – verbringen den Großteil ihrer Zeit nicht damit, Code zu schreiben, sondern damit, das Problem zu verstehen. Ein Problem zu verstehen kostet oft ernsthaft Zeit und erfordert beträchtliche geistige Anstrengung. Genau das ist die intellektuelle Herausforderung, die viele Programmierer meinen, wenn sie sagen, Programmieren sei interessant.“
Die neue Ausgabe[1], die kürzlich auf der Frontpage war[2], habe ich ebenfalls gekauft
[0]: https://www.stroustrup.com/PPP2e_Ch01.pdf
[1]: https://www.stroustrup.com/programming.html
[2]: https://news.ycombinator.com/item?id=40086779
Welche Datenbank man verwenden soll, welche Sprache die beste ist, ob man in Code und Datenbank null zulässt, API-Formate, Log-Formate und dergleichen
Das ist nicht besonders interessant und muss gelegentlich neu bewertet werden, aber dieser Zeitaufwand in meinen letzten drei Firmen fühlte sich größtenteils nach Problemen an, die längst hätten gelöst sein sollen
Tatsächlich kann ein Unternehmen, das eine starke Denkweise hat, viel produktiver sein, selbst wenn sie fragwürdig ist
Wenn festgelegt gewesen wäre, dass wir Perl, MongoDB und CGI verwenden, wäre ich trotz dieses Stacks vermutlich produktiver gewesen als zuletzt
„Programmieren ist größtenteils Denken“ ist einer dieser Sätze, die man sich selbst wie eine tiefe Wahrheit sagt, aber als Beobachtung ist er nicht besonders produktiv
Programmieren ist in genau demselben Sinn Denken, in dem jede Wissensarbeit Denken ist
Design ist ebenfalls größtenteils Denken, Buchhaltung ist größtenteils Denken, und Management ist im Wesentlichen Denken
Der sinnvolle Unterschied liegt nicht im Denken selbst, sondern darin, worüber man nachdenkt
Manager müssen Probleme mit Menschen debuggen, also brauchen sie viel Zeit mit Menschen, sprich Meetings
Entwickler debuggen Probleme mit Computern, also brauchen sie viel Zeit mit Computern
Hier gibt es eine offensichtliche Spannung, und keines der Extreme funktioniert; man muss also ein Gleichgewicht finden, um die Arbeit der jeweils anderen weniger zu stören
Ich meine damit keinen obskuren Code-Golf-Code, sondern den Umstand, dass alles, was man produziert, gewartet werden muss
Das unterscheidet sich klar von einem Romanautor, der sich wenig für Wartung interessiert und sich eher um die Gefühle kümmert, die der Text hervorruft
Die beste Optimierung auf die Frage „Wie schafft man ein System, in dem Denken durch Experimente und Lernen on the job optimiert wird?“ ist: Unterbrechungen reduzieren
Studien zeigen, dass Unterbrechungen eine zerstörerische Wirkung auf das Programmieren haben
Nach einer Unterbrechung dauert es 10 bis 15 Minuten, bis man die Arbeit wieder aufnimmt; Programmierer bekommen pro Tag wahrscheinlich nur eine einzige ungestörte Zwei-Stunden-Session, und der schlechteste Zeitpunkt für eine Unterbrechung ist, wenn sie gerade editieren, suchen oder verstehen
Ich frage mich, ob es eine Möglichkeit gibt, solche Unterbrechungen zu erfassen und sichtbar zu machen
[0] http://blog.ninlabs.com/2013/01/programmer-interrupted/
Von Entwicklern wird aber erwartet, zwischen endlosen Meetings, kurzen Slack-/Zoom-Pings und Syncs mehrstündige Coding-Aufgaben zu erledigen
Als ich manchmal am Wochenende von zu Hause aus arbeiten musste, habe ich gesehen, dass die Qualität der Arbeit an einem ungestörten Wochenende viel höher war als an hektischen Wochentagen
Das passt nicht für alle und nicht in jeder Situation, und die restlichen 20 % sind Koordination mit Menschen, die tagsüber arbeiten, aber die Produktivität aus mehreren Stunden guter ungestörter Sessions ist unvergleichlich
Noch einmal: Das ist nicht für alle geeignet, wahrscheinlich nicht einmal für die meisten
Zu Hause unterbricht mich niemand, und wenn doch eine Unterbrechung kommt, kann ich selbst entscheiden, wann ich reagiere
Besonders wenn man an einem schwierigen Problem arbeitet und alle 10 bis 20 Minuten unterbrochen wird, ist es besser, einfach aufzuhören; andernfalls produziert man wahrscheinlich chaotischen Code, der einem später Kopfschmerzen bereitet
Es war so konzipiert, dass es die Privatsphäre respektierte: Es zeichnete auf, dass jemand einen Webbrowser benutzt hatte, aber nicht die konkrete URL, also nicht, ob es das interne Intranet oder fb.com war
Gelegentlich ließ ein Pop-up die Nutzer ihre eigene Produktivität bewerten und Freitext-Kommentare hinterlassen; es wurde nicht mit Nutzer-IDs verknüpft, damit die Leute nicht logen, um wie Übermenschen zu wirken
Wir bauten ein Windows-Frontend und ein Scala-Backend und verteilten es an eine Gruppe von Freiwilligen, darunter Entwickler, Anwälte und Finanzleute, aber gerade als es nach der ersten Datenanalyse interessant wurde, gingen uns Zeit und Budget aus, sodass wir daraus kein Paper machten
Wir sahen uns auch bestehende Tools wie Rescue Time ( https://www.rescuetime.com/
) an, kamen aber zu dem Schluss, dass es nicht akzeptabel wäre, interne Produktivitätsdaten in einer externen Cloud zu speichern
Gutes Programmieren ist manchmal größtenteils Denken, aber der Satz „Kein Plan überlebt den ersten Kontakt mit dem Feind“ trifft zu
Praktisches Programmieren ist eine sorgfältige Kombination aus Planung und dem Ausprobieren von Code in der IDE, und dieses Gleichgewicht muss je nach Use Case angepasst werden
Wenn du tagelang keinen Code schreibst, kennst du entweder die Problemoberfläche vollständig oder du rätst nur
Im letzteren Fall gibt es nicht allzu viel, worüber man nachdenken kann
Beim zweiten Mal geht es schneller
Ich stimme zu, dass man Denken zu „werkzeuggestütztem Denken“ erweitern kann
Das ist eine Wiederholung von Peter Naurs Programming as Theory Building und war für mich entscheidend, um das Wesen des Programmierens zu verstehen.
Beim Programmieren geht es nicht darum, das Programm selbst hervorzubringen, sondern darum, eine bestimmte Einsicht in Vorgänge der Welt zu formen; der am Ende ausgegebene Code ist lediglich ein einfacher Ausdruck der Theorie, die man aufgebaut hat.