Meine Kollegen hatten heute das Vorort-Treffen. Da ich remote arbeite, war ich nicht vor Ort. Sie haben scheinbar das Thema „Developer Joy“ in diesem Meeting besprochen. Ich hatte davon schon vorher gehört, aber ich wusste nicht, welche Themen angesprochen werden.
Developer Joy Folien
Heute hat mein Kollege, mit dem ich zusammen an einem Projekt arbeite, in unserem Firmen-IT-Chat ein Dokument zum „Developer Joy“ veröffentlicht. Ich war natürlich neugierig, was in diesem Dokument steht. Als ich dann die erste Folie gesehen hatte, musste ich fast heulen. „Fast feedback for pull request“. Ja, genau Kollege. Fast. Also möglichst schnell.
Nur leider ist bei mir ein Pull-Request seit sieben Monaten offen. Das nenne ich jetzt nicht wirklich schnell. Selbst „langsam“ ist noch ein zu schneller Begriff für den Umstand.
Wer ist dafür verantwortlich? Genau der Kollege, der den Stein ins Rollen gebracht hat und auch die Folien veröffentlicht hat. Was soll man dazu jetzt sagen?
Feedback zu „Fast feedback“-Folie
Ja, es ist korrekt. Wenn man ewig auf seinen Pull-Request dann mindert es die eigene Zufriedenheit mit den Kollegen und damit auch der Firma. Seine eigene Arbeit fühlt sich dann wertlos an.
Es ist zwar nur ein Pull-Request, aber die Zeit ist das Wichtige.
Persönliche Meinung zu „Developer Joy“-Folien
Fast feedback for pull requests
Das bezieht sich zwar eher Pull-Requests, ich bin aber der Meinung, dass schnelle(r|s) Reaktionen/Feedback in allen Lebenslagen wichtig sind.
Work autonomously – improve later
Sinnvoll, vor allem wenn es um Übersetzungen handelt, dann tun es auch erst einmal DeepL-Übersetzungen. Perfektionieren kann man später noch.
Fast shipment of product increments
Theoretisch sinnvoll. Leider sieht die Realität anders aus, sodass man dann doch waren darf. Steigert aber meiner Meinung nach, nicht den „Developer Joy“.
High code quality, low technical debts
Meiner Meinung nach sehr sinnvoll. Ob das jetzt aber den „Developer Joy“ steigert ist aber fraglich. Ich persönlich finde es gut, wenn die IDE nicht mehr herum zickt. Das hebt die Stimmung auf jeden Fall.
Ich habe mich mal bei einer Firma beworben, wo der Code so schrecklich war, dass die damalige IDE an ihre Kotzgrenze kam, also sie die ganzen Anmerkungen machten wollte. Fazit: Ich habe gleich nach dem Probetag eine Absage an die Firma gesendet.
High level of automation
Routine-Aufgaben sollte (halb-)automatisch ausgeführt werden. Dadurch arbeitet es sich eindeutig besser.
Reduce monkey tasks
Ja, definitiv. Muss man machen.
Keep meetings tight
Oh ja bitte. Es ist mehr als lästig in langen Meetings zu sitzen. Das habe ich leider schon zu oft gesehen. Man kann die Zeit auch sinnvoll nutzen.
Maintained product backlog
Das ist vor allem wichtig, wenn man mal zu wenig Aufgaben im Sprint sind oder diese schneller wie erwartet fertig waren. Dann kann man sich als Entwickler eigenständig eine neue Aufgabe suchen und muss nicht erst beim CTO oder PO nach fragen, was man als nächstes machen kann.
Definition of Done
Durchaus wichtig. Sonst hat jeder eine andere Vorstellung von FERTIG. Das könnte zu unnötig Frust führen.
Measure of outcome
Als Entwickler ist es schwierig seinen eigenen Wert zu kennen. Daher ist schon sinnvoll, wenn man den Impact festhält. Macht sich in Gehaltsverhandlungen auch besser.
Celebrate when stuff is done
Das kann durchaus helfen. Mache ich selber auch viel zu wenig.