Transcript

[0:00] Wenn du versuchst, dich jede Woche ein Prozent zu verbessern, dann ist das wirklich Arbeit. Du musst dir überlegen, was kann ich besser machen, was kann ich vielleicht auch weglassen.
Wenn ich am Montagfrüh meine Woche starte, dann ist der komplette Kalender durchgeplant und alles, was ich tue, steht im Kalender drin.
Ich habe vor kurzem so einen LinkedIn-Post geschrieben mit der Überschrift, ich merke mir seit zehn Jahren keine Dinge mehr.
Also Empathie finde ich ein super wichtiges Stichwort, weil ich glaube, eine der wichtigsten Eigenschaften, die ein guter Softwareentwickler haben sollte, ist Empathie. Empathisch zu sein, macht dich zu einem besseren Softwareentwickler.

[0:34] Diese Revision von Working Draft wird euch präsentiert von Midwalt.
Next-Level-Hosting für deine Projekte.
Jetzt fragt ihr euch bestimmt, wie kann so was Langweiliges wie Hosting Next-Level sein? Ganz einfach.
Midwalts hochperformantes Cloud-Hosting ist perfekt abgestimmt auf die Anforderungen von Freelancern und Agenturen.
Es gibt zum Beispiel ein smartes Rollensystem für die Zusammenarbeit mit euren Projektpartnern. Und Midwald hat mit M-Studio auch eine sehr schöne moderne Verwaltungsoberfläche gebaut, mit der das Arbeiten Spaß macht.
Aber jetzt mal ehrlich unter uns Nerds. Sachen anklicken? In einem User-Interface?
Muss das sein? Nein, muss es nicht. Denn bei Midwald gibt's die M-Studio CLI.
Mit der könnt ihr euer Hosting komplett über die Kommandozeile verwalten und natürlich auch entsprechend automatisieren.
Von Nerds für Nerds bringt euch Midwald die optimale Developer-Experience, wenn's um's Hosting geht. Und deshalb jetzt auf zu midwald.de slash workingdraft.
Denn da wartet auf euch, exklusiv als Hörer von Working Draft, das Angebot, den Tarif pro Space für 30 Tage kostenlos zu nutzen.
Das war noch mal MITTWALD.de, slash Working Draft. Wir danken mit World für die Unterstützung von dieser Revision von Working Draft.

[1:42] Untertitel im Auftrag des ZDF für funk, 2017 Liebe Hörerinnen und Hörer, es ist soweit. Bald kommt unsere 600. Podcast-Episode.
Daher hab ich eine aufregende Ankündigung für euch. Denn am Sonntag, den 7. Januar, werden wir die 600. Podcast-Episode zusammen feiern.
Wir laden euch herzlich ein, an unserer Fishbowl-Diskussion teilzunehmen, bei der ihr direkt mit uns interagieren könnt.
Für alle weiteren Informationen folgt uns bitte in den sozialen Netzwerken oder schließt euch unserem Community-Working-Draft Slack an.
Wir freuen uns so sehr darauf, diesen Meilenstein mit euch zu teilen.

Revision 594: Vom Chaos zum Code - wie Developer ihre Arbeit effizient strukturieren

https://workingdraft.de/594/

[2:20] Revision 594. Willkommen bei Mockingdraft, wir sind heute zu dritt, da hätten wir aus dem Team einmal die Vanessa. Hallo.
Servus. Ich bin der Shep und das bedeutet wir haben wieder einen Gast da und zwar den Martin, hallo Martin.
Hallo grüß euch. Du bist zum ersten mal bei uns im Podcast und da ist es immer Usus, dass die Gäste sich einmal für unsere Hörerschaft vorstellen.
Erzähl mal, wer bist du und was machst du?
Ja, ich bin der Martin Dilger. Ich war mehr als zehn Jahre Freiberufler, bin mittlerweile in der Firma angekommen, Gott sei Dank in meiner eigenen Firma.
Ich bin Geschäftsführer einer kleinen Softwareentwicklungsfirma.
Wir arbeiten hier im Chiemgau. Unsere Kunden sind aber deutschlandweit.
Wir machen Softwareentwicklung.
Fokus ist verteilte Systeme, Microservices, ganz viel Backend-Entwicklung.
Und wir arbeiten sehr viel mit Confluent-Produkten, also.

[3:23] Kafka, Kafka Connect und den ganzen Tools um dieses System außenrum.
Außerdem mache ich sehr viele Schulungen, speziell rund um das Thema Git und auch Kafka.
Ich bin Trainer, habe mittlerweile mehr als 1200 Entwickler geschult, bin ich sehr stolz drauf.
Macht mir sehr viel Spaß. Und du hast auch ein Buch geschrieben zu Git zumindest.
Ich habe ein Buch geschrieben zu Git und ich habe ein Buch geschrieben zum Thema Freiberufler sein, korrekt. Ja, cool.
Genau, und unsere Hörer wissen ja, dass wir ein Frontend-Podcast sind, deswegen wird's heute nicht um Kafka gehen, und auch nicht um Infrastruktur, sondern um das Thema wie Developer ihre Arbeit effizient strukturieren können.
Genau, das hast du ja auch im Repertoire, hast du ja eben auch gesagt, da sind wir sehr gespannt drauf, was du so für Tipps und Tricks und ja, vielleicht Frameworks hast für uns Entwicklerinnen und Entwickler, um eben irgendwie reibungsfreier und entspannter durch den Tag zu kommen.

[4:28] Das Thema produktiv arbeiten, das beschäftigt mich ja schon quasi meine ganze berufliche Karriere.
Und das, was sich die meisten Entwickler und Leute immer wünschen, ist quasi so was wie den Zaubertrick zu haben.
Wie werde ich von heute auf morgen produktiv? Wie kann ich meine Arbeit besser strukturieren? Wie funktioniert das alles?
Ich habe aber in den letzten zehn Jahren gemerkt, das funktioniert vielleicht gar nicht so genau so.

[4:57] Der Ansatz, den ich für mich habe und den ich verfolge, ist eigentlich eher ein bisschen ein anderer.
Ich versuche, mich Schritt für Schritt zu verbessern. Wie mache ich das?

[5:09] Ich versuche, mich jeden Tag ein bisschen zu verbessern und ich versuche, mich jede Woche ein bisschen zu verbessern.
Da gibt es ganz viele verschiedene Möglichkeiten, wie man an dieses Thema rangehen kann.
Das erste, was ich mache, Und das ist auch eines meiner wichtigsten Werkzeuge, ist quasi mein wöchentliches Review.
Das mache ich für mich persönlich. Das heißt, ich frage mich jeden Freitagabend, ich habe Freitagabend einen Termin in meinem Kalender und frage mich, was war denn eigentlich diese Woche?
Was habe ich diese Woche gemacht? Wie kann ich meine Arbeit, die ich diese Woche gemacht habe, vielleicht nächste Woche ein kleines bisschen besser machen? Wie kann ich ein bisschen schneller arbeiten?

[5:46] Welche Möglichkeiten gibt es da? Also im Prinzip die agilen Arbeitsmethodiken aufgegriffen, aber eben nicht auf ein Team übertragen, sondern für dich selber praktiziert letztendlich.
Und das Ganze dann auch vielleicht so ein bisschen systematisiert, weil ich denke, jeder denkt ja so im Laufe der Woche immer mal über sein Werk nach und ihr oder ihm dünkt, dass da vielleicht Optimierungspotenzial schlummert, aber genau du machst das einfach so ein bisschen so dedizierter.
Also ich glaube, das richtige Stichwort ist wirklich systematisch.
Ich mache das Ganze systematisch.
Also ich habe wirklich, ich habe Termine im Kalender, ich weiß genau, wann ich was zu tun habe und das sind auch Termine, die verpasse ich nicht, weil die sind einfach in meinem Kalender drin und die sind mir auch persönlich auch sehr, sehr wichtig.
Und ich habe wirklich das Ziel, mich quasi jede Woche ein Prozent zu verbessern.
Das gibt es ja immer, Also wenn man sich ein bisschen umhört, die sogenannte Ein-Prozent-Methode wird.

[6:45] Ja sehr, sehr häufig beworben, aber machen tut das eigentlich niemand, weil es aufwendig ist.
Wenn du versuchst, dich jede Woche ein Prozent zu verbessern, dann ist das wirklich Arbeit. Weil du musst überlegen, was kann ich besser machen, was kann ich vielleicht auch weglassen.
Das ist viel Arbeit, die man tun muss.
Und ich persönlich, ich kenne eigentlich niemanden, der das macht.
Was machst du dann stattdessen?
Was meinst du damit stattdessen? In deinem Termin, also schreibst du da Sachen hin und überlegst, ob das jetzt ein Prozent wäre oder schreibst du dann einfach gute und negative Sachen auf?
Genau, erzähl mal vielleicht, wie deine letzten beiden eigenen Reviews waren, das wäre vielleicht mal interessant.
Was ich mache ist, im Prinzip, ich gehe durch meinen kompletten Kalender durch, also ich schaue mir alle Termine an, muss man vielleicht vorweg sagen, alles was ich tue steht in meinem Kalender drin. Also mein Kalender ist wirklich, mein komplettes Leben läuft nach meinem Kalender ab.
Es gibt im Prinzip nichts, was nicht in meinem Kalender drin steht.
Ich starte meine Woche eigentlich immer komplett durchgeplant.
Das heißt, wenn ich am Montagfrüh meine Woche starte, dann ist der komplette Kalender durchgeplant und alles, was ich tue, steht im Kalender drin.

[7:54] Und wenn ich jetzt mein Wochen-Review starte, dann gehe ich im Prinzip einfach von Montag bis Freitag durch meinen Kalender durch und überlege mir, für jeden Termin, den ich in meinem Kalender hatte, war dieser Termin wirklich notwendig?
Und gibt es vielleicht Dinge in meinem Kalender, die ich nächste Woche weglassen kann?
Oder Dinge, die ich vielleicht besser machen kann? Oder Dinge, die ich vielleicht automatisieren kann?
Automatisieren ist ein ganz, ganz wichtiges Stichwort. Gibt es Dinge, die ich einfach automatisieren kann und die ich vielleicht zukünftig gar nicht mehr selber machen muss? Oder kann ich die Dinge an jemand anderen übergeben?

[8:25] Du hast jetzt gerade gesagt, für alles einen Kalendereintrag.
Allerdings sind das dann Das sind wahrscheinlich nicht alles Meetings, sondern kann ich mir jetzt auch so einen Punkt vorstellen wie eineinhalb Stunden, ich wollte was in Kafka debucken, weil da ging was langsam. Genau.
Und danach brauch ich aber noch eine Stunde, weil da kommt wahrscheinlich ein Code-Review von jemand anders rein.
Und dann blockier ich mir dafür Zeit. Genau. Zeit blockieren ist genau das richtige Stichwort. Ich blockier mir Zeit für Dinge, die ich machen muss.
Das kann beispielsweise ein LinkedIn-Post sein, den ich schreiben möchte.
Das kann ein Blog-Eintrag sein für die Homepage, der Firma, den ich schreiben möchte, oder das kann ein Thema sein, mit dem ich mich beschäftigen möchte, weil ich weiß, ich habe einen Kunden, der das Thema braucht und ich muss mich ein bisschen tiefer damit beschäftigen.
Ich plane im Prinzip alles in meinem Kalender.
Ich kann mir vorstellen, das ist super. Ich persönlich mach's auch nicht immer, nicht streng.
Aber grade dann, wenn's stressiger wird oder wenn ich mal merke, ich verliere so selber meinen Überblick, dann fang ich das auch wieder an.
Manchmal mach ich das auch einfach, um so Pseudo zu schätzen.
Weil ich tendiere, seit ich denken kann, aus zum Unterschätzen.
Aber dann überleg ich mir, wie lange brauchst du dafür, dafür.
Rechne dann bei allem so zehn Minuten drauf und sag dann, das mach ich so eine Stunde lang, ach, dann ist das Meeting, dann mach ich das eine Stunde lang, dann ist Lunch, dann ist das eine Stunde lang.
Aber Moment, ich brauche zwei Tage und nicht einen Tag. Wieso hab ich einen Tag gesagt? Ich muss zwei Tage sagen.

[9:45] Jetzt würde ich aber mal kurz argumentieren, vielleicht hast du dafür ja dann auch Tipps und Tricks.
Das klang jetzt so, vielleicht, als wüsstest du am Anfang der Woche schon tatsächlich, wie die Woche aussehen wird.

[9:56] Das ist ja vielleicht nicht unbedingt der Fall. Vielleicht kommt am Dienstag was Neues rein oder vielleicht weiß man, ich weiß noch gar nicht, was ich tun muss, weil am Dienstag wird erst beschlossen von oben, in Anführungsstrichen, was jetzt mein nächstes Projekt wird.

[10:10] Kann man dann dennoch die Woche planen? Selbstverständlich. Du kannst die Woche immer planen. Also meine Woche ist immer durchgeplant. Das heißt aber nicht, dass diese Termine fix sind.
Also sobald ein wichtigerer Termin reinkommt, dann musst du den Termin, der halt ursprünglich an diesem Timeslot war, entweder auf die nächste Woche verschieben oder einfach umplanen.
Das heißt, man muss da agil sein, aber trotzdem solltest du immer einen Plan haben, was du heute machst und was du diese Woche machst.
Also ich habe immer ein Ziel für die Woche und weiß, was willst du denn diese Woche erreichen? Das sind meistens drei Dinge.
Also aus Prinzip drei Dinge oder ist es dann so, dass du quasi, also sind das so drei Kategorien von Dingen, die du immer irgendwie jede Woche schaffen möchtest? Also wie muss man das interpretieren?
Das, ich glaube, da kommt so ein bisschen die Erfahrung rein, die ich in den letzten zehn Jahren mit diesem Thema gesammelt habe.
Sobald ich mir mehr als drei Dinge vornehme, schaffe ich die Sachen meistens nicht. Das heißt, wenn ich mir drei Dinge vornehme, ist es meistens so, die schaffe ich auch.
Und es gibt fast kein schöneres Gefühl, als am Ende der Woche zu sagen, Haken dran, ich habe genau das gemacht, was ich mir vorgenommen habe und ich habe das auch geschafft.
Also es könnte sowas sein wie Angebot fertig machen, Kafka-Bug endlich mal auf die Schliche kommen und sowas, ne? Genau.
Angebot schreiben, ein neues Kapitel in einem Buch schreiben.

