Secrets Not Included: pair programming

Willkommen zu einer neuen Folge Secrets Not Included. Wieder Daniel und Ole hier. Und in dieser Woche, in der siebten Folge übrigens, sprechen wir über Pair-Programming. Ja Daniel, dann Bühne frei. Was hältst du denn davon?

Ja, das ist ein super schönes Tool, um Wissen zu verteilen. Also ich habe es oft in Projekten mitbekommen, dass gerade jüngere oder neuere Entwickler sehr viel Angst davor haben, weil es dann immer so gefühlt die Hose runterlassen ist. Also mit, guck mal, das habe ich gebaut und man bekommt Kritik. Warum hast du das gemacht? Warum ist das so? Und ja, Und das ist halt immer so ein bisschen, man ist mittendrin und muss aber schon irgendwie Gedanken offenbaren. Und das ist... Verursacht sehr viel Verletzlichkeit erstmal. Das fand ich am Anfang auch, bevor ich das erst mal richtig positiv erlebt habe, sehr negativ, weil man dann Leuten gegenüber saß und sagt, der macht mich gleich so richtig lang hier oder der hat so viel auf dem Kasten und ich sehe aus wie so ein Anfänger neben ihm. Das hat erstmal immer richtig Angst gemacht, wenn es dann so in die Richtung ging, Pair-Programming, Code-Reviews. Meistens ist es so nach...

Ja, ich...

nach einem Pull-Request oder so, wo dann gesagt wird, können wir das anders machen? Ja.

Also ich meine, der Unterschied, ich finde immer der erste Schritt ist, wenn man in diese Richtung denkt, dass man erstmal Code Reviews hat. Ich hoffe, jeder macht mittlerweile Code Reviews im Team. Ich befürchte, die Antwort ist nein. Aber eigentlich sollte das heute Standard sein, dass es etwas wie Code Reviews gibt. Und ich finde, das ist ja auch ein... emotional großer Schritt.

Ja.

Gerade wenn man in ein Team reinkommt und auch niemanden so einschätzen kann und dann kommt jemand und bewertet deine Arbeit. So, finde ich, ist eine schwierige, unangenehme Situation. In Teams, wo man weiß, man kann sich auf Menschen verlassen, man tickt auch ganz ähnlich und verfolgt ja doch irgendwie das gleiche Ziel, wenn man sich so eingegroovt hat. Da finde ich das mega angenehm. Da liebe ich auch das Feedback. Aber am Anfang ist das immer ein... unangenehmes Gefühl, möchte ich sagen. Ja, gar nicht so ungut und gar nicht so, dass man sagt, dass ich sagen würde, boah, nee, ich habe jetzt Angst davor, aber es fühlt sich ja, erst mal nicht so cool an. Und ich finde, dann kommt, im nächsten Schritt kommt Pair-Programming. Und Pair-Programming ist auch ich will nicht sagen, dass es Mag ich nicht, aber eigentlich, ich finde es nicht so richtig, so dass ich jetzt sagen würde, oh ja, cool, heute einen Tag Pair-Programming.

Lieber zum Zahnarzt gehen. Hm.

Das nicht. Das sind völlig unterschiedliche Kategorien. Aber Aber was mich halt beim Pair-Programming immer so ein bisschen Hemd, möchte ich sagen, ist dieses, ich ordne eigentlich gerade meine Gedanken beim Rausschreiben von dem, was ich da tue. Und dann sitzt da jemand und hat auch noch Ideen und sagt, ah ja, lass uns das aber so machen oder lass lieber so in die Richtung gehen. Oder man sitzt selber daneben und sagt, ah, ich würde das aber jetzt so und so lösen. Und ich finde, die Situation ist immer ein bisschen... Schwierig. Also das kann sehr intensives Arbeiten sein und sehr produktives Arbeiten für mein Empfinden.

Wie oft ich mich vertippe, wenn jemand zuguckt. Also die Fehlerquote steigt exponentiell.

Aber für mich, für mein Gefühl, ja, und dann kommen so diese Selbstzweifel, ja, ich kann gar nicht schreiben, ich kann gar nicht programmieren. Das ist ja so das eine Ding, das ich gefühlt dann nicht mehr schreiben kann. Ist auch, ich schätze, Absurd, oder? So, und wenn es aber jemand ist, den ich gut kenne und auch schätze und so, dann finde ich das cool. Dann bin ich auch nicht so, ah, was schreibe ich hier? Mache ich das gerade überhaupt richtig? Wie schreibe ich nochmal?

Genau. Also, was...

Was tue ich hier? Wie ist mein Name? Ich

