#65 Clean Code macht Software langsam

Zerstört die Anwendung von Clean Code die Performance deiner Applikation?

Es war einmal Casey Muratori, ein Softwareentwickler mit Fokus auf Game-Engines, der sich ins Internet gestellt hat und sagte "Clean Code resultiert in schrecklicher Performance". Das YouTube-Video ging um die Welt, die YouTube-Kommentare wurden deaktiviert und Hackernews ging bis an die Decke. Auch der Kopf hinter "Clean Code", Uncle Bob, hat dies nicht auf sich sitzen lassen und ging in die Diskussion.

Diese Episode handelt genau um das genannte Video. Wir besprechen, was die Key-Message des Videos ist, wer der Autor ist, was Clean Code ist und von wem es stammt und um was sich die Diskussion zwischen Casey Muratori und Uncle Bob dreht. Eine Art "Reaction-Podcast", sozusagen.

Bonus: Was der heilige Gral der Teamentwicklung ist.

Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partners

Das schnelle Feedback zur Episode:

👍 (top) 👎 (geht so)

Sprungmarken

(00:00:00) Intro

(00:00:54) Reaction-Videos

(00:02:26) Video "Clean Code, Horrible Performance"

(00:04:39) Worum geht es im Video "Clean Code, Horrible Performance"

(00:07:43) Wer ist Casey Muratori?

(00:12:22) Was ist eigentlich Clean Code und wer ist Uncle Bob?

(00:15:14) Warum sollte ich Robert C. Martin zuhören?

(00:17:48) Objektiv messbare Elemente von Clean Code

(00:21:24) Diskussion zwischen Casey Muratori und Uncle Bob auf GitHub

(00:29:28) Performance-Probleme beim Emoji-Detektor im GitHub Editor

(00:31:29) Cycle Lean Code vs. Optimierung der Algorithmen

(00:35:00) Verschiedene Regeln von Clean Code werden als gut angesehen

(00:39:30) Beachtung von Performance in Clean Code

(00:41:04) Wartung von Software

(00:43:33) Warum man Uncle Bob nicht mehr zuhören sollte

(00:54:31) Engineering Kiosk Community

(00:55:00) Der heilige Gral der Team-Entwicklung

Hosts