[11:27] Das kann die Urlaubsplanung Das können ganz unterschiedliche Sachen sein, aber meistens sind es drei Ziele, die ich verfolge.
A. Ok, das heißt, da läuft dann auch sozusagen deine privaten Vorhaben, die sind auch quasi Teil dieses Wochenplans von dir. B.
Tatsächlich ist das so, ja. Also ich trenne das nicht strikt, weil das funktioniert für mich wirklich überhaupt nicht.
Ich plane meine Woche und meine Woche besteht ja nun mal aus Arbeitszeit und aus Familienzeit und aus privater Zeit.
Das zu trennen funktioniert jetzt für mich persönlich überhaupt nicht.

[12:00] Okay, verstanden. Das klingt jetzt so, als wäre das jetzt erstmal was für einen selber.

[12:08] Würdest du auch sagen, das könnte auch positive Effekte für andere Personen haben, weil ich mir zusätzlich gerade gedacht habe, ein Vorteil, der mir jetzt persönlich noch einfällt, ist, dass ich dann auch anderen Leuten sehr schnell Feedback geben kann, ob ich für irgendwas Zeit habe oder nicht.
Und das ist, was ich gerade meinte mit, dass ich, wenn ich mal ins eher Schludern bekomme, weil ich mich grad selber nicht organisiert habe, merke ich dann, wenn mir zwei, drei Personen sagen, ich bräuchte ein schnelles Code-Review von dir, Person fünf schreibt noch, du, da ist ein Bug, ist der schnell zu fixen oder nicht?
Wir wissen alle, ich weiß das nicht, ohne mir das anzuschauen.
Und Person Nummer sieben hätte gerne noch eine Aufwandsabschätzung für irgendwie was anderes.
Und wenn ich jetzt vorher gar keine Termine für mich selber in meinem Kalender hab, dann sag ich, ja, klar, hab ich Zeit, weil ich hab ja nix vor.
Aber würdest du das unterstützen oder was denkst du?
Also das kenne ich nur zu gut, wenn der Kalender leer ist und jemand kommt und möchte was von dir haben, dann sagst du grundsätzlich ja, zumindest ist das bei mir so.
Also ich bin ein sehr hilfsbereiter Kollege und wenn jemand kommt und der Hilfe braucht, dann helfe ich. Aber wenn der Kalender voll ist, dann machst du das nicht.
Immer wenn jemand zu mir kommt und sagt, ich brauche deine Hilfe, dann sage ich, kein Problem, lass uns heute Nachmittag um 16 Uhr zusammensetzen, da habe ich Zeit.
Also das hilft mir, das hilft dem Team, das hilft dem Projekt.
Planen macht einfach total Sinn.

[13:32] Ich denke das zahlt dann ein auf den punkt den du auch hier in der stichwortliste ein bisschen später hast den ich jetzt vielleicht einfach mal also ich ziehe den schon mal jetzt hervor das ist ja dieses die burg.
Und wenn ich das richtig verstehe ist es ja im prinzip dieses dass du schaust dass du dich in so einen arbeitsfluss bringst und da auch eben einfach sozusagen dein dein eines thema an dem du arbeitest.
Erst mal zu Ende verfolgst, bevor du dann dich irgendwie anderen Dingen widmest.
Also, was ja letztlich, wenn du immer anspringst auf.

[14:14] Hilfegesuche anderer Leute und du sofort alle in deinen Griffel fallen lässt, dann bist du quasi, also dein Deep Work ist natürlich so oder so schon so, sagen wir mal, etwas angeschlagen durch die Anfrage, aber genau, du kannst das Thema dann auch grundsätzlich nicht weiterverfolgen.

[14:32] Richtig. Genau. Also Deep Work ist im Prinzip was, was ich wirklich versuche, täglich mindestens zwei oder drei Stunden zu machen.
Das heißt einfach, du setzt dich hin und du lässt dich durch nichts aus der Ruhe bringen und du arbeitest fokussiert an einem Ticket, an einem Bug, an Dokumentation, was auch immer gerade wichtig ist.
Und ich habe das auch, ich sage das grundsätzlich meinen Kunden und Projekten, in denen ich arbeite.
Es ist nichts Persönliches, wenn ich nicht sofort antworte, wenn jemand mich anschreibt, sondern ich antworte dann, wenn ich halt fertig bin mit meiner Arbeit.
Also, wenn jemand mich anschreibt und Teams poppt auf, ich antworte da nicht und ich reagiere dann normalerweise auch nicht sofort drauf, sondern ich versuche wirklich, meinen Task abzuschließen, um Kontext-Switches zu vermeiden und einfach möglichst gut in meinem Task voranzukommen.
Und jeder, der mit mir arbeitet, der weiß das.
Hast du es tatsächlich die Notification komplett aus und siehst sie nicht oder siehst du sie aber bist mental stark genug sie wegzublocken also mental.
Die kommen hoch habe ich sie sie nicht ich sehe sie also ich sehe die wirklich nicht.
Ich bin da so drauf konditioniert ich sehe die nicht mehr. Das ist natürlich was Starkes.
Also, ich hab auch gehört, das funktioniert bei Leuten sehr gut, die curved Monitore haben, weil sie sehen sie wirklich nicht mehr, wenn sie erst durch den Zoom-Kopf. Einfach ein super Breitbildmonitor.

[15:51] Ein Ding, was ich ja auch immer mache, ist, dass, wenn ich eine Notification bekomme, und ich möchte sie da lesen und stelle dann fest, darauf müsste ich zwar reagieren, aber ich kann aktuell nicht drauf reagieren, dass ich sie bei Slack in meinem Fall dann wieder als ungelesen markiere.
Das klappt sehr oft auch nicht, weil ich dann denke, oh, guck mal, ich habe eine Notification. Nur um die gleiche Nachricht nochmal zu lesen, ist dann semi-hilfreich.
Sondern ich mache tatsächlich dann wieder einen Kalendereintrag mit einem Link zu diesem Slack-Thread, dass ich dann weiß, ach ja, ich muss die nochmal lesen.
Das kenne ich auch nur zu gut. Also wenn es mir passiert, dass ich so eine Nachricht lese und ich Ich muss danach drauf reagieren, mache ich mir sofort eine Notiz, damit ich das nicht vergesse.
Grundsätzlich. Da steht auch ganz viel in diesen Overthinking-Büchern hilfreich drin.
Ich hab mir auch mal so ein Buch zum Overthinking geholt, wo, ich glaub, nur ein Kapitel drum geht.
So, hey, bist du so eine Person, die mal so drei Tage gebraucht hat, um auf eine E-Mail zu antworten, aber du warst während dieser drei Tage wahrscheinlich unfassbar gestresst, weil du die ganze Zeit überlegt hast, wann beantwortest du diese E-Mail? Die hättest du dir schon längst beantwortet.

[17:00] Das heißt auch da, einfach so mental zu sagen, okay, ich werde diese E-Mail, heute um 17 Uhr beantworten.
Haken dran, ist tatsächlich erstmal Task erledigt und das kann auch extrem hilfreich sein.
Ja und ganz wichtig, wenn du dafür einen Termin in deinem Kalender hast, dann ist es halt geplant. Das kannst du nicht mehr vergessen.
Ja, weil ich hatte tatsächlich immer so gedacht, mein Gedächtnis ist so super stark, ich vergesse sowas nicht.
Das Ding ist, ich vergesse es meistens auch nicht, aber ich hab die ganze Zeit so einen... Ich hab, das ist mathematisch sicherlich oder biologisch nicht korrekt, aber ich hab schon das Gefühl, dass so 20% von meinem Kopf ist nur damit beschäftigt, mir Dinge zu merken, die ich auch einfach aufschreiben könnte.
Da kommen wir vielleicht auch nachher noch dazu. Ich hab vor kurzem so einen LinkedIn-Post geschrieben mit der Überschrift, ich merke mir seit 10 Jahren keine Dinge mehr.
Also genau das mache ich eigentlich nicht mehr. Ich merke mir solche Sachen nicht mehr. Habe ich auch ein System dafür, können wir auch nachher noch drüber sprechen.
Lass uns auch gleich gerne drüber sprechen. Das Feedback in LinkedIn war durchaus durchwachsen.
Also das Feedback war wirklich, die ersten Leute sind sofort gekommen, haben gesagt, das ist ja total schlecht für dein Gedächtnis, wenn du dir nichts mehr merkst.

[18:07] Also Hintergrund davon. Ich habe ein System, das nennt sich Second Brain.
Also quasi, ich merke mir Sachen nicht. Mein Gehirn ist total schlecht darin, sich Sachen zu merken.
Mein Gehirn ist super darin, kreativ zu arbeiten und Probleme zu lösen, aber es ist super schlecht darin, sich Sachen zu merken.
Und deswegen habe ich ein System, das nennt sich Second Brain.
Da gibt es auch ein Buch von Tiago Forte, der das System so ein bisschen beschreibt.
Und im Prinzip ist es so, alle Dinge, an denen ich arbeite, alle Dinge, die ich mache, die sind einfach in einer Notion-Datenbank gespeichert.
Also, da kann man mit verschiedenen Technologien arbeiten. Ich nutze Notion dafür.
Und da ist im Prinzip alles drin, was ich machen muss und auch alles, was ich gemacht habe.
Das ist im Prinzip meine Wissensdatenbank und da ist mein komplettes Know-how, und mein Wissen von den letzten zehn Jahren drin.
Da sind mehr als 100.000 Einträge drin und wenn ich wissen möchte, was ich vorletztes Jahr an einem Mittwoch gemacht habe, dann muss ich einfach nur nachschauen, weil da steht alles drin. Ich bin jetzt ein bisschen neidisch.

[19:03] Das hätte ich auch gerne.
Das ist, also ich meine, es ist, ähm, Dora's Arbeit – Aber bringt es was?
Das ist jetzt die andere Frage.
Auf jeden Fall. Auf jeden Fall. Ich würde, wenn du mich fragst, würde ich sagen, das ist mein größtes Produktivitäts-Tool.

[19:16] Also, ich kann gerne mal ein bisschen beschreiben, wie ich das Tool benutze, wenn es für euch interessant ist.

[19:21] Also, das ist im Prinzip genauso, wie es in dem Buch auch beschrieben ist.
Man untergliedert sein Wissen in prinzipiell vier Bereiche.
Der erste Bereich, das nennt sich auch wirklich Bereiche, das ist dann sowas wie Finanzen, Das ist sowas wie Fitness, also wirklich übergreifende Bereiche in meinem Leben.
Das kann sein, die Firma ist ein Bereich.
Und dann gibt es immer Projekte, an denen ich arbeite.
Alles, woran ich arbeite, ist ein Projekt. Also zum Beispiel der Podcast hier ist ein Projekt in meiner Wissensdatenbank.
Da ist die Wissenssammlung drin, da ist alles gespeichert, was ich mir zu dem Podcast, welche Gedanken ich mir dazu gemacht habe, ist ein Projekt.
Und das Projekt werde ich heute nach dem Podcast auf DUNGEE.
Ich liebe es, Projekte auf dann zu schieben, deswegen freue ich mich jetzt schon drauf.
Der dritte Bereich, das sind sogenannte Ressourcen.
Das sind einfach Dinge, wo ich beispielsweise, ich sehe einen LinkedIn-Post, der interessant ist zu einem bestimmten Thema, dann überlege ich mir, was ist quasi der Tag dazu, was könnte die Überschrift dazu sein, das könnte Lebensweisheiten sein oder das könnte Kafka sein, also eine Technologie, völlig egal, und speichere mir alles in meiner Datenbank.
Und so landen im Prinzip jeden Tag 10, 20, 30 neue Einträge in meiner Datenbank.
Und der letzte Bereich, das ist im Prinzip das Archiv.
Da sind Sachen drin, die abgeschlossen sind. Also zum Beispiel der Podcast, der wandert heute Abend ins Archiv, weil der ist fertig.

[20:50] Der große Vorteil von diesem System ist, alles ist gespeichert.
Das heißt, wenn ich den nächsten Podcast mache, muss ich einfach nur schauen, okay, was habe ich denn eigentlich beim letzten Podcast gemacht?
Welche Sachen habe ich mir da überlegt? Was waren die einzelnen Schritte?
Und das Schöne ist, ich fange, egal was ich mache, eigentlich nie bei Null an.
Das heißt, ich habe nie das leere Blatt und weiß nicht, wie ich anfangen soll mit irgendwas, sondern ich fange immer schon mit einer Grundstruktur an, weil ich alles, ich habe eigentlich alles schon mal gemacht.
Alles wiederholt sich irgendwie.
Das merkst du spätestens dann, wenn du dir alles mal aufschreibst. Alles wiederholt sich.
Ja, da würde ich gerne noch mal ein bisschen tiefer nachhaken, denn ich denke, du meinst nicht unbedingt nur den Moment, dass du diesen gleichen Podcast wiederholen würdest mit dem gleichen Thema, Und du meinst auch, wenn du tatsächlich jetzt mal wieder einen Podcast bei anderen Hosts machst, aber über ein anderes Thema, würde es dir tatsächlich helfen, dass du weißt, diese vier Schritte hast du beim letzten Mal davor gemacht?
Wie zum Beispiel der Vanessa zu schreiben, dass sie vergessen hat, die Kalendereinladung rauszuschicken. Ist das auch ein Stichpunkt?
Das ist auch ein Stichpunkt. Das war ein Eintrag in meinem Kalender, das ist ein Stichpunkt in meiner Wissensdatenbank, das ist alles notiert.
Deswegen habe ich es nicht vergessen. Ja, aber ich hab's vergessen.
Aber dann kam die Kalenderanleitung sehr schnell nach. Genau.