Ja, also was oft geholfen hat, um das Eis zu brechen, also ich weiß nicht, irgendwo vor ein paar Projekten ist das mal so aufgekommen, dass man genau das Gegenteil gemacht hat. Da saßen wir, glaube ich, mit auch so drei, vier Leuten im Raum und mehrere Junior-Entwickler, ich saß da auch dazwischen und so, keiner hat sich getraut, irgendwie so mal eine Idee zu sagen, weil das könnte ja falsch sein und Ich weiß noch nicht mehr, wer das in den Raum geworfen hatte. Auf einmal hieß es so, was wäre die dümmste Idee, die dir dazu einfällt. Also genau das Gegenteil.

Ja. Ja, absolut. Ja.

Jeder ist ja so bemüht, oh mein Gott, ich möchte mich nicht planieren. Und auf einmal hat es so plopp gemacht, weil da kamen die Leute mit, da haben die Sachen in den Raum geschmissen, auf die ich auch nicht gekommen wäre, aber die waren lustig. Und dann war so die Stimmung erst mal ein bisschen lockerer. Und auf einmal kam von einem anderen so, lass mal in die richtige Richtung gehen. Und das ist mir gerade eingefallen. Oder guck mal, das Gegenteil von dem wäre ja schon fast eine Lösung. Und auf einmal hat es Plopp gemacht, weißt du, und dieser Knurr, die Angst war weg, weil so jeder mal was Dummes gesagt hat. Mhm.

Ja, das liebe ich auch eigentlich als Retro-Methode, ne, wir sprechen jetzt ein bisschen vom Thema, aber in der Retro, wenn du halt dir die Frage stellst, was würdest du denn jetzt tun, um jetzt sofort dieses Projekt zu sabotieren oder dieses Produkt oder was auch immer, ich liebe diese Frage, weil man da so kreativ sein kann. So, und ja, auch gerade wenn man so zusammensitzt und anfängt und immer nicht gut kennt, lockert das natürlich einfach diese Stimmung, das nimmt diese Anspannung und ich finde, das ist unfassbar wertvoll, weil irgendwie arbeitet man ja doch mit Menschen, das ist ja nicht wie mit der KI, wenn ich der KI schreibe, das ist aber eine dumme Idee, dann tut es dem Computer weh oder halt nicht.

Mhm. Mhm.

Aber jetzt Menschen zu sagen, die Idee ist nicht cool, finde ich auch immer schwierig. Ich habe mir angewöhnt, auch wenn man über Tickets oder Aufgaben spricht, oder Ideen bespricht und die dann nochmal zusammenfasst, halt immer voranzustellen, dass ich gerade diese Sachen so verstanden habe. Weil das halt so schön eröffnet, allen, die dabei sind, zu sagen, ah, ich hatte das jetzt aber so verstanden. Ja.

Ja, genau. Das versuche ich, mache ich selten, aber ich versuche immer zu sagen, ich sehe das so oder ich denke, das könnte ein Problem sein, das entschärft schon viel. Ja, ja.

oder aus meiner Erfahrung könnte das und das schief gehen. Ich finde, das ist bei solchen Sachen, wo man ja gerade sehr intensiv zusammenarbeitet in einem Team und ein Team ist ja auch nicht riesig oder wenn man tatsächlich Pair Programming macht eins zu eins gerade, dann entschärft das halt auch einfach diese Unsicherheiten unfassbar gut, weil es halt einerseits das so auföffnet, dass man das Gegenüber sagen kann na, ich sehe das gerade anders, aber auch man sich ja selber so ein Stück weit verletzlich damit macht, indem man sagt, na, vielleicht habe ich das auch nicht richtig verstanden, also was ist schon richtig, aber sehr philosophisch gerade.

Ja, genau. Das ist halt die Idee, mit der ich aufkomme. Und das Wichtigste ist, also... Das Schwere, das zu trennen zwischen, das ist einfach nur Quellcode und eine von vielen Möglichkeiten. Und das bist nicht du als Person, die kritisiert wird. Also wenn ich jetzt zum Beispiel sage, ich möchte, oder ich habe da ein Problem, ich möchte das Pattern da einbauen.

ja und das ist ja gerade das gefährliche dass das wenn man herzblutentwickler ist oder programmierer dass man ja irgendwie

Und du sagst, nee, das macht keinen Sinn, weil das haben wir schon dreimal versucht und das knallt. So, gelaufen. Gute andere Idee. Mhm.

doch sehr an dem hängt, was man tut und was man da auch fabriziert hat. Das ist ja das Absurde, das ist ja etwas total Persönliches, was da entstanden ist.

Ja.

Ich finde jetzt mit Open Code, Cloud Code und so weiter, ja, die KI-Agenten, die Code schreiben, das entschärft das so ein bisschen, weil man ja im Prinzip fremden Code liest. Da ist es ja nur noch die architektonische Idee, die dumm war, wenn sie nicht funktioniert. Dann hatte ich eine dumme Idee und die KI hat halt ein paar tausend Token verbrannt. Okay, jetzt muss man sich auch fast schon die philosophische Frage stellen. Ist es nicht Pair-Programming in dem Moment, wo ich jetzt die KI programmieren lasse und überwache und ihr sage, ändere das oder mach dieses?

