Developer Productivity es gibt zig Methoden, das zu messen.
Von Dora von Google, Space Framework, was irgendwie
Microsoft und github da oben drauf gesetzt haben.
Mc Kinsey hat letztes Jahr nen riesen Artikel geschrieben wo
sie da drauf noch mal Metriken gesetzt haben, was auch relativ
viel gemischte Kritik in der Development Community
hervorgerufen hat. Malte und ich sprechen heute
darüber, wie wir als Entwickler uns eigentlich produktiv fühlen
und was dafür gegeben sein muss. Und damit herzlich willkommen
zum To do Developer Podcast mit Robin Manuel Thiel, dem
berühmtesten Langenfelder auf dieser Welt, und Malte Dantin.
Ich glaube, das musst. Du aber letzten Endes ist es so.
Alle, die die Rheinische Post in Langenfeld lesen, kennen jetzt
Robin Manuel, da wir dankenswerterweise einen
spannenden Artikel zu unserem Podcast in der lokalen
Zeitschrift Langenfeld Langenfeld hatten.
Wer Langenfeld noch nie gehört hat, das ist meine Heimatstadt,
das liegt zwischen Köln und Düsseldorf, und da wird
scheinbar eine Reihe über podcaster Podcasterinnen aus der
Region gemacht, und da gab es einen Artikel, die whatsapp
Gruppe von meiner Mutter rotiert.
Bin mal gespannt, wie viele neue Hörerinnen und Hörer wir dadurch
gewinnen und ob es noch, ob es Auswirkungen hat.
Aber lustig war, es hat Spaß gemacht auf jeden.
Fall sehr. Ich bin sehr neidisch, bevor wir
ins Thema einsteigen, erstmal noch vielen Dank an diejenigen
von euch, die uns n Kaffee ausgegeben haben in den letzten
2 Wochen zum einen einmal 5 Kaffee von Frenko und 2 Kaffee
von Uwe Uwe fragt übrigens und da ist eine ganz gute
Überleitung zur letzten Folge um noch mal einen kleinen Rückblick
zu machen. Uwe fragt übrigens, wie ihr
jetzt an dein Kalender Tool kommt, ich glaube das hatte eine
gewisse Resonanz auch in unserer Community, dass du an dem Thema
jetzt arbeitest und alle warten sehnsüchtig darauf wann das tut
endlich rauskommt, aber lasst uns mal kurz ein bisschen auf
die letzte Folge zurückschauen, da gibt es ein paar Dinge die
wir noch besprechen wollten. Ja, zum einen erstmal, bevor ich
auf das Tool eingehe entfernt es, sorry, die letzte Folge hieß
fiverr Fail, aber die war auf jeden Fall auch Audio Fail,
zumindest so am ersten Tag. Also wer sich glaube ich nach 23
Tagen gehört hat, der hat vielleicht schon die bessere
Version ausgespielt bekommen, aber irgendwie ist uns dabei
beim Audio ein bisschen was durchgerutscht, sodass.
Wir, glaube ich zumindest. Wenn der eine gesprochen hat,
man bei dem anderen die Hintergrundgeräusche sehr laut
gehört hat und irgendwie wollt ihr gar keinen Spatzen von uns
bei dem Podcast haben. Deswegen ideale Ehrenwort, dass
wir. Sowohl diese diese Folge mit
leerem Mund aufnehmen, b vielleicht noch mal reinhören,
bevor wir die veröffentlichen und das Audio auf jeden Fall
dieses Mal besser wird. Wir achten jetzt auf jeden Fall
mal drauf. Schwatzen.
Malte. Ganz oben auf unserer to do
Liste. Ansonsten kam die Frage, Warum
haben wir eigentlich in der letzten Folge 2 mal was
ausgepiept als du darüber geredet hast, dass du das
Problem vorhast mit Geld zu erschlagen, wurden die Beträge
ausgepiept und da sind natürlich jetzt viel Neugier da.
Was waren denn eigentlich die Unsummen, die du da investieren
wolltest? Dass es dir letzten Endes
peinlich war? Ja, es war mir.
Es war nicht peinlich, es war mir eher zu undifferenziert.
Also ich habe dann nachher im Schnitt gedacht, also ich kann
die, die die Summe ja sagen, was ich ausgepiept habe, ist
1000,00€ ich habe damals gesagt, Ich bin bereit, da 1000,00€
dafür zu investieren, ich habe aber dann nicht erklärt.
Also es war mir zu undifferenziert.
Ich habe mir nicht erklärt, dass ich bereit war, das zu
investieren. Weil ich natürlich vorhabe, da
ein Projekt draus zu machen, was man vielleicht auch über den
Appstore vertreibt. Es scheint viele vor allem so
Business. Anwendungsfälle Fälle dafür zu
geben und. Ich wollte nicht, dass es so
klingt, als würden jetzt würde ich sagen, ich könnte bis zu
1000€ für so n Tool ausgeben und da wie mein so so n kleines Ding
was irgendwie im Hintergrund läuft, sondern sich eher bereit
gewesen wär da so n Mini Business draus zu machen, dass
das mein Invest gewesen wäre, was ich bei fiverr.
Bereit gewesen wäre zu bezahlen, damit mir das jemand baut,
sodass ich dann den Vertrieb machen kann.
Und vielleicht kann man das irgendwie in den App Store
stellen, ob man da in Subscription Model oder ne
lifetime Lizenz macht weiß ich nicht, das hab ich aber alles
nicht gesagt in der letzten Folge und deswegen wollt ich das
irgendwie nicht so stehen lassen, dass es einfach steht,
aber Manuel kann doch 1000€ für so n Tool ausgeben und deswegen
habe ich das Gepiept um das jetzt hier klarstellen zu
können. Wunderbar, dann wissen wir da
jetzt auch Bescheid und freuen uns darauf, dass das Tool bald
zur Verfügung steht, während ich für einen Preis, den wir uns
alle leisten können, dann ist es soweit.
Das wird auf jeden Fall nicht vierstellig werden.
Ja, da ist also ein bisschen das Thema Developer productity.
Also das Tool ist fertig. Ich hab wer das verfolgt hat
oder wer das noch verfolgen möchte.
Ich hab jeden Tag und jeden Abend wo ich dran war einen
blogspot darüber geschrieben, wie ich vorangekommen bin, wer
mir auf linkedin oder Twitter oder sowas folgt, hat das
vielleicht mitbekommen. 6 Abende habe ich dran gesessen.
Ich hab ja gesagt, ich wollte schauen, ob es in einer Woche
fertig ist. Das heißt, einen habe ich
theoretisch noch. Weil das natürlich auch nicht 6
Tage oder 6 Tage in Folge waren. Ich bin fertig.
Technisch funktioniert das und ich würde in den letzten Tagen
jetzt noch investieren, das irgendwie in den App Store zu
stellen. Bei Apple muss man das ja noch
irgendwie mit einem developer Account signieren, dass man das
irgendwo, also irgendwie irgendwas dazu machen, dass man
das irgendwo downloaden kann, das ist der letzte Tag, das ist
noch nicht fertig. Ich gehe davon aus, dass ich das
nächste Folge bis nächste Folge fertig habe und dann wieder
irgendwie einen Download Link auch in die Shownotes packen
können, bis dahin gesagt, wenn jemand von euch aber sagt Ey ich
würde das aber gerne schon mal testen oder ich habe da ein
riesen Interesse dran oder ich habe dasselbe Problem.
Dann meldet euch gerne bei mir. Das könnt ihr einfach unter die
E-Mail unter der E-Mail Adresse machen, die unten in den Show
Notes steht für den Podcast und wenn ihr Lust habt irgendwie
eine Preview Version schon mal zu testen, dann würde ich euch
die gerne zuschicken und ein bisschen Feedback abholen, sagt
also gern Bescheid. Wunderbar.
Ich freu mich auf jeden Fall drauf und werd das auch in den
nächsten Tagen mal ausprobieren. Jetzt glaube ich, kommen wir
endlich zu unserem Thema Produktivität Developer
Productivity. Häufig ist das ein Thema, was
zumindest in unserem beruflichen Alltag, wo wir viel mit großen
Unternehmen zu tun haben, eine. Zahlenorientierte Diskussion
ist, was ich persönlich alleine schwierig finde.
Das heißt, man redet mit. Unternehmen, die oder den
Leitenden von Entwicklungsabteilungen über das
Thema Developer Productivity und die erste Frage ist, wie kann
ich das denn messen, welche Metriken und zahlen kann ich
verwenden und könnt ihr uns nicht beibringen, wie diese Dora
Framework funktioniert, haben wir so viel von gelesen.
Erklärt uns doch mal, wie wir das mit unserer Dev Ops
Plattform, egal welche wie wir das da auswerten können und wie
kommen wir wirklich an diese Zahlen, wie produktiv unsere
Developer sind und das ist natürlich gerade jetzt ein ganz
heißes Thema. Allen Seiten irgendwie neue
Tools gerade so AI basierte Tools in den Developer Alltag
reinkommen und sich viele Unternehmen dann die Frage
stellen, mach das unsere Developer produktiver und lohnt
sich der zusätzliche finanzielle Invest und.
Wie Unternehmen sind, wollen Sie das letzten Endes irgendwie
quantifizieren und wollen wissen, OK, um wieviel Prozent
wird unsere Produktivität höher und wieviel Geld sparen wir denn
letzten Endes dadurch, dass wir neue Tools einführen und das
finde ich eigentlich immer so eine ganz unangenehme
Diskussion, weil das so ein bisschen den.
Alltag der Developer so n bisschen auf.
Output und Zahlen reduziert und die Zahlen, die häufig dann da
zugrunde liegen. Früher waren es irgendwie Lines
of Code, da haben alle verstanden, dass das kein
Produktivitätsmaß ist. Aber dann wird dann das ganze
Runtergebrochen auf irgendwie Anzahl der pro Requests, die
Gemerged werden oder Anzahl der Deployments die durchgeführt
werden und das ist natürlich relativ schwierig das so ganz
neutral zu beurteilen, weil das natürlich absolut vom Projekt
auch abhängt, was dann normal ist und häufig.
Müssen solche Messungen natürlich auch über einen sehr
langen Zeitraum überhaupt durchgeführt werden, damit man
auch Vergleichsmöglichkeiten hat?
Und komischerweise haben viele Unternehmen das bisher nicht
gemacht und plötzlich wollen sie irgendwie Produktivität messen.
Also ich persönlich finde es immer relativ schwierig das auf
Zahlen runterzubrechen. Du sagtest mir aber, dass du
gerade auch so eine Rolle bei github, viele auch mit großen
mit Enterprise Firmen sprichst und dass es da schon ein Thema
ist. Also das ist gerade also
meistens ja wahrscheinlich top Down aus einem Management.
Die gewohnt sind, dass sie sowas wie wie Sales oder Marketing,
Impact und und und, vielleicht auch klassische Produktion, also
klassisches produzierendes Gewerbe.
Dass die eigentlich sowohl gewohnte Dinge zu messen als
auch ganz, also einfach diese Metriken brauchen, weil das
einfach sonst sehr undurchsichtig für sie ist.
Was in dieser Softwareentwicklung Abteilung da
eigentlich von sich sind sind, sind wir denn gut?
In der der, der der Benchmark also sagt Es ist schon n Thema.
Also das Interesse ist ja schon da das irgendwie mit Zahlen und
Frameworks zu versehen, oder? Ja, absolut.
Aber man klammert dann häufig wirklich den developer Alltag so
in dem, wie die Leute wirklich arbeiten, so ein bisschen aus
und geht dann einfach nur auf den Output.
Ist so ein bisschen glaube ich diese denke wie du das sagst aus
diesem produzierenden Gewerbe, wenn ich irgendwie etwas
herstelle, egal was gucke ich, wieviel läuft am Ende des Tages
von Band und das ist meine Produktivität, also wie viele.
Stück von irgendwas habe ich ausgeliefert und dann wird
häufig versucht das auf Software zu übertragen, indem man halt
sagt Okay wie viele Deployments habe ich gemacht in Produktion
oder andere Themen, wie oft habe ich ein Release und habe das an
meine Kunden geschickt und das ist natürlich nur eine sehr
verengte Wahrnehmung der Realität und natürlich gibt es
dann modernere Ansätze. Du hast vorhin das Space
Framework erwähnt, wo man das so ein bisschen auch stärker
customers kann auf das eigene Unternehmen.
Heißt, ich greife mir da aus ganz vielen Dimensionen die
Dinge raus, die für mein Unternehmen relevant sind.
Und dann kommen dann natürlich noch weitere Faktoren mit rein,
die ich auch messen kann, wie zum Beispiel?
Wie viele Bugs werden in Produktion gefunden?
Hängt natürlich auch von ganz vielen Faktoren ab, oder?
Wie viele Produktionsausfälle habe ich, weil Software läuft,
irgendwo in Produktion? Und wie oft habe ich quasi
downtimes in einem Webservice zum Beispiel.
Das heißt, man kann dann natürlich ganz viele Dinge mit
reinnehmen und was ich so ein bisschen schade finde, ist, dass
die Leute das versuchen, so mit einer Zahl totzuschlagen, okay
was ist diese eine Produktivitätsmetrik und da
kommen natürlich solche Frameworks, die dann vielleicht
auch von irgendwelchen Beratungsunternehmen
vorangetrieben werden, einem irgendwie ganz recht.
Weil dann hole ich mir irgendwie Berater rein.
Die gehen dann rein, bringen irgendwelche Tools mit, schauen
dann, OK, was hab ich dort in meinen.
Source Control System drin ne und wieviel commits habe ich?
Wieviel Fifty pour request? Wie viele Deployments habe ich
und brechen das dann auf irgendwie ein 2 Metriken runter
und dann vergleiche ich die irgendwie vorher nachher was
hatte ich von 3 Monaten, was habe ich heute und was habe ich
in 3 Monaten und dann bilde ich mir ein, dass ich vielleicht
produktiver bin, aber ganz viele andere Faktoren fließen da nicht
ein und ich glaube da machen es sich viele Leute ein bisschen zu
leicht. Ich kann aber auch verstehen
warum, weil am Ende sind das häufig auch Menschen die sagen
okay ich will irgendwelche neuen Tools einführen und jetzt muss
ich irgendwie meinem Management beweisen, dass es sich lohnt.
Und das ist natürlich relativ schwierig, wenn du versuchst,
wirklich den Alltag mit einzubeziehen, der halt diese
Dinge beeinflusst und worüber ich mich eigentlich gerne mit
dir heute so ein bisschen mehr unterhalten würde, ist, wie
sieht wirklich dieser Alltag aus, also was beeinflusst unsere
Produktivität als Developer, also was können wir?
Auch tun selber oder was können auch unsere Arbeitgeber tun,
damit wir uns produktiv fühlen, weil ich glaub das ist n ganz
wichtiger Faktor. Man kann halt irgendwie alles
messen, aber man kann auch alle Metriken irgendwie.
Cheaten beeinflussen meiner Erfahrung nach, sondern was
können wir tun, dass du und ich uns wirklich produktiv fühlen
und dass wir wirklich das Gefühl haben, wir können.
Für uns oder für unser Team das Bestmögliche erreichen und da
gehören natürlich viele verschiedene Faktoren zu, die
eigentlich mehr wirklich auf unserer Weiß nicht lokalen
Entwicklungsumgebung basieren. Auf unserem Alltag, auf unserem
Terminkalender. Und da würde ich gerne ein
bisschen mit dir durchgehen. Ja, ich sehe da 2 Kräfte wirken
zum einen natürlich irgendwie, dass man so diese Zahl braucht,
um zu vergleichen, gar nicht unbedingt mit anderen
Unternehmen. Ich glaube, dass das in der
Branche gar nicht so wirklich möglich ist, dass man sich, also
ich glaube, dass dafür Software in die Entwicklung zu
individuell ist, dass man sich wirklich mit anderen Unternehmen
vergleichen kann, weil sowas die Anzahl der der Deployments ja
nicht aussagekräftig ist, weil ich ja gar nicht weiß, wie groß
ist denn das Deployment, wieviel Features schippen die denn, die
1000 mal am Tag jede Zeile Code oder die Pleulen, die einmal in
der Woche ein Riesending. Ist glaube ich schwer zu
vergleichen. Auch Zeilen von Code ist nicht
wirklich zu vergleichen, weil ich ja gar nicht weiß, wie ist
denn die Qualität. Manche sind 2 Stunden an einer
perfekten Zeile Code und manche hauen 50 Zeilen Code raus, die 2
Comics später wieder komplett ersetzt wurden.
Also ich glaube das ist gar nicht möglich.
Es sich da mit anderen Unternehmen zu vergleichen, mit
irgendwelchen Metriken, aber mit sich selber über Zeit, das finde
ich schon spannend. Um zu schauen, geht unsere
eigene Produktivität nach oben oder nach unten und warum gibt
es vielleicht managemententscheidungen, die
das Team betreffen, die jetzt unproduktiver machen, oder gibt
es vielleicht irgendwie cozemail oder ist die Codebase so
schwierig geworden, dass wir immer weniger geschafft kriegen
oder immer mehr Bugs in Produktion finden und dauert es
immer länger diese Bugs zu fixen?
Ich glaube das sind Dinge, wenn man sie nur mit sich selber
vergleicht. Sinnvoll sind und auf der
anderen Seite sehe ich aber auch einen riesen Pushback aus der
Developer Community. Fast jeder Developer, jede
Entwicklerin, mit denen ich über dieses Thema spreche.
Haben da sehr negative Gefühle, weil natürlich a keiner Lust hat
irgendwie individuell gemessen und getrackt zu werden.
Aber ich glaube das liegt vor allem daran, dass alle wissen,
wie schwierig das ist. Es kann sein, dass ich mir 3
Stunden lang n youtube Video angeguckt habe oder n geilen
Artikel durchgelesen. Habe der mich jetzt perfekt auf
die Lösung eines bestimmten Problems vorbereitet oder oder
irgendwie besser macht und das dann aber auch das aber nicht in
dieser Metrik dann abgespielt wird und dann auf einmal das
Team unproduktiv aussieht, wenn es irgendwie ne Woche lang auf
einer Fortbildung war. Das finde ich dann irgendwie
immer schwierig und deswegen erfahre ich da viel Pushback von
diesen offiziellen Metriken, kann aber verstehen, warum man,
warum man sie zumindest für sich selber messen möchte.
Ich denke, ein großer Teil des Widerstands kommt auch daher,
dass viele Dinge ja außerhalb der wirklich der Software
Entwicklung stattfinden. Es geht halt nicht nur um Code,
den ich produziere, sondern mein developer Alltag besteht halt
irgendwie zu 5060 70% aus anderen Tätigkeiten, wo ich mit
anderen zusammenarbeite, wo ich mir Dinge überlege.
Du hast gerade gesagt, Weiterbildung spielt eine
wichtige Rolle und wenn dann irgendwie nur 3040% meines Tages
aus Coding besteht, dann alle Messungen nur auf diesem Code
aufzusetzen, dann natürlich das ganze enorm verzerren kann.
Der vielleicht auch ein großer Teil des Widerstandes kommt.
Und ich persönlich find eine Metrik ganz gut, die sich aber
natürlich nicht bei allen ermitteln lässt.
Das wäre die Anzahl der. Geschafften Story Points pro
Sprint, das heißt, wenn ich ein sehr eingespieltes Team habe,
welches Scrum einsetzt und dann über einen längeren Zeitraum
nachverfolgen kann, OK wie viele Storypoints haben wir erledigt,
dann kann man da durchaus schon Veränderungen sehen.
Und sehen, OK, wir werden im Laufe der Zeit produktiver, das
ist ganz normal bei jedem Development Team, was sich
irgendwie im Laufe der Zeit immer mehr einspielt, sieht man,
dass der Trend nach oben geht, aber wenn man dann irgend auch
irgendetwas am Setup ändert, neue Tools einführt oder
grundsätzlich vielleicht den Leuten die Möglichkeit gibt,
sich mehr auf die Arbeit zu konzentrieren, weil man weniger
Meetings hat, gehen plötzlich die Anzahl der Story Points nach
oben und ich finde, das ist eigentlich ein sehr schönes
Messkriterium, das ist aber nicht für alle so einfach
ermittelbar, weil ich tatsächlich dann diese
Entwicklungsmethodik verwenden muss.
Ich brauche wirklich ein gutes Team, was eingespielt ist.
Ich brauche auch gute Product owner, die das entsprechend mit
dem Team. Planen, erfassen und messen.
Aber ich glaube, das ist eine der wenigen Dinge, die letzten
Endes auch wirklich funktionieren kann.
Ja, mag ich, finde ich. Okay setzt natürlich voraus,
dass man Story Points benutzt und das kann man glaube ich auch
erst nach einer gewissen Zeit messen, weil so ein Team auch
erstmal braucht, sich einzuspielen.
Dieses Scrum Poker und sowas dann überhaupt zu setzen.
Ich glaube da wenn man da ein Gefühl für hat nach einem halben
Jahr oder so, dass man dann. Anfängt das zu tracken und
natürlich auch, dass es normal ist, dass wenn man neue Sachen
einführt, das vielleicht auch erstmal so n Tipp gibt und es
runtergeht und dann sich. Wieder normalisiert oder im
besten Fall sogar dann besser wird.
Aber abseits von diesen Metriken, weil da können wir
jetzt 13 folgen drüber machen, da gibt es Tausende, da gibt es
wie wir haben es eben schon gesagt, so die 3 populärsten
Frameworks sind Dora Space und was mckinsey noch irgendwie da
draufgesetzt hat mit dieser Mischung aus den beiden plus
eigene Sachen. Aber jetzt mal von Developer zu
developer, wann fühlst du dich produktiv, also was ist, was ist
das, was man vielleicht nicht in der Metrik messen kann, sondern
was wurde das EY ich hatte heute einen produktiven Tag, woran hat
das gelegen, also was gibt es da bei dir jetzt einfach als
Developer, nicht als Project Manager oder Product Owner oder
Scrum Master. Ja, ich glaube, da gibt es
diverse Dinge, die sich auf den Alltag auswirken und viele ist
zumindest die Rückmeldung, die ich bekomme und kann ich auch
aus dem eigenen Alltag nachvollziehen.
Man fühlt sich produktiv, wenn man konzentriert an einem Thema
arbeiten kann und dieses Thema dann abschließen kann und da
kommen natürlich viele. Dinge zum Tragen zum einen.
Wie ist mein technisches Setup, wie funktioniert meine
Entwicklungsumgebung, wie viele Meetings habe ich vielleicht
noch neben dem Arbeiten an diesem Thema und wenn ich jetzt
überarbeiten an diesem Thema Rede?
Dann gehört dann natürlich auch Recherche dazu.
Es gehört dazu, dass ich mich irgendwie schlau mache, mich in
Dinge einlese, mir vielleicht auch irgendwelche Videos
anschaue, wie bestimmte Dinge erledigt werden können und dann
wirklich konzentriert an diesem Thema arbeiten kann, ohne dass
ich andauernd unterbrochen werde.
Und die Unterbrechungen sind, glaube ich, das, was einen so
das Gefühl von Unproduktivität gibt, und diese Unterbrechungen
können technischer Natur sein, ein ganz typisches Beispiel ist,
du hast halt irgendwas in deinem Setup, was nicht funktioniert
und dann. Musst du dich ewig damit
beschäftigen, irgendwelche Depensies zu installieren oder
ein Kollege hat mal irgendein Package aktualisiert und dann
funktioniert bei dir plötzlich der Build nicht mehr und dann
sitzt da wieder irgendwie mal 5 Minuten mal 20 Minuten, mal
länger und muss das Ganze wieder zum Laufen bringen und das ist
ja alles andere als produktiv, weil du dich dann aus deinem
Gedanken völlig entfernen musst und deinem Thema, an dem du
eigentlich arbeitest und dann solche Komischen, keine Ahnung
technischen Voraussetzungen wieder zurechtbiegen musst.
Und ich glaube, das ist ein Thema das ganze technische
Setup, wie oft man daraus gerissen wird und der zweite
große Block ist dieses. Organisatorische das Arbeiten im
Team oder das Arbeiten im Unternehmen?
Wie oft werde ich einfach aus meinem.
Auf aus meiner Aufgabe rausgerissen, weil ich halt
irgendwelche anderen Dinge habe und dazu gehören so positive
Dinge wie irgendwie Mittagspause, aber.
Auch Dinge dazu. Dass.
Da. Dass irgendwie wieder das
nächste Meeting irgendwie ansteht.
Und dann will wieder jemand irgendwie n
strategieplanungsmeeting machen, oder dann gibt es irgendwie
unseren. Weiß ich nicht.
Dann kommt kommt wieder ein Kollege auf mich zu wegen wegen
irgendwelchen Fragen, die er mit mir klären will.
Im schlimmsten Fall kriege ich dann noch irgendwie ein Meeting
von einer halben Stunde in meinen Kalender reingedrückt,
was ich dann wahrnehmen muss und da fällt es einem natürlich auch
schwer sich komplett da rauszuhalten, weil.
Dann natürlich auch andere drauf angewiesen sind, meinen Input zu
bekommen. Und manche Dinge sind halt auch
einfach vom Unternehmen her vorgegeben, dass man bestimmte
Austauschformate hat, aber alle diese Dinge, die mich wirklich
aus diesem Gedankenfluss rausreißen, sind eigentlich
negative Aspekte und Dinge, die mir helfen, in diesem
Standardbegriff, den man, den man immer verwendet, in diesem
Flow zu bleiben. Alles was mir hilft, im Flow zu
bleiben, ist positiv und führt dazu, dass ich mich am Ende
produktiver fühle, und ich glaube, eine Gute.
Uns einfach auch mit den Menschen zu reden.
Das heißt man, wenn man sagt, ich muss.
Developer Productivity messen sollte auf jeden Fall einer der
Aspekte sein, dass ich regelmäßig mit den Leuten
spreche und sage, OK. Hast du das Gefühl, dass du
produktiv bist? Und was sind Dinge, die dir das
Gefühl geben, dass dir deine Produktivität runterziehen und
dann konkret an diesen Dingen zu arbeiten?
Ich hab da, ich hab da ne Meinung zu ich ich mag das
nämlich eigentlich nicht so, also hast du es noch gar nicht
gemacht, aber ich mag das eigentlich nicht so, dass du oft
irgendwie verteufelt wird, das so das das entwicklerinnen
Entwickler sind so Meeting scheu und die haben irgendwie keinen
Bock irgendwie auf auf auf Abstimmungen und sowas.
Und ich glaube das das stimmt nicht, weil jeder, der irgendwie
schon n bisschen länger in der Branche ist, weiß es natürlich
wichtig ist, sich im Team abzustimmen, was man gerade
macht und es kann auch Spaß machen, Zischenergebnisse zu
präsentieren. Aber wie du gerade gesagt hast,
was was uns developern wahnsinnig wichtig ist, ist Flow
ist Fokus. Ich bin zum Beispiel selber n
richtig n riesen Verfechter vom Pomodoro Framework, wo man
einfach 25 Minuten an einem Task Mega fokussiert arbeitet und in
der Zeit auch bitte nicht geschört und nicht unterbrochen
wird und dann auch manchmal ganz überrascht ist, wieviel man in
25 Minuten schaffen kann, wenn man sich nicht ablenken lässt.
Und es ist völlig OK und es ist auch jedem klar, dass dass es
Meetings und Abstimmungen braucht.
Aber um diesen Flow gleichzeitig zu gewährleisten, halte ich es
für wichtig, dass diese Dinge planbar sind.
Ich kann gerne in Abstimmungsmeeting mit dir
gehen, aber nicht heute in einer Dreiviertelstunde, weil ich bin
ja gerade vielleicht im Kopf an irgendwas dran, sondern wenn du
mir, wenn es ein Regelmeeting gibt oder wenn man sagt, Hey,
halt dir bitte, also am Freitagnachmittag haben wir alle
unsere Abstimmungsmeetings oder sowas oder es gibt eine Stunde
am Tag oder irgendwas, weil dann plane ich da gar nicht Arbeit
ein, da kann ich meinen Flow darauf vorbereiten, dass ich da
vielleicht nicht in diese deep Zone bin, wo ich dann
rausgerissen werde und mich dann halt schlecht fühle.
Ja, jetzt gerade. Ist aber irgendwie doof, weil
ich sehe ein, dass du nicht weiterkommst.
Aber ich bin ja auch gerade voll in diesem Konzentrationsflow
drin und ich glaube, gibt den Leuten, und das ist mit
Sicherheit nicht nur was für Developer, sondern für jeden,
der irgendwie produktiv sein möchte, gib den planbare
Meetings so, dass sie ihren Workflow von vorne rein planen
können und ich halt dann auch diese knackigen Dinge nicht
angehen, wenn sie wissen, dass in einer halben Stunde
irgendwie. N Stand up ansteht.
Ja, bin ich absolut bei dir und ich glaub was man vermeiden muss
ist diese Fragmentierung der Tage, die man heute bei vielen
ja sieht. Ne, dass man irgendwie.
Alle anderthalb Stunden gibt es irgendwie das nächste Meeting,
weil das reißt einem aus dem Gedanken raus.
Und selbst wenn du jetzt sagst, OK, vielleicht verwendet man so
n Framework wo ich mich 30 Minuten voll konzentriert in ein
Thema reinstürze ich muss mir ja vorher mal Gedanken dazu gemacht
haben und wenn ich dann wieder irgendwie kontexwitches habe,
das reißt mich natürlich raus und ich glaube, wir müssen
versuchen diese Fragmentierung zu vermeiden.
Wir müssen versuchen Kontextwitches zu vermeiden und
kontexwitches, die können halt einfach ich persönlich bin
jemand der leicht abzulenken ist.
Das heißt für mich ist schon so ein Kontext Switch der mich
ablenkt. Ich muss online was nachschauen
und dann, ah, da sind noch 3 andere Browser Tabs offen.
Ach das ist ja auch spannend und dann bin ich plötzlich wieder in
einem völlig anderen Thema drin. Auf youtube.
Ich glaube, da muss man sich letzten Endes wirklich auch
selber disziplinieren. Aber man kann das natürlich auch
als als Team, als Unternehmen und als Developer selber steuern
und mich reißen halt solche technischen Themen raus und
solche Dinge, die von außen kommen.
Alle anderen Dinge kann man so n bisschen auch selber
beeinflussen und ich glaub es ist wichtig, wenn wir jetzt über
developer protectivity so aus der Team Unternehmensperspektive
sprechen, dass wir gucken, OK was sind so Dinge die jetzt
nicht du Robin Manuel als einzige als einzelne Person an
deinem Alltag verbessern kannst, sondern was sind Dinge, die wir
als Team besser machen können, damit du am Ende sagst, Hey das
war toll, ich fühle mich dadurch jetzt produktiver und da mögen
technische Aspekte zugehören. Wir haben glaube ich auch mal
eine Folge gemacht über dev Container, das finde ich halt
ein ganz tolles Werkzeug um sich wirklich produktiver zu fühlen,
weil häufig. Arbeitet man an verschiedenen
Dingen, gerade wenn man irgendwie.
Microservices oder ähnliche Dinge hat, wo es
unterschiedliche Projekte gibt, mit unterschiedlichen
Abhängigkeiten. Und wenn du dann jedes Mal
irgendwie erstmal, wenn du in so n neues Ding reingehst und
irgendwie n paar Stunden verlierst und dein ganzes
technisches Setup wieder auf den aktuellen Stand zu bringen, dann
fühlst du dich unproduktiv. Es mag am Ende nicht so sein,
wie man es immer hört und neue Devadopfer brauchen hier 4 Tage
um ihr Setup irgendwie aufzubauen gibt's auch ich hab
von Firmen gehört, wenn dann neue Leute ins Team kommen
brauchen die erstmal Tage um überhaupt Hardware zu bekommen
und brauchen dann Tage um alle Zugänge zu bekommen und dann
dauert es noch viele Stunden um halt die ganzen Depenses lokal
zu installieren. Ja gibt es auch, aber selbst
wenn. Wir das in unserem Alltag nicht
als Problem haben, nervt es halt tierisch, wenn ich irgendwie in
so ein Thema reingehe, wo ich einfach mal 3 Wochen habe ich
jetzt an was anderem gearbeitet. Ich geh jetzt wieder da rein und
dann funktioniert es halt nicht mehr, dann baut es auf meiner
lokalen Maschine nicht mehr, weil irgendjemand was geändert
hat und. Ultra nervig.
Das ist super nervig und das zieht wirklich die Produktivität
runter und deswegen sowas wie def Container finde ich super
cool, von daher gern nochmal in die alte Folge reinhören zu dem
Thema. Gibt es lokal auf der eigenen
Maschine, gibt es Cloud basiert finde ich super cool, weil damit
bin ich quasi Instant auf dem aktuellen Stand und kann
anfangen zu arbeiten finde ich ist eine extrem große
Bereicherung, die sich über die letzten wie lang gibt es das
Thema 5 Jahre entwickelt hat finde ich finde ich super gut.
Einen zweiten technischen Punkt, den ich noch habe, ist ein
bisschen. Zu dem, was wir hier im Podcast
machen, aber nicht ständig auf jedes neueste Thema irgendwie
technisch draufspringen, weil ich fühl mich produktiv, also
weil, also sorry, ich geh noch mal 2 Schritte zurück, wo mein
Gedanke herkommt ist. Es gibt ja einfach Phasen, wo
ich sag, ich hatte heute nen Tag da, ich konnt mich gut
konzentrieren, ich bin nicht unterbrochen worden, ich hab
hier 5 Stunden rumgecodeed, aber ich saß hier gerade.
Wie heißt das 5 Stunden an diesem verdammten kleinen
Problem und ich hab irgendwas nicht hin.
Ich war jetzt also ich hab sie 5 Stunden Login eingebaut in diese
App und irgendwas hat nicht geklappt und irgendwie konnt ich
den Token nicht validieren und also was auch immer so das gibt
es ja, dass man sagt das war jetzt ja gar nicht die Schuld
von von unserem technischen Setup oder von unserer
Organisation. Sondern da war vielleicht
irgendwie ne Doku, verhaltet irgendwas.
Das hat mich irgendwas genervt, da fühlt man sich ja auch
unproduktiv und dann einfach sagen okay, dass man sich
vielleicht in auch über Projekte hinweg oder innerhalb eines
Projekts den Text Tag nicht dauernd wechselt, sondern dass
ich vielleicht beim nächsten Projekt jetzt nicht sag, ich
spring jetzt auf das nächste Fancy Java Script Framework, wo
ich dann wieder irgendwie die Basics werden muss, oder ich
springe jetzt auf den ja, jetzt kommt da dieser neue coole
Identity Provider um die Ecke, lass mal den einbauen, sondern
wirklich produktiv würde ich mich ja fühlen, wenn ich die.
Wenn ich das wissen, das Know-how vom alten Projekt auch
aufs Neue übertragen kann und uns allen in den Fingern, ich
meine machen den Podcast hier nichts anderes als alle 2 Wochen
über neue Fans die Sachen zu sprechen.
Aber diese gelernten Dinge wieder anwenden zu können und
dass sie eigentlich das das Geniale in der
Softwareentwicklung, dass man Dinge wieder verwenden kann und
nicht jedes Wort, Ach komm, jetzt probieren wir mal doch mal
die neue Datenbanktechnologie aus, ich glaube, das ist auch so
n. Produktivitätsbremse auch wenn
uns das allen in den Fingern juckt, wenn man wirklich sagt,
EY, wie können wir denn, wie kommen wir denn jetzt wirklich
im schnellsten voran, dann ist es doch eigentlich eher, auf
bewährte Sachen zu setzen, auch wenn es vielleicht mittlerweile
irgendwas gibt, was ein bisschen fancy ist.
Mhm, ich hab ja gerade schon auf frühere Folgen verwiesen und da
will ich auch einfach noch mal auch unsere Plattform
Engineering Folge verweisen, weil genau solche Best Practices
Technologie Stacks können wir dann in so einer Plattform
hinterlegen und wenn ich dann. In ein neues Projekt einsteige,
kann ich direkt darauf zurückgreifen und die Dinge
funktionieren halt einfach. Und dann bekomme ich im
Idealfall. Einen guten Start mit
entsprechender Entwicklungsumgebung über einen
Def. Container irgendwie und kann
dann wirklich anfangen und kann dann auf das Wissen aus dem
letzten Projekt zurückgreifen und muss dann nicht um das
gleiche Problem nochmal zu lösen wieder die gleichen Aufwand
betreiben wie beim letzten Mal. Finde ich einen absolut validen
Punkt um wirklich auch das Gefühl zu haben, hey ich bin
produktiv, weil eigentlich für Produktivität.
Auch persönlich ist es ja ein wichtiger Faktor, dass man auch
das Problem gelöst kriegt, manchmal fühlt man sich auch
einfach produktiv, weil man was Neues gelernt hat, aber.
Häufig ist es ja so. Ich habe ein Problem, das möchte
ich lösen und wenn ich das Problem gelöst habe, dann fühle
ich mich gut und umso kürzer dieser Zeitraum ist, bis ich das
Problem gelöst habe, umso besser.
Und Limitiere mich nicht in der Art und Weise, wie ich das
Problem lösen will. Ich habe das in einigen Folgen
schon mal gesagt, dass ich das sehr allergisch reagiere, wenn
mir jemand Hardware, Tooling und sowas vorschreiben will, ich,
weil ich glaube, dass Produktivität am Ende was sehr
individuelles ist, ja. Vor allem die die Workflows, die
dahin führen. Jeder hat seine andere Lieblings
IDI, jeder verwendet einen anderen Browser, den er
irgendwie jetzt irgendwie machen möchte, jeder macht sich Notizen
in einem anderen Tool, schreibt mir da nicht so viel vor, also
ne wir beide arbeiten auch mit Kunden die sagen ah okay nee um
den Befehl jetzt auszusetzen oder um da jetzt irgendwie hier
den Container hochzuladen muss ich mich erst irgendwie auf
einer anderen virtuellen Maschine per Remote Desktop
einwählen, die jetzt in dem Rechenzentrum steht die dann
Zugriff drauf hat. Ah ja, okay, jetzt hast du mir
hier irgendwie im Chat diesen Befehl geschickt, den kann ich
jetzt hier aber gar nicht ausführen.
Ich kann aber auch kein copy Paste auf die andere Maschine
machen, weil das irgendwie unterbunden ist.
Auf der anderen Maschine habe ich jetzt, wie kriege ich denn
diese eine Zeile Code auf die andere Maschine, also dieses so
oh das ist wirklich wahnsinnig machen, wenn ich dann irgendwie
einfach nur was ausprobieren will und wir beide wissen und
wahrscheinlich auch die meisten die hier zuhören, dass es das
gibt und dass das auch viel gibt und dass mich das schon
wahnsinnig macht, wenn ich da irgendwie zuschauen muss bei.
Und wenn ich selber so arbeiten müsste und oft kann man ja gar
nichts für, aber dann, das würd mich wahnsinnig machen und mach
es mir einfach zu arbeiten und das klingt so einfach, aber mach
es mir einfach zu arbeiten und lass mich n bisschen meine
eigene Produktivität selber gestalten und wenn ich jetzt den
einen Browser nehmen will und es jetzt keinen defacto Grund weil
der wirklich unsicher ist oder sowas gibt der dagegen spricht
oder ich aber ich editiere meinen Code aber lieber so oder
ich hab lieber Dark Mode an oder was weiß ich oder ich nehm
lieber den Git client solange das alles halt irgendwie git
ist. Solange du den gleiche
Programmiersprache schreibst wie alle anderen ist es doch auch
egal und schreib mir da nicht so viel vor.
Ja, ich glaub letzten Endes bin ich zwar in meiner Position sehr
privilegiert, weil mein Arbeitgeber gibt mir einfachen
Zugang zu den ganzen Tools. Ich brauch halt nicht irgendwie
VPN Zugänge und kann halt Tools wie Code Space verwenden, aber
letzten Endes habe ich das auch schon erlebt, dass du irgendwie
auf eine Unternehmensressource zurückgreifen musst.
Da muss ich aber für per VPN verbinden, aber der VPN sagt,
Nee nee, du kommst hier nicht rein, du musst erst mal die
Request Updates installieren, dann sitzt er erst mal da 20
Minuten installiert die Updates Republic rebootest deinen
Rechner, muss erstmal alles neu starten.
Hatten und kannst dann auf die Ressource zurückgreifen.
Ich glaub nichts erzeugen, so viel Gefühl von Unproduktivität
als durch solche Dinge zu springen und ich dementsprechend
ist es glaub ich ganz wichtig wenn ich produktive Developer
haben kann, muss ich halt ein einfaches Setup bereitstellen,
was einfach funktioniert und wo ich nicht durch diverse Hürden
springen muss um einfach mal ein paar Zeilen Code lauffähig zu
produzieren. Du meinst das Setup, wo nicht
die Mitarbeiter selber in 7 Tagen einen
Kalendersynchronisierungstool bauen müssen, weil dein
Arbeitgeber es nicht erlaubt? Im privaten Kalender mit dem
Arbeitskalender. Dir so, dass du keine
Terminkonflikte hast. Meinst du sowas vielleicht?
Ich glaub, das ist eher so n Luxusproblem von dir, weil du zu
viele Kalender hast. Nein nein, ich glaub es gibt da
schon Grenzen. Man muss auch sicherstellen,
dass Dinge den entsprechenden Sicherheitsstandards
entsprechen, aber man kann das halt so oder so machen und das
heißt ja nicht, dass solche modernen Ansätze, die
mittlerweile viele jüngere Unternehmen fahren, per se
unsicherer sind als die Dinge, die vielleicht noch in manchen
großen Konzernen eingesetzt werden als das.
Vor 10 Jahren noch der Standard war und seitdem hat sich daran
nichts mehr geändert. Auch heute spreche ich quasi
wöchentlich mit Developer, die sagen ich hab hier meine
developer Maschine, die ist total Lockdown und ich muss
jetzt hier über irgendwelche virtuellen Desktop Umgebungen
reingehen um überhaupt einen Webbrowser aufzumachen um mal
kurz im Internet was zu recherchieren um das Problem zu
lösen oder ich komme jetzt gerade nicht ins Internet weil
irgendwie mal Zertifikat abgelaufen ist und jetzt muss
ich morgen ins Büro fahren und meinen Rechner einmal ans
Netzwerk hängen damit ich das neue Zertifikat Krieg und solche
Späße kann man natürlich vermeiden indem man sagt okay
wir als Unternehmen sehen. Uns zum Ziel, dass wir die
Developer Produktivität erhöhen und machen das nicht nur im
Sinne von wir messen irgendwelche Zahlen und sagen
dann den Leuten, ihr seid unproduktiv, ihr müsst einfach
mehr arbeiten, damit ihr bessere Zahlen generiert, sondern sich
wirklich Gedanken darüber machen.
Was muss ich tun, damit die Leute auch sich produktiv
fühlen? Und ich glaub, das find ich nur
raus, wenn ich mit den Menschen spreche und das passiert und da
ist der Bogen zum Anfang meiner Meinung nach zu selten.
Ganz viele gehen jetzt hin und sagen, OK, wir brauchen sowas
wie Dora und dann messen wir das alles und dann wissen wir wie
produktiv wir sind, dann führen wir ein neues Tool ein und dann
sehen wir ob es hoch oder runter geht, aber einmal mit den Leuten
zu sprechen, irgendwie ordentlich designten Survey zu
machen, vielleicht sogar mit irgendwie einer Hochschule, die
sich mit solchen qualitativen Umfragen gut auskennen und
einfach mal eine Studie intern zu machen, mit den Leuten zu
sprechen und dann Dinge herauszusuchen, die man wirklich
einfach lösen kann, sehe ich einfach viel zu selten.
Hast du Zugang zu den Tools, die du brauchst, um produktiv zu
arbeiten? Und ist dieser Zugang irgendwie
einfach? Hast du Zugang zu dem Know How,
das du brauchst? Kannst du, wenn du ein Seminar
besuchen willst. Wenn du ein Training brauchst?
Wenn du, wenn du einfach nur ein youtube Video über ein Thema
gucken willst, hast du das geht das hast du.
Hast du das Gefühl, dass wir konsistent sind in der Art, die
wir arbeiten? Hast du das Gefühl, dass du
blockiert wirst und zu häufig auf irgendwelche Kollegen oder
Eltern underwork Items warten musst?
Hast du das Gefühl, dass unsere Prozesse gut funktionieren?
Fühlst, und das sind doch Dinge, die ich Abfrage sage.
Fühlst du dich produktiv und ich glaube, dass das, was auch der
Konsens für uns alle ist und eigentlich ist es glaub ich, da
wird so n riesen beheiterung gemacht, aber wie du gerade
gesagt hast, eigentlich ist es ganz einfach, frag die Leute und
machst den Leuten einfach Motiv zu sein, weil am Ende glaube ich
ist das ein Menschenbedürfnis jeder aber die meisten Leute
möchten produktiv sein weil sie es einfach gut anfühlt produktiv
zu sein und wenn und je weniger Steine ich den Leuten in den Weg
lege, desto höher. Höher ist die
Wahrscheinlichkeit, dass sie sich selber.
Wieso? Wieso?
Wasser fließt selber so den Weg des geringsten Widerstandes
selber suchen und dann schon kommen und dann muss ich
eigentlich immer nur abfragen Hey gibt es irgendwelche
Probleme? Vielleicht ist die
Teamaufstellung falsch, vielleicht haben wir zu viel
Leute die das eine Thema gut können aber nur wie einen Abend
Frontend Development alles irgendwie bauen muss und die
Backend Leute warten die ganze Zeit sowas ist zum Beispiel was
wo man sagt die Verteilung im Team muss vielleicht messen oder
ich habe viel zu viele juniorige Developer aber fast keine
Seniors oder alle sind coder und keiner managed wirklich das
Team. Solche Dinge kann man natürlich
rausfinden, aber in erster Linie sorgt dafür, dass die Leute sich
selber ihre Produktivität. Gestalten können, weil es was
Individuelles ist. Und ja, fragt das regelmäßig ab
und wieso, sprich mit den Leuten, schau was schau was du
tun kannst und versuch nicht alles glatt und gleichzuziehen,
sondern versuche den Leuten glaube ich Verantwortung selber
in die Hand zu geben, denn jeder möchte eigentlich selber
produktiv sein und sich das selber auch gestalten.
Schaffe jenseits dieser Produktivitätsmetriken, die
wirklich auch die subjektive Developer Produktivität zu
erhöhen hat, das natürlich auch diverse andere positive Effekte.
Und das ist natürlich n positiver Trend, den ich
wirklich sehe. Ich hab jetzt schon in einigen
Gesprächen auch mit großen Unternehmen den Begriff
Developer Satisfaction oder Developer Happiness gehört und
das ist eigentlich ein super gutes Thema und häufig ist es
so, wenn ich developer Happiness Messe Leute befrage, hängt das
ganz stark mit dem Thema Produktivität.
Zusammen, das ist ganz interessant irgendwie, wenn ich,
wenn ich zu jemandem gehe, der am Fließband arbeitet, die
Person ist vielleicht nicht unbedingt glücklicher, wenn sie
den Output irgendwie n bisschen erhöht hat, aber bei Development
ist es tatsächlich so, wenn sie sich produktiv fühlen, wenn Sie
das Gefühl haben, Sie haben Ihr Ziel erreicht und da lagen wenig
Hindernisse im Weg, sie konzentriert arbeiten, dann sind
sie zufriedener, glücklicher und ich glaube, wir alle haben das
schon erlebt, manche häufiger, manche sind weniger häufig, dass
wir nicht, ich habe ein Problem gelöst, dann hat das richtig so
ein gibt's so ein richtiges, und da freut man sich, hat das
Problem gelöst, da kann man irgendwie.
Ganz entspannt in die Pause gehen, kleinen Spaziergang
machen und freut sich 2 Stunden später noch wie Produktivität.
Da kann man dann erfolgreich in die Kantine gehen und kreuzt
dann noch 2 Stunden später immer noch, wie wie gut man am
Vormittag war und ich glaube, solche positiven Erlebnisse muss
man fördern, fördert die Zufriedenheit und letzten Endes
führt es dazu, dass die Leute in dem Team arbeiten, auch es
einfacher ist Leute im Team zu halten.
Und das spielt dann natürlich immer alles.
Im Zusammenhang, weil wenn ich irgendwie unzufriedene Leute
hab, dann verlassen die das Team.
Ich hab häufige Wechsel, das zieht dann wieder die
Produktivität der anderen runter und ich mein von daher kann man
da glaube ich einen sehr positiven Entwicklung
vorantreiben, wenn man weggeht von den Zahlen und Produktivität
wirklich auch qualitativ misst. Finde ich einen schönen
Schlusssatz einfach zu sagen, Leute.
Steckt gar nicht so viel Energie da rein developer Productivity
zu messen, sondern Messe Developer Happiness, weil das
bedingt developer proaktivity ganz automatisch Leute suchen
sich das selber und es ist auch die viel angenehmere Umfrage und
Abfrage der Leute haben Spaß da Feedback zu geben ob sie happy
sind. Ich glaube das ist niemand hat
Sorge irgendwie kontrolliert zu werden und ich bin felsenfest
davon überzeugt, dass ein glücklicher Entwickler, der
richtig Spaß bei seiner Arbeit hat oder bei ihrer Arbeit hat,
automatisch. Produktiver wird, weil das, wie
du gesagt hast, einfach Spaß macht, Dinge zu shippen und zu
bauen sagen hier das Feature, das ist endlich fertig, das hab
ich gebaut, das fühlt sich gut an und ich bin felsenfest davon
überzeugt, dass ich das bedingt, aber es kann natürlich sein,
dass wir hier sehr bias sind, ne wir sind beides developer,
natürlich sagen wir es mal lieber meine eigene Happiness
wie du gesagt hast, das fragt dich, dann fließt man
wahrscheinlich auch fast keiner nach, da bedingt sich das aber
auch nicht, auch nicht so sehr und deswegen werde ich einfach
auch gerne mal auf eure Meinung gespannt ist.
Das Konsens auch bei euch, das Developer Happiness sich
eigentlich eigentlich die bessere und wichtigere Metrik
ist, weil das automatisch die Productivity bedingt, oder muss
man das schon irgendwo messen, weil man sonst irgendwas
vergisst oder irgendwas hinten überfällt oder sonst alle nur
ganz happy Ihre neuen Fancy Java Script Frameworks ausführen,
aber gar nichts geschippt wird? Das ist ja auch eine Gefahr, ist
ein Thema wo es glaube ich ganz viele Meinungen gibt, deswegen
was ist eure Meinung dazu? Lasst uns das gerne wissen, wenn
ihr das öffentlich chatten wollt könnt ihr das gerne machen.
Es gibt bei Spotify. Die Möglichkeit, unter der Folge
Kommentare zu hinterlassen. Wir freuen uns aber auch sehr
darüber, damit euch privat zu diskutieren und dazu können wir
uns auch gerne einfach ne E-Mail schreiben.
Ne e Mailadresse findet ihr auch in der Beschreibung vom Podcast.
Lasst uns da gerne ne Meinung da.
Können wir gerne auch dann noch mal diskutieren oder halt in der
nächsten Folge noch mal aufgreifen.
Und. Wenn euch die Folge gefallen
hat, lasst uns gerne positive Bewertungen.
Da freut uns immer entweder auf Spotify oder Apple Podcasts und
wenn ihr uns was Gutes tun wollt, findet ihr unten in den
Shownotes den Link zu bei mir Coffee, da könnt ihr einen
Kaffee ausgeben oder in unserem Shop euch die eigene to do
developer Podcast kaffeetasse kaufen, da freuen wir uns
natürlich auch immer sehr, wenn wir das ein oder andere Foto
bekommen von euch mit unserer Tasse.
Dann, bis dahin habt eine gute Zeit.
Wir hören uns in 2 Wochen wieder, denn der To do Cast
erscheint alle 2 Wochen, macht's gut, bis dahin habt eine gute
Zeit und schreibt ganz viel kommt ciao.
Bis dann.