[22:08] Ja, ich finde, bevor man jetzt da großartig darüber diskutiert, wie sinnvoll das nicht Sinnvollste ist, ich bin bei sowas immer doch tatsächlich der Meinung, man sollte das erst mal ausprobieren, bevor man mitreden darf.
Denn viele von diesen Punkten machen erst Sinn, sobald man die am eigenen Leib mal generell erfahren hat.
Das war jetzt ein ganz, ganz anderes Thema, aber ich habe mal Kalorien gezählt und mir haben auch mal ganz viele andere Leute darüber erzählt, was sie daran gut oder schlecht finden, die das aber selber nicht machen.
Und dann hörst du schon so bei so manchen, da fängst du, da hast du gar keine gemeinsame Kommunikationsgrundlage.
Ich finde es auf jeden Fall sehr spannend, aber ja, wie du schon sagtest, es klingt auch so, als würde es einfach Zeit kosten und ich glaube jetzt nicht nur vielleicht es runter zu schreiben, aber musst du da nicht auch ständig entscheiden, was ist jetzt was was Wichtiges, was du niederschreiben solltest? Ja.
Ja, also das ist wirklich, das ist zeitaufwendig. Was ich mache, ist im Prinzip die Woche über, also ich mache mir natürlich jetzt nicht bei jedem Eintrag in der Datenbank Gedanken, oh, was ist jetzt die Kategorie, wo ich das reinpacke.
Es gibt eine fünfte Kategorie im Prinzip, die nennt sich Capture bei mir.
Da landet im Prinzip einfach alles drin. Alles, was ich irgendwie interessant finde, das landet in Capture.

[23:24] Und freitags habe ich einen Termin in meinem Kalender, wo drin steht, gehe die Captures durch und sortiere die ein.
Das sind meistens so 30 bis 45 Minuten und dann ist das eigentlich auch erledigt.
Und damit hält sich der Aufwand für die ganze Wissensdatenbank eigentlich in Grenzen.
Und es ist im Prinzip bei mir, das ist alles systematisiert.
Ich mache das eigentlich ganz automatisch, deswegen ist es für mich jetzt nicht mehr so viel Arbeit. Ich mache das seit zehn Jahren.
Ich möchte jetzt einmal noch mal wieder kurz die Kurve zum.

[23:54] Mehr Alltagsarbeit für Developer bekommen. Ich denke, so was Ähnliches könnte ... Also, mir hilft's auch immer, die Sachen dann runterzuschreiben und in Relation zu sehen.
Weil je nachdem, in welchem Konzept ich grade arbeite, ich weiß, manchmal gibt's POs, die das alles komplett wegnehmen, die Priorisierungsarbeit.
Aber ich priorisiere schon viel meine Arbeit. Dass ich zum Beispiel zwei Features, drei Bugs und, keine Ahnung, drei Tech-Themen irgendwie bei meinen Notizen hab.
Klar, ich könnte das jetzt, je nachdem in welcher Situation, alles in einem PO zeigen und sag, jetzt sagst du mir, was ich machen soll.
Meine Realität ist selten so.
Ähm, und ich brauche tatsächlich sehr oft diese Liste daneben, weil ich dann noch einen Bug-Report reinbekomme.
Und dann, ich bin so von meinem Charakter her so, Ja, ich möchte das sofort fixen, aber dann, Moment, ich schreib das zuerst auf meine Liste und sag, oh, das andere klingt mir alles viel dringender, als dass da ein, keine Ahnung, ein Buchstabe fehlt in der Datei.

[24:58] Würdest du jetzt auch speziell für, wenn wir jetzt noch mal zurück an den Alltag von Developern denken, hast du da auch da Tipps und Tricks für ...
Oh, ich hatte jetzt so viele Fragen auf einmal. Aber hattest du da was, was du rüberübersetzen kannst?
Auch wenn ich jetzt zum Beispiel, ich mach ein konkreteres Beispiel, ich habe jetzt ein Ticket, an dem ich arbeite, kann ich da auch meine Arbeit in diesem einem Ticket so strukturieren oder mir sogar noch von der Vergangenheit aus, so habe ich das bei anderen Tickets gemacht, so bin ich davor gegangen, denkst du, es könnte auch da helfen, so Leitwege zu haben?
Auf jeden Fall. Also, in den meisten Projekten ist es ja so, dass du das eigentlich ganz automatisch machst.
Also, zum Beispiel, wir haben im aktuellen Projekt, wo ich arbeite, gerade eine neue Kategorie eingeführt, die unten im Ticket gespeichert ist.
Da steht im Prinzip genau das drin, was habe ich denn in diesem Ticket gemacht, warum habe ich das in diesem Ticket gemacht, und zwar im Prosa-Text.
Das heißt, jeder, der an einem Ticket arbeitet, der schreibt einfach auf, okay, was waren denn die wichtigsten Sachen in diesem Ticket, was habe ich in diesem Ticket gelernt, Und warum haben wir das eigentlich so gemacht?
Und wenn der Nächste mit diesem Ticket arbeiten muss oder vielleicht einen Bug zu diesem Ticket fixen muss, dann kann der wirklich in dem Prosa-Text lesen, okay, was ist denn die Geschichte von diesem Ticket? Was ist denn da eigentlich passiert?

[26:18] Du sprichst auch so – jetzt lenk ich ein bisschen vom Thema ab – aber das klingt alles sehr vertrauenswürdig auch, was du hier sagst.
Würdest du auch sagen, Es könnte jetzt gerade im Umgang mit Kunden helfen, so eine Art Planung zu haben, um ruhiger zu reagieren.
Wenn du jetzt zum Beispiel fünf Anfragen gleichzeitig bekommst, dass das jetzt, dass man jetzt keine Nervosität nach außen zeigt. Hast du?
Wie macht man das, dass man jetzt niemanden nach außen, dass niemand von außen merkt, dass man jetzt von dieser Situation vielleicht gerade gestresst wird?
Ich weiß es jetzt nicht, ob man irgendwann nicht mehr gestresst wird.
Mit einer gewissen Erfahrung, aber wahrscheinlich vielleicht doch noch?

[27:01] Also, ich glaube, da spielt Erfahrung natürlich eine große Rolle.
Also jemand, der jetzt neu in den IT-Bereich zum Beispiel kommt, der wird sich schwer tun, sich nicht stressen zu lassen, weil das ist einfach ein stressiger Bereich.
Speziell, wenn dann vier Leute von allen Seiten kommen und irgendwas von einem wollen, dann ist das erst mal stressig.
Aber so funktioniert die IT halt, so ist das halt.
Was mir da wirklich einfach extrem hilft, und das hilft auch allen Entwicklern, denen ich da ein bisschen unter die Arme greife, ist einfach, du brauchst einen Plan.
Wenn du einen Plan hast, dann hast du was, woran du dich halten kannst.
Und du bist immer dann gestresst, wenn du das Gefühl hast, du verlierst die Kontrolle.
Du hast nicht die Kontrolle. Wenn du das Gefühl hast, alles kommt gleichzeitig und du kannst irgendwie nicht kontrollieren, an was du gerade arbeitest, du willst niemanden enttäuschen, du willst jedem alles recht machen, aber das funktioniert halt einfach nicht.
Und was da wirklich hilft, ist, einen Plan zu haben. Du hast einen Plan und du hältst dich an diesem Plan. Und dann ist es nur wichtig, dass du das transparent kommunizierst.
Ich arbeite nach einem Plan. Ich helfe gerne jedem, aber nicht zu jeder Zeit.
Ich mache das mit Struktur.

[28:07] Ich finde dieses transparent machen total wichtig also wenn man wenn man das vor den verschiedenen leuten so ein bisschen versteckt hält wie man sozusagen aufgestellt ist und jeden sozusagen gerade so glücklich macht dass sie für einen moment ruhe geben dann ist einem irgendwie nicht geholfen also ich denke es ist also wenn er halt eben mehrere anfangen reinkommen ist, zwar vielleicht aus der Sicht der hereinreichenden alles wichtig, aber am Ende gibt's ja dann doch irgendeine Prioritätenreihenfolge wahrscheinlich.

[28:45] Genau, und dann entscheidet man sich eben für eine Reihenfolge und arbeitet das ab, was ja dann am Ende wahrscheinlich auch wieder effizienter ist, weil dann kann man eben Tunneln oder Deep Work betreiben.
Man kommt irgendwie schneller durch die Dinger durch, als wenn man eben die ganze Zeit Kontext-Switche macht.
Und ich finde es also ich bin zum Beispiel auch so jemand ich habe kein keine Notification die mir ins Gesicht springt.
Du kannst das ja gut ignorieren ich. Ich habe die einfach abgeschaltet und mache so Pool Prinzip.
Also ich weiß dann natürlich schon wenn jetzt irgendwie ein paar Feuerchen lodern, dass ich öfters mal dann den Pool mache und gucke ob es irgendwie Neuigkeiten gibt.
Genau aber ansonsten versuche ich eben das zu vermeiden, weil ich ja eben weiß okay, das sind die Dinge, die halt irgendwie gerade anliegen. Ich kümmere mich darum.
So. Bleibt entspannt. Ich mache, ich arbeite und ich melde mich dann, wenn ein Ticket abgearbeitet ist, so. Genau.
Die Queue wird ja abgearbeitet halt nur in einer bestimmten Reihenfolge.
Und wenn du das nicht transparent machst, dann wirkt es oft so, als würdest du jemanden ignorieren, was ja überhaupt nicht der Fall ist.
Also das Transparenz, genau wie du sagst, Transparenz ist ja extrem wichtig.

[30:00] Ich würde gerne tiefer in das Thema einsteigen, weil es jetzt gerade zwar sehr nett klingt, was ihr sagt, und sehr logisch.
Aber in der Realität ist es ja erstaunlich hart, das teilweise zu machen.
Und jetzt habe ich gerade, während ihr gesprochen habt, überlegt, was ist denn eigentlich so schwer da dran?

[30:18] Und Ticket nach Ticket arbeiten ist jetzt die eine Sache, aber es können ja, wie gesagt, ganz andere Themen reinkommen, wie dann Kollege, Kollegin schreibt hier so, hey, ich arbeite gerade an einem Stück Code, den kenne ich noch gar nicht, ich habe gesehen, du hast hier ein paar Zeilen verändert, hast du Zeit, mir dabei zu helfen?
Situation 1, die passiert. Aber vielleicht kommen da noch drei weitere Nachrichten rein.
Was kann ich jetzt also genau in der Sekunde machen?
Eigentlich hast du schon vorher beantwortet, du sagst wahrscheinlich jetzt zurück, also dir helfe ich um 17 Uhr und dir helfe ich um 13 Uhr.
So, wie findest du jetzt raus, wem solltest du früher helfen und wem solltest du später helfen?
Ich glaube nicht, dass du da eine feste Regel machen kannst.
Also manchmal hörst du es ja schon im Call, okay, der braucht wirklich Hilfe, weil... Oder es ist ein Produktionsproblem. Produktionsproblem geht immer vor.
Das kannst du natürlich nicht an einer festen Regel festmachen.
Ich hab aber ich kann euch sagen wie wie versucht wird das ganze dann trotzdem doch stressig zu gestalten für für uns was aber eigentlich immer nur in großen firmen passiert das ist wenn verschiedene.

[31:31] Stakeholder alle auf einen zukommen und man dann eben das macht was wir jetzt gerade besprochen haben also eigentlich ist das richtige und es passt denen dann nicht dann dann wird eben laut geschrien und wenn man dann.
Bei seinem Plan bleibt, dann kenne ich das so, dass die dann, also wenn die, sagen wir mal, sehr unsouverän sind, dann eskalieren die das immer noch mal nach oben und beziehen die Chefetage ein.
Die quakt dann auch noch rum, und da muss man erst mal sehr viel ordnen und sortieren, bevor man dann seinen Plan eben wieder weiter durchziehen kann.
Also, so habe ich das schon erlebt. Ist halt Kindergarten.

[32:07] Aber, ja. Also, ich finde, das ist dann so, da entsteht dann noch mal viel Unruhe.
Da geht natürlich auch viel Zeit verloren, wertvolle Zeit.

[32:15] Ähm, genau. Das sind so unangenehme Situationen, einfach weil sie unnötig sind.
Aber sie kommen auch dann irgendwann nicht mehr vor. Also, wenn man das ein paar Mal, ähm, ja, irgendwie eingefangen hat und gezeigt hat, dass das irgendwie nichts bringt, also, wenn die das so versuchen.
Natürlich. Wer kennt das nicht? Also, das ist ja wirklich der Alltag.
Normalerweise hast du einen Scrummaster, der dich eigentlich vor sowas beschützen sollte. Das genau ist die Aufgabe vom Scrum Master.

[32:45] Das funktioniert natürlich auch nicht immer. Was da meistens hilft, ist einfach ganz ruhig zu bleiben und einfach zu sagen, ich helfe dir, aber ich helfe dir halt nach der Reihenfolge. Du bist um 17 Uhr drin.
Und wenn du das ganz ruhig machst und freundlich, dann ist das meistens auch kein Problem.
Ja, klar. Ich wollte ja heute tatsächlich genau über diese Punkte reden, die man selber in der Kontrolle haben kann.
Die Dinge, die ich selber beeinflussen kann, entweder für mich selber, für meine eigene Gesundheit oder für meinen eigenen Kopf, oder vielleicht für noch ein paar Kollegen, Kolleginnen, dass ich die auch noch ein bisschen unterstützen kann.
Aber, Shep, die Situation, die du besprochen, äh, gezeigt hast, die liegt außerhalb jeglicher Kontrolle.
Da ist es wahrscheinlich wirklich nur auf sich selber zu schauen.
Vielleicht anzumerken, dass das zu einer unproduktiven Arbeit deinerseits führst und du würdest gerne performen, aber bräuchtest eine Entscheidung oder ähnliches.
Aber das ist, glaube ich, alles, was dann in der eigenen Macht ist und dann eben mal abwarten.

