Weil ich hatte das früher, das ist echt schon lange lange her, ne, aber dann sitzt du da. Ich hatte richtig Bock was zu coden, habe Ewigkeiten überlegt, habe eine Stunde nicht gecoded und dachte, boah ich weiß gar nicht wie ich das machen soll. Coding Buddies Dein Podcast rund um Softwareentwicklung und aktueller Tech News herzlich Willkommen.
Halli Hallo und herzlich Willkommen zur neuen Folge vom Coding Buddies Podcast. Und zwar natürlich mit mir, dem Fabi und natürlich auch mit dem Tino, der mir hier schon gegenüber sitzt. Hallo Tino, Wie geht es dir? Moin Moin Fabi, Was geht ab? Was geht ab? Ich kann dir sagen, was abgeht und zwar die 100. Folge unseres Podcasts geht heute ab wir.
Haben es echt geschafft. Wir haben ja eigentlich angedroht, dass wir die nie ausstrahlen werden, aber wir haben uns dann überlegt, Ach komm, die 100 machen wir voll, also eine gibt's noch. Muss, ja, muss ja. Muss ja, es muss ja weitergehen. Ja krass, fabi 100 Wochen in Folge heißt es 18:00 Uhr Donnerstag neue Codingbody's Podcast Folge. Das ist schon ne ganze Zeit jetzt. Mittlerweile muss. Man sie auch erstmal auf der Zunge zergehen lassen.
Aber ist geil. Ja, ja, ja, wir werden bald 2 Jahre alt, das find ich halt irgendwie erstaunlich, weil die Zeit denn doch schnell rumgegangen ist. Also man hangelt sich so von Woche zu Woche, überlegt sich n neues Thema, macht immer noch mega Spaß diesen Podcast zu machen. Und dann zack, 100. Folge. Zack, zack, 100 folgen krass, einfach nur krass. Und auch dann hab ich auch so
überlegt. So rückblickend muss ich sagen, ich Feier das auch extrem, wie unsere Community mittlerweile wächst und wieviel coole Leute wir da auch getroffen haben und die Zeit mit uns verbringen, mit dem man zusammen Projekte umsetzen kann ist einfach. Extrem cool und wir hatten es ja angeteasert. Es steht ja quasi n neues Projekt jetzt direkt vor der Tür. Also es kann gar nicht viel direkt da vor der Tür stehen als
es gerade ist. Du redest von Flappy Buddy Programmierwettbewerb vermute ich mal, oder was? Meinst du? Absolut, absolut.
Ja, das ist natürlich. Das ist natürlich jetzt n ganz großes Ding, da geht es ja im Endeffekt einfach wieder darum, also das ist ja so. Ding, was wir regelmäßig machen, also Programmierwettbewerbe, wo es um kleine Games geht, in denen man Bots implementiert und diese Bots steuern dann im Endeffekt den Spieler sozusagen im Spiel und dann wird daraus natürlich wie bei einem guten alten Programmierwettbewerb Halt eben auch gegeneinander angetreten.
Und es gibt natürlich auch meinen Gewinner oder eine Gewinnerin am Ende und für dieses Mal gibt es natürlich auch einen richtig coolen Hauptgewinn.
Oh yes, denn derjenige oder diejenige, die den Highscore knackt und das Turnier gewinnt, erwarten 2 Tickets für die WE are developers Konferenz 2025 im Juli in Berlin und wir können nur sagen, es ist ne unfassbar geile Konferenz, sie ist riesig, es sind unglaublich geile Speaker und Firmen vertreten mit richtig coolen Themen, eigentlich alle Bereiche, die man sich vorstellen kann in der Softwareentwicklung sag ich mal. Also da ist auf jeden Fall für jeden und für jede was dabei
und. Absolut klare Empfehlung an dieser Stelle. Ja, auf jeden Fall auch richtig, richtig cool, dass die Rea Developers da 2 Tickets gesponsert hat für den für den Hauptgewinn, das ist auf jeden Fall wie sagt man das, freut uns natürlich mega und falls dich liebe zürin lieber Zürer das interessiert und du dir sagst ey warte mal, da muss ich jetzt aber noch mal nachlesen, was es genau ist. Oh, das interessiert mich jetzt genau. Da geh einfach mal auf unsere
Homepage www.codingbuddies.de. Und da stehen auch noch mal alle Infos, wenn du da n bisschen runter scrollst. Da kommt direkt dann sozusagen die Flappy Buddy Ankündigung und da einmal drauf klicken und dann gibt es alle Infos dazu. Genau. Ja, was ist denn das heutige Thema? Kommen wir mal zu unserem heutigen Thema. Ich habe ein ganz cooles Thema mitgebracht, das würde ich jetzt gerne mal kurz anteasern und dann mit dir ausführlich darüber sprechen. Let's GO, Let's. Go Weil ich find's sehr
spannend. Und zwar soll es heute in der heutigen Folge darum gehen, um den Mythos des perfekten Codes und warum es vielleicht gefährlich ist, diesen Pfad zu beschreiten. Weil ich find es immer ganz spannend. Ist ja auch so n bisschen
allgegenwärtig. Ah ja, das ist wirklich perfekt gecoded und an irgendwas fehlt Oh das kann man auch besser machen hier und da und in meinen Augen und deswegen hab ich das Thema jetzt auch so benannt, ist dieser perfekte Code Mythos und da würd ich gerne heute mit dir drüber sprechen was deine Erfahrungen dabei sind, was deine Sichtweisen sind. Und einfach mal so n bisschen erläutern, warum es gefährlich sein kann, diesen perfekten Code anzustreben.
Was hältst du davon? Ja, find ich cool ist auf jeden Fall auch n irgendwo n bisschen ernsteres Thema, weil ich finde jeder will ja so seinen perfekten Code haben. Also ich hab glaub ich noch nie jemanden irgendwie kennengelernt der sagt so ja ach ich versuch mir hier mal nur so Kraut und Rüben zusammen zu programmieren, jeder will natürlich schon
irgendwie. Einen guten Code schreiben so ne, das ist natürlich klar, aber es ist natürlich auch ein kleiner Unterschied, ob du guten Code schreibst oder wirklich perfekten Code. Jetzt mal so ein bisschen überspitzt gesagt, weil also per perfekter Code erstmal an sich ist ja die Frage, was ist überhaupt perfekter Code, ne also? Das ist nämlich ein guter Punkt. Genau also im Endeffekt hat ja jeder erstmal wahrscheinlich seine eigene. Vorstellung von perfektem Code
vermute ich mal. Also nur weil jetzt jemand sagt, das ist ein richtig geiler Code, der ist wirklich perfekt für mich heißt das ja noch lange nicht, dass ein anderer eine andere Person sagt, das ist ja auf jeden Fall sehe ich genauso ne, aber vielleicht können wir uns ja mal hinstellen und sagen, gut, was ist denn, wenn man jetzt von dem perfekten Code spricht und wir versuchen mal eine allgemeine Definition für perfekten Code zu machen, was haben wir denn da da?
Sollten keine Bugs drin sein, beispielsweise also sollte wahrscheinlich auch richtig performant sein. Der Code, was fällt dir nur so ein? Ja, ich finde, das sind schon gute Beispiele, weil das ist irgendwo messbar. Also wenn man jetzt versucht, perfekten Code zu definieren, müsste es ja irgendwas nachweisbares, messbares sein und zu sagen okay, er ist nicht fehlerhaft okay das kann man prüfen, also du kannst es
abtesten. Sagen wir mal, wenn keine Bugs gemeldet werden, dann ist er auch fehlerfrei oder so. Performance kann auch ermittelt werden, die Komplexität der Algorithmen da drin beispielsweise, das ist für mich völlig fein, dass das ist greifbar, aber was du auch schon meintest ist, dass die Definition von perfekt oder sehr gut sehr viel Subjektives beinhaltet und da spielt es halt zum Beispiel eine Rolle. In welcher Umgebung befinde ich mich? Also?
Bin ich beispielsweise ein CC Plus plus Coder oder ein Python coder? Nur mal so, das sind ja 2 verschiedene Welten, du kannst zwar quasi gleiche Dinge programmieren, aber der Code der am Ende rauskommt wird sehr unterschiedlich sein und jeder in seiner Welt wird natürlich das perfekte was er anstrebt, auch er in seiner Welt sehen.
Ja, der würde sich denken. Ah, ich kenn diesen CC plus plus Code, wenn ich die kann man ja nicht mal richtig lesen, keine Ahnung, versteh ich nicht das Käse so nach dem Motto Mal überspitzt gesagt so ne das sollte man eh in. Rust. Hinschreiben. Wie sollte man eh n Rust machen? Nein, aber das sind genau die Punkte, es ist halt so unglaublich viel Subjektivität da drin, weil jeder ja wie du meinst ne andere Vorstellung hat
von dem perfekten. Und das finde ich es halt so schwierig, weil die Programmiersprache, das Framework, persönliche Präferenzen, dass das das hat so eine Riesen Impact darauf, was für ein gut ist, so dass du das gar nicht vergleichen kannst. Also du, du wirst keine allgemeine Definition finden, weil was für dich sehr sehr guter Code ist es für den anderen absoluter Murks und deswegen auch zum Beispiel das Framework. Frameworks entscheiden ja auch schon sehr viel darüber wie.
Eine Software designed ist. Wenn du dieses Framework verwenden möchtest, ja und wenn dieses Design für jemanden aber absoluter Käse ist, dann wird er ja niemals sagen, auch wirklich wirklich toll geschrieben. Ja guck mal super. Weißt du? Na ja, klar, na ja gut, wenn du natürlich kein Verfechter von einem bestimmten Framework bist, dann ist das vielleicht für ne bestimmte Person von Grund auf schon mal schlecht, ja. Genau, und das ist halt ja, was
willst du was? Ich find es halt schwierig, weil du kannst ja nicht mal denn sagen, ja du hast keine Ahnung oder so ne, nur weil du magst das Fraywork nicht, deswegen kannst du es nicht beurteilen, weil das ist ja halt auch von seiner Seite aus subjektiv, genauso kann es ja auch
andersrum sein. Also du wirst da ja nicht auf n Nenner kommen und trotzdem können ja beide Implementierungen, wenn wir jetzt noch mal diese beiden Sprachen nehmen in sich sehr gut umgesetzt sein und trotzdem würde niemals der eine vom anderen behaupten, dass er das
perfekt gemacht hat. Und deswegen ist für mich dieser perfekte Code einfach so n Mythos dahinter, den man aber natürlich logischerweise anstrebt, irgendwo zumindestens sehr guten Code zu schreiben wie du meintest, weil niemand will Murks machen, niemand möchte irgendwie dargestellt werden als jemand der so. So Waschi Waschi Codet weißt du so? Ja, es funktioniert zwar, aber das hast du. Ist wirklich nicht geil so ne es. Funktioniert und du machst ja schon. Das ist Spaghetti coded.
Oder so. Ja genau, du willst ja schon das Bestmögliche erreichen und ich finde diese Intention zu haben, zu sagen, es muss perfekt werden, aber diesmal mach ich es perfekt. Weißt du, das kennt man ja auch, wenn man so n neues Projekt anfängt, dann hast du wieder was aus den alten hinzu gelernt ne und bist besser geworden, erfahrener und denkst dir dieses neue Projekt. Diesmal wird alles perfekt laufen und 2 Wochen später wieder Spaghetti Coach Weiliges Chaos ja.
Oder der erste Workaround fließt ja nach einem Monat wieder ein oder so. Man kommt da manchmal gar nicht drum rum, das ist schwieriger in der ganzen Geschichte, finde ich, ist ja auch immer, dass man zwar relativ schnell von außen urteilen kann und zum Beispiel sagen kann, ja, das hätte ich zum Beispiel so niemals gemacht, weil das ist ja wirklich richtig schlecht. Ich finde es aber schwierig manchmal, weil man nicht nicht immer sozusagen alle Insights an
der Stelle hat. Also du weißt nicht, unter welchen Gedankengängen etwas quasi getroffen wurde, welche Entscheidung, und das ist manchmal auch gar nicht unbedingt so ersichtlich von außen, wenn du nur so als Außenstehender drauf guckst zum Beispiel, und ich hatte zum Beispiel auch mal ein Projekt. Da hatten wir, wie viele Leute waren wir da, ich sag jetzt mal 8 Leute mit 8 Leuten an dem Projekt gecoded und es wurde irgendwann abgegeben, also
übergeben sozusagen dieses Projekt an eine andere, an anderes Team beispielsweise, und wir haben richtig, richtig, richtig schlechtes Feedback bekommen, so nach dem Motto, Was ist das denn für ein Code, das ist richtig schlecht gemacht
und. Ich dachte mir, so ey, da haben so viele Leute dran gecodet, die wirklich richtig gute Programmierer waren, ne oder Softwareentwickler, wo ich mir dann auch dachte, so das ist schon irgendwo frech tatsächlich das einfach so abzustempeln ob. Obwohl da einfach also das das das war einfach so weiß ich nicht, das war so ganz ganz oberflächlich mal drauf geguckt und gesagt, nee das ist irgendwie blöd, so weißt du also ich glaube tatsächlich, da wurde
dann gesagt, ja, das Framework ist sowieso per se schon mal blöd, also ist das ja schon mal erstmal Quatsch und ich hatte eher das Gefühl, dass da nicht richtig, also die Lust da war da reinzusteigen, sondern eher so versuchen zu rechtfertigen, dass das blöd gemacht ist, um es einfach neu zu machen. Ja, weißt. Du dieses dieses typische Lass einfach noch mal von vorne auf einer grünen Wiese beginnen, weil es macht ja auch mehr Spaß. Ja. Und das fand ich irgendwie schon.
Das war für mich auch so n krasses Erlebnis, weil ich mir dachte, so, boah, wir haben echt keinen Scheiß gemacht an dieser Stelle ne und trotzdem wird es halt von einer von einer anderen Perspektive aus angesehen wie. Das war richtig schlecht, das ist schon krass so. Und das noch mal so zum Thema perfekter Code, Du gibst ja dein Bestes und jemand anders deklariert es als. Das ist schlecht.
Ja, und das ist eigentlich ein Paradebeispiel dafür, weil ihr habt quasi als Team angestrebt, es bestmöglich zu machen. Ja, also nach dem Stand der Dinge, des Projekts, der Wahl der Frameworks etc. Es bestmöglich umzusetzen und.
Du kannst auch aus heutiger Sicht sagen, das haben wir getan, also wir haben es bestmöglich umgesetzt, so wie es zu dem Zeitpunkt war, das würde er niemals ausschließen, dass man nicht Jahre später sagt, EY, gut, ich hab dazugelernt, die ein oder andere Sache würde ich anders machen heutzutage völlig
normal. Das wird jedem so gehen, jeder der was anderes behauptet, der lügt und da finde ich es halt krass, wenn jetzt so n anderes Team kommt und zum Beispiel jahrelang in einer anderen Sprache oder in anderen Frameworks arbeitet und. Bewusst zum Beispiel Eures.
Gemieden hat vorher natürlich denken die gar keinen Bock drauf, jetzt ist der Worst Case eingetroffen, jetzt müssen wir ein Projekt übernehmen mit diesem Framework, ja mag sein, schmeckt vielleicht nicht, aber sich dann so hinzustellen und das schlechtzureden ist halt auch Bad Practice sag ich mal ne und zeigt einfach wie unterschiedlich die Vorstellung von sehr guten oder sag ich mal in Anführungsstrichen perfekten Code ist. Definitiv.
Ich mein wie du hast es ja auch schon so schön gesagt und ich finde, das ist auch, das ist einfach auch ein perfektes Beispiel für auch den Werdegang eines Softwareentwicklers oder einer Softwareentwicklerin, und zwar du Programmierst an irgendeiner Anwendung oder du Programmierst privat für dich hin oder was auch immer und denkst, OK, ich hab das jetzt wirklich gut gemacht und irgendwann.
Nach 2 Jahren guckst du mal wieder drauf und denkst dir so, boah, das hätte ich ja, das könnte ich jetzt aber auch noch besser machen, was ja an sich gut ist, weil du natürlich auch gelernt hast. Das heißt, du weißt mittlerweile wie du meintest, ne, wie man es dann besser machen kann und das ist ja gut, das ist ja das das das zeigt ja, dass man sich verbessert hat, und es ist ja schwierig, sich hinzustellen und zu sagen, ja, ich hab das jetzt perfekt gemacht und das wird
niemals mehr besser. So weil du weißt ja eigentlich schon, also die Erfahrung hat wahrscheinlich jeder, der weiß ich nicht schon einige Jahre programmiert, auch gemacht schon, dass man sich immer hinstellt und sagt, was ist das denn, was habe ich denn damals gemacht, völliger Quatsch so, aber damals war es halt kein Quatsch so, damals war es das Beste was man machen konnte. Quasi der perfekte. Code, den man schreiben wollte so, aber der ist dann heute halt
nicht mehr perfekt. Ich finde es halt auch spannend, weil es kann genauso gut sein, dass der Code von damals nicht schlechter ist als das, was man heutzutage schreiben würde, sondern dass einfach der persönliche Coding Stil sich geändert hat, was auch nicht unüblich ist, dass du früher gewisse Design patterns cool fand, die du halt bei jeder Gelegenheit gefühlt genommen hast. Heutzutage denkst dir, nee, ist vielleicht nicht mehr so geil, mache ich andere, verwende ich andere Patterns.
Also einfach auch so diese, diese Stilfrage, wie man Dinge implementiert, variiert über die Jahre zwangsläufig und dementsprechend wirst du immer an den Punkt kommen zu sagen, Hey damals, na nee, das sieht irgendwie nicht mehr so geil aus, weil du einfach, ich habe das auch mal so als Satz gelesen, dass Code so ein Kind seiner Zeit ist, sozusagen in dem Moment, wo das entstanden ist oder das Projekt implementiert wurde. Ne, gab es gewisse Versionen von
Programmiersprachen? Gewisse Versionen von Frameworks definierte Best Practices, die zu der Zeit gut waren, die übrigens sich auch alle Jahre ändern können? Ne alle was vor 5 Jahren absolute Best Practice war, kann heute total out sein und dementsprechend muss man immer betrachten wann ist das entstanden und unter welchen Bedingungen und das bedeutet gerade in der Softwareentwicklung, die unfassbar schnelllebig ist. Ne, also wie oft kommen denn neue Versionen von irgendwelchen
Frameworks allein raus? Selbst so sehr fortgeschrittene und etablierte Frameworks hauen ja ständig Versionen raus, ne und selbst da kann sein, dass du, nimmst du jetzt zum Beispiel ja Angular oder so, also wirklich so n gesetztes Framework, was es in zig Versionen schon gibt, ja und? Was vielleicht in Version 8 absolut der heiße neue Scheiß war. Haben sie in Version 14 wieder rausgenommen, weil sie dachten, nee, den weg wollen wir in dem
Framework nicht mehr gehen. So war es deswegen schlecht umgesetzt in der Version 8 würde ich niemals behaupten, sondern es es hat sich halt einfach weiterentwickelt und ich finde jedes Projekt, jeder jede Software ist ständigen Veränderungen ausgesetzt und deswegen wird es diese dieses perfekte einfach nicht geben aus meiner Sicht. Na erstens, du hast ständig Veränderung, das ist das eine, ne, also sozusagen von außen auch die Veränderung.
Also jetzt ich, ich sag mal die technischen Veränderungen, die halt immer mitspielen, aber genauso hast du ja auch oft, dass Anforderungen an ne Software zum Beispiel auch sich ständig ändern und genauso ist es ja, kann es ja unter Umständen auch sein, dass du bestimmte Dinge programmierst, wie du sie programmierst, weil sich halt eben die Anforderungen
verändert haben. Also wie oft ich das schon erlebt habe, dass man von Grund auf so dieses schöne grüne Wiese Ding, du fängst an, du hast ne Anwendung, du die gibt es noch nicht, du darfst die wirklich von Grund auf Programmieren und du kriegst Anforderungen rein und du designst sagen wir mal im ersten Jahr genau nach diesen Anforderungen nach und nach Iterativ ganz entspannt diese Anwendung und denkst dir was
dabei. Und dann auf einmal kommen Anforderungen, die so n bisschen querschießen, wo du dir denkst, so, ja das war doch von, war doch jetzt eigentlich gar nicht so wirklich die Intention von dem ganzen, aber manchmal spielt sag ich mal die Realität da n kleinen Streich und sagt dann ja, aber wir müssen das leider doch auch so machen und dann stehst du manchmal n Punkt wo du dir denkst.
Ich habe eigentlich meine Software richtig geil designed für diesen Anwendungsfall und jetzt kommt was Neues rein, was mir halt einfach strich durch die Rechnung macht, weil diese Ganze dieses ganze Design was ich mir überlegt habe gar nicht mehr so richtig gut funktioniert. Also sei es jetzt zum Beispiel auch im Datenbankenbereich, wo du bestimmte Relationen hast, die miteinander verknüpft sind und du dir denkst, ja das können wir jetzt aber.
Gar nicht so einfach, zum Beispiel ne Kopie von von diesem Objekt erzeugen oder so. Es geht jetzt gar nicht mehr so einfach oder was auch immer ne. Ja, oder wenn irgendwie gewisse Attribute einzigartig waren oder Entitäten. Und dann heißt es auf einmal, ja nee, wär cool, wenn es mehrere davon geben könnte, solche Geschichten oder mal ganz vereinfacht dargestellt, stell dir vor, du entwickelst jahrelang n Spiel und es ist n Singleplayer Spiel ja und?
N halbes Jahr vor Release heißt es denn so, Ach Ey Multiplayer ist momentan zu angesagt, das können wir nicht machen, wir können nicht, wir können dir kein Spiel rausbringen, wo es kein Multiplayer gibt, baut mal einfach noch einen, dass man zu zweit Coop mäßig da drin rumrennen kann, das meinst du, dass es so ne Panik auslösen würde, so weißt du und das sind so Sachen da, da kickt dann die Realität rein und wenn du von Anfang an angenommen hast, dass es nur einen Spieler gibt und
dann heißt es baut mal n zweiten einen so nach dem Motto Mal ganz vereinfacht dargestellt und dann. Das ist Realität, sowas wird passieren und dementsprechend wird der Code ja nicht. Also so so schlagartig nicht mehr perfekt sein, weil er diesen Fall gar nicht darauf
ausgelegt. Ist ja genau, aber das sind ja zum Beispiel auch wieder Dinger, wo man sich dann hinstellen kann und sagen kann, klar passiert sowas, damit kann man ja schon fast rechnen und dafür ist es halt unglaublich wichtig, dann
aber beispielsweise auch. Wenn man sagt, OK, wir haben jetzt erstmal n stand zum Beispiel von diesem Multiplayer Spiel, dass man sich darauf dann auch nicht ganz ausruht, sondern sagt, OK, wir refact dann das zum Beispiel nach und nach auch mal wieder n bisschen ne so also sowas kommt ja einfach mit rein und ich hab mal auch gehört, dass das war eher so n so n bisschen so n provokanter Spruch so nach dem Motto, Wenn du ne Software von Grund auf entwickelst, musst du dann auch
refact dann. Und die Antwort, die erwartet wurde, mit nach dieser Frage, war eher so. Nein, dann muss man das natürlich nicht mehr so, aber das ist halt Quatsch, also jeder der sich hinstellt und sagt, ich entwickle eine Software, die ich niemals mehr refact dann muss ist halt auch utopisch, das ist ein Wunschdenken, das wird niemals passieren. Und da sind halt genauso die Gefahren, da würde ich auch gern mal so ein bisschen hinkommen
jetzt. Welche Gefahren lauern denn da, wenn man sagt, ich möchte perfekten Code schreiben und da ist Refact dann schon mal der erste Punkt refactoring, das haben wir auch schon sehr oft in diesem Podcast erwähnt, sollte ein fester Bestandteil in der Softwareentwicklung sein und fest eingeplant sein. Zum Beispiel haben wir ja auch eine Folge über Tdd gemacht, wonach wir arbeiten, wo Refact dann ja wirklich ein fester Ablaufschritt ist.
Aber jetzt stell dir vor, du strebst perfekten Code an und sagst, ich entwickle hier diese Software perfekt. Das lähmt dich irgendwo nach meiner Erfahrung immer wenn ich mir dachte, das muss jetzt perfekt sein, hat mich das extrem ausgebremst und irgendwie in meinen, in meinen Entscheidungen gelähmt, weil man sich ständig hinterfragt, also man Challenge sich halt die ganze Zeit selbst. Ist das jetzt wirklich die richtige Lösung?
Geht das besser? Sollte ich nicht vielleicht doch das anders machen, weißt du, dass du denn so im ständigen inneren Konflikt bist, weil du diese Perfektion anstrebst? Und jetzt, Stichwort Refactoring, wenn du sagst, ich refactor das, würdest du dir ja eingestehen, nicht perfekt entwickelt zu haben, dass der die Software so wie sie ist, nicht perfekt ist. Und das ist irgendwie so n. Wenn du das Anstrebst, so n innerer Kampf und wie?
Wieso ne Niederlage mal überspitzt gesagt und so dürfte oder darf einfach refactory nie betrachtet werden, sondern als sehr gutes Mittel seine Codequalität zu erhöhen und stetig zu verbessern, was auch angewandt werden sollte.
Also Refact, dann heißt nicht, guck mal, der Refact hat seinen Code, der kann ja gar nicht so weißt du was hat denn der da gemacht, so darf das halt niemals betrachtet werden und ich finde halt, wenn ich diesen Perfektionismus nachjage komme ich halt schnell zu einem negativen Bild diesbezüglich.
Ja, vor allem das ist ja auch einfach, das ist ja auch ein riesen Zeitfresser beziehungsweise auch ein hindert ja auch deine Produktivität am Ende ne, wenn du die ganze Zeit darüber nachdenkst, wie du vielleicht das Ganze perfekt
machen könntest, dann. Ich meine, ich weiß nicht, du kennst das bestimmt auch, dass man sich überlegt, ich möchte jetzt irgendwie ein etwas bauen, eine Klasse, was auch immer, oder zum Beispiel eine nimm mal eine Website oder so ne, und du sagst ja, ich möchte jetzt eine Website basteln und. Ich werde aber wahrscheinlich von dieser Art von Website noch
mal was ähnliches machen. Ne, also sagen wir mal wie zum Beispiel unsere Programmierwettbewerbe und wir hatten ja jetzt 4 gewinnturnier letztes Jahr und dieses Jahr kommt jetzt flappy Buddy so ja und dann kann man sich natürlich hinstellen und sagen ja komm ich, man will ja natürlich die Infos den Leuten zur Verfügung stellen, so also könnte man sich hinstellen und sagen ja gut ich will das ja aber nicht jedes Mal. Es sind ja immer eigentlich die
ähnliche Infos die da drauf sind, also versuch ich irgendwie
direkt n Template zu machen. So, und dann fängst du an und sagst ja, hast du ne gute Idee n Template, das heißt du hast irgendwie ne ich sag jetzt einfach mal n Bild n Textblock noch n Bild und noch n textblock so kleines Beispiel und die erste Idee ist erstmal ja OK, das ist ja super, das ist ja ist ja perfekt, dann kann man das ja wieso n Template nutzen, das ist ja schon, geht ja schon Richtung perfekt wenn du das nicht jedes Mal alles wieder neu machen musst will man ja auch nicht
immer machen beim Programmieren. Du willst dir ja irgendwie Zeit sparen, so und dann denkt man näher darüber nach und denkt sich hm naja, aber vielleicht will ich ja noch mal hier noch ein Bild mehr einfügen und manchmal, da brauche ich vielleicht hier noch was, ja gut, und dann fängst du an das immer weiter zu durchdenken, ein Template zu haben, was du aber am Ende irgendwie sogar am besten noch freigestalten kannst, was am Ende vielleicht gar kein Template mehr ist.
Und du dann irgendwie so n Wulst hast von einem Parametrisierbaren von so einer parametrisierbaren Website, dass du sagen, dass dass du selber gar nicht mehr klar kommst und damit gar nicht mehr umgehen kannst. Und dann hast du auch nichts gewonnen. Ja, das sind halt hartes over Engineering, ne wo quasi auch immer die Gefahr liegt, wenn ich so diesen Perfektionismus an. Strebe ne, dass ich halt unfassbar viel Zeit verbrenne, vielleicht viel zu viel Code schreibe für das, was eigentlich
gerade gemacht werden soll. Also ich komm halt schnell in den Modus mich auf Dinge zu fokussieren, die eigentlich gar nicht wichtig sind gerade also weißt du, dass ich so detailliert an Dinge arbeite, richtig viel Zeit und damit ja auch Geld verbrenne, dem Produkt aber nicht helfen so.
Ich hab in 2 Stunden n kleines Feature gecoalet und die Funktionalität funktioniert und es ist gut gemacht so dieses Typische. Es ist gut genug, es funktioniert ne weil das ist n Zustand der erstrebenswert ist zu sagen es ist für den Zeitpunkt gerade gut genug, es ist nicht schlecht. Aber wenn ich jetzt sage, es muss perfekt sein und denk schon wieder über 1000 Sachen nach, was ich alles da verbessern möchte und so, dann brauch ich
auf einmal 23 Tage inklusive. Ich hab noch mal 5 mal alles weg gemacht, weil ich dachte eigentlich ich muss doch n ganz anderen Ansatz verfolgen. Ja und das ist halt einfach diese diese Riesengefahr dabei, wenn du überlegst, dass die Anforderung sich ja noch tausendmal ändern können, wie du so schön gesagt hast, werd ich es wahrscheinlich eh alles noch mal anfassen müssen weißt. Du ja.
Und ich find halt ein Punkt ist halt extrem wichtig und zwar mir persönlich ist es halt tausendmal lieber, wenn der Code der am Ende rauskommt Wartbar ist. Das heißt er ist auch verständlich, er ist skalierbar, ja man kann ihn anpassen als Oh das ist aber n sehr sehr schöner Algorithmus, meine Güte ist der toll geschrieben und die variablen eleganten Zucker wirklich Hammer, so weißt du.
Also klar ist das cool. Jeder liest gerne geilen Code und denkt sich, Mensch, das ist richtig geil gecoded, aber am Ende gibt es halt andere Aspekte und die sollten wir nachher auch noch mal klar herausstellen, die einfach wesentlich wichtiger sind, gerade auch wenn man in einem Team arbeitet, weil ich finde Teamwork da ist so Perfektionismus richtig Gift
drin. Ja, gerade weil das ja auch ne sehr subjektive Sache ist, wie wir anfangs auch schon gesagt haben, ne. Und da ist es, glaube ich, auch sehr, sehr wichtig, dass man sich im Endeffekt einfach darauf einigt, wie man bestimmte Dinge umsetzt, in gewissen Grenzen ne und nicht, sage ich jetzt mal wirklich ganz, ganz strikt, sondern man muss so gewisse Rahmenbedingungen schaffen und innerhalb dieser Rahmenbedingungen kann man sich bewegen. Aber. Ich finde es auf jeden Fall auch.
Also was ich noch mal sagen wollte, was mir auf jeden Fall noch eingefallen ist so. Was, was mich auch manchmal oder früher auch oft gelähmt hat, dieses Ich möchte anfangen, etwas zu coden und versuch hab mir halt möglichst versucht das richtig, ich wollte es richtig gut machen und ich hab Ewigkeiten darüber nachgedacht bis ich angefangen hab mal den ersten die erste Zeile Code zu schreiben und das ist halt so
hinderlich. Es ist ja auch nicht nur hinderlich fürs Produkt dann am Ende wenn wir jetzt von einem Produkt sprechen. Sondern auch hinderlich für einen selber, auch für die eigene Motivation, weil du willst ja irgendwie was machen, weil ich hatte das früher, das ist ja echt schon lange lange her, ne, aber dann sitzt du da.
Ich hatte richtig Bock was zu coden, hab Ewigkeiten überlegt, hab ne Stunde nicht gecoded und dachte boah ich weiß gar nicht wie ich das machen soll, das geht doch gar nicht weißt du so ja. Genau dann kommst du halt genauso in diesen überdetaillierten Modus.
Dann am Ende ja. Aber stell dir mal vor, du hast jetzt n Team oder du bist Teil eines Teams und da gibt es beispielsweise Junior Developer und Senior Developer und du hast jetzt einen Senior Developer, der sehr den Perfektionismus anstrebt und seine klare Definition davon hat. Ne, also subjektiv genau weiß was für ihn perfekt ist. Sehr wahrscheinlich werden es Sachen sein, die er selbst gecoded hat, aber jetzt nimmst du.
Jetzt bist du aber in der Rolle des Junior Developers und kriegst du im Projekt deine ersten Tickets, zum Beispiel die ersten Features, die du umsetzt und du weißt einfach ne, dass da dieser Senior Developer sitzt, der am vielleicht noch n Code Review dazu macht. Ne, und das ist doch einfach ne richtig beschissene Situation, wenn du schon diesen Druck, also diese Last auf den Schultern spürst.
Dass du es ja auf jeden Fall so machen musst, wie derjenige es toll findet, weil er wird es reviewen und wird es dir voll um die Ohren hauen und dann kannst, kommst du gar nicht mehr so in diese iterative Arbeitsweise. Also du hast so n richtig toxisches Umfeld, versteh dir vor, du kriegst dann so Reviews ja hier das und das, nee das musst du mal anders machen und hier aber für dein Empfinden denkst du dir ja wieso es funktioniert doch und das ist doch gut gecoded also ich bin
doch. Auch ein Entwickler oder eine Entwicklerin, die weiß, wie es läuft, sozusagen. Nur weil du subjektiv das jetzt schlecht findest, haust du mir jetzt so n Review hier um die Ohren, wenn du halt in so n Modus kommst, ist das halt pures Gift für so n Team. Ja, definitiv. Aber ich meine, an der Stelle ist es natürlich auch n sehr, sagen wir mal n relativ schlechtes Code Review, was da wahrscheinlich stattgefunden
hat. Also auch noch mal zu dem Thema Code Review haben wir auch mal ne Folge drüber gemacht, wie man die richtig macht oder wie wir finden, dass man sie machen sollte. Also Liebe zu lieber zu ra, hör da gerne mal rein, wenn es dich interessiert. Ja, aber stell dir vor, du bist dann in diesem Modus, dass du dir denkst, oh, jetzt muss ich das, jetzt muss ich n keine Ahnung pull request schicken, er wird das Reviewen und ich weiß ganz genau er wird wieder meckern.
Kann ich das jetzt so einreichen? Bin ich wirklich fertig? Guckst du mal 5000, mal über deine Änderungen, dann ist es auch wieder so ne Frage von so
einer. Ich bin nicht gut genug Mentalität wie das im Poster Syndrom, dann haben wir auch mal ne Folge drüber gemacht, weil das einfach in der Softwareentwicklung n Riesenthema ist und das würde halt total reinkicken da an der Stelle wieder nur weil jemand seine klare Vorstellung von Perfektionismus hat und das anstrebt anstatt zu sagen Hey ich weiß du bist neu im Team. Und vielleicht ist es auch noch nicht so ganz unsere Richtlinien, wie das Gecoded ist, wenn es welche gibt, oder?
Ich denke, so und so wäre es besser, aber erstmal nice, dass du es gemacht hast. So weißt du wirklich gut umgesetzt. Wir können im Review noch mal über ein 2 Punkte diskutieren, ne so Stichwort gutes Review wieder und ihm einfach auch n geileres Gefühl geben dann oder ihr. Ja, der viel bessere Weg also von seinem Perfektionismus abzuweichen und zu sagen, It's good enough, wir können fortführen, wir können einfach weitermachen, das ist so jetzt an der Stelle okay
beziehungsweise gut. Ich finde, das ist aber auch so ein kleines Ding. Also so ein persönliches Ding von einem Entwickler oder einer Entwicklerin. Ich finde, dass ein guter Entwickler oder eine gute Entwicklerin auch genau das können sollte.
Weißt du also sich hinzustellen und zu sagen, Ey hier, das ist richtig scheiße gemacht, das ist ja, entspricht halt gar nicht meinen Anforderungen, mein meinem Standard, den ich hier an den Tag lege, so, und dann irgendwie, wen dafür halt eben wie du meintest, halt so rund laufen zu lassen, klar, das ist also. Perfektionismus sollte hat hat da erstmal nichts zu suchen, weil dann im Endeffekt genau das dadurch resultieren kann. Und genauso finde ich, ist es
aber auch einfach. Gehört es dazu, dass ein guter Entwickler und eine gute Entwicklerin eben genau auch das kann und zu sagen ey coole Sache, ich gebe dir mal einen Tipp wie du es in Zukunft besser machen kannst oder so oder guck mal, wenn wir das und das so und so machen, was meinst du?
Dass das das würde doch den Code vielleicht auch verbessern und verschönern, so also sozusagen das mitzugeben, um zu sagen, ey, hier, ich, ich, ich gebe dir einen Tipp für die Zukunft, auch mit so ne, also ich sag mal Stichpunkt konstruktives Feedback einfach an der Stelle ne. Und wie gesagt, interessanterweise würde man mit so einem Kollegen seinen eigenen Code, der vielleicht ein Jahr
alt ist oder so reviewen. Wäre man genau an der gleichen Stelle, weil es wird nicht der Punkt kommen, da bin ich fest von überzeugt. Deswegen wir haben es auch schon ein paar Mal gesagt, aber du wirst nicht auf alte Projekte schauen und dir denken, ah das ist der Hammer wirklich, ich habe nicht einen Änderungsvorschlag, das ist genauso wie es mir immer erträumt hatte, so weißt du, das
gibt also. Ich find es auch krass, wenn man sich mit dem Thema n bisschen auseinandersetzt und auch so n bisschen sag ich mal im World Wide Web da n bisschen rumschaut selbst sehr sehr erfahrene Entwickler wirklich auch so Ikon und von großen Firmenentwickler werden das bestätigen. Es wird nicht dazu kommen zu sagen, ich habe ich weiß alles, ich kann alles, ich habe es durchgespielt Softwareentwicklung ich werde immer nur noch perfekt
abliefern. Sondern diese Subjektivität wird dir auch selbst zum Verhängnis, dass du sagst, hey nee, das ist einfach nicht mehr mein Style das und es ist okay, es ist okay, dass ich es damals so gemacht habe, es war gut genug, es hat seinen Zweck erfüllt, vielleicht würde ich es heute anders machen, vielleicht auch besser so, what scheißegal. Ja, da muss man sich das auch einfach selber eingestehen können. Und jetzt ist die Frage. Was wäre für dich denn der bessere Ansatz?
Also ich würde sagen, dass es auf jeden Fall nicht verkehrt ist, eine, ich sag mal kontinuierliche, also ein Ansatz zu fahren, sich kontinuierlich zu verbessern, dass man im Endeffekt sagt okay man fängt an etwas zu coden, was auch immer man gerade coden möchte oder woran man gerade sitzt und sagt
okay es wird erstmal. Etwa es wird erstmal gecoded sozusagen ne natürlich nach bestem Gewissen logischerweise ne nicht perfekt, weil wie gesagt, wir meinten ja perfekt ist Auslegungssache, aber gut genug ist quasi perfekt so und wenn man dann aber einfach mal ganz pragmatisch dran geht und sagt, Ey komm, lass uns das erstmal machen und wir verbessern uns kontinuierlich und gehen vielleicht noch auf.
Bestimmte Änderungswünsche Iterativ ein, dann ist das ja einfach ne gute Sache. Ne und genauso ist es natürlich auch hilfreich, sich an bestimmte Prinzipien zu halten, die man vielleicht so kennengelernt hat, die gibt es ja nicht ohne Grund, wie zum Beispiel Clean Code, ne.
Ich meine, Clean Code ist jetzt nicht, dass man sich hinstellt und sagt das da muss man hundertprozentig nach arbeiten, aber die Konzepte dahinter zu verstehen und sie anzuwenden im Code auf eine gewisse Art und Weise wieder mit einem gewissen Interpretationsspielraum, weil du kannst nicht ein Kamm über alles scheren, das funktioniert niemals, aber so was zu verinnerlichen um mal auch darüber nachzudenken, kritisch bestimmte Dinge zu hinterfragen und zu sagen, Hey.
Macht es denn Sinn, zum Beispiel bestimmte Clean Code Techniken hier zu nutzen? Dann ist das auf jeden Fall hilfreich. Das ist ein guter Punkt, diese ganzen Praktiken und ja, auch so, so Prinzipien, finde ich, sind halt immer ein ganz geiler Leitfaden, das heißt, man kann sich daran entlang hangeln und immer ein bisschen challengen, ob man da in die Richtung geht, aber man sollte es nicht so.
Zu absolut strikt und stur verfolgen, weil clean Code zum Beispiel kann auch genau das Gegenteil bewirken, dass du halt wieder in diese Perfektionismusfalle läufst und sagst, Oh, der Code ist. Das ist aber kein Clean Code, das muss hier und da und ich brauch das noch und das anstatt dann einfach erstmal eine Lösung zu basteln. Wir hatten ja jetzt vor Kurzem auch zum Beispiel die MVP Folge, die ja komplett diesen nicht perfekten Ansatz fährt zu sagen,
Nein wir wollen erstmal. Das Konzept quasi evaluieren, wie es beim Kunden ankommt. Wir wollen Feedback haben, wir wollen einfach erstmal umsetzen, diese Kernfunktionalitäten und
dann Feedback dazu bekommen. Gefällt es dem Kunden, möchte es doch vielleicht noch anders sein, wenn ich jetzt jahrelang aber an der perfekten Software arbeite und der Kunde dann sagt, so, ja nee, brauche ich gar nicht, so ist gar nicht, was ich möchte, habe ich ja auch nichts gewonnen und es gibt auch, so hatten wir auch im Podcast, haben wir verschiedene.
Prinzipien besprochen wie beispielsweise das Don't Repeat Yourself Prinzip oder Yakni das Kiss Prinzip hatten wir noch und das sind alles Sachen, die einen daran erinnern und auch helfen, halt von diesem Perfektionismus wegzukommen, hinzu pragmatischen Ansätzen zu sagen, mach erstmal und verbesser es kontinuierlich und das ist auch für mich der wesentlich bessere Ansatz.
Definitiv. Das ist ja also, das ist auf jeden Fall etwas, woran man sich irgendwie orientieren kann, auf jeden Fall und zum Beispiel halt, was ich auch wichtig finde, ist, dass man halt eben auch in den Austausch geht mit
anderen. Ne, also zum Beispiel sagen, weil wir hatten n Code Review vorhin und natürlich jetzt nicht im unter dem Deckmantel Perfektionismus, dass man Angst haben muss, dass man dann n böses Code Review um die Ohren geschmissen bekommt, sondern eher im Sinne von Setz dich nicht allein hin, versuch deinen perfekten Code in deinem kleinen Kämmerchen zu programmieren, sondern den Austausch in das Team. Hol dir Code Review, gib Code Reviews. Aber halt auf einem guten Level.
Ne, dass man halt wirklich auf einem auf einem Level von, also auf auf auf einem Level, der mit einer Diskussionsgrundlage um zu sagen ey, guck mal hier so und so haben wir es gemacht. Ja ne coole Sache, das passt ja erstmal soweit ganz gut und dann vielleicht halt immer im Hinterkopf zu behalten, dass man vielleicht bestimmte Dinge noch, wie ich ja meinte, Iterativ verbessern kann, sollte es denn dazu kommen. Das muss man natürlich auch sagen.
Das ist nämlich genau der Punkt, weil der Perfektionismus bringt dir nichts, wenn du dann nie dieses Feature abschließen und damit die Software in ihrer Entwicklung nicht weiterkommt, dann hast du halt nichts gewonnen und ich finde, das ist auch genau die Challenge. Es muss halt immer eine Balance sein zwischen sage ich mal Geschwindigkeit, also wie schnell entwickle ich meine Software und der Qualität, also ich muss es schaffen eine gute Qualität in absehbarer Zeit zu
liefern. Und das ist halt auch genau der Punkt. Dieser perfekte Code ist in meinen Augen halt eine Illusion und es sollte eher sein, wann habe ich gut genug für den jetzigen Stand unter den jetzigen Anforderungen erreicht. Das ist das Ziel, ich habe das Feature gut genug implementiert, um fortfahren zu können, ich. Um weiterzukommen in der Entwicklung.
Das heißt nicht, dass ich nicht später dieses Feature noch mal erweiter, weil denn doch noch mal n Edge Case dazu gekommen ist oder Anforderungen sich geändert haben. Ich werde ja mit hoher Wahrscheinlichkeit eben noch mal an dieser Stelle angelangt und deswegen ist es jetzt, stand jetzt, wann ich dieses Feature entwickel gut genug und wir können fortführen und das muss der Spirit sein dahinter. Auf jeden Fall. Und im Endeffekt. Das jetzt noch mal so n bisschen.
Wir können das ja noch n bisschen zusammenfassen, einfach nur mal um so vielleicht n paar Keypoints mitzugeben. Du meintest ja schon, der perfekte Code ist ne Illusion, gut genug, das sollte das Ziel sein, so weil im Endeffekt kann man sich ja iterativ weiterentwickeln, man kann sagen ey OK wir verbessern das ganze noch zu dem entsprechenden Zeitpunkt und was ja auch sehr wichtig ist, man kann das ganze auch noch refectern, man wird eh nicht drum herum kommen so.
Dann ist es wahrscheinlich so, dass jeder, der mal Code geschrieben hat und irgendwann mal wieder auf seinen Code zurückguckt, dass man sich sagt, EY Zeichen da gemacht, komische Sachen, so ist eine, es ist eine ganz normale Sache, das ist ganz normal, dass man sich weiterentwickelt und verbessert und dass man vielleicht rückblickend immer irgendetwas zu verbessern hat und demzufolge aus dieser. Sag ich mal Prämisse heraus, kann man ja schon gar nicht den
perfekten Code schreiben. Richtig, absolut. Das sollte auch mit so die größte Tech Home Message sein und da auch den Druck einfach aus dieser ganzen Sache rausnehmen. Für jede Entwicklerin und für jeden Entwickler richtig. Denn viel wichtiger ist es, und das haben wir auch, glaube ich, klar rausgestellt.
Ich finde, oder wir finden das Softwarelösungen einfach praktikabel, wartbar und verständlich sein sollten, das halt viel höheren Stellenwert haben sollte als so in der Theorie diesen perfekten Algorithmus zu schreiben oder den perfekten Code, weil davon das bringt das Projekt am Ende nicht weiter, es funktioniert oder es funktioniert nicht richtig, kann man mal so quasi binär runterbrechen.
Genau. Und dann das hattest du vorhin gesagt, und das finde ich, ist auch sehr, sehr wichtig und sollten wir als Take Home Message hier mit aufnehmen.
Du hast ja gesagt, das Ganze ist ja auch irgendwo lebendig und entwickelt sich ständig weiter, du hast ja auch gesagt, zum Beispiel, Du hast ein Projekt und auf einmal kommt ganz neue Anforderungen, die Realität kickt rein und auf einmal kommt ganz, ganz andere Anforderungen und Prämissen rein in das Produkt oder in das Projekt. Die vorher nie da waren. Und das ist einfach die Realität.
Und dann muss ich kontinuierlich mich adaptieren, mich verbessern und das wird halt immer am Ende den Perfektionismus schlagen, wenn ich in der Lage bin, das umsetzen zu können. Wenn ich dann sage, nee, halt, Stopp, das machen wir jetzt aber nicht mein perfekter Code, hier wird nicht angerührt, denn der ist perfekt, da hast du ja nichts gewonnen, dann fährst du das Projekt wahrscheinlich eher gegen die Wand am Ende. Definitiv. Ja, fällt dir noch ein Punkt ein? Ich bin ne.
Das waren eigentlich die Hauptpunkte. Wieviel waren es jetzt 453 wieso 3 bis 53 bis 5 genügend okay ja dann würde ich sagen, liebe Zuhörer, liebe Zuhörer, wie ist denn deine Meinung dazu, was ist für dich perfekter Code und strebst du diesen perfekten Code an oder gehst du eher den Weg, den wir gerade versucht haben zu erläutern und. Nennen uns doch einfach mal deine Sicht der Dinge und erläuter sie, wir würden uns mega freuen. Schreibt uns dazu gerne eine Mail oder über die Plattform.
Die ganzen Links findest du in den Shownotes wenn dir der Podcast gefällt, lass auch sehr sehr gerne eine Bewertung da oder empfiehl ihn weiter an vielleicht 2 oder 3 Freunden, das würde uns auch mega helfen und ansonsten würde ich sagen. Hören wir uns alle beim nächsten Mal wieder. Es war ne geile Folge, fabi, vielen Dank dafür noch mal. Danke auch dir, Thilo. Und bis zum nächsten Mal. Habt ne schöne Zeit deine Kundenbodys. Gemeinsam besser.