Das hatten die bei Enterprise schon. Ab wann ist der Computer ein Mensch oder ein Individuum?

Ja, genau. Ab wann?

Wir wissen, dass Data ein Individuum ist, ja.

Genau.

Ja.

Wobei auch RobberDuck-Debugging. Ja, genau.

Was mir aber jetzt bei dem Thema noch sehr geholfen hat, ist zum Beispiel auch der Zeitpunkt, zu dem man Pair-Programming macht. So viele, mit denen ich zu tun hatte oder die Angst davor haben, von denen ich das höre, ist das so, es gibt ein Ticket, da steht drin, das und das muss passieren, Akzeptanzkriterien, Das wird theoretisch los in den Topf geworfen. Ein Entwickler zieht sich das, baut zwei Wochen lang einen Feature, setzt sich dann hin und dann kommt der große Senior-Entwickler, setzt sich mit dem da hin und sagt, so jetzt gucken wir mal da durch und dann gibt es auf die Mütze.

Ja, aber das ist ja mehr Co-Tributors, das ist ja nicht Pair-Programming.

Also da wirst du lang gemacht.

Ja. Ja, absolut.

Ja, aber das artet oft dann in Pair-Programming aus, im Sinne, dass der Senior dann kommt und sagt, guck mal, das machst du anders, das musst du so machen. Und das finde ich einen ganz falschen Ansatz, dass dieses Pair-Programming müsste eigentlich beim Ziehen vom Ticket mit mindestens zwei Leuten passieren. Dass die sich zusammensetzen und sagen, guck mal, wir haben das Ticket, das und das muss hinten rauskommen. Wie kommen wir hin? Design-Pattern, Architekturentscheidungen, was auch immer. Dann spielt man da zusammen rum und am Ende Also, wenn das fertig ist, der Pull-Request gestellt wurde, setzen die zwei sich nochmal zusammen und sagen, was ist da rausgekommen? Warum hast du die Idee, die wir hatten, verworfen? Ist vollkommen legitim, weil was aufgefallen ist, was nicht funktioniert. Was Neues oder setzen sich hin und sagen, cool, hat doch so funktioniert oder, oh, das hast du sogar noch anders gemacht, das ist viel besser als meine Idee vorher.

Ehrlicherweise unterscheiden sich da gerade unsere Ideen von, oder unsere Definitionen auch so ein bisschen von, wie die Abläufe sind.

Und das... Grund auf. Gut.

Also für mich ist Coach Review wirklich einer schreibt das Ganze, dann schmeißt man das hin und jemand anderes schaut drauf und dann setzt man sich vielleicht zusammen.

Okay. Okay.

Aber das ist für mich die Methode Coach Review. Ja, weil eine Code-Tribu, da kommentiere ich ja eh, ob ich das jetzt in Person mache oder im Ticket. Also ich bin immer ein Freund von direkt dran kommentieren. Weil in Person finde ich das dann noch schwierig. Also weiß ich nicht. Finde ich dann irgendwie, das fühlt sich falsch an in meinem Kopf. Pair-Programming ist für mich wirklich, zwei Leute nehmen sich ein Ticket.

Mhm.

Oder finden sich zu einem Ticket zusammen. Es kann ja auch sein, jemand nimmt sich ein Ticket, stellt fest, ich bekomme das jetzt doch irgendwie nicht gelöst. Ich hänge hier und holt sich jemand Zweiten dazu und dann entwickelt man das zusammen. Dann reviewen aber für mein Verständnis niemand von diesen beiden das Arbeitsergebnis, weil die es ja zusammen produziert haben, sondern ein unbeteiligter Entwickler reviewt dann das Ergebnis von den beiden.

Wenn du so viele hast, ja. Ja, also meine Annahme war jetzt ein sehr kleines Team. Ja, definitiv, wenn es mehr Leute gibt, sollten Unbeteiligte das reviewen, das stimmt.

Ja, wenn wir jetzt mal Richtung Standards gehen, dann ist es, glaube ich, im SOC 2 so, die Idee oder die Empfehlung, ich glaube, es ist kein Muss, ich bin mir da gerade ehrlicherweise nicht hundertprozentig sicher, dass eh eine Review durch zwei Personen erfolgen muss, die nicht am Code gearbeitet haben. Das wäre nochmal ein Schritt mehr, also nicht ein plus eins, sondern zwei.

Das ist sechs Augenversiv.

Aber ja, das hängt natürlich total von der Teamgröße ab. Wenn du ein kleines Team hast, dann kannst du dir natürlich nicht erlauben, zu sagen, alles klar, ich gehe jetzt hin und Jetzt muss jeder hier diese Review machen. Ich habe auch schon Projekte gesehen, wo ich dann reingekommen bin, wo einfach nur zwei Personen in Teilzeit jeder an einem Tag in der Woche, an verschiedenen Tagen in der Woche gearbeitet haben.