[33:46] Ich versuche mir dann auch tatsächlich immer so vorzustellen, dass das für das große Ganze ist. Es ist jetzt vielleicht sinnvoller, das so zu machen, aber ich glaube, da wissen wir jetzt schon alle, da bringt es eben selber dann normalerweise nicht sich selber aufzuarbeiten.
Und da hat jetzt vielleicht auch niemand mehr was davon, dass man bis 23 Uhr noch was fertiggemacht hat.
Genau, aber das ist ja auch dann so, dass dann auch die höheren Instanzen irgendwann sehen, dass das Ganze dann doch so leichte Kindergartenzüge hat.
Wenn die nämlich dann merken, dass das alles Hand und Fuß hat, was man macht, und man ja auch, sagen wir mal, zuverlässig dann abliefert und transparent ist, dann, genau, Das ist eigentlich so das Beste, was man machen kann, ja.
Die meisten Menschen sind ja durchaus zugänglich für logische Argumente.
Ich meine, das habe ich auch schon erlebt, dass es halt nicht so ist, wenn es dann plötzlich laut wird, wenn du angeschrien wirst, habe ich auch schon erlebt.

[34:42] Soll vorkommen, aber das ist ja dann wirklich die große Ausnahme.
Also, normalerweise passiert sowas nicht.
Und selbst dann, wenn ich angeschrien werde, bin ich immer noch der, der ruhig bleibt. Also du kannst mich im Büro auch anschreien.
Ich fände das nicht gut, aber ich werde niemals zurückschreien.
Das wird nicht passieren.
Ja, ja, genau. Ich glaube, bei mir hätte man dann, würde man aber dann in der Prioritätenliste dann ein bisschen weiter nach hinten rutschen.
Genau, das ist dann die logische Konsequenz.

[35:09] Ja, sehr interessant, finde ich allerdings zu dem Thema jetzt auch noch.
Schreib nochmal, wie du sprichst. Deswegen finde ich das so spannend, immer wieder im Podcast zu sprechen mit unterschiedlichen Erfahrungen, weil du jetzt von Stakeholdern und die gesagt hast, Es gibt immer so zwei Partien, das sind die einen und die anderen.
Ich arbeite ja gerade komplett in dem Zustand, da gibt es nur ein Wir. Wir sind halt ein Team.
Es gibt vielleicht auch Personen, die sagen, das sind die Produktideen und so soll es ausschauen, aber das ist nicht unbedingt mal oben, das ist so quasi daneben und wir versuchen das immer alles zu machen.
Wir haben da eigentlich ganz...
Eher andere Probleme, oh, ich glaub, so was Kleines, Süßes, was immer wieder passiert ist, dass Leute für Developer versuchen zu schätzen, aber das ist so unterbewusstes.
So, das ist doch nur ein Button, du, ich hab dir ... Kannst du das mal schnell machen?
Und da musste ich für mich auch die Kunst lernen, dass ich jede Handlung, die mir jemand vorschlägt, ob ich die mal kurz machen sollte, diese Einschätzung anderer Personen sofort ausblende und mir selber überlege, wie lange würde das jetzt dauern.
Und da versuche ich auszuüberlegen, kenne ich diesen Bereich von der Codebase?
Sonst plane ich gleich schon mal ein, ich muss da erstmal nachgucken, was da los ist, weil vielleicht gibt's ja einen guten Grund, warum diese eine Stelle oder dieses eine Feature da noch nicht war.

[36:26] Und hab dann, ähnlich wie du sagst, Martin, da jetzt über zwei, drei Jahre das aufgebaut, dass Leute schon wissen, Vanessa muss erstmal gucken, und dann sagt sie aber auch in einer Stunde oder mal in fünf Stunden oder mal in zwei Tagen Bescheid.
Aber ich versuche es meistens schon irgendwie vorher anzugeben, wann ich dann antworten werde.
Ich komme dann am Nachmittag mit einer Antwort und dann kann ich dir sagen, ob das ein kurzes Ding wird oder ob es ein langes Ding wird.

[36:52] Der große Vorteil da ist, und das habe ich wirklich gemerkt, die Leute wissen das wirklich zu schätzen, wenn du mit einer Antwort kommst, die dann wirklich auch fundiert ist.
Also da lege ich dann auch großen Wert drauf. Wenn du eine Antwort von mir bekommst, dann ist das auch wirklich eine Antwort, die durchdacht ist und die fundiert ist. Und das ist viel mehr wert, als eine Antwort, die du einfach mal schnell gibst, weil du halt gerade fünf Minuten Zeit hast vielleicht.
Das finde ich einen super wichtigen Satz, weil wer kennt es nicht, dass man angesprochen wird?
Und wenn es nur ein Bauchgefühl ist, ist dann auch egal, wenn es nicht gestimmt hat. Aber was hast du so für ein Bauchgefühl?
Und sich da nicht presschen zu lassen, zu sagen, keine Ahnung, klingt nach zwei Tagen, ist schon echt schwierig, weil man möchte ja nur helfen.
Und man hat dann vielleicht in der Sekunde schon wirklich das Gefühl, ich helfe der Person jetzt, dass ich jetzt so ungefähr eine Hausnummer spreche.

[37:40] Aber vielleicht sollte man der anderen Person auch die Möglichkeit geben zu erfahren, wie es ist, wenn eine tatsächliche richtige Schätzung dann kommt.
Und wenn es auch erst am Nachmittag ist, weil es vielleicht dann doch einfach mehr bringt.
Ja, ich meine, sowas lernst du normalerweise quasi durch die harte Schule.
Also ich kann, glaube ich, gar nicht zählen, wie oft ich das gesehen habe.
Jemand fragt mich von der Seite, wie viel ist denn das?
Du sagst zwei Tage und dann irgendwann später kommt es in irgendeinem Management Summary und da steht drin, das ist zwei Tage groß und die Zahl ist dann für alle Ewigkeiten festgeschrieben.
Ja und dann geht es halt darum, okay, was können wir jetzt alles runterbrechen und damit das dann auch in zwei Tagen klappt und dann, ja, ja, ja, ja, ja, ja, aber das gehört teilweise dann auch halt eben dazu. Ja.

[38:19] Ich mach sowas grundsätzlich nicht mehr, also Schätzungen war so im Zuruf, das kriegst du von mir nicht, egal um was es geht.
Das grundsätzlich ist wichtig, aber auch echt schwer.
Ich möchte es nochmal sagen, wir reden hier immer in der Theorie drüber und wenn ich jetzt mir gerade vorstelle, diesem Podcast selber zuzuhören, dann klingt es so, ah ja logisch, mach ich jetzt auch so.
Es ist wirklich schwer, vor allem wenn dann, wenn es gerade der eigene Manager oder die eigene Chefin ist, die sagt, ja komm nur ein Bauchgefühl, nur ein Bauchgefühl, dann ist es halt wirklich sehr schwer da hart zu bleiben.
Und natürlich braucht man dann eine Art auf jeden Fall des Vertrauensverhältnisses zu den Personen, die einen da ernst nehmen.
Was gerade, wenn man jetzt hier noch ein bisschen jünger ist oder in der IT ein bisschen weiblicher und vielleicht ein bisschen zu blond, auch manchmal schwieriger, dann wirklich auf seinem Standpunkt zu bleiben.
Aber hat man sich den erarbeitet, dann bekommt man teilweise hoffentlich in den richtigen Teams das Vertrauen auch zurück.
Und ansonsten brauchst du vielleicht dann doch eher ein neues Team, wenn das sonst gar nicht klappt, dann.

[39:17] Also ich kann da, ich würde da gerne kurz zurückkommen zum Thema, was wir eingangs hatten, das wöchentliche Review.
Ich meine, du kannst natürlich jetzt nicht morgen ins Büro gehen und sagen, ich mach das jetzt nicht mehr, das geht nicht.
Aber du kannst dir nach jeder Woche überlegen, okay, was habe ich diese Woche gemacht?
Okay, ich habe da geschätzt, da geschätzt. Was hätte ich denn machen können, um das Ganze ein bisschen besser zu machen? Wie kann ich das nächste Woche ein kleines bisschen besser machen? Ein kleines bisschen reicht schon.
Wenn du dich jede Woche 1% verbesserst, dann bist du 60% besser nach mir. Das ist ziemlich viel.

[39:48] Das klingt auch sehr schön unwertend, wie du das da teilweise machst.
So nicht unbedingt, das habe ich da irgendwie schlecht gemacht oder das war jetzt alles doof.
Nee, gar nicht. Sondern es klingt wirklich so, ja, jetzt hier in der ruhigen Minute merke ich, ich hätte stattdessen antworten können, ich komme am Nachmittag mit einer Schätzung zurück.
Okay, Haken dran, das nächste Mal mache ich das so, dann wird es ja besser. Das klingt sehr schön.
Das könnte dann zum Beispiel ein Ziel für die nächste Woche sein.
Also so ein Learning aus einer Woche könnte ein Ziel für die nächste Woche sein.
Das funktioniert ganz hervorragend. Aber das ist superschön bei einer Woche, weil eine Woche ist bald.
Das ist ja nicht so wie so ein Jahresreview, sondern man hat ja schnell die Chance, das beim nächsten Mal besser zu machen.
Und eigentlich sind es ja tatsächlich auch diese kleinen, wir reden jetzt hier über die Kleinigkeiten, die dann großen Impact haben können, aber natürlich ist jetzt auch nichts normal, naja, je nachdem, nicht so Schlimmes passiert, wenn ich aus dem Bauchgefühl zum Beispiel geschätzt habe, Außer vielleicht, dass ein Manager ein wichtiges Slide geschrieben hat und jetzt ist es so, jetzt müssen alle Developer das machen.

[40:49] Aber ich denke, das sind so oft so Kleinigkeiten, die andere gar nicht wissen, dass man die jetzt irgendwie verbessert hat oder verbessern möchte. Ja.
Shep, wir haben dich vor langer Zeit unterbrochen. Weißt du noch, was zu sagen?
Ich weiß nicht mehr, wobei ... Ja, ich wollte nur sagen, es ist natürlich cool, wenn man das dann, wenn man seine eigene, seine Review macht und das Ganze so systematisiert, wenn man sozusagen seine Antworten beim nächsten Mal schon fertig in der Schublade liegen hat, ist auch immer leichter, dann kann man eben sozusagen planvoller reagieren auf das nächste Mal, weil man ja schon sozusagen sich das vorher vorbereitet hat, wie man das nächste Mal die Gleichsituation begegnet.
Das ist schon auch cool.

[41:41] Genau ansonsten wir haben es auch ein paar mal erwähnt und du hast es hier auch in den in den stichworten drin transparenz genau so irgendwie immer klar machen für alle im team woran man gerade sitzt dann ist es nicht so dieses ich hatte wahrscheinlich gerade zeit oder die oder was macht der oder die eigentlich überhaupt gerade woran sitzt die oder der.
Genau, aber das ist ja so einer der Grundpfeiler auch der agilen Arbeit, würde ich sagen.
Also der Boards und der Stand-Ups.
Ich glaube, da, wenn man sich an diese Geschichten hält, dann ist es auch gar nicht so leicht, intransparent zu sein.
Also kann man schon, aber man kann das nicht lange durchhalten.
Also in der Praxis ist es doch häufig so, dass es einfach, wenn dann so ein Ticket im Scrum Board einfach drei Wochen lang in der To-Do-Spalte hängt oder in der In-Progress-Spalte.
Also.

[42:47] Man kann schon tricksen, wenn man möchte, aber Ziel ist es eigentlich wirklich, transparent zu sein.
Was ich auch ganz gerne mache, ich spreche das auch immer mit meinen Kunden ab, ich schreibe jeden Abend eine Summary, was ist heute passiert, was habe ich heute gemacht per E-Mail, einfach drei, vier Sätze, damit einfach jeder sofort weiß, okay, das ist heute passiert, daran wurde gearbeitet und wenn ich wissen möchte, was wir diese Woche geschafft haben, muss ich einfach nur die fünf E-Mails lesen.
Und viele Kunden schätzen das wirklich. Die müssen nicht nachfragen, die wissen genau, was heute passiert ist und wenn sie auch mal einen Tag im Urlaub waren, Transparenz ist immer da.
Ja, ich schreibe das auch immer auf, weil ich auch immer nach Time and Material abrechne Und dann schreibe ich eben immer runter, wie viel habe ich denn heute eben gearbeitet und an welchen Themen habe ich gearbeitet.
Und dann kann man ja noch zusätzlich, hat man in der Regel dann noch das Git-Log, das ist ja auch hilfreich.
Also zumindest wenn man eben Entwicklerin oder Entwickler ist, dann spiegelt sich das da ja oft wieder, was man den Tag über gemacht hat.
Das gilt natürlich nicht für Angebote schreiben etc., das müsste man dann irgendwie anders tracken.
Aber das ist natürlich auch praktisch, dass man das dann auch nochmal da so Google Maps-Zeitleisten-mäßig nachsehen, kann.

[44:02] Was ich tatsächlich meine Zeit lang gemacht habe, jetzt nicht mehr aktiv, und ich bin dann auch wieder zurückgekehrt zu meinem, ich mach einfach im Kalender Einträge für mich selber, ist, dass ich Zeit getrackt habe in Firmen oder Teams oder Projekten, bei denen ich keine Zeit tracken musste.
Sondern da war es im Endeffekt, okay, wenn man sagt, acht Stunden gearbeitet, ich war halt da.

