Dave verweist auf Sarahs Beitrag über Entwicklererlebnis (DX) bei Netlify. Ein Teil dessen, was Sarah dort getan hat, ist die Darlegung, was diese Rolle bedeutet. Es ist eine dreiteilige Sache:
- Integrations Engineering (z.B. Features)
- Developer Experience Engineering (z.B. Erstellung von Integrationen zur Sicherstellung von End-to-End-Qualität für Kunden)
- Dokumentation (z.B. … äh, Dokumentation)
Ich mag das. Man muss die Sache definieren, um die Sache zu tun. Dave schreibt jedoch eher über den Konsumenten von DX als über den Schöpfer von DX. Ein weiterer Dreiteiler
- Ist es einfach? Löst diese Technologie ein Problem, das ich habe, besser als ich es derzeit tue?
- Kann ich Hilfe bekommen? Wenn ich ein Problem habe, kann ich mit jemandem sprechen? Spreche ich mit jemandem, der hilfreich ist, oder mit jemandem, der scheiße ist?
- Ist die Community gesund? Wenn ich mich voll darauf einlasse, ist die Community dann toxisch oder nett? Gibt es, falls zutreffend, gute Community-Erweiterungen?
Ein weiterer Favorit von mir zu diesem Thema ist Shawn Wangs Developer Exception Engineering, das der Grundprämisse von DX zustimmt, aber dann etwas tiefer in die „unbequemen“ (aber ehrlichen und offenen) Aspekte eintaucht. Hier ist ein Beispiel
Sind Ihre Preise vorhersehbar oder benötigen Ihre Benutzer eine Tabelle, um herauszufinden, was Sie ihnen berechnen werden? Wenn die Gebühren unerwartet hoch sind, können Entwickler Ihre Software verwenden, um herauszufinden, warum, oder müssen sie um Hilfe betteln? Gibt es gute Standardeinstellungen, um frühzeitig gewarnt zu werden?
Ich mag es, dass gute DX aus Klarheit in den unbequemen Teilen entstehen kann. Wo sind die Kanten? Sagen Sie es mir, und Sie gewinnen mein Vertrauen. Verstecken Sie es, und Sie verlieren es.