Ja. Ja.

Der eine macht das, dann revieut das der andere und beim nächsten Mal, das ist ja auch... an für sich schon eine schwierige Situation, auch um vorbeizukommen. Aber natürlich hast du in Teams, ich sag jetzt mal, mit vier, fünf Leuten, mit Entwicklern, nicht Menschen, Entwicklern, Entwicklerinnen, also die, die auch verstehen, was passiert da technisch und das beurteilen können, sagen wir das mal ein bisschen neutraler, Da kannst du natürlich anfangen, solche Prozesse gut zu spielen. Wenn du natürlich nur zwei oder drei Personen bist, dann bist du natürlich darauf angewiesen, gewisse Sachen zu modifizieren. Zum Beispiel, wie viele schauen sich etwas an.

Ja, ja.

Völlig logisch. Ich finde das aber auch nicht schlimm, dass man so Sachen modifiziert darin, dass sie für einen funktionieren. Ähm, Ich finde, das ist immer wertvoll und richtig Feedback zu bekommen, weil ich eher der Freund davon bin, das nachgelagert zu machen, einfach um auch meine Gedanken zu ordnen. Und ich stelle mir auch vor, wie wir jetzt Pair-Programming mit der KI machen. Im Sinne von, wir betrachten die KI wie die IDE und tippen da jetzt rein und reviewen das dann gleichzeitig zusammen, was da rauskommt.

Ja, also das ist zumindest in dem Konstrukt, so wie ich das öfter erlebt habe, passiert viel mehr Arbeit vorne, also wirklich per Programming zum Beispiel, wo sich die zwei hinsetzen und auch von mir aus mit KI und sagen, wir haben ein Problem, wir müssen was einbauen. Also mal mehr als wie, wir brauchen den hundertsten Controller, der A nimmt und B rausspuckt, sondern keine Ahnung, es muss irgendwo ein neues Eventsystem eingebaut werden oder irgendwas muss an irgendwelchen Stellen immer passieren und externe Systeme angetriggert werden oder irgendwas Komplexeres, wo du sagst, so ne, da

ja natürlich

Und dann setzen die zwei sich hin und fangen an zu suchen, so was gibt es für Design-Pattern. Und das kannst du ja mit KI auch machen. Also dieses, einer teilt den Monitor zum Beispiel und dann bist du automatisch in diesem, wie heißt das, Driver und... und... Ja, ganz viele Buzzwords. Also einer ist derjenige an der Tastatur, der andere sagt, was gemacht werden soll. So ein bisschen, das kommt dann auch automatisch, wenn der eine schon den Monitor teilt. Und das funktioniert ganz gut, dass man dann so ein bisschen rumspielt und sagt, guck mal, es gibt diese Muster, das ist Vorteil, das ist Nachteil. Man klatscht mal so schnell irgendwie so eine leere Klasse dahin, die so zwei Methoden hat, damit die keinen Compile-Fehler aufrufen.

Ja, ja.

Und dann lässt du es mal laufen als POC. Und das wäre dann der Punkt, wo du sagst, okay, wir haben etwas, was technisch, haben wir uns eine Lösung ausgedacht. Den Code schreiben ist wie jetzt mit KI ja auch, das kann, traue ich jedem zu, dass er das alleine kann. Und deswegen ist das bei mir so, nachher setzen die zwei sich nochmal zusammen, wenn das fertig ist und reden nochmal darüber, ob es dabei geblieben ist oder ob da was Neues noch hinzugekommen ist. Also so die ganze Zeit per Programming jemanden beim Tippen zu gucken.

Ja, das ist ja nicht nur ein Zugucken, sondern es ist ja ein aktives Mitdenken und Mitarbeiten, theoretisch.

Weißt du, wie blöd ich mich anhöre, wenn ich Shell-Befehle ausspreche?

Ja, ich lasse dann ja so implizit Sachen weg, wo ich von ausgehe, dass Gegenüber weiß, dass da jetzt ein Leerzeichen hinkommt.

CD, Leerzeichen, SRC, Slash.

Und dann ist, ne, du musst nochmal zurück, du hast da, ne, so, ja.

Du weißt die Parameter nicht auswendig auf der Konsole. Ja.

Oder ich weiß die dann ja auch nicht und dann sage ich, aha, ich muss mal eben nachschauen.

Mhm.

Das ist halt auch so ein bisschen.........