[44:25] Aber es hilft eben dann doch, dass man einerseits nicht rumschlingert mit den Gedanken, sondern man hat sich schon vorgenommen, ich will zwei Stunden dafür brauchen.
Und wenn ich dann merke, ich werde aber in zwei Stunden nicht fertig, dann kann ich noch mal kurz ein Reset für mich selber machen.
War das, weil ich blank auf meinen Monitor starre und grad halt nichts zusammenkriege, und wär vielleicht doch mal ein Zehn-Minuten-Spaziergang hilfreicher als noch 30 Minuten auf einen Monitor zu starren?
Oder einfach, dann hab ich auch so einen kleinen Break drin und kann vielleicht auch überlegen, ey, muss ich grad jemandem Bescheid sagen, dass, ich meine jetzt nicht wegen zwei Stunden, aber wenn es ein größeres Ding ist, muss ich grad jemandem Bescheid sagen, dass ich ungeplanterweise dafür jetzt geschätzte zwei Tage mehr brauche, weil ich hier diese folgenden X-Punkte sind.
Und da habe ich sehr stark tatsächlich in jeder Firma, denke ich, bisher gelernt, dass sich die Leute, die diese Planungen weitergeben müssen oder mit diesen Zahlen was anfangen müssen, sich sehr freuen, wenn ich sehr rechtzeitig Bescheid sage, boah, das dauert länger.
Weil dann ändert sich vielleicht für mich nichts als kleiner Developer bei diesem großen, großen Projekt.

[45:41] Aber die anderen haben die Macht, mit diesem Wissen jetzt was anzustellen.
Und ob das ist, wir brechen dann jetzt dieses Projekt ab, das passiert halt so gut wie nie.
Aber trotzdem können sie vielleicht anders planen und sagen, du, da ist jetzt ein Projekt, das wird dann vielleicht nicht unbedingt an mich kommuniziert, Vielleicht war da irgendwo gestanden, Vanessa macht ab Mittwoch das.
Und dann steht da, oh, nee, Vanessa macht ab Mittwoch gar nicht das, sondern wir müssen das Projekt jemand anders geben.
Das höre und sehe ich vielleicht nicht auf dem Blatt Papier.
Aber ich stelle mir vor, dass solche Sachen passieren und dass sich deswegen diese Personen immer so freuen.

[46:15] Und ich habe schon auch das Gefühl, dass wenn das Personen nicht machen, es mehr Reibereien im Endeffekt gibt.
Und vielleicht kann es keiner genauso gut benennen, woran das lag.
Aber ich sehe ja im Verhältnis dann auch die Unterschiede und immer wenn ich sehr rechtzeitig sage, das wird hier nix, scheinen, manchmal meine Projekte, glaube ich, für andere schneller zu laufen.
Obwohl ich mir manchmal gedacht habe, du nur rein auf den Papier.
Sagst du mir gerade, die Person war ein bisschen langsam und bei dir wäre es schneller gegangen. Dabei war die Person eigentlich bei dem Projekt in zwei Tagen fertig und ich habe zwei Wochen gebraucht.
Also woran liegt das? Und ich denke, ich hoffe, dass es diese Art meiner offenen Kommunikation dann ist.
Und offene Kommunikation heißt nicht, dass ich alle zwei Sekunden eine Slack-Nachricht, schreibe, sondern einfach ohne Angst, deswegen Vertrauen ist wieder wichtig, schreibe, das war hier verschätzt oder wir haben gar nicht geschätzt oder keine Ahnung was.
Ich wollte jetzt Bescheid sagen, ich brauche dafür länger.
Oder willst du vielleicht jetzt einfach von Features noch von Must-Have auf Nice-to-Have-Liste kippen und dann werden wir doch morgen fertig und dann geht es halt ohne die zwei Features live.
Aber vielleicht ist es ja für jetzt einen Kunden sehr wichtig, dass das tatsächlich heute Abend live geht, weil wir haben es jemand anders versprochen.
Und vielleicht ist es cooler, wenn wir halt dann doch, vielleicht ist es besser, dass wir jetzt halt nicht die beste Transition oder Animation der Welt noch mit dran haben.
Aber dafür haben wir uns zwei Tage eben am Ende gespart.
Und, ähm, da hab ich eine Übergangsfrage noch.
Ähm, dazu gehört es ja auch, tatsächlich die Arbeit selber zu strukturieren.

[47:43] Für wichtig zu unwichtig oder wie es ich immer sonst versuche zu beschreiben, so von deployable state zu deployable state.
Habt ihr beide denn Tipps und Tricks, wenn ihr ein Ticket habt und das ist halt jetzt nicht ganz runtergebrochen, sondern da kann man jetzt eigentlich noch selber sehr viele Subtickets für sich selber schreiben.
Wie überlegt ihr euch denn bei einem Feature Landing Page shippen?
Was sind jetzt für mich die Must-Haves, die muss ich unbedingt machen, damit ich am Ende des Tages ein deployable state habe, um zu sagen, die anderen Features habe ich zwar noch nicht, aber ich habe was kompilierbares.
Wer möchte anfangen? Das ist gar nicht so einfach.
Was ich da immer mache, ist, ich überlege mir immer, was kannst du denn in der Demo zeigen?
Also das ist immer quasi, was ist das kleinste Ding, was du in der Demo zeigen kannst?
Und das ist meistens auch ein Inkrement, was du als Ticket implementieren kannst.
Das ist immer so mein Maßstab. Und wenn du das machst, kannst du eigentlich jeden größeren Task in kleinere Bereiche runterbrechen.

[48:42] Also ich finde, dass das mit dem Schippen, das scheitert weniger an dem runterbrechen in einzelnen Tasten, zumindest in meinen Projekten, sondern eher daran, dass also das funktioniert, also man bricht das eben runter und dann gibt es eben so quasi Basis Elemente und dann kann man aufsatteln und noch eine Schicht drauflegen.
Und oft sind es aber eher die, ja, die, äh, Product Owner, die dann sich noch nicht trauen, irgendwas zu shippen, weil, also auch für die sich zu unfertig anfühlt, so.
Und eben die Angst vor Ablehnung durch die, äh, durch die Benutzerschaft dann.
Deswegen sind das meistens diejenigen, die lieber noch mal warten darauf, dass noch mehr, ähm, Features gebaut sind, bevor sie sich dann trauen, äh, das zu shippen, ja. Witzig, komm mal zu mir in Start-up.

[49:37] Da bin ich nämlich der Gegenpol. Ich bin immer der Gegenpol, die Person, die sagt, ja, ich hätt das gern noch, können wir nicht das noch machen? Ich werd das noch gern machen, und das wär doch eigentlich cool.
Nee, passt schon, ist jetzt gut genug, lass los. Nein, ich hab doch fünf weitere Ideen.
Ja, ich mein, das muss man natürlich auch immer, man muss das immer so ein bisschen, äh, abschätzen.
Also wenn man jetzt schon andere Dinge hat in seinem Produkt und es gibt halt einen heftigen Bruch, wenn man jetzt sozusagen in diesen Bereich, in den neuen Bereich reinkommt und das ist dann wirklich klar erkennbar, dass das zwar irgendwie funktioniert, aber sehr rudimentär ist, dann würde ich auch sagen, also man kann da vielleicht irgendwie mal so ein paar Beta-Tester oder Alpha-Tester draufschicken.

[50:24] Genau, dann fühlt sich das auch nicht richtig an, das schon zu shippen, dann würde ich das auch so lange zurückhalten, bis eben sozusagen der da nicht mehr so eine Riesenlücke klafft, also sozusagen in der in dem Polish, die der der einen und der anderen Bereiche.
Aber genau das ist natürlich immer individuell vom Projekt abhängig, dass man da hat.

[50:51] Beispiel. Ihr habt zwar ein Ticket, aber ihr seid jetzt nicht alleine dafür verantwortlich, dass dieses Ticket live gehen kann.
Ihr braucht als Frontend-Dev meistens ein Design von Pixel Perfect zu zumindest ein Konzept.
Und sehr oft braucht ihr eine Backend-Arbeit dran, damit die Daten da sind oder API-Requests vorhanden sind etc.
Ja, wie gesagt, es gibt Situationen, da gibt es einfach POs und dann werden die Tickets ganz, ganz, ganz genau aufgeteilt.
So, Frontend kann erst starten, wenn Backend hier das auf dann geschoben hat etc.
So ist aber bei vielen Projekten die Realität nicht, sondern das ist eher, jetzt fangst du alle schon mal an, dann redest du miteinander und in einer Woche ist fertig.
Was liegt jetzt im Frontend, in unserer Macht, was können wir tun, damit das möglichst smooth läuft, dass, weiß ich nicht, würdet ihr mit Sachen im Frontend anfangen, für die A, das Design noch nicht ganz da ist, weil wir wissen alle, dass diese 10-Pixel-Unterschied, manchmal eine ganz andere HTML-Struktur auf einmal wird oder ein Input-Feld, ist jetzt ein Selector oder was anderes.
Aber auf der anderen Seite, wir wissen ja auch, wenn wir mit Backend-Daten raten, vielleicht ist dann die Struktur ganz anders und wir müssen unser JavaScript-Map-Transform wieder umschreiben.
Würdet ihr mit den Sachen anfangen und wenn ja, habt ihr kluge Techniken, um Fehler zu vermeiden?

[52:17] Also wenn du nicht mit den Sachen anfängst, dann hast du ja nichts anderes als den agilen Wasserfall im Projekt.
Das willst du ja eigentlich gar nicht haben. Der agile Wasserfall.
Was ist denn der agile Wasserfall?
Achso, wir nennen es Scrum und wir machen Wasserfall? Ganz genau.
Und ich warte einfach so lange. Ah ja, verstehe. Genau.
Ich würde auf jeden Fall anfangen. Immer. Das Einzige, worauf du dich einigen musst zwischen den einzelnen Schichten, ist ja die Struktur der Daten.
Das muss zumindest einigermaßen klar sein. Wie sieht die API aus?
Wie kommuniziert das Frontend mit dem Backend? Und was kommt denn da, wenn wir eine Anfrage schicken?
Das muss klar sein. Alles andere kannst du eigentlich unabhängig voneinander entwickeln. Und wenn das nicht der Fall ist, dann stimmt was im Projekt nicht.
Das sollte möglich sein.
Ja, ich würde das auch sagen. Und ich würde auch sagen, also, es kommt natürlich so ein bisschen darauf an.

[53:07] Wie weit gediehen das gesamte Frontend als, sagen wir mal, als Framework oder Toolkit schon ist.
Aber irgendwann erreicht man einen Punkt, da kann man Dinge schon bauen und prototypen, ohne dass ein dediziertes Design dafür vorliegt, weil man in der Regel für viele Aufgabenstellungen ja schon Komponenten hat.
Und ich habe auch festgestellt, dass das auch so ein bisschen dazugehört, dass alle einen Blick auf was werfen können, um dann, Also, das ist dann eben so dieses weiße Blatt, was man nicht hat.
Also man sieht was, und es fällt ja dann den Leuten immer leichter, Gedanken dazu zu formen und das dann weiter zu spinnen.
Und natürlich wird das alles nochmal umgeworfen.

[53:56] Oder vielleicht auch nicht alles, aber es wird halt vieles umgeworfen.
Aber wenn man das einpreist, dann frustriert das halt auch nicht.
Also ich glaube, es ist immer dann frustrierend, wenn man Wenn man sich so vorstellt, es gibt kein Design, dann packe ich das jetzt an, ich baue da jetzt was, aber dann haben die das gefälligst auch so zu nehmen, wie ich das dahin baue.
Das funktioniert halt meistens nicht, weil man auch selber leider nicht so perfekt ist, dass man alles denkt.
Und dann gibt's ja auch eben die sozusagen, die das Domänenwissen, was man vielleicht nicht hat, wo dann jemand sagt, ja, aber das ist leider sehr, sehr wichtig für die Benutzer unserer Anwendung, dass dieses, diese Info an der Stelle steht oder der Gesetzgeber sagt, dass deswegen müssen wir das jetzt nochmal ändern.

[54:39] Genau und also wenn man das sozusagen schon antizipiert, dann finde ich das auch nicht so frustrierend, weil das hat dann irgendwie allen geholfen und man muss halt einfach dann mehrere Runden drehen, bis man ins Ziel kommt.
Und so ist das so ein bisschen so, dass so die Dinge, finde ich, sich aufeinander zubewegen und dann wie so zwei Tunnelbohrer oder eben dann mehrere Tunnelbohrer vielleicht auch, weil Design und Frontend und Backend und die Daten und dann irgendwann schnappt das ineinander und dann hat man was Gutes.

[55:17] Aber das ist ja eigentlich genau die Art und Weise, wie du eigentlich arbeiten möchtest.
Bisschen Pingpong hin und her und idealerweise setzen sich die Frontendler und die Backendler auch einfach mal an einen Tisch und überlegen, okay, wie machen wir das denn jetzt eigentlich?
Und dann kommt meistens doch was ganz Gutes dabei raus, erfahrungsgemäß.
Untertitel im Auftrag des ZDF für funk, 2017, Ich möchte jetzt auch kurz noch mal Mediatorin spielen für diese Abende sein, ne? Schepp, es gibt ... Vielleicht musst du mal zu mir kommen.
Das klappt auch manchmal ganz gut, dass du sagst, hier, das war jetzt technisch viel einfacher, oder das war noch nicht da, ich hab mir das überlegt, was sagst du dazu?
Ja, klar, das klappt. Vielleicht liegt's jetzt auch an mir, aber das klappt teilweise auch ganz gut und wird dann schon mal durchgenommen.
Das teilt meistens auch den Grund, wenn man sich schon länger kennt, oder was heißt nicht unbedingt sich jetzt persönlich, sondern die Arbeitsweise und so eine Art System von der Web-Applikation.
Jetzt mache ich natürlich die gleiche, ungefähr seit drei Jahren.
Das heißt, ich weiß schon, wir haben da doch immer einen Space zwischen dem Label des Input-Fields und diesem Asterix-Sternchen.

