Latest / Coding Buddies | Tech & Dev-Mindset / Der Mythos vom perfekten Code

Transcript

Der Mythos vom perfekten Code · Coding Buddies | Tech & Dev-Mindset

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