Wobei, was ich auch sehr interessant fand, war, was ich jetzt oft gesehen habe, es gibt so viele unterschiedliche Wege, wie Leute durch Code navigieren. Also gerade bei diesem Pair-Programming, wo du sagst, so ihr, mach mal, geh mal in die und die Datei. Ich bin zum Beispiel jemand, so ich weiß gar nicht genau, in welchem Pfad die liegt, aber irgendwie mein Gehirn speichert so besseren Namen, so Klassennamen. Und ich bin dann immer so, der zum Beispiel PHP-Storm mit den Anfangsbuchstaben so die Kombinationen weiß, damit ich zu der Datei komme. Und dann sitzt du dann da und dann fängst du anderen Kollegen das an zu sagen und die sind so welche, die merken sich so ganz krass den Dateifad und die klicken das dann so darunter und fragen so, in welchem Pfad ist das?

Ja.

Und dann, keine Ahnung. Namespaces, ja.

Ja, Fun Fact dazu, ich habe mal in der Zertifizierung gesessen und da, also Multiplier Joy ist klar, aber dann wurde da tatsächlich abgefragt, wie denn der korrekte Pfad für etwas ist. Also wo kommt denn da ein S hinten dran? So, und ich denke mir so, sorry, not sorry, ich habe eine Idee, die weiß das und übrigens, die Pfade generiere ich mir ja auch nicht oder wenn, dann mache ich das einmal und wenn ich mir unsicher bin, dann schaue ich dann in die Doku, aber eigentlich mache ich das auf der Command Line und sage, hey, ich möchte hier jetzt ein neues Modell oder irgendwas anderes anlegen und der sagt nur, ja, in welches Paket denn bitte schön, bitte gleich.

Mhm.

Also so Sachen, ich finde, das sind so überflüssige Informationen. Ich speichere die einfach nicht. Deswegen finde ich auch, so eine ganz schlimme Krankheit ist ja irgendetwas Utility zu nennen.

Service. Es gibt so viele Services bei mir immer. Es tut mir so leid.

Und dann gibt es überall General Utility. Ich denke mir so, what? Ja. Ja, oder Service oder Helper. Aber Service finde ich fast noch nicht so schlimm. Aber Utility und Helper... Und ganz schlimm finde ich, ist mir jetzt vor kurzem aufgefallen, die Tendenz dazu, unter Classes direkt ausgeschrieben Data Transfer Objects abzulegen. Alles ist auf einmal ein DTO. Das ist auch für mich so ein Das gehört in kein sauberes Pattern rein, das unter Classes Data Transfer Optics liegt und alles, was irgendwie Daten von A nach B oder ein Schema ist, ja, so ein ganz klassisches, okay, diese Funktion hat diese Parameter zum Konfigurieren und die werden jetzt normalerweise in Array übergeben, also eine klassische kleine Funktion und diese auf einmal in DTO und dann

Aber das ist genau der perfekte Moment, wo du sagst, du sitzt gerade so in einem Pair-Programming mit einem anderen Entwickler und der macht das.

weiß ich auch nicht da das fühlt sich so falsch an ja

Und das sind so einerseits die Momente, die ich mag, weil man dann nachfragen kann, warum machst du das? Was denkst du dir dabei? Also, wenn ich das schreiben würde, das kommt ganz falsch immer an. Und wenn man spricht, dann ist das wenigstens abgemildert. Dann kann ich darauf achten, dass ich nicht so aggressiv mich anhöre oder so vorbeugungsvoll klingt, sondern neugierig, weil derjenige denkt sich ja gerade was dabei.

Warum machst du den Mist?

Und Ja, wenn du die Hand dabei so am Kopf hast, ist das wieder schlecht. Genau. Naja, nein, aber dafür sind

Oder so die Kaffeetasse dabei schon so zitternd. Was tust du da? Ich kann mir das gut vorstellen, Daniel, wie du da versuchst, dich zu beherrschen und

Nein, gar nicht. Sondern ich bin echt oft neugierig und denke mir so, warum? Also natürlich weiß ich für mich, was ich mir gerade denke, das ist echt keine coole Lösung.

Ja.

Aber warum? Woher kommt das? Also es gibt ja zum Beispiel dann unterschiedlichste Frameworks, wo das vielleicht Gang und Gebe war und derjenige ist damit aufgewachsen oder in anderen Teams war es Voraussetzung dafür. Und das bringt natürlich jeder mit und das merke ich auch in jedem neuen Projekt. Ich bin so vorbelastet, was so die Teams von vorher betrifft, weil bei jedem Team gibt es irgendwelche Conventions mit, zum Beispiel die einen haben gerne super viele kleine Klassen, die so per Invoke alles machen, die nächsten verabscheuen das wieder. Die anderen wollen irgendwelche Registries, Manager, was auch immer. Und du bringst das dann immer so vom Projekt zu Projekt mit. Deswegen auch bei den DTOs wäre jetzt mein Ansatz oder mein erster Gedanke, was ist in den anderen Teams passiert oder wer hat dir da so die Finger, so auf die Finger gehauen, dass du das immer noch machst. Also, das ist so.