[56:18] Da muss doch ein Space hin. Da brauche ich doch jetzt nicht mehr ein Design-Review, dass mir jemand sagt, du hast den Space vergessen. Das weiß ich doch selber schon.
Ja gut, vielleicht muss man sich da ... Ja, und wir sind natürlich auch gut darin, als Frontend-Menschen, einfach weil wir ja sozusagen wir schreiben ja regelwerke also zss ist ja im grunde nichts anderes als ein regelwerk wenn das so auftaucht dann muss das immer so aussehen und dadurch merken wir ja auch schnell wenn du hast natürlich kein tail und.
Ich hab keinen Tailwind, das stimmt wohl.
Ähm, nee, aber ich finde, dass man dann irgendwann ein Gespür dafür hat, äh, zu sagen, so dieses Ding da, das muss doch eigentlich mit dieser Komponente abgefackelt werden.
Wir bauen doch jetzt nicht eine neue Komponente.
Also, das sind ja nur noch verschiedene so andere Dinge, die man in der Balance halten muss.
Also, vielleicht steckt da ja sehr viel gekapseltes Know-how schon in so einer Komponente drin, dass man eben vermeiden möchte, eine neue zu bauen.
Accessibility und irgendwelche Performance-Geschichten, die man da drin schon optimiert hat. Also darum sind wir auch immer bestrebt.

[57:24] Wiederverwertbare bauteile zu haben die die wir einsetzen können und ich glaube dass wir dann eben auch schnell erkennen wo man was wiederverwenden kann und in der regel also genau wenn wir nicht komplett geschmacksbefreit sind dann dann können wir da auch was gutes hinbauen aber ich glaube ich würde auch nicht ohne designer sein wollen Nee, ich auch nicht, das schaut ganz furchtbar bei mir aus.
Genau, man kann halt auch einfach dann auch Dinge durchspielen, das ist ja auch ganz schön, also dann kann man irgendwie screensharen und dann sagt man, guck mal, das ist jetzt sozusagen, wir können ja mal damit rumspielen und dann können wir diesen Teil mal auswechseln und den Teil und guck mal, was ist denn, wenn da hier so ein langer Text drin steht, wie würde das aussehen, oh, das ist jetzt schlecht, was macht man da?
So, man hat eine Diskussionsgrundlage, finde ich.

[58:12] Martin, du hast gerade gesagt, dann setzen sich ja hoffentlich auch mal alle an den Tisch und dann kommt ja schon irgendwas Gutes raus.
Eine Problematik, die ich hin und wieder beobachte, ist, wenn es entweder keinen Manager dafür gibt oder einfach keine so proaktive Person, die das von sich aus so macht.
Also da gibt es jetzt niemanden, der hat das schon mal für ein Meeting erstellt.
Und meiner Meinung nach hat es sehr wenig mit Remote versus nicht Remote zu tun, weil ich hab das in beiden Situationen erlebt, wo alle zusammen im Raum sitzen und nicht kommunizieren, oder wo alle zusammen remote sitzen und nicht kommunizieren.
Hat für mich gar nichts miteinander zu tun.
Hast du da Erfahrungen mit? Oder hast du da Tipps und Tricks, wo niemand anfängt, so ein Gespräch zu ... zu machen?
Also, da bin ich vielleicht jetzt ein schlechter Ansprechpartner, weil ich bin immer der, der ... Ja, ich hab das Problem auch.
Ich laber halt immer. Aber jetzt versuch ich, Tipps zu geben an Teams, wo es vielleicht dann nicht so läuft, aber was sage ich denn da?

[59:12] Also eigentlich sollte das Aufgabe entweder vom PO oder vom Scrum Master sein.
Wenn es das Team selber nicht macht, dann muss es jemand tun.
Aber ganz ehrlich, ich verstehe nicht, warum das Team das nicht tun sollte.
Weil das ist eigentlich ganz natürlich. Natürlich setzt du dich hin und überlegst dir, wie machen wir denn das jetzt?
Was ist denn jetzt die beste Lösung dafür? Ich habe da eine Idee, warum das manchmal nicht funktioniert.
Also ich will es auch zu persönlichen Charaktere, will ich da gar nicht mit reinbringen, sondern dieses, es gibt so viele durchgetaktete Meetings teilweise.

[59:42] Und dann hab ich schon das Gefühl, dass viele Personen denken, dass wir tatsächlich als Developer jetzt wirklich aus dem Meeting rausgehen und anfangen, einen Code zu schreiben.
Als ob das so die Realität immer wäre.
Und ich hab das manchmal auch so unterbewusst im Kopf. Und ich so, nee, das stimmt ja gar nicht.
Ich muss ja jetzt... Also, es gibt dann auch die Situation, wo ich dann irgendwie meinen Managern oder Produktmanagern sage, Moment mal, ich brauche jetzt noch ein Meeting.
Ich muss jetzt erst mal mit XY quatschen, wie wir das überhaupt machen wollen.
Erst dann kann ich dir sagen, was möglich ist. Das weiß ich gar nicht.
Dann seh ich manchmal, ihr müsst da noch reden. Ich so, ja klar, müssen wir da noch miteinander sprechen.
Das hab ich schon ganz oft erlebt, dass es so ist. Wir haben doch nur diese zwei Meetings am Tag, wo ist das Problem?
Die letzten sechs Stunden kamst du zu Coden, die so, nee, Kai, nicht. Ich muss mich mit diesem Problem beschäftigen.

[1:00:33] Jeder denkt immer, Softwareentwicklung ist Coden. Coden ist eigentlich nur ein kleiner Teil davon.
Und deswegen wundere ich mich auch immer, wenn ich diese Kommentare überall lese, JetGPT wird alle Entwickler in den nächsten zwei Jahren ersetzen, sehe ich nicht wirklich, weil erstens kann JetGPT nicht wirklich gut coden und zweitens ist Coden halt nicht Softwareentwicklung. Da gehört noch eine ganze Menge mehr dazu.
Auch Kommunikation zwischen Teammitgliedern und Entwicklern.

[1:01:00] Wichtiger Punkt. Ja. Apropos Kommunikation, eine deiner Stichpunkte hier ist, dass du sagst, Entwickler sollten die Sprache vom Fachbereich sprechen.
Und also die sollten sich an den Fachbereich anpassen und nicht die anderen an die Entwickler.
Ja, da ecke ich häufig an mit dieser Meinung. Aber ich stehe dazu.
Also meiner Ansicht nach ist es immer so, dass der Fachbereich im Prinzip der Auftraggeber für die IT ist.
Oft sind die Strukturen in den Konzernen und in den Unternehmen anders aufgestellt, aber im Endeffekt ist es meistens so, der Fachbereich beauftragt die IT.
Und dann solltest du als Entwickler eigentlich auch so fair sein und die Sprache vom Fachbereich sprechen.
Das hat zunächst mal die Vorteile, dass du natürlich dich mit denen unterhalten kannst.
Du kannst die Requirements in der Sprache vom Fachbereich diskutieren, was schon mal jede Menge Probleme einfach aus der Welt schafft, die du normalerweise hast.
Denn oft ist es so, Entwickler bauen was, weil sie glauben, sie haben es verstanden.

[1:02:06] Im Endeffekt ist es aber vielleicht gar nicht so. Vielleicht haben sie sich gar nicht verstanden, weil die sprechen einfach nicht die gleiche Sprache.
Ich meine, da gibt es ja sehr viele Konzepte, die da drauf eingehen, Domain-driven Design und alles.
Aber im Prinzip ist es einfach so, lernt euch doch mal kennt, redet mal miteinander und lernt mal, wie ihr miteinander spricht.
Ein schönes Beispiel ist, ich war mal in einem Projekt, da sind wir in einen Call-Center gegangen, zum Fachbereich und haben geschaut, okay, wie arbeiten die da eigentlich? Was machen die da eigentlich?
Wie funktioniert denn das da? Und das ist unglaublich, was man dabei lernt.

[1:02:38] Ja, das ist, finde ich auch immer gut, wenn Firmen das machen.
Also ich hatte das auch mal bei von Picnic gehört. Also wenn man da anfängt als Software-Entwicklerinnen.

[1:02:48] Oder Entwickler, dann geht man auf Tour auch erstmal mit den Picknickfahrern und liefert aus, um einfach so ein Gefühl dafür zu kriegen, was sind deren Herausforderungen, wie läuft das ab, also für wen baue ich den Kram dann später.
Das finde ich wirklich toll. Ja. Finde ich fantastisch. Interessant wäre mal die Gegenseite, einen vom Fachbereich mal einen Tag lang in die Entwicklermeetings zu schicken.
Ob das denen auch so viel Spaß machen würde, ich weiß es nicht.
Untertitel im Auftrag des ZDF für funk, 2017, Ja, weiß ich nicht, also mutmaßlich schon.
Also es gibt tatsächlich auch Firmen, wo wirklich dann rotiert wird durch Abteilungen, also bewusst.
Und dann kommt eben jeder auch mal in der IT-Abteilung vorbei.
Also, finde ich grundsätzlich nicht verkehrt.
Also, ich finde, dann hat man auch einfach ein anderes, man sieht auch die anderen Abteilungen anders.
Also, das ist dann eben auch weniger von die und wir, sondern wir alle halt.

[1:03:50] Was ich ganz gern mache, wenn ich in neue Projekte komme, ist, ich bin meistens der Erste, der sofort anfängt, ein Glossar zu machen von Fachbegriffen.
Und ich schicke das auch regelmäßig, also, ich picke mir immer gleich so zwei, drei Leute vom Fachbereich raus, wo ich merke, okay, die reden gern mit mir, und denen schicke ich auch regelmäßig dieses Glossar und frage, kannst du mal kurz drüber schauen, stimmt das eigentlich alles?
Auch da kann man sehr, sehr viel lernen.
Das ist am Ende aber natürlich was, das braucht Zeit.
Also, ich finde, es ist halt ganz schwierig, Also man kann einfach nicht irgendwo reinkommen und dann relativ zügig.

[1:04:26] Gute maßgeschneiderte Software abliefern. Was halt hilft, ist, wenn in der IT Leute sitzen, die vielleicht schon lange im Betrieb sind, die kennen, das sind dann sozusagen immer die Orakel, die dann vielleicht auch immer sagen so, ja, da ist ja dann, ich weiß, wie die arbeiten, die brauchen das so und so.
Das ist immer hilfreich zu jemandem zu haben, aber ansonsten braucht es halt wirklich einfach Zeit und genauso auch für die anderen, um zu verstehen, wie halt die eigene IT-Abteilung denkt und arbeitet und warum die Dinge in Anführungszeichen auf seltsame Art und Weise anpackt.

[1:05:11] So, ich war auch mal bei einer Firma, wo ich dann erstmal quasi zu der Produktionsstelle noch hin bin und fand das da auch super interessant, habe dadurch jetzt aber auch gerade noch durch dieses Gespräch noch einen anderen Gedanken.
Ihr kennt das vielleicht, dass man manchmal für Dinge gelobt wird, die man entweder nur unterbewusst macht oder die einem selber gar nicht so viel bedeuten oder die einem selber gar nicht so viel Arbeit machen.
Während man für andere Sachen, auf die man eher stolz ist, so keiner sagt was dazu, na ja, gut, auch gut.
Aber eine Sache, die bei mir gelobt wird, die ich manchmal verwirrend finde, ist dieses, du denkst mehr als nur ein Entwickler, Entwicklerin.
Wo ich mich auch immer frage, was ich weiß eigentlich auch gar nicht, was dieser Satz heißt, da muss ich da mal was reininterpretieren.

[1:05:58] Es ist jetzt so, ich habe mich nicht für jedes Produkt interessiert, für das ich Code geschrieben habe.
Ich habe mich aber immer für den Code interessiert, den ich da geschrieben habe.
Aber was ich mache, ich schaue immer mit so zwei Blickwinkeln auf diese eine Sache und je nachdem, mit wem ich auch darüber gerade kommuniziere.
Das heißt, ich erzähle jetzt vielleicht beim Daily, wenn da jetzt gerade eher nur PO-Wild abhaken, wie das so der Zustand ist, erzähle ich jetzt nicht irgendwie von jedem tollen Algorithmus und Ähnliches, sondern da kehre ich so ein bisschen meine User-Ansicht zurück.
Und das mache ich auch bei Demos oder Reviews. Wenn ich weiß, ich mache in eineinhalb Wochen eine Demo über was, dann überlege ich mir nicht zehn Minuten vorher, was sage ich da eigentlich, sondern während ich diese Sache entwickle und schreibe das bei mir selber mit auf.
Du, wenn du das demust, denk unbedingt dran, dass du das und das zeigen wolltest, weil du glaubst, dass das aus User-Sicht wichtig ist.
Ich möchte jetzt diese Entwickler-Challenges nicht kleinreden.
Die kann man auch gerne, je nach Demo, wie das da abläuft, zeigen.
Man kann gerne mal das Network-Tab öffnen und sagen, du guck mal, ich hab sogar den Fall behandelt, wenn der Request abgebrochen wird, dass dann das und das und das passiert.
Ähm, aber bei jeder Demo, und jedes Mal, auch wenn ich mit diversen Personen dann spreche, spreche ich immer aus einer Art User-Sicht.

[1:07:16] Und was mir tatsächlich bei anderen Entwicklerinnen und Entwicklern aufgefallen ist, Es geht mir nicht darum, ob man sich für das Produkt generell interessiert oder nicht.
Aber manchmal war diese Benutzung so komplett weg von dieser Person.
Und wo ich dann teilweise gefragt habe, hast du dich eigentlich mal hingesetzt mit deinem Handy und hast mal dieses Produkt durchprobiert?
Ja, nee. Wie, nee?
Du musst doch wissen, wie sich das anfühlt. Ganz egal, ob du es jetzt am Ende kaufen wollen würdest oder nicht, aber du musst doch schon mal dieses Feeling haben.
Und ich denke, es hilft mir dann auch, die Prioritäten zu machen.
Diese Entscheidungen kommen ja nicht von ungefähr. Aber ich weiß einfach, was wäre der Fehler, der mich jetzt im Diesel-Flow auch meistens stören würde.
Also mache ich den zuerst oder lege da ein bisschen mehr Wert drauf, als vielleicht irgendwo in dem kleinen Text da jetzt irgendein Typo oder ähnliches zu fixen.
Schaut ihr denn auch auf eure Produkte? Habt ihr da auch so zwei Sichten drauf?
Einmal so Entwicklersicht und einmal so, wie würden es echte Personen benutzen?
Auf jeden Fall. Also das finde ich extrem wichtig und das gilt auch nicht nur fürs Frontend, das gilt auch für die Backend-Entwicklung.

