Transcript
Kai Ole Hartwig: Willkommen zu einer neuen Folge Secrets Not Included.
Kai Ole Hartwig: Wieder Daniel und Ole hier.
Kai Ole Hartwig: Und in dieser Woche, in der siebten Folge übrigens, sprechen wir über Pair-Programming.
Kai Ole Hartwig: Ja Daniel, dann Bühne frei.
Kai Ole Hartwig: Was hältst du denn davon?
Daniel Langemann: Ja, das ist ein super schönes Tool, um Wissen zu verteilen.
Daniel Langemann: 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.
Daniel Langemann: Also mit, guck mal, das habe ich gebaut und man bekommt Kritik.
Daniel Langemann: Warum hast du das gemacht?
Daniel Langemann: Warum ist das so?
Daniel Langemann: Und ja,
Daniel Langemann: Und das ist halt immer so ein bisschen, man ist mittendrin und muss aber schon irgendwie Gedanken offenbaren.
Daniel Langemann: Und das ist...
Daniel Langemann: Verursacht sehr viel Verletzlichkeit erstmal.
Daniel Langemann: 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.
Daniel Langemann: Das hat erstmal immer richtig Angst gemacht, wenn es dann so in die Richtung ging, Pair-Programming, Code-Reviews.
Daniel Langemann: Meistens ist es so nach...
Kai Ole Hartwig: Ja, ich...
Daniel Langemann: nach einem Pull-Request oder so, wo dann gesagt wird, können wir das anders machen?
Daniel Langemann: Ja.
Kai Ole Hartwig: Also ich meine, der Unterschied, ich finde immer der erste Schritt ist, wenn man in diese Richtung denkt, dass man erstmal Code Reviews hat.
Kai Ole Hartwig: Ich hoffe, jeder macht mittlerweile Code Reviews im Team.
Kai Ole Hartwig: Ich befürchte, die Antwort ist nein.
Kai Ole Hartwig: Aber eigentlich sollte das heute Standard sein, dass es etwas wie Code Reviews gibt.
Kai Ole Hartwig: Und ich finde, das ist ja auch ein...
Kai Ole Hartwig: emotional großer Schritt.
Daniel Langemann: Ja.
Kai Ole Hartwig: Gerade wenn man in ein Team reinkommt und auch niemanden so einschätzen kann und dann kommt jemand und bewertet deine Arbeit.
Kai Ole Hartwig: So, finde ich, ist eine schwierige, unangenehme Situation.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Da finde ich das mega angenehm.
Kai Ole Hartwig: Da liebe ich auch das Feedback.
Kai Ole Hartwig: Aber am Anfang ist das immer ein...
Kai Ole Hartwig: unangenehmes Gefühl, möchte ich sagen.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Und ich finde, dann kommt, im nächsten Schritt kommt Pair-Programming.
Kai Ole Hartwig: Und Pair-Programming ist auch ich will nicht sagen, dass es
Kai Ole Hartwig: 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.
Daniel Langemann: Lieber zum Zahnarzt gehen.
Daniel Langemann: Hm.
Kai Ole Hartwig: Das nicht.
Kai Ole Hartwig: Das sind völlig unterschiedliche Kategorien.
Kai Ole Hartwig: Aber Aber was mich halt beim Pair-Programming immer so ein bisschen
Kai Ole Hartwig: Hemd, möchte ich sagen, ist dieses, ich ordne eigentlich gerade meine Gedanken beim Rausschreiben von dem, was ich da tue.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Oder man sitzt selber daneben und sagt, ah, ich würde das aber jetzt so und so lösen.
Kai Ole Hartwig: Und ich finde, die Situation ist immer ein bisschen...
Kai Ole Hartwig: Schwierig.
Kai Ole Hartwig: Also das kann sehr intensives Arbeiten sein und sehr produktives Arbeiten für mein Empfinden.
Daniel Langemann: Wie oft ich mich vertippe, wenn jemand zuguckt.
Daniel Langemann: Also die Fehlerquote steigt exponentiell.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Das ist ja so das eine Ding, das ich gefühlt dann nicht mehr schreiben kann.
Kai Ole Hartwig: Ist auch, ich schätze,
Kai Ole Hartwig: Absurd, oder?
Kai Ole Hartwig: So, und wenn es aber jemand ist, den ich gut kenne und auch schätze und so, dann finde ich das cool.
Kai Ole Hartwig: Dann bin ich auch nicht so, ah, was schreibe ich hier?
Kai Ole Hartwig: Mache ich das gerade überhaupt richtig?
Kai Ole Hartwig: Wie schreibe ich nochmal?
Daniel Langemann: Genau.
Daniel Langemann: Also, was...
Kai Ole Hartwig: Was tue ich hier?
Kai Ole Hartwig: Wie ist mein Name?
Kai Ole Hartwig: Ich
Daniel Langemann: 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.
Daniel Langemann: 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
Daniel Langemann: Ich weiß noch nicht mehr, wer das in den Raum geworfen hatte.
Daniel Langemann: Auf einmal hieß es so, was wäre die dümmste Idee, die dir dazu einfällt.
Daniel Langemann: Also genau das Gegenteil.
Kai Ole Hartwig: Ja.
Kai Ole Hartwig: Ja, absolut.
Kai Ole Hartwig: Ja.
Daniel Langemann: Jeder ist ja so bemüht, oh mein Gott, ich möchte mich nicht planieren.
Daniel Langemann: 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.
Daniel Langemann: Und dann war so die Stimmung erst mal ein bisschen lockerer.
Daniel Langemann: Und auf einmal kam von einem anderen so, lass mal in die richtige Richtung gehen.
Daniel Langemann: Und das ist mir gerade eingefallen.
Daniel Langemann: Oder guck mal, das Gegenteil von dem wäre ja schon fast eine Lösung.
Daniel Langemann: 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.
Daniel Langemann: Mhm.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: So, und ja, auch
Kai Ole Hartwig: 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,
Kai Ole Hartwig: dann tut es dem Computer weh oder halt nicht.
Daniel Langemann: Mhm.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Aber jetzt Menschen zu sagen, die Idee ist nicht cool, finde ich auch immer schwierig.
Kai Ole Hartwig: Ich habe mir angewöhnt, auch wenn man über Tickets oder Aufgaben spricht,
Kai Ole Hartwig: oder Ideen bespricht und die dann nochmal zusammenfasst, halt immer voranzustellen, dass ich gerade diese Sachen so verstanden habe.
Kai Ole Hartwig: Weil das halt so schön eröffnet, allen, die dabei sind, zu sagen, ah, ich hatte das jetzt aber so verstanden.
Kai Ole Hartwig: Ja.
Daniel Langemann: Ja, genau.
Daniel Langemann: 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.
Daniel Langemann: Ja, ja.
Kai Ole Hartwig: oder aus meiner Erfahrung könnte das und das schief gehen.
Kai Ole Hartwig: Ich finde, das ist bei solchen Sachen, wo man ja gerade sehr intensiv
Kai Ole Hartwig: 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
Kai Ole Hartwig: 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.
Daniel Langemann: Ja, genau.
Daniel Langemann: Das ist halt die Idee, mit der ich aufkomme.
Daniel Langemann: Und das Wichtigste ist, also...
Daniel Langemann: Das Schwere, das zu trennen zwischen, das ist einfach nur Quellcode und eine von vielen Möglichkeiten.
Daniel Langemann: Und das bist nicht du als Person, die kritisiert wird.
Daniel Langemann: Also wenn ich jetzt zum Beispiel sage, ich möchte, oder ich habe da ein Problem, ich möchte das Pattern da einbauen.
Kai Ole Hartwig: ja und das ist ja gerade das gefährliche dass das wenn man herzblutentwickler ist oder programmierer dass man ja irgendwie
Daniel Langemann: Und du sagst, nee, das macht keinen Sinn, weil das haben wir schon dreimal versucht und das knallt.
Daniel Langemann: So, gelaufen.
Daniel Langemann: Gute andere Idee.
Daniel Langemann: Mhm.
Kai Ole Hartwig: doch sehr an dem hängt, was man tut und was man da auch fabriziert hat.
Kai Ole Hartwig: Das ist ja das Absurde, das ist ja etwas total Persönliches, was da entstanden ist.
Daniel Langemann: Ja.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Da ist es ja nur noch die architektonische Idee, die dumm war, wenn sie nicht funktioniert.
Kai Ole Hartwig: Dann hatte ich eine dumme Idee und die KI hat halt ein paar tausend Token verbrannt.
Kai Ole Hartwig: Okay, jetzt muss man sich auch fast schon die philosophische Frage stellen.
Kai Ole Hartwig: 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?
Daniel Langemann: Das hatten die bei Enterprise schon.
Daniel Langemann: Ab wann ist der Computer ein Mensch oder ein Individuum?
Kai Ole Hartwig: Ja, genau.
Kai Ole Hartwig: Ab wann?
Daniel Langemann: Wir wissen, dass Data ein Individuum ist, ja.
Kai Ole Hartwig: Genau.
Daniel Langemann: Ja.
Kai Ole Hartwig: Wobei auch RobberDuck-Debugging.
Kai Ole Hartwig: Ja, genau.
Daniel Langemann: Was mir aber jetzt bei dem Thema noch sehr geholfen hat, ist zum Beispiel auch der Zeitpunkt, zu dem man Pair-Programming macht.
Daniel Langemann: 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,
Daniel Langemann: Das wird theoretisch los in den Topf geworfen.
Daniel Langemann: 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.
Kai Ole Hartwig: Ja, aber das ist ja mehr Co-Tributors, das ist ja nicht Pair-Programming.
Daniel Langemann: Also da wirst du lang gemacht.
Kai Ole Hartwig: Ja.
Kai Ole Hartwig: Ja, absolut.
Daniel Langemann: 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.
Daniel Langemann: Und das finde ich einen ganz falschen Ansatz, dass dieses Pair-Programming müsste eigentlich beim Ziehen vom Ticket mit mindestens zwei Leuten passieren.
Daniel Langemann: Dass die sich zusammensetzen und sagen, guck mal, wir haben das Ticket, das und das muss hinten rauskommen.
Daniel Langemann: Wie kommen wir hin?
Daniel Langemann: Design-Pattern, Architekturentscheidungen, was auch immer.
Daniel Langemann: Dann spielt man da zusammen rum und am Ende
Daniel Langemann: Also, wenn das fertig ist, der Pull-Request gestellt wurde, setzen die zwei sich nochmal zusammen und sagen, was ist da rausgekommen?
Daniel Langemann: Warum hast du die Idee, die wir hatten, verworfen?
Daniel Langemann: Ist vollkommen legitim, weil was aufgefallen ist, was nicht funktioniert.
Daniel Langemann: 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.
Kai Ole Hartwig: Ehrlicherweise unterscheiden sich da gerade unsere Ideen von, oder unsere Definitionen auch so ein bisschen von, wie die Abläufe sind.
Daniel Langemann: Und das... Grund auf.
Daniel Langemann: Gut.
Kai Ole Hartwig: 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.
Daniel Langemann: Okay.
Daniel Langemann: Okay.
Kai Ole Hartwig: Aber das ist für mich die Methode Coach Review.
Kai Ole Hartwig: Ja, weil eine Code-Tribu, da kommentiere ich ja eh, ob ich das jetzt in Person mache oder im Ticket.
Kai Ole Hartwig: Also ich bin immer ein Freund von direkt dran kommentieren.
Kai Ole Hartwig: Weil in Person finde ich das dann noch schwierig.
Kai Ole Hartwig: Also weiß ich nicht.
Kai Ole Hartwig: Finde ich dann irgendwie, das fühlt sich falsch an in meinem Kopf.
Kai Ole Hartwig: Pair-Programming ist für mich wirklich, zwei Leute nehmen sich ein Ticket.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Oder finden sich zu einem Ticket zusammen.
Kai Ole Hartwig: Es kann ja auch sein, jemand nimmt sich ein Ticket, stellt fest, ich bekomme das jetzt doch irgendwie nicht gelöst.
Kai Ole Hartwig: Ich hänge hier und holt sich jemand Zweiten dazu und dann entwickelt man das zusammen.
Kai Ole Hartwig: 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.
Daniel Langemann: Wenn du so viele hast, ja.
Daniel Langemann: Ja, also meine Annahme war jetzt ein sehr kleines Team.
Daniel Langemann: Ja, definitiv, wenn es mehr Leute gibt, sollten Unbeteiligte das reviewen, das stimmt.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Das wäre nochmal ein Schritt mehr, also nicht ein plus eins, sondern zwei.
Daniel Langemann: Das ist sechs Augenversiv.
Kai Ole Hartwig: Aber ja, das hängt natürlich total von der Teamgröße ab.
Kai Ole Hartwig: Wenn du ein kleines Team hast, dann kannst du dir natürlich nicht erlauben, zu sagen, alles klar, ich gehe jetzt hin und
Kai Ole Hartwig: Jetzt muss jeder hier diese Review machen.
Kai Ole Hartwig: 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.
Daniel Langemann: Ja.
Daniel Langemann: Ja.
Kai Ole Hartwig: Der eine macht das, dann revieut das der andere und beim nächsten Mal, das ist ja auch...
Kai Ole Hartwig: an für sich schon eine schwierige Situation, auch um vorbeizukommen.
Kai Ole Hartwig: 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,
Kai Ole Hartwig: Da kannst du natürlich anfangen, solche Prozesse gut zu spielen.
Kai Ole Hartwig: Wenn du natürlich nur zwei oder drei Personen bist, dann bist du natürlich darauf angewiesen, gewisse Sachen zu modifizieren.
Kai Ole Hartwig: Zum Beispiel, wie viele schauen sich etwas an.
Daniel Langemann: Ja, ja.
Kai Ole Hartwig: Völlig logisch.
Kai Ole Hartwig: Ich finde das aber auch nicht schlimm, dass man so Sachen modifiziert darin, dass sie für einen funktionieren.
Kai Ole Hartwig: Ähm,
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Und ich stelle mir auch vor, wie wir jetzt Pair-Programming mit der KI machen.
Kai Ole Hartwig: Im Sinne von, wir betrachten die KI wie die IDE und tippen da jetzt rein und reviewen das dann gleichzeitig zusammen, was da rauskommt.
Daniel Langemann: 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.
Daniel Langemann: 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
Kai Ole Hartwig: ja natürlich
Daniel Langemann: Und dann setzen die zwei sich hin und fangen an zu suchen, so was gibt es für Design-Pattern.
Daniel Langemann: Und das kannst du ja mit KI auch machen.
Daniel Langemann: 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.
Daniel Langemann: Also einer ist derjenige an der Tastatur, der andere sagt, was gemacht werden soll.
Daniel Langemann: So ein bisschen, das kommt dann auch automatisch, wenn der eine schon den Monitor teilt.
Daniel Langemann: 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.
Daniel Langemann: Man klatscht mal so schnell irgendwie so eine leere Klasse dahin, die so zwei Methoden hat, damit die keinen Compile-Fehler aufrufen.
Kai Ole Hartwig: Ja, ja.
Daniel Langemann: Und dann lässt du es mal laufen als POC.
Daniel Langemann: Und das wäre dann der Punkt, wo du sagst, okay, wir haben etwas, was technisch, haben wir uns eine Lösung ausgedacht.
Daniel Langemann: Den Code schreiben ist wie jetzt mit KI ja auch, das kann, traue ich jedem zu, dass er das alleine kann.
Daniel Langemann: 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.
Daniel Langemann: Also so die ganze Zeit per Programming jemanden beim Tippen zu gucken.
Kai Ole Hartwig: Ja, das ist ja nicht nur ein Zugucken, sondern es ist ja ein aktives Mitdenken und Mitarbeiten, theoretisch.
Daniel Langemann: Weißt du, wie blöd ich mich anhöre, wenn ich Shell-Befehle ausspreche?
Kai Ole Hartwig: Ja, ich lasse dann ja so implizit Sachen weg, wo ich von ausgehe, dass Gegenüber weiß, dass da jetzt ein Leerzeichen hinkommt.
Daniel Langemann: CD, Leerzeichen, SRC, Slash.
Kai Ole Hartwig: Und dann ist, ne, du musst nochmal zurück, du hast da, ne, so, ja.
Daniel Langemann: Du weißt die Parameter nicht auswendig auf der Konsole.
Daniel Langemann: Ja.
Kai Ole Hartwig: Oder ich weiß die dann ja auch nicht und dann sage ich, aha, ich muss mal eben nachschauen.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Das ist halt auch so ein bisschen.........
Daniel Langemann: 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.
Daniel Langemann: Also gerade bei diesem Pair-Programming, wo du sagst, so ihr, mach mal, geh mal in die und die Datei.
Daniel Langemann: 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.
Daniel Langemann: Und ich bin dann immer so, der zum Beispiel PHP-Storm mit den Anfangsbuchstaben so die Kombinationen weiß, damit ich zu der Datei komme.
Daniel Langemann: 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?
Kai Ole Hartwig: Ja.
Daniel Langemann: Und dann, keine Ahnung.
Daniel Langemann: Namespaces, ja.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Also wo kommt denn da ein S hinten dran?
Kai Ole Hartwig: So, und ich denke mir so, sorry, not sorry, ich habe eine Idee, die
Kai Ole Hartwig: 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.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Also so Sachen, ich finde, das sind so
Kai Ole Hartwig: überflüssige Informationen.
Kai Ole Hartwig: Ich speichere die einfach nicht.
Kai Ole Hartwig: Deswegen finde ich auch, so eine ganz schlimme Krankheit ist ja irgendetwas Utility zu nennen.
Daniel Langemann: Service.
Daniel Langemann: Es gibt so viele Services bei mir immer.
Daniel Langemann: Es tut mir so leid.
Kai Ole Hartwig: Und dann gibt es überall General Utility.
Kai Ole Hartwig: Ich denke mir so, what?
Kai Ole Hartwig: Ja.
Kai Ole Hartwig: Ja, oder Service oder Helper.
Kai Ole Hartwig: Aber Service finde ich fast noch nicht so schlimm.
Kai Ole Hartwig: Aber Utility und Helper...
Kai Ole Hartwig: Und ganz schlimm finde ich, ist mir jetzt vor kurzem aufgefallen, die Tendenz dazu, unter Classes direkt ausgeschrieben Data Transfer Objects abzulegen.
Kai Ole Hartwig: Alles ist auf einmal ein DTO.
Kai Ole Hartwig: Das ist auch für mich so ein
Kai Ole Hartwig: 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
Daniel Langemann: 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.
Kai Ole Hartwig: weiß ich auch nicht da das fühlt sich so falsch an ja
Daniel Langemann: Und das sind so einerseits die Momente, die ich mag, weil man dann nachfragen kann, warum machst du das?
Daniel Langemann: Was denkst du dir dabei?
Daniel Langemann: Also, wenn ich das schreiben würde, das kommt ganz falsch immer an.
Daniel Langemann: Und wenn man spricht, dann ist das wenigstens abgemildert.
Daniel Langemann: 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.
Kai Ole Hartwig: Warum machst du den Mist?
Daniel Langemann: Und
Daniel Langemann: Ja, wenn du die Hand dabei so am Kopf hast, ist das wieder schlecht.
Daniel Langemann: Genau.
Daniel Langemann: Naja, nein, aber dafür sind
Kai Ole Hartwig: Oder so die Kaffeetasse dabei schon so zitternd.
Kai Ole Hartwig: Was tust du da?
Kai Ole Hartwig: Ich kann mir das gut vorstellen, Daniel, wie du da versuchst, dich zu beherrschen und
Daniel Langemann: Nein, gar nicht.
Daniel Langemann: Sondern ich bin echt oft neugierig und denke mir so, warum?
Daniel Langemann: Also natürlich weiß ich für mich, was ich mir gerade denke, das ist echt keine coole Lösung.
Kai Ole Hartwig: Ja.
Daniel Langemann: Aber warum?
Daniel Langemann: Woher kommt das?
Daniel Langemann: 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.
Daniel Langemann: Und das bringt natürlich jeder mit und das merke ich auch in jedem neuen Projekt.
Daniel Langemann: 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.
Daniel Langemann: Die anderen wollen irgendwelche Registries, Manager, was auch immer.
Daniel Langemann: Und du bringst das dann immer so vom Projekt zu Projekt mit.
Daniel Langemann: 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.
Daniel Langemann: Also, das ist so.
Kai Ole Hartwig: Woher kommt die Idee, warum macht man was?
Kai Ole Hartwig: 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
Kai Ole Hartwig: annähert und vermeintlich zu zweit eine bessere Lösung findet als alleine.
Kai Ole Hartwig: Und das ist ja der interessante Teil.
Kai Ole Hartwig: Und was ja auch häufig passiert ist, je länger ein Team oder Menschen zusammenarbeiten, je ähnlicher wird sich der ganze Output.
Daniel Langemann: 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.
Kai Ole Hartwig: Das gleicht sich ja an.
Kai Ole Hartwig: Deswegen, manchmal ist es total spannend, wenn neue Leute einfach reinkommen, weil dann auch neue Ideen reinkommen und manchmal auch
Kai Ole Hartwig: auch lange vorherrschende Probleme sich lösen.
Kai Ole Hartwig: Ja, das war immer ich.
Kai Ole Hartwig: Also, Blame brauche ich nicht machen, das war immer meine dumme Idee.
Kai Ole Hartwig: Das ist mittlerweile meine Grundannahme.
Daniel Langemann: Welcher Spacko war das denn?
Daniel Langemann: Das hat mich mal in den Coach Review echt gebracht.
Daniel Langemann: Dann gucke rein und sage, boah, ist das ein Scheiß?
Kai Ole Hartwig: Wenn ich mich besonders viel aufrege über etwas und so, was ist denn das für ein Scheiß, dann
Daniel Langemann: Wer macht denn so einen Dreck?
Daniel Langemann: Macht das auf und da steht da mein Name.
Kai Ole Hartwig: Ja, wie kann man so einen Mist machen?
Kai Ole Hartwig: Ja, so innerlich schon so.
Kai Ole Hartwig: Dann... Ja, das ist dann so der Moment der Selbsterkenntnis.
Kai Ole Hartwig: Okay.
Daniel Langemann: Innerhalb einer Woche.
Daniel Langemann: Hm.
Kai Ole Hartwig: Ich habe mich weiterentwickelt.
Kai Ole Hartwig: Ich sehe Dinge heute anders.
Kai Ole Hartwig: Und ich finde, solange man das hat, ist das doch auch was Gutes.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: verabscheue fast schon und sage, Mist, das müssen wir auf jeden Fall refactoren.
Kai Ole Hartwig: Das können wir unter gar keinen Umständen weiter so laufen lassen.
Kai Ole Hartwig: Ja.
Kai Ole Hartwig: Ja.
Daniel Langemann: Aber man entwickelt eine eigene Handschrift oder ich denke mal, jeder Entwickler hat zum Teil auch eine eigene Handschrift.
Daniel Langemann: 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.
Daniel Langemann: Der eine neigt so dazu, irgendwo mehr Schleifen zu machen.
Daniel Langemann: Der andere hat so eher diese PHP-internen Array-Funktionen zum Beispiel lieber.
Daniel Langemann: Mancher hat so ein paar Sprünge mehr im Quelltext oder zieht die Sachen einfach länger.
Daniel Langemann: 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.
Daniel Langemann: Oder das könnte der Kollege geschrieben haben.
Daniel Langemann: Also noch nicht mal negativ, sondern da hat jeder so seine Handschrift.
Daniel Langemann: Und das fand ich auch immer sehr interessant, dass so Pairprogramming dazu führt, dass ich so die Denkmuster von dem anderen verstehe.
Daniel Langemann: Und
Daniel Langemann: 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.
Kai Ole Hartwig: Ja, klar, weil... Ja.
Kai Ole Hartwig: Nee, ich mag DTOs, aber DTOs gehören für mich ins Model und ähm
Daniel Langemann: Was dann dazu führt, dass ich Quelltext beim Lesen viel schneller wieder verstehe.
Daniel Langemann: 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.
Daniel Langemann: Wo ist die Factory, um das Problem zu lösen?
Daniel Langemann: Oder DTOs vielleicht?
Daniel Langemann: Zum Beispiel würde ich jetzt bei dir nie im Leben DTO suchen.
Daniel Langemann: Ja.
Kai Ole Hartwig: Und ich arbeite aber halt auch gerne mit Value Objects zum Beispiel.
Daniel Langemann: Ja.
Daniel Langemann: Oh ja, Naming.
Kai Ole Hartwig: Also einfach, ich bevorzuge es, wenn Dinge den richtigen Namen haben quasi.
Kai Ole Hartwig: Und der richtige Name ist ja ein komplett eigenes Ding, wo man Stunden verbringen kann, den richtigen Namen zu suchen und so Sachen.
Kai Ole Hartwig: Und ich mag es dann doch irgendwo am Tagesende, wenn so Konventionen, wo etwas liegt, eingehalten sind.
Kai Ole Hartwig: Weil ich finde, es gibt ja auch so eine Semantik und dann fügt sich das zusammen und das ist ja eigentlich erzählen,
Kai Ole Hartwig: Programme ja eine Geschichte.
Kai Ole Hartwig: Und jeder, der an dieser Geschichte mitschreibt, hat seinen eigenen Stil, die Geschichte zu schreiben und zu erzählen.
Kai Ole Hartwig: Und ich finde, das sieht man halt.
Kai Ole Hartwig: Und das merkt man auch.
Daniel Langemann: Also du beziehst das auch auf Namespaces oder Dateiparten?
Daniel Langemann: Mhm.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Ja, allgemein.
Kai Ole Hartwig: Das Gesamtding ist ja am Tagesende...
Kai Ole Hartwig: ist es ja in einer menschenverständlichen Sprache geschrieben, nicht in Maschinencode.
Kai Ole Hartwig: Und wenn man das so durchliest, dann kommt ja ein mehr oder weniger grammatikalisch korrektes Satzkonstrukt daraus.
Kai Ole Hartwig: Ja, ja, schon, ja.
Daniel Langemann: ich würde sagen, du erzeugst Bilder im Kopf.
Daniel Langemann: Also das passt eher so, diese Analogie zu einem Märchen.
Daniel Langemann: Wenn du Quältest liest, also da bauen sich Bilder bei mir im Kopf auf.
Daniel Langemann: Und wenn ich mit dir viel zusammengearbeitet habe, weiß ich, welche Metaphern du gerne benutzt.
Daniel Langemann: Und das kopiert sich dann viel schneller, glaube ich.
Kai Ole Hartwig: 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.
Daniel Langemann: Oder macht es mir leichter, diese Bilder dann abzurufen.
Daniel Langemann: Ja.
Kai Ole Hartwig: Aber das spricht halt sehr dafür, dass Code eigentlich auch eine Form einer natürlichen Sprache ist.
Daniel Langemann: Ja, definitiv.
Daniel Langemann: Das ist für Menschen, nicht für Maschinen.
Daniel Langemann: Oh mein Gott, ja.
Kai Ole Hartwig: Ja.
Kai Ole Hartwig: Boah, wie philosophisch.
Kai Ole Hartwig: Jetzt wieder die Frage...
Kai Ole Hartwig: 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?
Kai Ole Hartwig: 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.
Daniel Langemann: 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.
Daniel Langemann: Bei KI ist es mir mehrfach passiert, wo ich gesagt habe, ey, warum kommst du auf so eine Lösung?
Daniel Langemann: Das passt vorne und hinten nicht.
Kai Ole Hartwig: Also ich habe das auch, dass mich KI überrascht in beide Richtungen.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Und man merkt auch echte Unterschiede in der Qualität.
Kai Ole Hartwig: Aber es gibt zum Beispiel ein neues Paper von, wie heißt er denn jetzt gleich?
Kai Ole Hartwig: Dem Autor von The Art of Computer Programming.
Kai Ole Hartwig: Ich habe den Namen gerade vergessen.
Kai Ole Hartwig: 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.
Daniel Langemann: Ja, der Dude.
Daniel Langemann: Echt?
Daniel Langemann: Mhm.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Cloud Cycle hat das dann, Cycles hat das dann genannt.
Kai Ole Hartwig: Total spannend tatsächlich.
Kai Ole Hartwig: Also, und das ist auch das, was ich merke, dass auch,
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Nicht am besten, sondern am zufälligsten, mit am wenigsten Fantasiegeschichten, die eingebaut werden.
Daniel Langemann: müssen wir erwähnen, dass wir keine Werbung machen und nicht dafür bezahlt werden, Firmennamen zu nennen?
Daniel Langemann: Also ich bin nicht mit Cloud Code unterwegs.
Daniel Langemann: Vielleicht liegt das auch daran.
Daniel Langemann: Ja.
Daniel Langemann: Ja.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Also ich bin ja so, ich probiere das die ganze Zeit aus und ich behandle im Moment die
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Was sind denn deine Überlegungen dazu?
Kai Ole Hartwig: Oder auch zum Teil gehe ich jetzt mittlerweile
Kai Ole Hartwig: 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.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Deswegen sage ich ja, also ist es nicht schon, machen wir nicht jeden Tag mittlerweile Pair-Programming, wenn wir
Kai Ole Hartwig: KI-Agenten mit einsetzen.
Kai Ole Hartwig: Das müssen ja noch nicht mal Agenten sein, KI-Systeme.
Kai Ole Hartwig: Die arbeiten ja gar nicht so autonom an der Stelle.
Daniel Langemann: Also im weitesten Sinne ja.
Kai Ole Hartwig: Ja.
Daniel Langemann: Und dass man seinen Code reviewen lässt, also zum Beispiel CodeRabbit nutze ich auch gerne.
Daniel Langemann: 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.
Daniel Langemann: Und dann zu sagen, für den Rest bin ich zu faul.
Daniel Langemann: Diese an alle Stellen einen Nullcheck machen, wo einer sein könnte.
Kai Ole Hartwig: Ja.
Daniel Langemann: Weiß ich nicht, baue das hundertste for each rein und weiß ich nicht, iteriere darüber und hole irgendwelche Sachen raus oder filter erase.
Daniel Langemann: Die Sachen, dafür bin ich zu faul.
Daniel Langemann: 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.
Daniel Langemann: Und dann sage ich der KI, guck mal, das ist das Problem, so will ich das lösen.
Daniel Langemann: Und dann auch so wie du sagtest, schlag mal was anderes vor.
Daniel Langemann: Oder so nach dem Prinzip, überrasch mich mal.
Daniel Langemann: Und wenn es dann so passt, natürlich ist es dann immer so, super Idee, Daniel.
Daniel Langemann: Auf nichts Besseres wäre ich auch gekommen.
Daniel Langemann: Zumindest einfach nicht.
Kai Ole Hartwig: Ja, soll ich sagen, welches KI-Modell das sagt?
Kai Ole Hartwig: Ja.
Daniel Langemann: Da klingelt der Wecker immer.
Daniel Langemann: Und dann sage ich dir, bau das mal aus, implementiere mal das.
Daniel Langemann: Das sind die Akzeptanzkriterien.
Daniel Langemann: Das ist dann so dieser Boilerplate-Code, wo ich sage, den kann das Ding generieren.
Daniel Langemann: Das kann ich dann auch reviewen.
Daniel Langemann: Das ist dann auch so eine Codemenge, die hinten rauskommt, handelbar für einen Code-Review für mich nochmal.
Daniel Langemann: Also, dass ich die Code nochmal angucke, die KI generiert hat.
Daniel Langemann: Und ja, also irgendwie ist das schon per Programming, ne?
Kai Ole Hartwig: Ja.
Kai Ole Hartwig: Ein Venegrer Kaffee.
Daniel Langemann: Nur nicht so charmant.
Daniel Langemann: Das nächste Mal sitzt ich mit T-Shirts.
Daniel Langemann: Genau.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Jetzt ist schon wieder Werbung, ne?
Kai Ole Hartwig: Ich weiß nicht, ob andere das auch so können.
Kai Ole Hartwig: Also mit ChatGPT kann man auch reden.
Kai Ole Hartwig: Ja, ja.
Kai Ole Hartwig: Sorry.
Kai Ole Hartwig: Falls ihr einen Sponsoring-Vertrag machen wollt, schreibt uns.
Kai Ole Hartwig: Wir nehmen Geld.
Kai Ole Hartwig: Ähm.
Kai Ole Hartwig: Aber ich meine, es gibt jetzt tatsächlich diesen Command dafür, dass du mit dem System auch quatschen kannst.
Kai Ole Hartwig: Das habe ich noch nicht ausprobiert.
Kai Ole Hartwig: Das wäre natürlich mal eine ganz heiße Kiste, dass ich den ganzen Tag mit dem System einfach vor mich hin quatsche.
Kai Ole Hartwig: Aber ich glaube, dann bekomme ich auch Stress, wenn ich die ganze Zeit vor mich hier hin brabbel.
Kai Ole Hartwig: Mein Gegenüber findet das dann bestimmt irgendwann nicht mehr cool.
Daniel Langemann: Ja, das wäre echt interessant.
Daniel Langemann: Also muss ich mal gucken.
Daniel Langemann: Jetzt bin ich neugierig, weil... Äh?
Daniel Langemann: An...
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Ich habe das noch nicht validiert.
Kai Ole Hartwig: Ich bin im Moment total hin- und ergerissen.
Kai Ole Hartwig: Also es gibt Tage, da finde ich die Tools alle doof.
Kai Ole Hartwig: Und es gibt Tage, da bin ich wirklich glücklich darüber.
Daniel Langemann: 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.
Kai Ole Hartwig: Ja, das habe ich auch, ja.
Kai Ole Hartwig: Ja, das kannst du bei den anderen, glaube ich, auch.
Kai Ole Hartwig: So, ich... Ah, siehst du, da bist du weiter als ich.
Kai Ole Hartwig: Ja.
Kai Ole Hartwig: Ja,
Daniel Langemann: 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.
Daniel Langemann: Das ist… Nicht, dass ich das mache, aber ich könnte.
Daniel Langemann: Wieder ein Feedback, was keiner braucht, aber jeder haben will.
Kai Ole Hartwig: Perfekt.
Kai Ole Hartwig: Also stellen wir fest, wir mögen Pair Programming, wenn wir Menschen mögen und ansonsten machen wir es mit der KI.
Daniel Langemann: Das hat sich sehr zweideutig angehört.
Daniel Langemann: Ja.
Daniel Langemann: Was ist, wenn wir Menschen nicht mögen?
Daniel Langemann: Dann bleibt die KI.
Kai Ole Hartwig: Dann bleibt jetzt ja die KI.
Kai Ole Hartwig: Ich finde, das ist eine schöne Alternative geworden.
Kai Ole Hartwig: Gegenfrage, seit wann mögen Entwickler Menschen?
Daniel Langemann: Bis dann, ciao.
Kai Ole Hartwig: 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.
Kai Ole Hartwig: Bis dahin, denkt ans Liken, Abonnieren, Teilen und so weiter.
Kai Ole Hartwig: Ihr kennt das Spiel und wir sehen uns dann.
Kai Ole Hartwig: Macht's gut!