Woher kommt die Idee, warum macht man was? Und ich finde, das ist ja auch dann tatsächlich sowohl bei CodeRevues als auch beim PairProgramming eigentlich der interessante Teil, dass man sich dann annähert und vermeintlich zu zweit eine bessere Lösung findet als alleine. Und das ist ja der interessante Teil. Und was ja auch häufig passiert ist, je länger ein Team oder Menschen zusammenarbeiten, je ähnlicher wird sich der ganze Output.

Und Und noch schlimmer ist, wenn du länger mit Leuten zusammenarbeitest, irgendwann musst du kein Git-Blame mehr machen, um zu sehen, wer welchen Code geschrieben hat.

Das gleicht sich ja an. Deswegen, manchmal ist es total spannend, wenn neue Leute einfach reinkommen, weil dann auch neue Ideen reinkommen und manchmal auch auch lange vorherrschende Probleme sich lösen. Ja, das war immer ich. Also, Blame brauche ich nicht machen, das war immer meine dumme Idee. Das ist mittlerweile meine Grundannahme.

Welcher Spacko war das denn? Das hat mich mal in den Coach Review echt gebracht. Dann gucke rein und sage, boah, ist das ein Scheiß?

Wenn ich mich besonders viel aufrege über etwas und so, was ist denn das für ein Scheiß, dann

Wer macht denn so einen Dreck? Macht das auf und da steht da mein Name.

Ja, wie kann man so einen Mist machen? Ja, so innerlich schon so. Dann... Ja, das ist dann so der Moment der Selbsterkenntnis. Okay.

Innerhalb einer Woche. Hm.

Ich habe mich weiterentwickelt. Ich sehe Dinge heute anders. Und ich finde, solange man das hat, ist das doch auch was Gutes. Aber tatsächlich, die größten Aufreger, die ich so habe, ist bei Kurt, den ich selber geschrieben habe, den ich dann auf einmal abgrundtief schreibe. verabscheue fast schon und sage, Mist, das müssen wir auf jeden Fall refactoren. Das können wir unter gar keinen Umständen weiter so laufen lassen. Ja. Ja.

Aber man entwickelt eine eigene Handschrift oder ich denke mal, jeder Entwickler hat zum Teil auch eine eigene Handschrift. Und ich hatte schon ein paar Mal das Gefühl, wenn man lang genug mit Leuten zusammenarbeitet und so, jeder hat so ein bisschen andere Denkmuster. Der eine neigt so dazu, irgendwo mehr Schleifen zu machen. Der andere hat so eher diese PHP-internen Array-Funktionen zum Beispiel lieber. Mancher hat so ein paar Sprünge mehr im Quelltext oder zieht die Sachen einfach länger. Und da hatte ich schon ein paar Mal das Gefühl, dass du so draufguckst und sagst, boah, das fühlt sich so ein bisschen nach dem Kollegen an. Oder das könnte der Kollege geschrieben haben. Also noch nicht mal negativ, sondern da hat jeder so seine Handschrift. Und das fand ich auch immer sehr interessant, dass so Pairprogramming dazu führt, dass ich so die Denkmuster von dem anderen verstehe. Und Was später, also wenn das oft genug passiert, sitze ich irgendwann da, gucke mir den Quelltext an und sage, stimmt, das könnte von ihm sein und bei ihm weiß ich, das kommt oft so oder er löst das Problem so.

Ja, klar, weil... Ja. Nee, ich mag DTOs, aber DTOs gehören für mich ins Model und ähm

Was dann dazu führt, dass ich Quelltext beim Lesen viel schneller wieder verstehe. Beispiel, wir arbeiten viel zusammen, du hast irgendwann was geschrieben und ich gucke später drauf und sage, Ole macht das immer so, der hat gerne Factories oder so. Wo ist die Factory, um das Problem zu lösen? Oder DTOs vielleicht? Zum Beispiel würde ich jetzt bei dir nie im Leben DTO suchen. Ja.

Und ich arbeite aber halt auch gerne mit Value Objects zum Beispiel.

Ja. Oh ja, Naming.

Also einfach, ich bevorzuge es, wenn Dinge den richtigen Namen haben quasi. Und der richtige Name ist ja ein komplett eigenes Ding, wo man Stunden verbringen kann, den richtigen Namen zu suchen und so Sachen. Und ich mag es dann doch irgendwo am Tagesende, wenn so Konventionen, wo etwas liegt, eingehalten sind. Weil ich finde, es gibt ja auch so eine Semantik und dann fügt sich das zusammen und das ist ja eigentlich erzählen, Programme ja eine Geschichte. Und jeder, der an dieser Geschichte mitschreibt, hat seinen eigenen Stil, die Geschichte zu schreiben und zu erzählen. Und ich finde, das sieht man halt. Und das merkt man auch.

Also du beziehst das auch auf Namespaces oder Dateiparten? Mhm. Mhm.

Ja, allgemein. Das Gesamtding ist ja am Tagesende... ist es ja in einer menschenverständlichen Sprache geschrieben, nicht in Maschinencode. Und wenn man das so durchliest, dann kommt ja ein mehr oder weniger grammatikalisch korrektes Satzkonstrukt daraus. Ja, ja, schon, ja.