[1:08:32] Also auch wenn du nur im Backend arbeitest, solltest du wissen, was passiert eigentlich mit den Daten, die ich da über meine API mit nach vorne gebe.
Also, ich weiß nicht, also mich interessiert das auch persönlich.
Mich interessiert einfach persönlich, was bauen wir da eigentlich und was machen wir da eigentlich.
Das sorgt auch insgesamt einfach für, ich glaube, für bessere Software, wenn jeder das im Blick hat.
Ich glaube, das ist so ein bisschen das Thema Empathie, also so sich in die Verbraucher des eigenen Werkes hineinversetzen und so schauen, wie würden die sich fühlen, wenn sie das, was ich jetzt da fabriziert habe, benutzen.
Im Backend ist das ja vielleicht auch einfach so eine Library oder eine Schnittstelle, wie ist so die Developer Experience, also frustriert die?
Oder ist sie schlüssig oder nicht?
Und werde ich sie hassen bei der Benutzung oder werde ich sie lieben?
Genau, und im Frontend ist es dann eben vielleicht das UI.

[1:09:33] Aber ich finde, das kann halt ... Also, da hat nicht jeder ein Händchen für.
Ich finde, das ist halt auch schwer zu lernen.
Ich hab so das Gefühl, so empathisch zu sein, ist so leicht gesagt, aber das ist so ein Ding, das muss so ein bisschen Klick machen.
Also da muss so der Groschen irgendwie fallen und man auf einmal das so vor sich sehen, hab ich das Gefühl.
Wobei ich, also Empathie find ich ein super wichtiges Stichwort, weil ich glaub, eine der wichtigsten Eigenschaften, die ein guter Softwareentwickler haben sollte, ist Empathie. Was bedeutet das?
Du solltest dich auch, wenn du Code schreibst, ständig überlegen, wie fühlt sich eigentlich der, der nach mir kommt und diesen Code sieht, der diesen Code warten muss, ist das, was ich mache, eigentlich gerade das Richtige?
Oder ist es vielleicht das völlig Falsche?
Also empathisch zu sein, macht dich zu einem besseren Softwareentwickler.
Da bin ich fest davon überzeugt.
Allerdings weiß ich jetzt auch gar nicht.

[1:10:34] Wie ... Wie schwer das ist, will ich jetzt gar nicht sagen. Aber ich glaub, die Hürde ist jetzt gar nicht so groß.
Also, man muss ja natürlich nicht sofort die besten Ideen haben, zu sagen, ach, ich hab jetzt noch die drei Ideen, und deswegen hab ich die Prioritäten so gemacht.

[1:10:49] Wahrscheinlich sind viele meiner Entscheidungen auch ein bisschen falsch und sehr biased, weil nur ich geh halt diesen Weg so, und der ist dann golden optimiert, und wenn du einen anderen Weg gehst, ist es ja blutgelaufen.
Aber ich sag's ja, deswegen hab ich am Anfang gemeint, dass ich dafür oft gelobt wäre, obwohl es mir so klein vorkommt.
Deswegen mein ich, wenn ich allein eine kleine Idee habe, freuen sich schon alle anderen und sagen, ach, du denkst ja auch mit.
Wo ich mir denke, das klingt immer so komisch, als würde ein Entwickler nicht denken.
Aber anscheinend kommt es immer so ganz, ganz gut an.

[1:11:18] Und ich denke schon, und da braucht man nicht so viel dafür, dass wenn man dreimal das eigene Produkt so ein bisschen durchgespielt hat, dann wird man sicherlich zwei Punkte allein nennen können, wo man denkt, ach, das hätte ich gern verbessert oder hier hätte ich eine kleine Idee und die kann ich weiter kommunizieren.
Ob das dann jeweils mal umgesetzt wird, ist egal.
Aber ich habe schon das Gefühl, damit kann man sie auch einfach gut dastehen lassen, wenn man es mal so ausdrücken will, dass sich gerade POs, Designer immer so total darüber freuen über diese kleinen Anmerkungen.
Und ich kann das für mich auch übersetzen und für mich macht das auch Sinn, weil wenn ich im Code das Feedback von fünf Personen bekommen und drei Personen sagen, die eine Funktion, die fand ich sehr schwer zu benutzen, und zu anderen zwei Sachen sagt niemand was, dann weiß ich, ach, das ist total hilfreich jetzt für mich.
Also, wenn ich jetzt mal wieder TechDev einplane, dann lass uns doch zuerst mal diese Funktion anschauen.
Da hat sich weder jemand beschwert, noch hat jemand ein halbstündiges Meeting mit mir eingesetzt.
Da kam eine Slack-Nachricht und so nach dem Motto, die Funktion war ein bisschen komisch, oder? Geht's dir auch so? Dieser kleine Satz kann irre viel wert sein.

[1:12:25] Da muss ich auch keine Designkenntnisse haben, ob der Button links oder rechts war, dann kann von mir aus dann jemand sagen, nein, aus diesen psychologischen Gründen ist das sehr wichtig.
Oder hey, nicht vergessen, es gibt Personen, die kommen da mit ihren Händen nicht hin, deswegen aus diesem Grund haben wir das so eingestellt.
Dann kann das auch jemand erklären, dann akzeptiert das ja normalerweise auch dann jeder.
Ja und ich finde es halt auch gut als entwicklerinnen und entwickler angebote zu machen und darauf hinzuweisen was könnte man tun weil oft ja auch gar nicht klar ist was möglich ist also das ist ja dann auch manchmal so ein bisschen so ein.
Also dann geben sich geben sich die anderen auch alle mühe irgendwie sich so in in unser mindset hinein zu denken aber.
Aber das fällt denen halt dann manchmal schwer oder sie denken zu kompliziert oder denken manchmal eben auch Dinge gehen nicht und dann sagt man denen ja guck mal hier wir können könnten auch sowas bauen. Ach echt es geht ja super geil.
Ja und dann wissen sie das auch für das nächste mal und denken daran dass sowas möglich ist. Ich würde einmal gerne noch nachhaken, so richtig nachstochern, weil es ja heute so Real-Podcast und so, zum Thema dieser Context-Switches.
Und jetzt nicht einfach nur bla bla, Context-Switches sind blöd, aber dennoch, ähm, wenn ich jetzt ein Meeting hab, und das geht bis um 11.20, Uhr, und dann hab ich ein Meeting um 11.30 Uhr.

[1:13:53] Was kann ich denn tun? Ich kann doch bestimmt irgendwas tun, um diese 10 Minuten sinnvoll zu verbringen. Und vielleicht bin ich jetzt hier so ein Generation-X-Kind und mach da halt einfach meine fünf E-Mails, noch einen Kaffee und mach noch ... Keine Ahnung, was noch daneben.
Ähm, aber denkt ihr wirklich, dass diese zehn Minuten so schlimm sind, dass man gar nix machen kann?
Oder liegt tatsächlich irgendwas in meiner Macht, damit diese Context-Switch, nicht so schlimm wird? Und ist es überhaupt eigentlich ein Context-Switch?
Bleiben wir mal kurz beim Thema. Ich glaub, das ist eigentlich gar kein Context-Switch.
Aber dann mach mal das zuerst und das andere danach. Also wie verbringe ich 10 Minuten zwischen zwei Meetings am sinnvollsten?
Also ich schreibe Meeting-Notes. Ich schreibe zu jedem Meeting-Notes und schreibe, mir auf, was wir in dem Meeting gemacht haben.
Entweder nur für mich oder für alle, aber die 10 Minuten sind perfekt geeignet für Meeting-Notes.
Wenn du Meeting-Notes machst und du hast nichts reinzuschreiben und es ist kein Outcome da, dann war es ein super schlechtes Meeting.
Dann solltest du das nächste Mal überlegen, ob du da überhaupt reingehst.
Ich habe das im letzten Projekt gelernt, die Zwei-Füße-Regel.

[1:15:02] Zwei-Füße-Regel? Die Zwei-Füße-Regel. Wenn du in einem Meeting bist und du merkst, es bringt dir nichts und du kannst nichts beitragen, darfst du gehen.
Also ja. Jederzeit. Ja, aber das muss man erst mal merken. Das ist nämlich gar nicht so einfach, das, was du gerade sagst.
Also ich habe das auch mal. Das heißt bei uns auch, wir arbeiten ja alle in guten Fällen. Wenn du nichts beitragen kannst, dann geh einfach.
Aber Aber das musst du ja auch wirklich wissen, ob du gar nichts beitragen kannst, weil manchmal sind auch nur Sachen mit anzuhören, können ja wichtig werden.
Aber wenn du es danach versuchst aufzuschreiben, was war jetzt wichtig? Gute Technik.

[1:15:30] Also, ich kann das nur empfehlen, das bringt wirklich viel, sich nochmal Gedanken zu machen.
Und außerdem hast du dann, oder ich hab dann eine Notiz in meiner Wissensdatenbank fürs nächste Mal.
Chep, was machst du zwischen zwei Meetings? Man kann Tickets schreiben, vielleicht zu Themen, die man da besprochen hat, aber vielleicht ist es auch einfach, kann man einfach mal fünf Minuten die Augen zumachen.
Bisschen entspannen, bevor es dann wieder weitergeht, das hilft ja auch.
Also ich bin ja auch ein großer Power-Nap-Fan, generell.

[1:16:04] Also ich muss die nicht machen, aber ich finde die, also wenn ich die machen kann, finde ich die auch super.
Genau, das geht ja dann auch so ein bisschen in die Richtung.
Schaffst du ein Powernap in 10 Minuten?
Ja, genau. Also Powernap ist ja eigentlich immer so, dass man, wenn der Wecker klingelt, denkt, Mist, ich war im Begriff einzuschlafen.
Aber und dann ist aber genau richtig. Also so muss das sein.
Und ich habe, glaube ich, entweder gestern oder heute noch gelesen, dass das tatsächlich wissenschaftlich auch erwiesen ist, dass nur sozusagen das Vorhaben, sich hinzulegen und zu schlafen, auch wenn man es dann, wenn man dann eben nicht einschläft, schon total viel einbringt.
Und so empfinde ich das auch.
Spannend. Das dürfen wir jetzt alle gerne mal anonym ... Ich weiß nicht, wie man anonym schreibt. In Frage stellen.
Nee, anonym schreiben, falls dann doch ... Ob wir tatsächlich hier bei den Hörerschaften jemanden haben, der schnell runter zur Waschmaschine rennt und die Waschmaschine macht.
Ich hab gehört, das macht man als Millennial zumindest so.
Ach so. Na ja, gut, warum nicht? Geht auch, klar.
Ich finde auch, dann kommt man mal kurz aus den ganzen Themen raus, lüftet aus. Also es ist ja auch so, also früher, vor langer Zeit habe ich geraucht und da waren diese Zigarettenhausen. Oh Gott, hören deine Eltern zu?

[1:17:24] Scherz, sorry. Wahrscheinlich nicht, genau. Aber da war auch immer das Erstaunliche, dass einem da immer die brillantesten Ideen gekommen sind in diesen fünf bis zehn Minuten, wo man eben einfach sich eigentlich gar nicht mit der Thematik beschäftigt hat, aber ...
Nee, ich kann das aus dem Grund nicht, weil da kommt das Overthinking wieder ins Spiel. Dann sind mir das zu viele Tasks.
Wenn ich die Waschmaschine mach, hab ich im Kopf, dass ich das in den Trockner tun muss. Dann stört mich das die ganze Zeit so, dass ich tatsächlich auch mit Homeoffice bin.
Ich mach alles, mein Samstag ist einfach kaputt. Ich mach am Samstag die ganze Hausarbeit, aber ich funktionier damit besser.
Okay, du brauchst echt mal hier was, wo du dir deine Tasts aufschreibst, damit du die aus deinem Kopf sozusagen verbannen kannst. Ja, ich hab sogar übrigens sehr zu empfehlen, Laundry-Fi-App.
Das heißt, da ist eine Steckdose mit Wi-Fi am Wäsche-, Waschmaschine und Trockner und die schicken uns dann quasi Notification, wenn der Strom ausgegangen ist, weil die Maschine fertig ist. Ja, das ist ja auch clever. High-Tech.
Ja, vielleicht soll ich dazu sagen, dass der Trockner kaputt ist und der meldet sich alle 10 Minuten, dass er neu gestartet werden will. Der maximiert dieses Problem.
Gut, wir hatten noch gerade Context Switches gesagt. Kann mal einer kurz erklären, was tatsächlich ein Context Switch ist und wie der passiert?

[1:18:46] Also bei mir ist ein Kontext-Switch immer dann, wenn ich arbeite, fokussiert arbeite in meiner Bitte-nicht-stören-Zone, und jemand kommt von hinten und klopft mir auf die Schulter und reißt mich aus dieser Zone raus aus irgendeinem Grund.