Wolfgang Gassler (https://mastodon.social/@woolf)
Andy Grunwald (https://twitter.com/andygrunwald)

Feedback (gerne auch als Voice Message)

EngKiosk Community: https://engineeringkiosk.dev/join-discord
Email: stehtisch@engineeringkiosk.dev
Mastodon: https://podcasts.social/@engkiosk
Twitter: https://twitter.com/EngKiosk
WhatsApp +49 15678 136776

Transkript

Das Transkript wurde automatisiert per Speech-to-Text erstellt und kann daher Fehler enthalten.

Wolfi Gassler (00:00:03 - 00:01:05)

Über Jahre war Clean Code die Geheimwaffe, die behutsam von alten weißen Senior Developern als Geheimwaffe an jüngere Generationen weitergegeben wurde. Und jetzt das. Clean Code von Uncle Bob ist also Schuld, warum ich meinen alten Computer nicht mehr verwenden kann und alles so langsam geworden ist? Diese Aussage aus einem viralen YouTube-Video hat mich wirklich getriggert. Und damit willkommen zu einer neuen Episode des Engineering Kiosks, in der Andi und ich etwas tiefer in das Thema einsteigen. Wer kämpft denn da gegen Uncle Bob und Clean Code? Um was geht's eigentlich? Stimmt das Ganze? Und überhaupt, wer ist eigentlich dieser Uncle Bob? So Andi, was ist der coole, hippe Scheiß, den alle Influencer machen heutzutage? Mit dir über Influencer reden, das funktioniert nicht.

Andy Grunwald (00:01:06 - 00:01:06)

Okay.

Wolfi Gassler (00:01:06 - 00:01:15)

Also der hippe Scheiß ist, Reaction-Videos zu machen. Und nachdem wir keine Videos machen, sondern Podcasts, machen wir jetzt einen Reaction-Podcast.

Andy Grunwald (00:01:15 - 00:01:50)

Das habe ich schon mal gesehen. Und zwar habe ich das im Musikbereich sehr viel gesehen. Wenn irgend so eine Metal-Band, Emo-Core-Band, was weiß ich nicht, irgendwie so ein ganz komisches Video rausbringt, dann gehen die ganzen anderen Metal-Fans da drauf und schauen sich dann... Also du schaust dann Leuten zu, wie sie das Musikvideo schauen. Am Anfang hab ich gedacht, was ist das? Und dann kommentieren sie das. Und dann meinte ich so, es ist doch dieselbe Musik, also warum soll ich mir jetzt 25 Reaction-Videos ansehen? Und dann hab ich sogar gesehen, dass die Band, die das ursprüngliche Musikvideo rausgebracht hat, eine eigene YouTube-Playlist gebaut hat, wo es nur Reaction-Videos zu dem neuen Musikvideo gibt. Also ist irgendwie so ein bisschen so Reactionception.

Wolfi Gassler (00:01:50 - 00:01:58)

Also das gemeinsame Anschauen werden wir jetzt überspringen. Wir werden nur auf das Kommentieren gleich losgehen. Wir sind ja ein Podcast, der kommentiert, wenn.

Andy Grunwald (00:01:58 - 00:02:06)

Aber ist das denn jetzt das neue Format oder ist das jetzt einfach so, weil du ein Video gesehen hast, was dich wirklich getriggert hat?

Wolfi Gassler (00:02:07 - 00:02:32)

Na ja, um es genau zu sagen, ist es ja dein Video, das du gesendet hast bei uns in der Community und ich war natürlich zu faul, das anzuschauen und ein paar Tage später habe ich es mir dann angeschaut und dann bin ich wirklich getriggert worden, weil da schon Aussagen drinnen stecken, die, sagen wir mal, so schwierig sind. Aber zu dieser Diskussion kommen wir später. Aber erklär mal, warum du dieses Video gepostet hast und was da drin ist in diesem Video, weil es ist ja dein Link.

Andy Grunwald (00:02:32 - 00:03:12)

The Community lebt von Engagement. Und allein der Titel dieses Videos schüttet Öl ins Feuer. Clean Code Horrible Performance. Und ich dachte mir, immer wenn es um Clean Code geht, immer wenn es um Performance geht, da hat immer jeder eine Meinung. Und wenn man halt so einen Glaubenskrieg einfach in so eine Community schmeißt, Dann hab ich mich halt schon ein bisschen Engagement erhofft, so nach dem Motto, ja das ist ja gar nicht so und doch, Clean Code ist nur das einzig wahre und nein, Clean Code ist das doofe, weil wir müssen alles performant kriegen. Hat in der Community jetzt nicht so funktioniert, vielleicht sind sie alle irgendwie zu erwachsen. Schade. Ich hatte wenigstens gedacht, wir haben so ein bisschen Spaß mit Tabs vs. White Spaces, Clean Code vs. Performance.

Wolfi Gassler (00:03:13 - 00:03:37)

Ja, aber genau das ist eine coole Community, weil unsere Community hat einfach dann zusätzliche Links gepostet, zusätzliches Material, grundsätzlich auf der Meta-Ebene diskutiert und hat sich gar nicht auf diesen Flame War eingelassen. Ist sehr, sehr smart, diese Leute, muss man schon sagen. Darum machen wir jetzt den Flame War, weil du bist ja für diese Performance immer verantwortlich, Andi. Und du programmierst ja immer Tracking Code.

Andy Grunwald (00:03:37 - 00:04:13)

Aber weil unsere Community sich so gut vorbereitet hat und uns mit Material gefüttert hat, gibt es ja zum Glück andere Communities, die genau auf den Zug, den ich gerade angesprochen habe, aufspringen. Denn das Video Clean Code Horrible Performance hat in den letzten zwei Wochen 400.000 Aufrufe bekommen. Was ich für ein Clean-Code und Performance-Coding-Video schon sehr, sehr viel finde auf YouTube. Die Hacker-News-Diskussion hatte über 900 Kommentare. Beim YouTube-Video sind Kommentare sogar deaktiviert. Du merkst schon, das geht genau in diese Ich-pack-mal-mehr-Öl-ins-Feuer-Richtung.

Wolfi Gassler (00:04:13 - 00:04:39)

Ja, ich habe sogar die letzten Tage noch einen Kollegen angesprochen, das ist meine go-to-person, wenn es um so Code-Struktur und so weiter geht und sogar der hat es mitbekommen und der lebt eigentlich mittlerweile unter einem Stein, weil er recht frischer Vater ist und so weiter und sogar der hat es irgendwo mitbekommen auf Kanälen. Also scheinbar dieses Video kennt eigentlich eh schon jeder, darum brauchen wir es eigentlich gar nicht mehr erklären, aber Andi erklärt trotzdem, was geht ab in dem Video, damit wir endlich mal den Inhalt haben.

Andy Grunwald (00:04:40 - 00:06:36)

Also das Video ist circa 20 Minuten lang und verlinken wir natürlich auch in den Shownotes. Falls ihr das wirklich nicht kennt, macht mal kurz Pause, schaut euch das mal an. Aber worum geht's in diesem Video? Und zwar sieht man in dem Video einen Menschen namens Casey Muratori. Ich glaub ich hab den Namen richtig ausgesprochen. Was Casey in diesem Video tut, ist, er nimmt sich 5 Punkte, die er sagt, okay, die sind objektiv messbar, neben den ganzen anderen Regeln. Punkt 1 wäre Polymorphismus, das ist gut. If-Konstrukte und Switch-Konstrukte sind bad. Zweite Regel, Internals sollen nicht nach außen getragen werden, zum Beispiel Internals eines Objektes. Punkt 3, Funktionen sollen klein sein. Punkt 4, Funktionen sollen eine Sache machen. Und 5, das Dry-Prinzip, don't repeat yourself. Danach stellt er sich die Frage, wenn ich einen Code habe, der diese fünf Regeln folgt, also mehr oder weniger dann als clean gilt, wie ist denn die Performance von diesem Code? Als Beispiel nimmt er wirklich Quellcode aus dem originalen Clean-Code-Buch und führt dann darauf ein Performance-Benchmark aus und danach nimmt er sich den Code und ignoriert Regel für Regel von diesen fünf genannten objektiv messbaren Regeln bricht diese und führt den Benchmark erneut aus. Und somit hat er am Ende des Videos ein Performance Improvement bei Optimierung der Code Struktur. Im ersten Schritt vom anderthalbfachen Speed dann zum zehnfachen Speed bis hin zu einem Geschwindigkeitsimprovement von bis zu 24 mal so schnell. Und diese Performance Improvements vergleicht er dann immer mit, wir haben gerade zehn Jahre der Hardware Evolution. weggeschmissen und so weiter bei der Nutzung von Clean Code. Das ist so eigentlich der Inhalt des Videos. Dabei geht er aber noch nicht mal so weit und macht wirkliche Performance Optimierung wie Nutzung von einem bestimmten CPU Instruction Set oder ähnliches, sondern er strukturiert den Quellcode in der Regel nur anders ignoriert.

Wolfi Gassler (00:06:36 - 00:06:40)

Polymorphismus macht if switch statements statt polymorphismus.

Andy Grunwald (00:06:40 - 00:06:45)

Und so weiter und was ist eigentlich die die die finale message von dem video.

Wolfi Gassler (00:06:45 - 00:06:50)

Und um die geht es ja eigentlich das ist das ist wirklich der der kern des anstoßes.

Andy Grunwald (00:06:50 - 00:07:36)

Er sagt wenn du clean code befolgt beziehungsweise die ersten vier regeln denn er sagt auch, dass das Dry-Prinzip, don't repeat yourself, das kann ja drin bleiben, das ist völlig okay, sagt er, wenn du die ersten vier Regeln von Clean Code befolgst, dann wird dein Code langsam. Also Polymorphismus ist gut, If- und Else-Switches sind schlecht, Internals sollen nicht nach außen getragen werden, Funktionen sollen klein sein und Funktionen sollen eine Sache machen. Und er beharrt auf dem Standpunkt, du wirst mehrere Dekaden von Hardware-Performance-Development dadurch aufgeben und nicht zu deinem Benefit nutzen. Und wenn man sich ins Internet stellt und sowas rausposaunt und dann sogar dieses Video noch sehr viel Traction gekriegt, dann kann ich mir schon vorstellen, bringt das sehr viele Leute auf die Palme. Und das habe ich anscheinend, oder das hat Casey anscheinend auch bei Wolfgang geschafft.

Wolfi Gassler (00:07:37 - 00:07:48)

Was er nicht geschafft hat, ist, dass ich Subscriber von seinem Newsletter werde, weil da steckt ja sicher auch viel dahinter. Vielleicht erklär mal in zwei Sätzen, wer das überhaupt ist. Hast du den davor gekannt, vor diesem Video?

Andy Grunwald (00:07:48 - 00:09:03)

Ich hab ihn davor nicht gekannt und danach hab ich ihn mal gegoogelt und hab mich ein bisschen eingelesen. Also wer ist eigentlich Casey Muratori? Casey Muratori hat circa 70.000 Abonnenten auf YouTube. Er ist Softwareentwickler mit einem harten Fokus auf Forschung und Entwicklung für Spiele-Engines. ist also ganz offensichtlich im Game-Bereich unterwegs. Die meisten seiner YouTube-Videos drehen sich halt auch oft darum, meist in Form von Livestreams, Coding-Sessions. Generell sind seine Videos und sein Content sehr fokussiert auf performanceorientierte Programmierung. Kein Wunder, wenn er Spiele-Entwicklung macht. Und das sagt er ja auch. Das ist auch so ein bisschen Hintergrund des Videos. Was man ihm aber zugutehalten muss, ist, dass Teile seines Research- und seines Source-Codes auf Basis von SDKs in großen Spielen wie Age of Empires verwendet werden. Also schon eine beachtliche Leistung. Meine Frage an dich Wolfgang ist aber, und die habe ich mir danach auch gestellt, nachdem ich diesen Menschen gegoogelt habe, warum google ich diesen Menschen jetzt gerade? Warum schaffe ich mir Hintergrundinformationen auf? Weil warum ist das wichtig, wer er ist? Weil eigentlich sollten wir ja in einer respektablen Welt leben, wo sich jeder hinstellen kann und sowas behaupten kann, oder? Also welche Zusatzinformation bringt dir jetzt die Antwort? Wer ist Casey?

Wolfi Gassler (00:09:03 - 00:09:10)

Ja, das musst du mir sagen. Du hast ihn gegoogelt, ich habe ihn gar nicht gegoogelt. Ich habe nur kurz auf sein Profil geklickt, habe nichts gesehen, bin wieder weg.

Andy Grunwald (00:09:10 - 00:09:20)

Ja, ich finde es eigentlich schade, dass ich ihn gegoogelt habe und dass ich dann seinen Hintergrund mit in die Bewertung von dem, was er da sagt, einfließen lasse. Das mache ich sehr wahrscheinlich unterbewusst.

Wolfi Gassler (00:09:20 - 00:09:28)

Hast du ihn gleich gegoogelt, wie du das Video angeschaut hast, oder hast du ihn gegoogelt, wie ich in unsere Notes reingeschrieben habe? Wer ist eigentlich dieser Typ?

Andy Grunwald (00:09:28 - 00:09:29)

Zweiteres.

Wolfi Gassler (00:09:29 - 00:09:35)

Okay, dann hast du ja, Entschuldigung, dann hast du es ja nur gemacht, weil ich das wissen wollte für unsere Episode heute.

Andy Grunwald (00:09:35 - 00:10:04)

Ich muss aber auch sagen, jetzt, wo ich weiß, aus welcher Ecke er kommt und worauf er spezialisiert ist, sehe ich das Video gar nicht so reißerisch, wie glaube ich die meisten Leute es wahrnehmen. Sondern, du sagst es ja auch immer, ich bin immer ein Fan von Kontext. Und den Kontext habe ich halt jetzt auch. Und deswegen, ich bin ja immer ein Freund davon, Menschen zu verstehen, warum machen sie das, was sie tun, warum sagen sie das, was sie sagen. Und den Kontext von ihm, also seine Perspektive, ist ja jetzt für mich klar.

Wolfi Gassler (00:10:05 - 00:11:24)

Ja, aber es ist schon was anderes, wenn er jetzt sagen würde, in der Spieleindustrie ist Performance so wichtig und wir können nicht immer Clean Code machen. Es ist völlig valide. Aber was er ja sagt ist, die Software heutzutage ist so so langsam und Schuld daran ist Clean Code. Wir können auch gerne diese Stelle noch mal kurz einspielen. Die Antwort auf die Frage, warum die Software so langsam ist, ist, dass es nur wegen des Quote-unquote sauberen Codes geschieht. Diese Teile der Anweisungen sind alle absolut schrecklich für die Leistung. Ihr solltet sie nie wirklich machen. Sie wurden ausgestaltet, weil jemand dachte, sie würden mehr verhältnismäßige Codebases produzieren. Aber selbst wenn es wahr ist, dass sie mehr verhältnismäßige Codebases produzieren, müsst ihr fragen, was das kostet. Und das ist natürlich schon ziemlich direkt, wenn man sagt, okay, Clean Code ist schuld daran, dass eben heutzutage alles so langsam ist. Und ich kenne das ja selber von mir. Du hast einen alten Laptop und der wird immer, immer langsamer mit der Zeit. Und nicht, weil der Laptop langsamer wird, sondern weil einfach die Software irgendwie aufwendiger wird und alles langsamer wird. Und die einfachsten Dinge, die früher super schnell waren, sind plötzlich super langsam. Wobei das natürlich auch die Wahrnehmung von uns ist, dass wir vielleicht gewöhnt sind, dass Sachen schneller sind als früher, was früher einfach als schnell angesehen wurde.

Andy Grunwald (00:11:24 - 00:11:26)

Hast du schon mal die Festplatte in der Zwischenzeit defragmentiert?

Wolfi Gassler (00:11:27 - 00:11:31)

Hatten wir das Thema nicht schon mal? Muss man das bei SSDs noch? Muss man nicht mehr, oder? Schätze mal.

Andy Grunwald (00:11:32 - 00:11:51)

Nee, bei SSDs muss man es nicht mehr, aber das war immer so früher der Running-Gag, da hast du dann irgendwie jede Woche defragmentiert, weil du hattest halt das Gefühl, dass dein Betriebssystem oder dein Computer langsamer wurde, was vielleicht so war oder auch nicht, ist relativ egal, aber du hattest nach der Defragmentierung immer ein gutes Gefühl, weil du warst ja alles wieder geordnet. Die Bits und Bytes werden ja zusammengeschoben.

Wolfi Gassler (00:11:52 - 00:12:21)

Ich überlege gerade, ob bei SSD irgendeinen Vorteil gibt, je nachdem, ob du da, wenn du da Read Ahead oder irgendwas hast, ob da trotzdem Vorteile entstehen, wenn die Daten irgendwie näher beieinander liegen. Aber wahrscheinlich ist es wirklich rein random. Okay, so tief bin ich jetzt in der SSD-Technik auch nicht drin, ob man da trotzdem noch was rausholen könnte, theoretisch mit Defragmentierung. Aber das zeigt ja eigentlich schon, wir haben superschnelle Festplatten-SSDs und trotzdem wird alles langsamer. Und das war ja seine Key-Aussage. Der Grund dafür ist Clean Code.

Andy Grunwald (00:12:22 - 00:12:34)

Okay, du reitest jetzt so auf CleanCode rum. Hol mal alle Leute ab, inklusive mir. Erklär uns mal, was CleanCode ist und warum ist das so bekannt und warum ist das so ein Hype und warum ist das jetzt auf einmal schlecht?

Wolfi Gassler (00:12:34 - 00:12:51)

Also hoffentlich kennt jeder CleanCode und hat es schon mal gehört, der irgendwie programmiert. Und zwar ist es ein Buch von Robert C. Martin, besser bekannt als Uncle Bob in der Szene. Ist zum ersten Mal 2008 erschienen, also gar nicht so alt eigentlich.

Andy Grunwald (00:12:51 - 00:12:55)

Naja, 15 Jahre, ne? In JavaScript Framework Terms.

Wolfi Gassler (00:12:55 - 00:15:14)

Da hatte ich schon meinen Mastertitel, da war ich schon am Doktormachen. Also das ist wirklich spät. Das heißt, es ist rausgekommen, nachdem ich mein Studium eigentlich abgeschlossen habe. Auf jeden Fall ist es eigentlich ein kleines, gar nicht so langes Buch, kann man also wirklich empfehlen, dass das jeder mal durchliest. Und darin beschreibt da Uncle Bob eben Vorgehensweisen, Strukturierungen, wie man schönen, clean Code, der wertbar ist, gerade wenn man im Team arbeitet, wie man den schreibt und welche Regeln man da beachten sollte. Und da geht es um ganz logische Dinge wie keep it simple, dass simple besser ist, dass die Komplexität reduced werden soll, damit man eben auch Code leichter versteht, Boy Scout Rule, also die Pfadfinderregel, dass wenn man irgendwo ankommt, dass man das immer schöner hinterlassen soll, als wie man es vorgefunden hat. Also wenn man irgendwo mitmacht und was anderes sieht, was man schnell fixen kann, soll man das gleich mitfixen. Solche grundlegenden Dinge, wie macht man richtiges Naming, wie benennt man Funktionen, Variablen, Funktionen sollen möglichst klein sein, auch Data Structures und Objekte sollen möglichst klein sein, immer eine Aufgabe haben, interne Strukturen verstecken, auch das, was der Casey angreitet, was es dann langsamer macht, wie man richtig testet, welche Patterns man verwendet und so weiter. Also wirklich die Klassiker, die man kennt, damit man eben sauberen Code am Ende rausbekommt, der wartbar ist, der langlebiger ist, der die Wartung vereinfacht, verkürzt und auch den Einstieg zum Beispiel von neuen Leuten in dem Team, dass die einfach möglichst schnell im Code drinnen sind und nicht ewig lang brauchen, um irgendwas zu verstehen. Und dieser Uncle Bob hat eigentlich Eine lange Historie und gilt so als der große Kopf hinter dem Ganzen, war auch beim Agilen Manifesto mit dabei, hat eben dieses Clean-Code-Buch geschrieben, hat auch die Solid Principles in seinem damaligen Paper mehr oder weniger erfunden im Jahr 2000. Also auch gar nicht so lange her, dieser ganze Trend, die Softwareentwicklung ein bisschen zu strukturieren, ist eigentlich genau in den 2000er-Jahren entstanden. und ist eigentlich ein ganz bekannter Speaker. Man findet tausende Videos auf YouTube, Artikel, Blog-Einträge und man könnte ihn fast so als Guru des Clean Codes sehen.

Andy Grunwald (00:15:14 - 00:15:43)

Und warum sollte ich jetzt Robert C. Martin aka Antel Bob zuhören? Also wer ist das? Weil ich könnte mich ja auch hinstellen und sagen, ich schreibe jetzt ein Buch über Dirty Code und führe ganz viele Argumente auf, Warum ein guter Hack einfach besser ist als jede saubere Architektur. Und vielleicht finde ich auch ein paar Anhänger, aber im Endeffekt stellt sich die Frage, wer ist eigentlich dieser Andi und warum sollte ich dem zuhören, dass ein guter Hack einfach besser ist als jede Architektur. Also wer ist Onkel Bob? Ich weiß nicht, was er gemacht hat, aber wer ist das?

Wolfi Gassler (00:15:43 - 00:16:51)

Ja, der hat sich einfach einen Namen gemacht durch seine ganzen Veröffentlichungen und gerade in den 2000er Jahren, wo halt die Softwareentwicklung immer, immer wichtiger geworden ist, ist halt auch diese ganze Wartbarkeit, wie erstellt man denn gemeinsam Software und Code, viel, viel wichtiger geworden. Und da ist er halt als großer Berater auch aufgetreten, hat viele Firmen natürlich beraten, hat diese ganzen Publikationen gemacht und hat sich dadurch einfach diesen guten Ruf aufgebaut und scheinbar hat es halt auch ganz viele Firmen funktioniert. Und ich kenne eigentlich wenige Entwickler, die grundsätzlich gegen diese Clean Code Welle schwimmen, außer jetzt den Casey. Und vielleicht hinter vorgehaltener Hand sagen das sehr viele, dass Clean Code vielleicht nicht so viel Sinn macht. Aber jeder, der schon mal in einem Team gearbeitet hat, kennt schönen und nicht so schönen Code und schwer lesbaren Code. Und da macht es natürlich durchaus Sinn, solche Patterns und Regeln zu befolgen, um zu diesem schönen Code zu kommen. Und der Typ ist halt einfach seit 70 Jahren in der Branche. Und da gibt's halt wenig, die so viel zu dem Thema gesprochen haben und Informationen erstellt haben. Aber er ist kein Professor oder so was zum Beispiel.

Andy Grunwald (00:16:51 - 00:16:58)

Soviel ich weiß, ist Uncle Bob gerade 71 Jahre alt. Ich weiß dann nicht, ob der gleich 70 Jahre in der Branche ist. Vielleicht ist er 70 Jahre verwählt, aber.

Wolfi Gassler (00:16:58 - 00:17:04)

... Okay, das war ein bisschen übertrieben, ja, er ist 71 Jahre, aber er ist schon lange in der Branche unterwegs, würde ich mal sagen.

Andy Grunwald (00:17:04 - 00:17:08)

Da haben wir jetzt also einen Typen, der rennt durch die Welt und predigt seit 2008.

Wolfi Gassler (00:17:08 - 00:17:10)

Seit 2000 eigentlich.

Andy Grunwald (00:17:11 - 00:17:17)

Oder seit 2000 irgendwelche Pfadfinderregeln für Sourcecode. Okay, habe ich verstanden. Und dann haben wir auf der anderen Seite.

Wolfi Gassler (00:17:17 - 00:17:20)

Hast du's gelesen, das Buch? Hast du Clean Code gelesen?

Andy Grunwald (00:17:20 - 00:17:35)

Am Anfang meiner Karriere, ja, aber ich hätte dir jetzt nicht mehr die ganzen Regeln nennen können. Und ich muss auch zugeben, damals als ich gelesen hab, war ich auch voll Fan und dann bin ich natürlich auch durch den Code gelaufen und hab das versucht anzuwenden und ja, so nach dem Motto, ich hatte ja neuen Hammer, ja, und hab dann immer nur Nägel gesucht.

Wolfi Gassler (00:17:36 - 00:18:24)

Und wir können da gerne noch einen Link verlinken, so ein GitHub-Gist, das das Ganze nochmal zusammenfasst, einfach die Überschriften und die Oberpunkte, ist ganz praktisch, um das wieder aufzufrischen. Und man muss das ja auch unter dem Aspekt sehen, wenn man sich heute Programmierung ansieht und was für Zeit in Softwareentwicklung fließt, dann ist es halt ganz oft Wartung, Bugs ausbessern, kleine Änderungen, ein Feature hinzufügen, gerade wenn man langlebige Software natürlich hat. Und wenn man da natürlich Zeit rausholen kann, dann hat man extrem viel gewonnen, weil die eigentliche Zeit, Code zu erstellen, im Vergleich zu der Lebensdauer von Software, ist ja super, super klein. Und wenn ich da nur ein paar Prozent rausholen kann in der Wartung, die dann vielleicht 80 Prozent von der Lebensdauer von der Software ausmacht, dann habe ich da natürlich viel gewonnen.

Andy Grunwald (00:18:24 - 00:18:48)

Also ich denke, dass umso mehr Erfahrungen du in deinem Job als Software-Ingenieur bekommst, desto eher wendest du diese Regeln aus dem Code automatisch an. Zum Beispiel ist einer dieser Design-Regeln, dass du Multithreading-Code separieren solltest. Heutzutage würde ich mich auf den Standpunkt stellen, wenn du es nicht tust, kommst du automatisch in Race-Conditions. Also das ist so mein Standpunkt gerade.

Wolfi Gassler (00:18:49 - 00:20:14)

Ja, das ist natürlich der Punkt, wo es auch wieder ums Bugfixen geht. Wenn der Code natürlich leichter zu verstehen ist, leichter zu debuggen ist, dann bist du da natürlich auch viel schneller. Und es geht halt meiner Meinung nach nicht nur zumindest um diese Performance vom Code an sich, sondern auch eben um die Wartung, um die Erstellung, um das Verstehen, um das Onboarding und alles, was rundherum mitspielt. Und das stellt halt Casey jetzt in Frage. Und es ist ja auch so, dass Casey in dem Video, der pickt sich ja jetzt die vier Sachen raus, er sagt, dass die messbar sind. Don't Repeat Yourself hat er netterweise noch mitgenommen. Aber das ist ja ein Buch voller voller Regeln und Ideen. und er pickt sich halt genau vier raus und macht das ganze dann auch noch auf dem Code, der das vorzeigt, im Buch, was ja okay ist, aber man muss ja auch sagen, das ist ein Code, um einfach mal zu beschreiben und zu erklären, um was es eigentlich geht bei Clean Code. Also wenn man den jetzt herausnimmt, so ein einfaches Beispiel, und da alle Function Calls aufruft und so weiter. Klar kann man da viel rausholen, weil der eigentliche Teil, der irgendwas berechnet, ist natürlich super klein, weil bei diesen Beispielen geht es ja wirklich nur um die Struktur. Und wenn die eigentliche Berechnung so so klein ist, dann macht die ganze Struktur, die Function Calls, alles rundherum natürlich viel viel mehr aus, als wenn ich jetzt irgendwie ein Programm habe, was ganz viel berechnet und ich da dann die eine oder andere Funktion rausstreiche oder ein Virtual Function Call mache durch Polymorphismus.

Andy Grunwald (00:20:14 - 00:20:59)

Naja, also das Buch Clean Code hat jetzt so 50, 60, 70 verschiedene Regeln. Und einen Punkt muss ich Casey schon geben, nicht alle sind wirklich objektiv messbar. Wir haben jetzt hier zum Beispiel eine Regel, die um die Benahmung geht und das heißt, use searchable names. Ist relativ schwierig, objektiv messbar zu machen. Zumindest bei einem Computer, wenn ich ein Programm über meine Software laufen lasse und sage, das ist clean. Auf der anderen Seite hast du natürlich andere Regeln, die du befolgen solltest, zumindest nach Clean Code, die auch objektiv messbar sind, wie zum Beispiel, dass du keine negativen Conditionals benutzen solltest, also in If-Abfragen oder Ähnliches. Das kannst du halt auch schon sehr objektiv messen, das nimmt jetzt Casey nicht raus.

Wolfi Gassler (00:20:59 - 00:21:01)

Was sind denn negative Conditionals?

Andy Grunwald (00:21:01 - 00:21:24)

Sowas wie if not. Fu oder ähnliches. Du solltest dann eher auf den Wahrwert prüfen. Das ist ja schon objektiv messbar, das nennt Casey jetzt nicht in seinem Video mit hoher Wahrscheinlichkeit, weil ob du jetzt auf den positiven Fall prüfst oder negativen, hat mit der Performance in der Regel nichts zu tun. Also da kann man so ein bisschen sagen, hm, pickst du dir hier vielleicht gerade nur die Rosinen raus, ja, nein.

Wolfi Gassler (00:21:24 - 00:22:06)

Aber das wirklich coole an dieser ganzen Geschichte ist ja, und das hat uns jemand aus der Community, der Simon dann gesendet nach dem Video, ist ja, dass es da eine Diskussion jetzt gibt zwischen Uncle Bob und Casey. und zwar eine sehr, sehr tiefgehende. Und was ja noch cooler ist, die machen das über GitHub und zwar nicht über irgendeine coole Discussion Function oder sonst was in GitHub, sondern die haben einfach ein Repository und machen Commits zu einem Markdown-File und antworten sich da wie in einem Chat mit sehr tiefgehenden Messages. Und alleine das ist schon cool zu erwähnen, wie man Git verwenden kann, um quasi ein Diskussionsforum zu machen, wo jeder mitlesen kann. inklusive allen Komits und Rechtschreibfehlern, die man ausbessert.

Andy Grunwald (00:22:06 - 00:22:35)

Auf der einen Seite finde ich das sehr, sehr geil, dass Uncle Bob sich da hinstellt und sagt, okay, lass mal drüber sprechen. Auf der anderen Seite muss man ja auch sagen, Casey greift so ein bisschen Uncles Bob Reputation an und er muss sich jetzt ein bisschen verteidigen. Also vielleicht ist das auch einfach so die Flucht nach vorne, bevor der Shitstorm kommt und und Casey mehr Fans kriegt. Also ich weiß noch nicht ganz, wie ich die ganze Diskussion einschätzen sollte. Auf jeden Fall habe ich mir sie durchgelesen.

Wolfi Gassler (00:22:35 - 00:23:05)

Und man muss vielleicht auch noch dazu sagen, die ist ongoing. Also jetzt, wir nehmen gerade am 20.3. auf und die diskutieren noch immer. Also da ist gerade gestern wieder was dazugekommen und vorgestern. Also wenn wir die Episode wahrscheinlich ausstrahlen, wir verlinken das natürlich auch, könnt ihr wahrscheinlich noch viele, viele Messages, die sehr, sehr, sehr, sehr in die Tiefe gehen, muss man auch dazu sagen, durchlesen, wenn euch diese Diskussion interessiert. Und es ist, wie gesagt, cool zu sehen, auf welcher Ebene man sowas diskutieren kann.

Andy Grunwald (00:23:05 - 00:23:26)

Das Schöne an dieser Diskussion ist, da unterhalten sich zwei sehr erwachsene und sehr erfahrene Menschen auf einem, meines Erachtens nach, sehr hohen Level, ohne persönlich zu werden. Und das liest man im Internet selten, besonders wenn YouTube und Hacker News involviert ist. Da wird's halt oft schon persönlich. Aber da geht's halt, hab ich wirklich das Gefühl, so rein um die Sache.

Wolfi Gassler (00:23:26 - 00:23:41)

Sie probieren es zumindest auf einer sehr sachlichen Ebene zu spielen, auch wenn das natürlich schwierig ist und Bob hat schon mal gemeint, das Video ist auf der rhetorischen Seite schon teilweise sehr angriffig und das finde ich auch, aber sie probieren in dieser Diskussion wirklich auf der sachlichen Ebene zu bleiben.

Andy Grunwald (00:23:41 - 00:24:16)

Ja, die Diskussion startet ja genau damit. Uncle Bob sagt so, hey, pass mal auf, danke für das Video. Rhetorisch ist es nicht ganz, wo ich sagen würde, okay, da stimme ich zu. Also, er pickiert sich da so ein bisschen über die Wortwahl. Auf der anderen Seite muss ich sagen, Casey wäre nie zu dem Punkt gekommen, wo Uncle Bob sich mit ihm auf GitHub auf eine Diskussion einlässt, wenn er nicht so provozierend gewesen wäre. Und dann wäre das nämlich noch ein Video über 10.000 Videos über Clean Code auf YouTube und dann wäre das nie so viral gegangen. Also bedeutet, du musst halt schon ins Feuer stechen.

Wolfi Gassler (00:24:16 - 00:24:18)

Der Klimakleber-Approach.

Andy Grunwald (00:24:18 - 00:24:19)

Der was?

Wolfi Gassler (00:24:19 - 00:24:21)

Der Klimakleber-Approach.

Andy Grunwald (00:24:21 - 00:25:21)

Ja, so ungefähr. Ist halt so ein kleiner Clean-Code-Radikalist vielleicht, ja? Oder Performance-Radikalist. Naja, auf jeden Fall, Bob stellt sich ziemlich schnell auf den Standpunkt und sagt, hör mal, pass mal auf, die meiste Software, die draußen rumschwirrt, braucht weniger als ein Prozent der Power von modernen CPUs, von modernen Prozessoren. Er sagt, Prozessoren sind günstig und durch diese zwei Gründe kann man den Trade-Off der Programm-Performance, der Software, der technischen Performance austauschen, um dafür die Performance vom Entwicklerteam zu erhöhen und somit weitere Systeme zu erstellen, beziehungsweise die existierenden Systeme am Laufen zu halten. Und da kommt gerade Clean Code, Da sagt er, okay, er hat nie gesagt, dass Clean Code die Programmperformance improved. Wenn du wirklich versuchst, jede Nanosekunde aus einer GPU rauszuholen, dann ist Clean Code mit hoher Wahrscheinlichkeit nicht das Beste, was du anwenden solltest.

Wolfi Gassler (00:25:21 - 00:26:28)

Aber wenn du jede Nanosekunde, wenn man das so nennen will, aus einem Team rauspressen willst, also ein Team möglichst effizient zu machen, schnell und performant, dann ist Clean Code das Richtige. Aber er sagt natürlich auch, dass es gewisse Bereiche gibt in der Softwareentwicklung, sie nennen da am Anfang IDEs oder diskutieren über IDEs zum Beispiel, dass in einer IDE der Parser an sich super schnell sein muss, weil der ist einfach immer an, der muss immer deinen Code parsen, der muss irgendwelche Vorschläge machen, das muss also super schnell sein, aber wenn man als Config Menü aufmacht und irgendwelche Settings verstellt in der IDE, dann braucht diese Oberfläche zum Beispiel nicht super schnell sein, weil man die einfach sehr sehr selten braucht. Wenn man eine JavaScript-Core-Engine schreibt, die muss super schnell sein. Da geht es um jene Nanosekunde. Aber das sind halt nur gewisse Bereiche. Und wenn man den Großteil der Softwareentwicklung anschaut, was wir so tagtäglich programmieren, dann ist es sehr selten irgendein Browser und sehr, sehr oft irgendein Window, irgendein Formular, irgendwelche Workflows, irgendwelche Business-Workflows, die man abbildet. Und selten eben die Game-Engine, die Casey programmiert.

Andy Grunwald (00:26:29 - 00:26:53)

Und da ist er wieder, mein Freund der Kontext. Und das finde ich gerade so schön. Also Anke-Bob stellt sich ja und sagt, hey, pass mal auf, ja, Clean Code mag jetzt hier nicht das performanteste sein, aber in 99 Prozent der Fälle braucht man das nicht. Und die Leute, die dann wirklich diese Nanosekunde aus jedem Code rausbrauchen, die sind dann aber auch so erfahren, die wissen, wann man jetzt hier welche Clean-Code-Regel brechen sollte.

Wolfi Gassler (00:26:53 - 00:27:46)

Aber ich habe da zum Beispiel gestern mit einem Kollegen gesprochen, der an dem Datenbankkern entwickelt. Und der hat eben auch gemeint, gerade kürzlich, er hat so viele Probleme gefunden in dem Code und so schwer lesbaren Code gehabt, dass er da selbst dann so eingebremst wird, bis er den Code versteht und so viel Zeit verliert, dass es schon auch die Frage ist, wurde da wirklich ein Trade-Off gemacht und bewusst das gemacht, weil die Performance ein Problem war oder wurde da einfach dreckig programmiert? Und ich glaube, das ist ja das grundsätzliche Problem. Wie viele Leute machen das wirklich bewusst und sagen absichtlich, okay, da gehe ich jetzt diesen Trade-Off ein, dass ich schlechtere Wartbarkeit habe, weil ich unbedingt diesen Speed brauche. Oder gehe ich grundsätzlich hin und sage, ich werfe diese ganzen Clean-Code-Regeln über Bord, weil das grundsätzlich performanter ist, weil ich weniger Virtual-Function-Calls habe oder solche Dinge.

Andy Grunwald (00:27:47 - 00:28:08)

Ja, mir fallen immer zwei Sachen bei dem ein, was du gesagt hast. Auf der einen Seite, ist das überhaupt für andere nachvollziehbar, dass jetzt hier gerade ein Trade-Off angegangen wurde? Also steht das überhaupt irgendwo? Ich bin immer ein Freund davon, einen kleinen Kommentarblock da hinzuschreiben, eine kleine Story zu erzählen. Hör mal, pass mal auf. In der Regel würde ich das sowieso und so lösen, aber ich gehe jetzt diesen Trade-off ein aus Gründen ABC.

Wolfi Gassler (00:28:08 - 00:28:20)

Ja, aber der macht ja diesen Switch noch unlesbarer, der da achtfach verschachtelt in der Loop ist und so weiter. Drum lasst mir da natürlich die Kommentare auch noch weg, weil dann versteht man den Code ja leichter. Da waren jetzt Ironie-Tags dran, um dir das zu erklären.

Andy Grunwald (00:28:21 - 00:29:25)

Wir sind hier auf der Audiospur, also keine Ahnung, ob man deine Quote in Quote Krähenfüße mit deinen Fingern alles so sieht. Auf jeden Fall, das ist für mich so der erste Grund, so nach dem Motto, wurde hier bewusst ein Trade-Off eingegangen? Und wenn da ein Kommentar steht, dann weiß ich, okay, hier hat sich jemand Gedanken gemacht. Die zweite Geschichte ist, denke ich, dass es performanter oder habe ich es wirklich gemessen, weil was ich immer sehe oder was ich sehr oft sehe, ist, dass Leute sagen, oh, das ist performanter und so weiter und so fort, aber sie testen es gar nicht. Also sie haben keine Vergleichsgrundlage. Und wenn doch, dann sind diese Performance-Teste in der Regel nicht reproduzierbar oder auf deinem lokalen Laptop und nicht auf einem Server. Also da ist das Environment irgendwie sehr laborähnlich. Beispiel, ich kann einen John-Deere-Mähdrescher im Labor, ja, hat der eine super Power. Wenn dein Feld trotzdem mega nass ist, dann kannst du es trotzdem nicht dreschen. Also es ist halt, in Produktion sind halt andere Gegebenheiten als bei deinem Performance Test auf deinem Laptop. Das ist immer so die zweite Geschichte von Problemen, die ich immer bei der Aussage, die du gerade gemacht hast, in der Praxis sehe.

Wolfi Gassler (00:29:25 - 00:30:02)

Es ist ja auch sehr schön in der Diskussion zwischen Uncle Bob und Casey, kommt ja dann Casey mit einem Beispiel daher aus der realen Welt und zwar, weil er gerade in dem GitHub Editor, indem er die Diskussion schreibt und seine Antworten schreibt, zeigt, dass der plötzlich super langsam wird. Wenn der Paragraph irgendwie länger ist, macht er einen kleinen Screencast davon und stellt das auf YouTube online als Beweis. Sieh her, das ist so ein Klassiker. Es wird einfach langsamer und das kann es doch nicht sein, auf einem superschnellen CPU, dass plötzlich, während ich tippe, dass diese Buchstaben erst mit einem Riesendelay in dem Editor ankommen.

Andy Grunwald (00:30:03 - 00:31:26)

Um was geht's da in diesem Beispiel? Und zwar wird die ganze Diskussion in einem Markdown-File auf GitHub geführt. Und beide sind sehr gut, lange Paragrafen zu schreiben, also wirklich mehrere Sätze in einer Zeile ohne Zeilenumbruch zu machen. Und was der GitHub-Markdown-Editor macht, ist, der schaut sich immer an, ist da ein Doppelpunkt irgendwo? Weil auf GitHub mit einem Doppelpunkt leitet man einen Emoji ein. Und sofern ein Doppelpunkt in diesen Paragrafen ist, und umso länger man schreibt, umso langsamer wird das Tippverhalten in deinem Editor, weil der Emoji-Checker prüfen muss, oh, da war ein Doppelpunkt irgendwo. Jetzt muss ich immer zurückgucken bei jedem Buchstaben, der getippt wurde, ob die getippten Buchstaben zu einem Emoji passen. Der algorithmische Fehler hier war jetzt, dass sie die Länge, also wie lang ein Emoji-Name sein kann, nicht begrenzt haben. Und das kann sein, dass er dann immer halt so 50, 60, 80, 100 Charakter zurückguckt. Und dann haben sie in dieser Diskussion diesen Emoji-Parser da ein bisschen reverse-engineert und haben gesagt, ja, pass mal auf, wenn du hier ein zweites Doppelpunkt addest, dann wird das wieder schnell. Und AkelBob so, ja, wir können auch einfach die Paragrafen öfter umbrechen, das geht eigentlich auch. Auf jeden Fall, das war so ein relativ lustiger Sidetrack, wo die Diskussion ein bisschen abgedriftet sind, aber wo dann beide so in die Sidetrack-Richtung gegangen sind.

Wolfi Gassler (00:31:27 - 00:33:02)

Aber genau das zeigt ja auch schon super gut, wo das eigentliche Problem von Softwareentwicklung liegt. Es ist ja ganz, ganz selten diese Mikrooptimierung, die du da irgendwo machst oder der Function Call, sondern du hast irgendeinen beschissenen Algorithmus, der schlecht durchdacht ist, der schlecht implementiert ist, der vielleicht gar nicht durchdacht ist, eine externe Library, und die machen die Probleme. Und selten ist es dieser Function Call oder Virtual Function Call von Polymorphismus, der dir die Zeit kostet. Oder wenn du eine Funktion aufteilst in drei Funktionen, dass du drei Function Calls hast. Und heutzutage machen die das mit JIT-Compiler und so weiter sowieso, die ganzen Compiler und Programmiersprachen sehr viel Wetter am Ende und du hast diese Probleme gar nicht mehr. Also dass du auf so einer unteren Ebene wirklich optimieren musst in manchen Bereichen, ja. Und wenn es wirklich langsam ist, verstehe ich das. Aber ganz oft ist es am Ende der Emoji-Picker, der das Problem ist. Ich glaube, das spiegelt das eigentlich sehr gut wider, das Ganze. Und ich glaube, man kann sehr viel aus Code rausholen, wenn man sich mal überlegt, okay, wie sieht mein Algorithmus aus? Wo sind die Schwachstellen von meinem Algorithmus? Wo könnte in Performance Probleme laufen bei dem Algorithmus? Wie kann ich den Algorithmus optimieren? Und wir haben da ja eigene Episode dazu gemacht über die O-Notation, über die Komplexität von Algorithmen, Laufzeitkomplexität. Wenn ich da irgendwo was verbessern kann für meine Laufzeitkomplexität, dass ich plötzlich statt 10.000 Schleifendurchläufe nur mehr 1.000 habe, da hole ich mir zehnmal mehr raus, als wenn ich irgendwo ein Function Call optimiere oder ein Switch Statement verwende.

Andy Grunwald (00:33:03 - 00:34:18)

Uncle Bob bezeichnet das, was Wolfgang gerade beschrieben hat, als sogenannten Cycle-Lean-Code in der Diskussion. Und er sagt auch zu Casey, ja das, was du da machst, ist eigentlich Cycle-Lean-Code. Und Cycle-Lean-Code kann die Effizienz um eine Größenordnung deines Codes vielleicht steigern, aber die richtige Wahl des Algorithmuses kann die Effizienz um mehrere Größenordnungen deines Codes steigern. Und Clean Code bezieht sich halt primär nicht auf die Anwendung des richtigen Algorithmuses, sondern eher, wie strukturierst du den Algorithmus bzw. wie programmierst du den Algorithmus oder die Funktion und den Code um den Algorithmus. Und das Lustige ist, bei dieser ganzen Emoji-Story, die haben sich jetzt auch gar nicht angesehen, ob der Emoji-Parser selbst Clean Code verwendet oder nicht. Also das hat mir so ein bisschen bei der Diskussion gefehlt. Also da hab ich mich so ein bisschen gefragt, okay, warum gehen wir jetzt hier runter? Klar, dann konnten sie einmal Cycle Lean Code droppen und dann mal gesagt haben, okay, wähl mal lieber den richtigen Algorithmus. Und der richtige Fix für den Algorithmus wäre jetzt aber wahrscheinlich gewesen, begrenze mal die Länge eines Namens für ein Emoji. Und dann wäre das Problem gegessen. Aber ja, die richtige Wahl des Algorithmus ist nicht einfach. Und ich glaube, das ist auch der größte Bestandteil von sogenannten Lead Code Interviews bei Big Tech, ne?

Wolfi Gassler (00:34:19 - 00:37:33)

Ja, wobei auch da muss ich wieder sagen, ist die Frage, wo du den Algorithmus verwendest. Wobei der Emoji-Programmierer oder die Programmiererin hat sich wahrscheinlich auch nicht gedacht, dass das vielleicht irgendwann mal ein Problem wird, dass da irgendwelche Leute so lange Paragraphen schreiben und den Code-Editor dafür verwenden. Insofern kann man sagen, man sollte immer irgendwo optimieren. Aber unsere Zeit ist halt trotzdem endlich und ich glaube, man muss priorisieren, was einfach wichtiger ist. Und wenn ich ein Hardcore-Datenbank- oder JavaScript-Engine-Entwickler bin, kann ich da sicher auf einer anderen Ebene arbeiten, als jetzt irgendwer, der irgendwelche Formulare programmiert. Ganz klar. Und was auch noch bei dieser Diskussion dazukommt und rauskommt, ist eigentlich, dass Casey schon einige Sachen als richtig bezeichnet. Sie diskutieren da zum Beispiel auch über Tests, wann man Tests schreiben soll, wie man Tests schreiben soll. Klar, da gibt es kleine feine Unterschiede, aber beides sind der Meinung, Tests sind wichtig. Auch dass man deskriptive Namen für Variablen zum Beispiel verwendet, da ist ja auch kein Speed-Nachteil eigentlich dabei. Also da sind auch beide der Meinung, dass der Code besser und verständlicher wird dadurch. Also es gibt ganz viele Regeln in diesem Clean Code, die Code auf jeden Fall besser machen und die Casey auch als gut ansieht, die beide als gut ansehen. Und es geht halt um ein paar Dinge, wo sie wirklich diskutieren und ein Problem damit haben. Was man halt auf keinen Fall machen sollte, ist sich jetzt irgendwie denken, okay, Clean Code ist Bullshit, weil einfach so viele Regeln sehr, sehr gut sind. Und wenn ich mal überlege, wie wichtig das ist, sinnvolle Namen zu haben alleine in dem Programm und wie grausam unübersichtlich das wird, wenn man einfach kurze Variablennamen hat mit A, B, C, D oder sowas, was auf der Uni leider immer noch gang und gäbe ist, muss ich dazu sagen, in ganz, ganz vielen Vorlesungen. Ich habe es damals nicht anders gemacht, wie Übungsaufgaben teilweise erstellt habe, weil man halt einfach faul war, kurze Variablen Namen eingebaut hat, verwendet hat, keine Kommentare, ist ja nur ein super kurzer Code, irgendwie 20, 30 Zeilen und da macht man das nicht. Aber wenn man das halt nie vorlebt oder Clean Code liest und das dann dementsprechend vorlebt, dann lernt man das halt auch nie. Und das ist, was mich zum Beispiel auf der Uni immer noch extrem stört, dass keiner sich über solche Dinge Gedanken macht. Also keiner will jetzt nicht sagen, aber ganz, ganz viele Leute sich nicht Gedanken drüber machen. Und dann jeder, der durch die ganze Uni geht, ist gewöhnt, abc als Variablennamen zu verwenden. Und man lernt das einfach nie ordentlich und darum finde ich es schade, wenn man dann einfach das gesamte Clean Code Buch irgendwie schlecht redet oder auch nur vielleicht unbewusst schlecht redet und alle, die das dann gewohnt sind und auch auf dem Zug aufspringen, das ist ja alles kompliziert und Clean Code kostet mich so viel Zeit und ich muss da irgendwie dann schöne Sachen machen und da bekomme ich noch ein Code Review. wo ich irgendwie mitbekomme, was ich nicht alles besser machen soll, und das dauert nur Zeit. Und am Ende ist dann so ein Video draußen, wo ich sage, ah, genau der hat ja recht. Und ich habe schon immer gesagt, das ist alles Bullshit und ich kann einfach dreckig dahin programmieren. Und das ist, glaube ich, genau das Falsche, was eben das Video aber durchaus erreichen kann, dass eben die Leute, die gegen Clean Code sind, dass die jetzt eine Unterstützung haben und sagen, da gibt es jemanden, der uns jetzt endlich das Gegenteil beweist, dass Clean Code Bullshit ist.

Andy Grunwald (00:37:33 - 00:37:39)

Naja, in der Diskussion sagen Sie jetzt mal wegen der Variablenbenennung schon beide Punkte, ja?

Wolfi Gassler (00:37:39 - 00:37:45)

Ja, ja, in der Diskussion schon, aber in dem Video eben nicht. Und wer liest sich denn diese Diskussion durch?

Andy Grunwald (00:37:45 - 00:38:21)

Ja, ich hoffe, das wird später nochmal in einem Video aufgearbeitet. Von mir aus auch in einem Reaction-Video. Aber wegen der Benahmung ist es so, beide sind einig, beschreibende Variablennamen sollten genutzt werden. Uncle Bob erwähnt aber auch noch, hey, wenn du eine Funktion oder eine Methode hast, die zwei, drei Zeilen lang ist, dann ist das auch völlig okay, wenn man irgendwie ein A oder ein B nennt, oder ein I. Aber wenn diese Methode dann zehn, 15 Zeilen lang wird, dann wird aus dem I für ihn halt auch ein Index. Und das, finde ich, sage ich, ist okay, ja? Also, wenn die Funktion und Methode relativ gescoped ist, weißte, sehr, sehr übersichtlich, sehr, sehr einfach, dann kann man so was mal eben machen.

Wolfi Gassler (00:38:21 - 00:38:24)

So eine Vergleichsfunktion zum Beispiel, die man dann irgendwie reinreicht.

Andy Grunwald (00:38:24 - 00:38:30)

Ja, oder klassisch sind diese Sort-Funktionen. Da hat man auch immer I und J. Und man vergleicht einfach nur ...

Wolfi Gassler (00:38:30 - 00:38:32)

Das hab ich grad gemeint mit Vergleichsfunktion.

Andy Grunwald (00:38:33 - 00:39:03)

Ja, siehste? Da sind wir doch auch d'accord. Oder bei den Tests, die du angesprochen hast. Den Bereich der Diskussion find ich super. Du hast einen, Ankel Bob, der sagt, okay, Tests first, Test-Driven-Development. Ich schreib immer erst einen Unit-Test, der failt, und danach schreib ich die Implementierung. Dann hast du auf der anderen Seite Casey und sagt, ja, Tests kosten eigentlich sehr, sehr viel Zeit, wenn sie keine Fehler finden. Und im Endeffekt einigen sie sich da drauf, ja, hey, pass mal auf, wir beide sagen, Tests sind sinnvoll, nur wann wir diese Tests schreiben, ist ein bisschen anders.

Wolfi Gassler (00:39:03 - 00:39:04)

Oder wie viele.

Andy Grunwald (00:39:04 - 00:40:18)

Oder wie viele. Ich, also ich mit Bob, schreibe Tests, Solange es keinen guten Grund gibt, diese nicht zu schreiben, du, du Casey, schreibst Tests nur, wenn es einen guten Grund gibt, diese zu schreiben. Und diese Unterscheidung finde ich sehr schön, wie sie sich da irgendwie von einem Streitpunkt auf einen mehr oder weniger gemeinsamen hinkommt. Eine Sache, die ich aber sehr, sehr, sehr, sehr, sehr schön finde in der Diskussion, ist, Casey bringt als Kritikpunkt an, dass das Thema Performance in dem ganzen Clean-Code-Buch und in den neunstündigen Kursen, die Uncle Bob auf YouTube veröffentlicht hat, kein einziges Mal erwähnt wird. Und die Antwort von Uncle Bob ist, hey, die Kritik ist valide, ich werde das beim nächsten Mal mit einbauen. Das muss ich zugeben, wow. Und danach sagte Casey auch, okay, also eigentlich ist dieser Nudge, den ich hier gerade platziert habe, nur das, was ich erreichen wollte. Und das finde ich schon schön, das finde ich schon von beiden Seiten, dass sie sagen, okay, ja, du hast einen validen Punkt gefunden und gegebenenfalls sollte ich mich da mal irgendwie verbessern oder das in meiner nächsten Beratung irgendwie mit einfließen lassen. Also das fand ich schön zu sehen und hat mich auch ein bisschen zum Grinsen gebracht.

Wolfi Gassler (00:40:19 - 00:41:39)

Ja, ich glaube sowieso, wenn man Sachen dogmatisch sieht, ist sowieso immer ein großes Problem und wahrscheinlich kann man bei Clean Code auch einzelne Bereiche durchaus diskutieren, ganz klar, aber ich glaube man sollte eben, und das macht man halt mit so Videos, klar, man will da möglichst viele Views bekommen und vielleicht einen reizerischen Titel haben, Clickbait, was auch immer, Aber wenn man das halt auf so einer oberflächlichen Ebene betrachtet, wo dann die Message am Ende Clean Code ist Bullshit rauskommt und das macht eine schlechte Performance, dann ist es genau gleich wenig sinnvoll, wie wenn man sagt, okay, alles bei Clean Code ist perfekt und du musst alles dogmatisch anwenden, weil Software eben komplexer ist und das spielt sich auf ganz vielen Ebenen ab. Aber meine grundlegende Haltung ist schon, baue mal Clean Code. Wenn es Performance-Probleme gibt, kümmere dich um die Performance-Probleme. Aber am Anfang ist meiner Meinung nach Wartbarkeit im Vordergrund, vor allem, wenn es eine langlebende Software ist. Und die meiste Software ist langlebig, muss man auch dazu sagen, und wird im Team entwickelt. Und wenn jetzt ein Newcomer, sei es im Team, sei es ein Newcomer in der Firma, zehnmal so lange braucht, um irgendwas zu verstehen oder zu ändern, dann ist es am Ende, glaube ich, schmerzvoller für alle Beteiligten und schlechter für die Software, als wenn die Performance um ein, zwei, drei Prozentpunkte Langsamer ist.

Andy Grunwald (00:41:39 - 00:41:50)

Meiner Berufserfahrung nach ist die meiste Software langlebig. Langlebig. Ja, das war... Meiner beruflichen Erfahrung nach ist die meiste Software langlebig. Das ist richtig. Wird aber nicht gewartet.

Wolfi Gassler (00:41:50 - 00:42:35)

Aber umso wichtiger ist es, glaube ich, wenn man, ich kenne ja auch so Software, die greift man dann vier Jahre später an, wenn man da schöne Kommentare geschrieben hat und das Ganze wertbar ist, dann ist man so glücklich, wenn man dann eine Änderung ganz, ganz einfach machen kann mit ein paar Zeilen. Also ich habe mich da schon so oft gefreut, wo ich mir gedacht habe, habe ich wirklich schön gemacht damals. habe ich wirklich vorausschauend gemacht und jetzt habe ich eine Änderung. Super einfach. Und dann gibt es diesen Code, wo ich mir denke, um Gottes willen, was habe ich da für ein Bullshit gebaut? Und ich muss hunderttausend Sachen ändern und es funktioniert überhaupt nicht. Und wenn man den Unterschied mal erlebt hat, dann weiß man eigentlich, wie viel das wert ist und wie viel Freude man sich da auch selber machen kann. Und ich spreche jetzt nur von Code, den nur ich selbst programmiere. Da spreche ich gar nicht von Code, den die im Team irgendwie bearbeiten.

Andy Grunwald (00:42:35 - 00:43:00)

Wenn ich Code sehe von mir, den ich vor vier Jahren geschrieben habe, Da kann ich mir damals noch so viel Mühe gegeben haben, heutzutage sage ich, oh was habe ich denn da gemacht, das müsste ich neu schreiben, weil ich in den letzten vier Jahren sehr wahrscheinlich zehnmal mehr gelernt habe, wie ich das jetzt besser machen kann. Also es ist sehr selten, dass ich in dieser Situation renne, die du darauf beschrieben hast, oder du hast die letzten vier Jahre einfach nichts gelernt Wolfgang, das könnte natürlich auch sein.

Wolfi Gassler (00:43:01 - 00:43:26)

Das ist, weil du so ein Programmierer bist, der immer alles neu machen will. Ich schaue da einfach drüber hinweg und bin froh, dass ich was schnell ändern kann und dass das von der Struktur einigermaßen sauber war, dass das dreckiger Code ist womöglich und dass man es besser machen hätte können. Das ist eh immer so. Aber man kann dann schnell eine Änderung machen. Man muss ja nicht immer den gesamten Code betrachten und da einen Schönheitswettbewerb machen. Also du musst da pragmatischer herangehen. Du bist immer der Pragmatiker, Andi. Jetzt willst du wieder alles neu programmieren.

Andy Grunwald (00:43:26 - 00:43:30)

Das klingt gerade so ein bisschen so, boah, komm du mal in mein Alter, dann wirst du auch so müde wie ich.

Wolfi Gassler (00:43:30 - 00:43:45)

Ja, wir sind beide noch nicht in Uncle Bobs Alter mit 70 Jahren. Darum haben wir auch noch keine sexistischen Witze und womöglich irgendwelche Trump Unterstützer Tweets im Gegensatz zu Uncle Bob. Aber zumindest sind wir auf der Clean Code Ebene auf der gleichen Wellenlänge.

Andy Grunwald (00:43:45 - 00:43:54)

Für alle, die Wolfgang jetzt gerade nicht folgen können, und zwar im ganzen Dunstkreis von diesem Video, was wir hier besprochen haben und in dieser GitHub Diskussion ist noch ein zweiter Link gefallen.

Wolfi Gassler (00:43:55 - 00:43:58)

Danke, Christian, übrigens für den Link in unsere Community.

Andy Grunwald (00:43:58 - 00:44:23)

Der Link ist schon ein bisschen was älter, fast zwei Jahre alt, aber das ist eigentlich ein Blogpost, worum es primär geht, ist, warum die Meinung von Uncle Bob gegebenenfalls nicht mehr gefolgt werden sollte. Und in dem Blogpost geht's nicht nur um Clean Code, sondern auch um Clean Code. Aber da geht's auch so ein bisschen um die Person, und da geht's halt in die Richtung, wie er sich politisch äußert, dass er ein weißer CIS-Mann ist und so weiter und so fort. Alles etwas schwierig.

Wolfi Gassler (00:44:23 - 00:44:35)

Also es geht nicht darum, dass er weißer Zisman ist, sondern wie er sich dann verhält mit seinen sexistischen Kommentaren. Aber wie gesagt, ist halt ein 70 Jahre alter weißer Amerikaner. Uncle Bob trifft den Namen auch sehr gut.

Andy Grunwald (00:44:35 - 00:45:57)

Aber in dem Blogpost geht es auch um technische Argumente, die ich auch sehr interessant fand. Also zum Beispiel wird in dem Blogpost erwähnt, dass sich jemand mal ein Open Source Projekt von Uncle Bob angesehen hat. Und zwar heißt das Fitnesse oder Fitness. Man hat dieses Open-Source-Projekt darauf untersucht, inwieweit Uncle Bob denn selbst die Clean-Code-Regeln dort anwendet. Und siehe da, es wurden Stellen gefunden, die mit hoher Wahrscheinlichkeit nicht Clean-Code entsprechen. Das ist eine Kritik. Die zweite Kritik ist, dass man viele Sachen, die in Clean-Code eigentlich als Regeln dargestellt werden, heutzutage mit modernen tools und mit deren modernen compiler regeln ja abfangen kann besonders wenn man jetzt hier so an kotlin swift und rust denkt und da lehnt sich halt ankel bob so ein bisschen aus dem fenster sagt man passt mal auf tools sind nicht die antwort also die einzige antwort ist wirklich Programming Disziplin, weil der Root Cause immer ist, dass Programmierer einfach faul sind und Shortcuts nehmen oder unter Zeitdruck sind oder dass zu viele Programmierer sagen, okay, das muss so sein und ja, es ist Zeitdruck, deswegen geben wir jetzt hier den Shortcut. Und dass seine allgegenwärtige Lösung ist, dass wir das Level von Software Disziplin und Professionalismus erhöhen müssen und dass wir nie, nie, nie Entschuldigungen für sogenannte Sloppy Work machen sollen.

Wolfi Gassler (00:45:57 - 00:48:08)

Also was mir bei diesem Blogartikel ein bisschen stört und ich bin jetzt kein Unterstützer von von Uncle Bob oder will Uncle Bob da irgendwo in Schutz nehmen, weil seine sexistischen Aussagen sind einfach unterm Hund und Meiner Meinung nach geht es um die Clean-Code-Sache an sich und es hilft mir nichts, wenn ich jemanden persönlich angreife und sage, dadurch ist Clean-Code irgendwie nicht sinnvoll. Nur weil Uncle Bob in irgendeinem Repository schlechten Code geschrieben hat, heißt es ja nicht, dass Clean-Code und die Herangehensweise dadurch schlecht ist. Es kann sein, dass er Wasser predigt und Wein sauft oder wie es so schön heißt, das kann durchaus sein, aber es hat ja jeder irgendwelche Leichen im Keller und jeder schreibt mal Dreck in Code, muss man auch dazu sagen, aber wie gesagt, es hat ja mit dem Clean Code an sich nichts zu tun, nur weil Uncle Bob eine schlechte Person ist zum Beispiel. Und ich würde die Tools-Geschichte auch eher von der anderen Seite sehen. Sauberen Code zu schreiben ist schon wichtig und Tools, die mir da irgendwie Unterstützung geben, die sind gut, sollte man auch verwenden. Aber ich würde mir auch nicht auf den Tools ausruhen. Aber wo man sehr wohl auf die Tools setzen kann, ist, dass die ganzen Compiler wesentlich besser werden und wir mittlerweile eben aus meinem vielleicht schönen, clean Code, der langsamer ist, einen schnellen, performanten Code im Hintergrund bauen. Und da kann ich wirklich auf Tools setzen und wirklich extrem viel rausholen. Und wenn man gerade an den ganzen Hotspot Detections und so weiter, wo im Hintergrund wirklich viel, viel passiert und wir gar nicht drüber nachdenken müssen, weil wir damit keinen Kontakt haben. Und ich glaube, es ist besser, dort Tools zu nützen und dort die Optimierung anzusetzen, wo es darum geht, okay, beim Kontakt zur CPU, zum Computer, dort kann ich optimieren, dort kann ich die Verbesserung machen. Aber wenn es um den menschlichen Kontakt geht im Team, wo man im Team zusammenarbeitet, Da kann man natürlich auch Tools einsetzen, aber wenn der Grundcode besser ist und einfacher verständlich ist, dann brauche ich gar keine Tools, brauche mich nicht darauf verlassen. Und ich glaube, das Arbeiten ist dann für jeden einfacher und erleichtert für alle im Team die Arbeit mit dem Code. Ohne Tools, mit Tools, was auch immer. Egal, was wer verwenden will und wenn man mit dem VI drauf zugreift, ist er genauso verständlich.

Andy Grunwald (00:48:09 - 00:48:56)

Naja, du sagst jetzt wieder, Andi, du kommst jetzt wieder mit deiner Wischi-Waschi-Meinung an. Mein Problem ist eigentlich seine Extreme in der Hinsicht. Ja, nein, Tools lösen das Grundproblem nicht. Ja, und vielleicht ist das auch richtig, dass Tools nicht das Grundproblem lösen, weil Tools ja nur ein Hilfsmittel sind. Der Grund, weswegen ich sage, das ist ein Extrem, ist relativ einfach. Wenn man sich da hinstellt und sagt, ja, pass mal auf, Viel zu viele Programmierer sind zu faul und nehmen Shortcuts und alles. Ja, mag vielleicht sein und ja, vielleicht sollten wir alle mehr Professionalität an den Tag legen. Auf der anderen Seite erhöht das aber auch die Hürde für neue Leute reinzukommen in die Programmierung, weil, Viele Leute wissen es einfach nicht besser und keiner kann erwarten, dass wenn du mit etwas anfängst, dass du sofort auf einem Wissensstand bist wie jemand, der 10, 15 Jahre Erfahrung hat.

Wolfi Gassler (00:48:56 - 00:49:12)

Aber das erwartet sich ja auch niemand. Für das gibt es ja Code Reviews, für das wächst man ja in ein Team hinein. Wir haben ja eigene Episoden zu Code Reviews gemacht und für Newcomer, die ins Team kommen und so weiter. Also wo liegt da das Problem? Es setzt ja niemand voraus, dass du auf die Welt kommst mit dem Wissen.

Andy Grunwald (00:49:12 - 00:49:40)

Naja, wenn ich mir hier Uncle Bobs geschriebene Meinung so durchlese, dann liest man das halt schon zwischen den Zeilen. Es geht ja immer nur darum, ich red ja über das, wie er seine Meinung jetzt hier schreibt. Ich red ja nicht darum, wie die ganze Welt ist mit Code Reviews. Ich bin ja ein Freund davon, von guten Code Reviews. Aber wenn ich mir das so hier anlese, dann sieht das alles hier sehr, sehr, sehr direkt aus. Und ohne ... Wir können jetzt hier auch links oder rechts gehen.

Wolfi Gassler (00:49:40 - 00:50:49)

Er ist sehr dogmatisch, das stimmt. Und darum meine ich auch. Also ich glaube, man muss das von dieser Person entkoppeln. Das, was er geschrieben hat, macht Sinn. Und die ganze Herangehensweise macht Sinn. Und man darf Clean Code nicht gleichsetzen mit Uncle Bob, nur weil er ein Dogmatiker ist und wie gesagt teilweise auch viel Bullshit verbreitet, heißt es ja nicht, dass der Approach vom Clean Code an sich schlecht ist. Und ich glaube, das muss man einfach von dieser Person entkoppeln. Und wie du am Anfang gesagt hast, manchmal macht es vielleicht Sinn, gar nicht den Background einer Person zu googeln, sondern man bewertet einfach die grundlegende Herangehensweise, die grundlegende Meinung, die zum Beispiel in dem Video verbreitet wird und nur die, und darüber kann man dann diskutieren. Beziehungsweise muss man dann für sich selber immer entscheiden, was macht Sinn. Und wie gesagt, es macht nicht jede Clean-Code-Regel absolut Sinn, aber ich glaube, wenn man die mal verfolgt, macht es durchaus Sinn und natürlich sollte man sich immer hinterfragen und auch im Kontext dann, wenn es um Performance geht, hinterfragen, macht es in dem Fall Sinn, muss ich das dogmatisch folgen oder kann ich das zum Beispiel aufweichen, weil mir jetzt einfach die Performance zu wichtig ist. Und dann aber mit gutem Grund aufweichen und vielleicht auch kommentieren, wie du es gesagt hast.

Andy Grunwald (00:50:49 - 00:50:55)

Ich stimme dir zu, aber Wolfgang, tut mir leid, so funktioniert die Welt nicht. Das, was du da rauspackst, ist eine Sache.

Wolfi Gassler (00:50:55 - 00:51:00)

Ja, meine Welt schon. Wie du immer sagst, mach mir meine Welt wie sie mir gefällt.

Andy Grunwald (00:51:00 - 00:52:18)

Das was du da rauspackst ist ja eine Sache. Das kannst du kontrollieren. Was du nicht kontrollieren kannst, ist wie es gelesen wird. Und wie es aufgenommen wird. Ich würde mir wünschen, mehr Leute sehen die Welt so wie du. Ja, man sollte das entkoppeln von dem, was man sagt, aber das könnte man auch über gewisse Sätze von Adolf Hitler sagen. Ja, ja, das, was Adolf Hitler damals gesagt hat, verstehst du? Das ist für mich irgendwie keine... Weiß ich nicht, ob das eine wirklich valide Argumentation ist, weil Adolf Hitler war trotzdem ein scheiß Mensch. Was ich sagen möchte, so ist die Welt halt nicht. Das ist genauso wie, nehmen wir mal einen ganz anderen Vergleich, der aber meines Erachtens nach relativ gut passt. Jeder sagt DevOps-Engineer. Und dann im zweiten Satz sagt jeder, ja, DevOps ist aber kein Jobtitel. Aber im dritten Satz heiern sie trotzdem für einen DevOps-Engineer. Es ist ... Jeder weiß, dass DevOps eine Kultur ist, blabliblub. So funktioniert aber die Industrie, weil vielleicht wir alle zu müde geworden sind, dagegen zu argumentieren und die Sache zu berichtigen. Und genau so ist es hier bei Uncle Bob und bei Clean Code. Wenn du rausgehst, geh mal in irgendeine Firma, geh mal auf irgendein Meetup und sprich mal über Clean Code. Und dann fragst du, wer hat's geschrieben? Oder was ist das erste, was sich einfällt, wenn ich sage Clean Code? Da wird keiner sagen, Polymorphismus ist besser als If-Switch-Statements, sondern sagen, Uncle Bob, Robert C. Martin.

Wolfi Gassler (00:52:19 - 00:53:28)

Ja, du vielleicht schon. Ich habe bis vor kurzem weder gar nicht mehr gewusst, dass das der Onkel Bob geschrieben hat oder ob das der Fowler ist. Ich verwechsel die zwei sowieso immer. Und das, was du gesagt hast, ist, man muss die Meinung von der Person trennen. Das finde ich nicht. Also die Meinung und die Person gehören zusammen. Also wenn jemand Bullshit verbreitet, dann ist die Person und seine Meinung auch bei mir unten durch. Aber Clean Code ist ja mehr als eine Meinung. Clean Code ist ja eine Herangehensweise, eine Technik. Also nur weil Leute, die absoluten Bullshit verbreiten, auch sagen, die Klimaerwärmung stimmt, heißt das ja nicht, dass die Klimaerwärmung Bullshit ist, nur weil diese Person Bullshit ist. Also das eine hat mit dem anderen nichts zu tun. Meinung und Person gehören meiner Meinung nach zusammen, aber eine grundlegende Haltung, irgendwie ein Themenbereich, irgendwas, was sich weiterentwickelt hat, so wie Clean Code, Meiner Meinung nach gehört Clean Code nicht an Uncle Bob. Der hat vielleicht dieses Buch geschrieben, aber das ist ja ein Konzept, ein allgemeines Konzept, wo ganz viele Leute dahinter stehen, wo ganz viele Leute geforscht haben in dem Bereich. Und diese zwei Sachen muss man, glaube ich, entkoppeln von der Person. Aber seine Meinung ist seine Meinung und die gehört zusammen. Und wenn er unten durch ist, interessiert mir seine Meinung auch nicht mehr.

Andy Grunwald (00:53:29 - 00:54:13)

Dann beende ich diese Podcast-Episode jetzt mal von meiner Seite, weil bevor ich dann hier bei Wolfgang noch unten durchs Gitterratter. Wir verlinken alle Dokumente, alle Diskussionen, alle YouTube-Videos, alle Blogposts, über die wir gesprochen haben, unten in den Shownotes. Nehmt euch mal ein bisschen Zeit und lest euch ruhig die Diskussion mal durch. Es ist inzwischen ein sehr langer Read, aber auch sehr interessant. Nach dieser Episode werde ich diese Diskussion nicht mehr befolgen, weil ich habe mich, glaube ich, jetzt schon zu viel mit dem Thema beschäftigt und habe mir, glaube ich, von links und rechts alle Meinungen angehört. Aber ich muss auch zugeben, ich bin jetzt nicht so passioniert, jede Nanosekunde aus meinem Source-Code rauszuholen und ich bin auch nicht so passioniert, super sauberen Code zu schreiben, denn ich denke, immer noch ein guter Hack hält eh länger.

Wolfi Gassler (00:54:13 - 00:54:28)

Von daher... Du bist einfach zu pragmatisch und zu wischiwaschi, Andi, das ist eindeutig. Aber ich bin eh deiner Meinung, man sollte nicht allem dogmatisch folgen, alles hinterfragen, macht definitiv Sinn und von mehreren Quellen vielleicht das Ganze auch bewerten lassen, egal was es ist.

Andy Grunwald (00:54:28 - 00:54:47)

Und wenn ihr mal ein bisschen weniger erwachsen über solche Thema sprechen wollt, kommt gerne in unsere Community. Ab und zu packe ich da mal einen Link rein, der wirklich Öl ins Feuer packt. Weil ich dann hoffe, da kommt mal wieder ein guter, ordentlicher Streit. Also, ich hab die Whitespace-versus-Tubs-Diskussion oder Wim oder Emacs noch nicht ausgepackt, die bewahr ich mir noch.

Wolfi Gassler (00:54:47 - 00:54:52)

Es gibt einfach keine Flamewars bei uns in der Community. Es sind alle zu erwachsen, Andi.

Andy Grunwald (00:54:52 - 00:55:09)

Ich find immer, ein Flamewar hat auch immer einen guten Lacher zwischendurch. Und deswegen bin ich für mehr Flamewars. Ich versuche immer noch den heiligen Graal der Teamentwicklung zu finden und der heilige Graal der Teamentwicklung ist für mich, wie du die Energie, die Leute bei einem Flame War da reinstecken, wie du die kanalisieren kannst.

Wolfi Gassler (00:55:09 - 00:55:21)

Du hast es falsch verstanden, Team ist absolut unwichtig. Es geht nur um die reine Performance vom Computer und von deinem Code und Team ist ganz egal. Da waren weder Ironie-Tags dran übrigens, nur dass du das verstehst.

Andy Grunwald (00:55:21 - 00:55:41)

So, die nächste Episode wird mit hoher Wahrscheinlichkeit über vier Seiten einer Nachricht passieren und wie diese Nachricht konsumiert wird und dass auf einem Podcast man keine Ironie-Texte sehen kann. Also, falls wer eine Podcast-Episode mit vier Seiten einer Nachricht mit mir machen kann, die der Wolfgang sich dann anhören kann, bitte gerne melden. So viel von mir. Bis zum nächsten Mal.

Wolfi Gassler (00:55:41 - 00:55:45)

Tschüss. Ciao.

Andy Grunwald (00:55:45 - 00:55:46)

Mach Ende, wenn gut ist.

Wolfi Gassler (00:55:46 - 00:55:48)

Ja, warum muss ich jetzt Ende machen übrigens?

Andy Grunwald (00:55:48 - 00:55:51)

Soviel von mir. Bis zum nächsten Mal. Tschüss.

Wolfi Gassler (00:55:51 - 00:55:54)

Was heißt von dir? Von uns?

Andy Grunwald (00:55:54 - 00:55:56)

Weil ich gerade gebrabbelt hab.

Wolfi Gassler (00:55:56 - 00:55:57)

Lass mal nochmal lassen, was heißt jetzt auch gehen?