ich würde sagen, du erzeugst Bilder im Kopf. Also das passt eher so, diese Analogie zu einem Märchen. Wenn du Quältest liest, also da bauen sich Bilder bei mir im Kopf auf. Und wenn ich mit dir viel zusammengearbeitet habe, weiß ich, welche Metaphern du gerne benutzt. Und das kopiert sich dann viel schneller, glaube ich.

Ja, und dadurch, dass man eine Person gut kennt, den Stil gut kennt und den Schreibstil, ja, im Deutschen, wenn man Deutsch Texte schreibt und Artikel schreibt, dann sind es ja Schreibstile, das hat man auch halt bei Code, finde ich.

Oder macht es mir leichter, diese Bilder dann abzurufen. Ja.

Aber das spricht halt sehr dafür, dass Code eigentlich auch eine Form einer natürlichen Sprache ist.

Ja, definitiv. Das ist für Menschen, nicht für Maschinen. Oh mein Gott, ja.

Ja. Boah, wie philosophisch. Jetzt wieder die Frage... Ist es Pair-Programming, wenn ich Open Code verwende oder Cloud Code oder whatever, welchen Agenten, der mit mir schreibt auch, den kann ich ja auch fragen und belästigen mit, hey, welche Architektur könnten wir verwenden für das Problem? Also wenn ich quasi in den Plan-Mode gehe, wäre ich ja bei dem, wo du sagst, die Vorarbeit erledigen, ist eher so das Pair-Programming-Thema.

Menschen haben mich bis jetzt schon ein paar Mal überrascht mit Lösungen, wo ich gesagt habe, cool, da wäre ich nie drauf gekommen. Bei KI ist es mir mehrfach passiert, wo ich gesagt habe, ey, warum kommst du auf so eine Lösung? Das passt vorne und hinten nicht.

Also ich habe das auch, dass mich KI überrascht in beide Richtungen.

Mhm.

Und man merkt auch echte Unterschiede in der Qualität. Aber es gibt zum Beispiel ein neues Paper von, wie heißt er denn jetzt gleich? Dem Autor von The Art of Computer Programming. Ich habe den Namen gerade vergessen. Der Don Knuth, glaube ich, der hat jetzt veröffentlicht, tatsächlich vor einigen Tagen ein Paper oder ein Unpaper, wo er ein Grafentheorie-Problem durch Cloud Opus 4.6 hat lösen lassen.

Ja, der Dude. Echt? Mhm.

an dem er wochenlang gearbeitet hat und das hat das tatsächlich in, ich glaube, einer Stunde oder sowas ähnlichem tatsächlich gelöst bekommen. Cloud Cycle hat das dann, Cycles hat das dann genannt. Total spannend tatsächlich. Also, und das ist auch das, was ich merke, dass auch, Technische Herausforderungen möchte ich es mal nennen, wozu es nicht so viel Code gibt im Internet, Cloud Opus 4.6 gerade am besten für mich löst. Nicht am besten, sondern am zufälligsten, mit am wenigsten Fantasiegeschichten, die eingebaut werden.

müssen wir erwähnen, dass wir keine Werbung machen und nicht dafür bezahlt werden, Firmennamen zu nennen? Also ich bin nicht mit Cloud Code unterwegs. Vielleicht liegt das auch daran. Ja. Ja.

Also das merke ich, also wenn ich ein anderes Unternehmen von OpenAI zum Beispiel, um noch einen Namen zu droppen, damit es keine Werbung hier ist, oder auch mit DevStral, da sind die Ergebnisse schon deutlich unterschiedlich. Also ich bin ja so, ich probiere das die ganze Zeit aus und ich behandle im Moment die die KI meistens irgendwie dann doch irgendwie wie beim Robber-Dug-Debugging und sagt, hey, hier habe ich den Fehler und das habe ich so gemacht. Was sind denn deine Überlegungen dazu? Oder auch zum Teil gehe ich jetzt mittlerweile mehrheit hin und sagt ihm, ja, das habe ich, wie können wir das lösen, ja, plan das mal und iteriere quasi so über diese Ideen drüber und lasse dann nachher tatsächlich die KI den Code generieren, wenn die Architektur steht.

Mhm.

Deswegen sage ich ja, also ist es nicht schon, machen wir nicht jeden Tag mittlerweile Pair-Programming, wenn wir KI-Agenten mit einsetzen. Das müssen ja noch nicht mal Agenten sein, KI-Systeme. Die arbeiten ja gar nicht so autonom an der Stelle.

Also im weitesten Sinne ja.

Ja.