[1:19:00] Was macht man jetzt? Also was passiert, ist es wirklich so? Ich meine, gut, ich brauche jetzt nicht fragen, weil ich glaube, da gibt es tatsächlich Studien drüber, wie, keine Ahnung, 23 Minuten dauert es, wieder zurückzukommen.
Ist es so? Ist es so schlimm? Du, also ich habe da auch kürzlich einen LinkedIn-Post, drüber geschrieben, weil ich das wirklich wichtig finde.
Die Kontext-Switches, die gehen nicht weg. Die gehören einfach zum Projekt.
Du kriegst die nicht weg. Es ist einfach so.
Das Einzige, was du machen kannst, ist, du kannst es halt, den Weg zurück in deine fokussierte Arbeit kannst du kürzer machen. Wie machst du das?
Ich schreibe mir grundsätzlich auf, wenn ich irgendwo rausgerissen werde, okay, wo bin ich gerade?
Wo, was ist mein Kontext? Steht dann zwei Sätze da. Wenn ich zurückkomme, muss ich nicht überlegen.
Ich weiß sofort, okay, ich bin genau da und ich muss genau da weitermachen.
Oder was ich auch ganz gerne mache, ist, wenn ich gerade mitten in der Implementierung bin, ich schreibe einen Test, der fehlschlägt.
Und wenn ich zurückkomme, sehe ich genau, okay, dieser Test ist rot.
Da ist eine Beschreibung drin. Der Test ist deswegen rot. Ah, klar, ich war genau da an der Stelle. Ich kann sofort weitermachen.
Also viele versuchen immer, die Kontext-Switches zu vermeiden, Aber das ist, glaube ich, der falsche Weg. Die gehen nicht weg, egal, was du tust.

[1:20:11] Schepp, hast du bestimmte Tipps und Tricks?
Ja, also im Grunde, so wie Martin sagt, also irgendwie festhalten, wo man zuletzt war, also was sozusagen offen ist, damit man da weitermachen kann.
Ich versuche die entweder kurz zu halten innerhalb des Tages oder dann eben dann die Arbeit daran, ganz sein zu lassen und dann eben am nächsten Tag irgendwie das wieder aufzugreifen.
Wenn die Pause kurz ist, dann muss ich mir nichts notieren. Dann ist es nicht nötig.
Aber wenn ich halt merke, dass das wird nix mehr, dann wird das eben auch schnell irgendwie niedergeschrieben.
Und ansonsten, ja, Context Switches sind ja, man sagt ja irgendwie, dass man so 20 Minuten braucht, um so gedanklich wieder in den Flow zu kommen, so Pi mal Daumen.

[1:21:02] Und Content-Switches sind darum sehr, sehr unpraktisch, weil sie halt jedes Mal diese 20 Minuten verschwenden, oder vielleicht auch 15 oder sowas.
Vielleicht ist es so ein bisschen wie, wenn halt dann so auch, fühlt man sich danach auch so wie so, wenn der Film im Kino zu Ende ist und das Licht angeht, dann ist man ja auch erst mal so ein bisschen so, kommt man da aus seinem Fluss raus, indem man da zwei Stunden saß, genau, um dann wieder klarzukommen. Das braucht halt eine Weile.
Ja, ich kann euch natürlich auch nur zustimmen. Wie gesagt, ich frag mich ja auch selber, was kann ich jetzt mit der Situation machen?
Ich kann ja nichts verhindern, dass mich ... Also, keine Ahnung, ich kann das Internet ausmachen und die Tür zusperren, ist jetzt vielleicht auch schwierig im Arbeitsalltag.
Aber was kann ich machen, um so eine Situation besser zu machen?
Eins davon hängt damit zusammen, was ich vorher schon meinte, von deployable state zu deployable state zu kommen.
Ich versuche sogar schon, die Situation zu vermeiden, dass ich überhaupt sehr viele Sachen mir jetzt schnell notieren muss, um zu wissen, woran arbeite ich eigentlich gerade.

[1:22:11] Und da versuche ich eigentlich das, was ich alles in meinem Alltag und Freizeit nicht mehr auf die Reihe kriege, so strukturiert meinen Takt da zu machen, mache ich auf der Arbeit auch immer sehr genau tatsächlich.
Also ich mache eine Sache fertig oder ich weiß, ich kann diese Sache jetzt noch nicht fertig machen, weil der Trockner braucht halt noch zwei Stunden.
Also notiere ich, der Trockner läuft gerade, du kannst gerade nichts dran tun, warte mal, bis Backend fertig ist und dann musst du hier noch, du wolltest noch die zwei APIs machen.
Da habe ich das da hingeschrieben, dann weiß ich das, dann kann ich jetzt zum nächsten Thema gehen.
Das heißt, wenn da ein Context Switch passiert, also wenn ich unterbrochen werde, dann werde ich zumindest nur von der Kleinigkeit unterbrochen.
Viel schlimmer fände ich es jetzt, wenn ich, ich soll eine ganze Tabelle bauen und ich habe für alle zehn Spalten noch nicht die und für 5 habe ich noch nicht die richtigen Icons.
Aber ich lege ja trotzdem schon mal alle 10 an und weiß dann gar nicht mehr, waren das eigentlich gemockte Daten?
Geht das eigentlich schon? Habe ich das schon mit echten Daten getestet?
Ist das eigentlich schon das richtige Icon?
Das ist unfassbar anstrengend, im Nachhinein wieder zu rekonstruieren, was geht davon eigentlich schon und was geht nicht.
Und da ist es auch sehr simpel mit, ich habe so einen Stift, so einen Bleistift und so ein Blatt Papier.
Und da habe ich dann so ein Format wie, ist schon fertig, musste später noch mal und musste so, da habe ich noch gar nicht angefangen.

[1:23:30] Aber da hilft es ja auch einfach nicht so viele Fäden gleichzeitig aufzugreifen also dieses wirklich so auch wenn es einen juckt in den Fingern also ich kenne das auch man will ja schon man hat bock so cool da jetzt auch Lust auf nee einfach auf die Finger hauen.

[1:23:48] Ja machen wir aber jetzt das eine das mache ich jetzt erstmal noch zu ende weil sonst komme ich in teufels küche und ich finde halt auch dieses pull prinzip also dass man das andere leute sozusagen ihre bedürfnisse. nicht einem aufobtruieren können.
Also die machen das ja jetzt nicht irgendwie aus Böswilligkeit, sondern weil die ja auch gar nicht gerade sehen, was woran man sitzt, was man macht.
Die schicken dann einfach ihr oder die schreiben ihr Ticket, schicken dir eine Nachricht oder was auch immer.
Und ich bin dann, ich mach, guck lieber nach, dann wenn ich eben mit irgendwas fertig bin. So was hat sich getan?
Gibt's irgendwie hier was Neues und dann, wenn's nix gibt, dann nehm ich halt das nächste Thema.
Und eventuell seh ich dann aber, okay, hier, ähm ...
Braucht's irgendwie meine Hilfe oder so. Aber das andere hab ich halt dann fertig.
Wahrscheinlich fängt's für mir sogar noch viel früher an, um solche Gefahren zu vermeiden, indem ich mir auch einen Task strukturiere, in was ist so ein risikomäßiges an dem Task, und was wird einfach Standard, schön, nett und drunter zu schreiben.
Persönlich würde ich sehr gerne auf all die Sachen springen, die am meisten Spaß machen werden, und wo ich jetzt schon weiß, was zu tun gibt und wo ich mit niemandem reden muss.
Wunderschön wär das. Aber man lernt nach ein paar Jahren, das tut am Ende immer sehr weh.
Und dann will man das so jetzt ... Hard-Choice, Easy-Life-Dinges mäßig.

[1:25:16] Macht man vielleicht doch die harten Sachen zuerst.
Was heißt harte Sachen? Die Arbeiter in das Vergnügen, das weißt du ja.
Ich überleg mir, wo wir jetzt am meisten Kommunikation generell brauchen, wo vielleicht dann auch Zeiten dazwischen sind. Also, ähm ...
Im Design weiß man noch nicht, ob man mit dem oder mit dem gehen möchte. Oder wie man dann ...
Da gibt's noch was Offenes zu besprechen. Also schau ich mir das gleich an.
Dann kann ich gleich sagen, du, das ist ungefähr so kompliziert, das so kompliziert, überlegt euch mal, was wär das jetzt mehr wert.
Oder ich schau gleich schon mal nach, was sind überhaupt Möglichkeiten.
Weil oft ist es ja auch, wenn du an dem Punkt dran bist, mal kurz, was könnten wir technisch umsetzen?
Das versuche ich immer am Anfang zu machen. Oder genau, ich weiß, hier wird eine Backend-Kommunikation notwendig.
Ich schaue mir das zuerst an. Ich finde es manchmal ein bisschen unfair, aber manchmal ist es sehr oft die Realität, dass ich im Frontend immer Bescheid sagen muss, welche Daten brauche ich denn eigentlich von Backend.
Können ja alle auf Figma, können ja alle gucken. Ähm, aber meistens ist dann doch so, ich muss dann Bescheid sagen.
Oder ich sag halt von Anfang an, hey, guck noch mal, lass uns doch mal zusammen über Figma drüberschauen, welche Daten wir alle brauchen werden.
Dann ist das so ein Zehn-Minuten-Huddle.

[1:26:29] Dann haben wir alle geklärt. Und dann kann ich meine ganzen lustigen Sachen machen.
Und es ist wirklich viel angenehmer, wenn diese Sachen am Anfang geklärt sind.
Weil dann ist der ganze andere Kladderradat auch schon weg. Ähm, und dann, ja, es kommt halt nicht zu dieser Situation, dass jetzt nur diese Kleinigkeiten, die vielleicht auch sehr zeitintensiv waren, aber für das Feature nur mal Kleinigkeiten waren, fertig sind und wunderschön implementiert worden sind.
Aber es soll in zwei Tagen live gehen, und der Button funktioniert nicht, weil der Server in 500 zurückläuft. Und dann passiert Stress.

[1:27:03] Oder dann passiert ein Context-Switch, während ich hier meine fünf Baustellen jetzt offen hab, und dann komm ich halt nicht mehr klar. Ja, also für mich ist auch so ein Tipp so immer die, ich nenn's die risky Sachen, das ist jetzt kein Framework, das hab ich mir selber so ausgedacht, also, keine Ahnung.
Die versuch ich zuerst wegzuarbeiten und dann, ja, und dann das Vergnügen, dass ich meinen Border-Radius von vier Pixel auf acht Pixel erhöhe.
Wobei das meistens auch nicht nur die risky Sachen sind, sondern das sind auch ganz, ganz oft die Sachen, die einfach keiner machen will, die man einfach als Erstes machen muss.
Das ist auch oft so, ich glaub, du bist auch wahrscheinlich jemand, der einfach diese Sachen dann einfach in Angriff nimmt, weil es halt niemand anders machen möchte. Ja, natürlich.
Und irgendeiner muss es halt machen, aber das sind oft die Sachen, die einfach ganz, ganz wichtig sind. Und einer muss es halt machen.
Ich mache das auch ganz gern.
Damit kann man sich wahrscheinlich dann aber auch sehr beliebt machen generell.
Also speziell als Externer ist das natürlich nicht unpraktisch.

[1:28:01] Aber es ist ja auch ein schönes Gefühl, wenn man so ein Ding dann fertig hat.
Auf jeden Fall. Wenn das, wenn das eine schwierige Geschichte war und man es endlich erledigt, dann kann man irgendwie auch unbeschwerter die, die schönen Teile angehen, weil man eben weiß, da lauert eben nicht noch irgendwie so ein dreckiges Ticket irgendwo.
Aber auch da habe ich das Gefühl, dass man da sozusagen unverhältnismäßig viel Lob oder Danke bekommt.
Weil vielleicht war diese Sache ein bisschen unangenehm, ein bisschen nervig.
Das kann jetzt auch für jede Person was ganz unterschiedliches sein.
Aber ich mache es halt dann auch einfach.
Und dann war das vielleicht 20 Minuten lang ein bisschen nervig.
Aber dann sind fünf Leute auf einmal ganz happy und dann freue ich mich auch mit.
Versus, keine Ahnung, ich arbeite an irgendwas, was mir Spaß macht, für acht Stunden. Und dann wird es so weitergenickt wie, ja, was ist an dem Button jetzt so toll?
Haben ja schon 5.000 andere Leute Buttons gemacht. Ja, aber der war schwer.

[1:29:03] So.
Schöpfe mich wär's, ich hab jetzt durch. Okay, ich wollte jetzt nicht zumachen.
Ich hab's gemerkt, du hast gewartet, ob ich noch weiter in meinem blauen Wasserfall bin.
Auf jeden Fall vielen Dank, Martin, für deinen Besuch heute bei uns.
Sehr gerne. Ich muss gestehen, ich war ein bisschen nervös, weil das ja eigentlich ein Frontend-Podcast ist, und ich bin jetzt aus der Frontend-Welt doch schon eine Zeit raus.
Deswegen war ich ein bisschen nervös, aber mir hat es sehr, sehr viel Spaß gemacht.
Vielen Dank für die Einladung.
Ja, super. Ja, uns auch. Genau.
Und du hast gesagt, du bist ja auch Trainer. Also, wenn man dich jetzt hier gehört hat und denkt, Mensch, ich glaube, ich würde gerne einfach noch ein bisschen mehr vom Martin hören und sehen.

[1:29:55] Genau, also du machst Trainings im Bereich – sag nochmal schnell zum Abschluss.
Genau, also Trainings im Bereich IT.
Ich mach Git-Trainings, ich mach Kafka-Trainings und insgesamt einfach rund, um Entwicklung, Kotlin, Java, das ist alles mit dem Angebot.
Wer daran interessiert ist, darf sich natürlich gerne melden.
Am besten einfach über LinkedIn einfach kurz anschreiben.
Ja, wunderbar. Und dort kann man dir auch folgen und du postest da offenbar regelmäßig.
Tatsächlich tue ich das, ja. Ein Highlight.
Ja, super. Werd ich auch gleich im Anschluss noch machen.
Schön, freut mich. Vielen Dank auch an Vanessa, die ja hier dich eingeladen hat, den Kontakt hergestellt hat sozusagen.
Und auch für den Input.
Genau, und an unsere Hörer, vielen Dank fürs Zuhören. Wenn ihr irgendwie Feedback habt, dann wisst ihr, wo ihr uns findet.
Und den Martin ja auch auf LinkedIn. Und dann sehen wir uns nächste Woche wieder.
Bis dahin, macht's gut. Tschüss. Tschüss. Tschüss!

[1:30:57] Music.