Ein guter Aufsatz von Jean Yang.
Was ich unter Entwicklererfahrung verstehe, ist die Gesamtheit dessen, wie Entwickler mit ihren Werkzeugen interagieren, End-to-End, Tag für Tag. Sicher, es wird mehr als je zuvor darauf geachtet, wie Entwickler Werkzeuge nutzen und annehmen, und es gibt ganze Vorträge und Podiumsdiskussionen, die dem Thema der sogenannten „DX“ gewidmet sind – doch große Teile der Entwicklererfahrung werden immer noch weitgehend ignoriert. Da Entwickler weniger als ein Drittel ihrer Zeit mit dem eigentlichen Schreiben von Code verbringen, umfasst die Entwicklererfahrung all die anderen Dinge: Codepflege, Tests, Sicherheitsprobleme, Behebung von Zwischenfällen und mehr. Und viele dieser Aspekte der Entwicklererfahrung werden weiterhin ignoriert, weil sie komplex, unübersichtlich sind und keine „Silberkugel“-Lösungen haben.
Sie argumentiert, dass DX möglicherweise generell vereinfacht wurde und dass es Werkzeugkategorien gibt, die sehr unterschiedliche DX haben.
Meine wichtigste Erkenntnis war, dass es tatsächlich zwei Werkzeugkategorien gibt – und damit zwei verschiedene Kategorien von Bedürfnissen in Bezug auf die Entwicklererfahrung:Abstraktionswerkzeuge (die davon ausgehen, dass wir im Vakuum coden) undkomplexitätserforschende Werkzeuge (die davon ausgehen, dass wir in komplexen Umgebungen arbeiten). Die meiste Entwicklererfahrung konzentrierte sich bisher ausschließlich auf die erstgenannte Kategorie der Abstraktion, bei der es einfachere Wege gibt, gute Entwicklererfahrung zu verstehen, als bei der letzteren.
Erinnert mich daran, wie Shawn denkt:
Es ist an der Zeit, über die einfachen Fragen in der Entwicklererfahrung hinauszublicken und uns den unbequemen zuzuwenden.