Und dass man seinen Code reviewen lässt, also zum Beispiel CodeRabbit nutze ich auch gerne. Das ist nur für CodeReviews da, weil ich versuche aktuell so dieses vorher Code selber schreiben, wie auch im PairProgramming, wie vorgeschrieben, so schnell die Muster irgendwo hinklatschen und zu sagen, guck mal, das könnte so funktionieren. Und dann zu sagen, für den Rest bin ich zu faul. Diese an alle Stellen einen Nullcheck machen, wo einer sein könnte.

Ja.

Weiß ich nicht, baue das hundertste for each rein und weiß ich nicht, iteriere darüber und hole irgendwelche Sachen raus oder filter erase. Die Sachen, dafür bin ich zu faul. Also ich gehe gerne hin und skizziere so etwas im Code vor, wo ich sage, das wäre eine Klasse, das Design Pattern, so und so und so. Und dann sage ich der KI, guck mal, das ist das Problem, so will ich das lösen. Und dann auch so wie du sagtest, schlag mal was anderes vor. Oder so nach dem Prinzip, überrasch mich mal. Und wenn es dann so passt, natürlich ist es dann immer so, super Idee, Daniel. Auf nichts Besseres wäre ich auch gekommen. Zumindest einfach nicht.

Ja, soll ich sagen, welches KI-Modell das sagt? Ja.

Da klingelt der Wecker immer. Und dann sage ich dir, bau das mal aus, implementiere mal das. Das sind die Akzeptanzkriterien. Das ist dann so dieser Boilerplate-Code, wo ich sage, den kann das Ding generieren. Das kann ich dann auch reviewen. Das ist dann auch so eine Codemenge, die hinten rauskommt, handelbar für einen Code-Review für mich nochmal. Also, dass ich die Code nochmal angucke, die KI generiert hat. Und ja, also irgendwie ist das schon per Programming, ne?

Ja. Ein Venegrer Kaffee.

Nur nicht so charmant. Das nächste Mal sitzt ich mit T-Shirts. Genau.

Ich hatte jetzt gesehen, ich bin mir nicht sicher, ob es jetzt tatsächlich so ist, aber man scheint jetzt auch mit Cloud Code reden zu können. Jetzt ist schon wieder Werbung, ne? Ich weiß nicht, ob andere das auch so können. Also mit ChatGPT kann man auch reden. Ja, ja. Sorry. Falls ihr einen Sponsoring-Vertrag machen wollt, schreibt uns. Wir nehmen Geld. Ähm. Aber ich meine, es gibt jetzt tatsächlich diesen Command dafür, dass du mit dem System auch quatschen kannst. Das habe ich noch nicht ausprobiert. Das wäre natürlich mal eine ganz heiße Kiste, dass ich den ganzen Tag mit dem System einfach vor mich hin quatsche. Aber ich glaube, dann bekomme ich auch Stress, wenn ich die ganze Zeit vor mich hier hin brabbel. Mein Gegenüber findet das dann bestimmt irgendwann nicht mehr cool.

Ja, das wäre echt interessant. Also muss ich mal gucken. Jetzt bin ich neugierig, weil... Äh? An...

Ja, um jetzt auch die Liste voll zu machen, ich lese in meiner Timeline im Übrigen auch immer, dass, ich glaube, es heißt Codex, besser wäre als Cloud-Code. Ich habe das noch nicht validiert. Ich bin im Moment total hin- und ergerissen. Also es gibt Tage, da finde ich die Tools alle doof. Und es gibt Tage, da bin ich wirklich glücklich darüber.

Dann kann ich nur sagen, es gibt auch noch OpenCode, also Quelloffen macht das gleiche wie CloudCode und Codex und da bin ich hängen geblieben, weil du da einfach das Model wechseln kannst.

Ja, das habe ich auch, ja. Ja, das kannst du bei den anderen, glaube ich, auch. So, ich... Ah, siehst du, da bist du weiter als ich. Ja. Ja,

Bei Codex musstest du in die Config und bei OpenCode kannst du einfach so Tastenkombinationen und wählst dann das Model aus und der nächste Command läuft mit dem Model. Das ist… Nicht, dass ich das mache, aber ich könnte. Wieder ein Feedback, was keiner braucht, aber jeder haben will.

Perfekt. Also stellen wir fest, wir mögen Pair Programming, wenn wir Menschen mögen und ansonsten machen wir es mit der KI.

Das hat sich sehr zweideutig angehört. Ja. Was ist, wenn wir Menschen nicht mögen? Dann bleibt die KI.

Dann bleibt jetzt ja die KI. Ich finde, das ist eine schöne Alternative geworden. Gegenfrage, seit wann mögen Entwickler Menschen?

Bis dann, ciao.

Ich finde, das ist ein schönes Schlusswort und wir sehen uns, hören uns dann in der nächsten Woche wieder mit einer neuen Folge Secrets Not Included. Bis dahin, denkt ans Liken, Abonnieren, Teilen und so weiter. Ihr kennt das Spiel und wir sehen uns dann. Macht's gut!