Und ich weiß nicht, ob du dich auch schon mal auf so ein
Experiment eingelassen hast, wo man dann sagt, Ja, komm, wir
probieren noch mal a. Eigentlich hast du recht,
wirklich gute überzeugende Argumente, man probiert A ist
irgendwann an einem Punkt wo man sagt und deswegen haben wir
nicht a genommen. Coding Buddies Dein Podcast rund
um Softwareentwicklung und aktueller Tech News herzlich
Willkommen. Moin Moin und herzlich
Willkommen zur neuen Folge des Coding Bodys Podcast.
Schön, dass du wieder eingeschaltet hast, deine
Gastgeber, du weißt es schon, aber wie soll es auch anders
sein, meine Wenigkeit, der Tino und auch der fantastische Fabi,
den ich begrüßen möchte, er guckt mich schon an, er grinst
mich an, er freut sich, er hat einfach Bock auf diese Folge
heute fabi was geht ab Hallo Tino.
Das wäre so geil so, er lacht schon, er freut sich.
Moin er. Ist eigentlich gar nicht.
Da, nee, ja, hi grüß dich Tino, Lass uns mal grüße dich hier
jetzt mal heute schön ne neue Podcast Folge aufnehmen.
Ich freue mich auch auf jeden Fall schon aufs Thema, aber
bevor wir richtig losstarten geht's dir denn gut?
Ja mir geht's gut soweit, ich hatte ein sehr entspanntes
Osterfest. Ich konnte mich echt mal so
richtig entspannen über die Feiertage, das war richtig gut.
Aber jetzt steht ja wieder was Aufregendes vor der Tür, und
zwar unser Flappy Buddy Turnier. Da heißt es natürlich wieder
Action und was wie werden die Bots abschneiden?
Also ich bin auf jeden Fall schon wieder richtig gespannt
fabi. Ja, ich bin auch gespannt.
Ich bin wahrscheinlich wieder wie beim letzten Turnier auch
schon gespannter als eigentlich die teilnehmenden Mal gucken.
Ich find das auf jeden Fall mal cooles Event, das findet ja auch
am 29.4. Statt, so ist es auf jeden Fall
stand jetzt geplant, ich denke mal das ziehen wir auch so
durch. Und ja, liebe Zurin, lieber
zurer, schalt auf jeden Fall mal bei Twitch ein. 20:00 Uhr geht's
los und also generell ne genau. Ja, und bis dahin können wir ja
noch n Thema bequatschen. Fabi, ich hab n ganz cooles
Thema mitgebracht und zwar ist es jetzt heute mal wieder so ne
typenfrage beziehungsweise philosophisch fast schon, aber
wir versuchen das natürlich auch unsere Sicht der Dinge dahinter
fachlich zu begründen. Also auch wirklich Pros und Cons
wieder anzubieten. Und zwar soll es heute um das
Stichwort cleverer Code gehen, da gibt es auch so n paar
Artikel dazu, das ist eigentlich n ganz spannendes Thema und zwar
einfach mal sich zu überlegen, was ist jetzt eigentlich besser
so n richtig schön cleverer Code wo sich der Entwickler denkt so
ach das hab ich so richtig schön als Einzeiler gemacht.
Das ist so richtig smart gelöst. Oder ist es vielleicht doch
besser zu sagen, nee, ich schreib lieber n paar mehr
Zeilen? Das Ganze ist verständlich und
lesbar und genau das Thema möchte ich mit dir heute mal
beleuchten. Ja, auf jeden Fall.
Also mir fällt da immer direkt erstmal ein, da kann man, das
kann man sich finde ich, so schön vorstellen, dass man und
ich glaube, das kennen vielleicht viele, dass man sagt,
so ey, ich mache jetzt mal wieder eine Aufgabe auf, zum
Beispiel so, so Code Wars oder Lead Code, also weißt du, wo du
so so kleine Aufgaben hast, mit denen du dich challengen kannst.
Ne, und dann liest du dir so die Aufgabe durch und denkst dir so,
ja, jetzt geht's los, weißt du, dein Kopf fängt an zu rattern,
wie löse ich das Ganze? Und dann kommt man ja mal.
Zumindest das ist ne Sache, da geht es mir so, da kommt man
immer relativ schnell dann auf den Punkt, dass man sagt, ja,
ja, ich will jetzt, ich lös das irgendwie.
Na ja, ich hab n Algorithmus im Kopf, aber warte, warte warte
ich, ich krieg das noch besser hin, ich ich das das das könnte
n Onliner werden, ah wie braucht wie ist die Syntax dafür, dass
ich den Onliner hinkriege, was muss ich da, welche Funktion
gibt es? Ah dann ratter zweiter, Ratter
zweiter und dann kommt also. Das ist ja dann so n so n
Gefühl, dass man sich so denkt. Ich will mir nicht die Blöße
geben, weil ich kann das besser, ich kann das in dem One Liner,
weißt du und ja, ich find das, manchmal hat man dann auch
direkt erstmal so, da überschlagen sich die Gedanken
und man kommt eigentlich erstmal zu gar nichts, weil man sich
erstens denkt, OK ich hab n Algorithmus im Kopf, du
versuchst ihn direkt zu optimieren.
Und hast noch nicht mal irgendwas hingeschrieben.
Weißt du so dieses typische, wenn du jetzt wirklich nach Tdd
zum Beispiel Codes sagst? Du schreibst einen Test.
Du machst eine Implementierung und dann kannst du hinterher
immer noch refact an alles cool, aber man versucht halt immer
erstmal gleich, zumindest kenne ich das so je weniger Code desto
besser One Liner, super clever und ob man es aber jetzt
sozusagen dann schafft oder nicht, diese One Liner Lösung
nenn ich es jetzt mal hinzukriegen sei mal
dahingestellt, aber. Die Frage ist ja, wie du schon
so schön eingeleitet hast. Ist es jetzt wirklich immer gut
auch so ein One Liner zu haben? Weil klar es gilt als clever ne,
aber es ist jetzt also da steckt ja zwangsläufig ne Menge
Überlegung hinter, dass du das so komprimiert bekommst, ne?
Ja. Ich find es halt auch spannend,
wenn wenn wir jetzt noch mal das Thema Code Wars aufgreifen, weil
in unseren Live Streams auf Twitch machen wir ja auch öfter
mal Code Wars Aufgaben und lösen die so zusammen mit der
Community, überlegen uns dann wie könnte man das lösen, was
könnte man verbessern und da ist man ja auch immer so getrieben
zu optimieren ne also wir versuchen ja auch wirklich gute
Lösungen einzureichen, sie zu minimieren in Sachen Codezeilen
auch mal ruhig n kleinen Kniff einzubauen.
Aber sind trotzdem am Ende immer Verfechter davon, dass man sich
diese Funktion anguckt und sie noch versteht, was da passiert?
Und da ist nämlich genau auch wieder der Punkt, wenn ich zum
Beispiel bei Codewars dann meine Lösung einreiche, sehe ich ja,
und das finde ich auch sehr cool, an der Plattform die
Einreichung der anderen ne und dann kann man die bewerten, dann
gibt es ja clever glaube ich wirklich auch als Feld ne so
kann kannst du Punkte vergeben. Und dann sind da manchmal
Lösungen bei, die wirklich sehr kurz und knapp sind, aber die
man dann einfach auch nicht mehr sofort versteht.
Und genau da ist nämlich der Knackpunkt ne, so dass wir
sagen, nein, wir wollen, dass man diese Funktionen, die wir
geschrieben haben, noch verstehen kann, und das ist
nämlich auch der große Unterschied, wenn ich ne Code
Ross Aufgabe mache, dann guck ich mir eine Funktion an und
versuch da denn halt mich so n bisschen auszutoben die
hocheffizient zu machen oder oder super smart zu lösen.
Aber es ist halt nur eine Funktion, ne und da müssen jetzt
nicht andere Entwickler noch mit arbeiten oder es muss nicht
eingebettet werden in ein großes Projekt und deswegen da ist halt
wirklich die Frage. Da.
Kannst du flexen, was genau? Da kannst du ruhig mal flexen,
aber was für n Eindruck macht das auch gerade auf Junior
Developer zum Beispiel. Und da möchte ich mal was mit
dir bequatschen, weil das fand ich sehr witzig.
Und vielleicht erkennt sich da der eine oder andere oder die
andere wieder es. Gibt so gefühlt.
Phasen im Entwicklerleben, die man so durchschreitet, und die
habe ich auch an mir selbst zum Beispiel wahrgenommen.
Auch jetzt, so rückblickend. Das heißt, wenn du so
beispielsweise Junior dev bist und noch am Anfang deiner
Karriere stehst. Dann codest du ja oft.
Also dann ist dein Algorithmisches denken noch
nicht so ausgeprägt beziehungsweise du hast halt
einfach noch nicht so viel Erfahrung gesammelt und man
codet meistens oder oft auch unabsichtlich kompliziert.
Ne, gehst halt so Wege die du vielleicht kennst, die aber
nicht so optimal sind, dafür vielleicht umständlich sind, ja
zum Beispiel also sehr verschachtelter Code oder wie
auch immer. Dann kommst du irgendwann in
dieses Midlevel, dann bist du kein Junior Developer mehr, bist
aber auch noch nicht so Senior Death, sondern du bist halt so
normaler Developer. Aber normal jetzt nicht
abwertend. Ne, du hast halt schon so n
bisschen Erfahrung gesammelt und da war das bei mir zum Beispiel
und das war auch gerade so meine Embedded Zeit in C, dass ich mir
dachte, Na jetzt musst du ja zeigen, dass du es kannst, ne
und dann fängst du halt an so. In Anführungsstrichen clever zu
coden und dann hab ich da halt auch so Lip Funktionalitäten
implementiert und das waren halt auch teilweise ein Zeiler so ne
also oder hocheffizient einfach, aber so richtig verstehen konnt
die keiner. Also dann kamen halt auch
Kollegen an und meinten Ey ich wollt da irgendwie die Library
erweitern aber irgendwie check ich die Funktion nicht.
Und du denkst dir so in deinem Midlevel ja, weil sie halt super
clever ist. Ne guckst selbst drauf nach
Wochen und denkst dir oh warte mal.
Jetzt muss ich aber selbst erst mal überlegen und das ist halt
schon n richtig schlechtes Anzeichen zu sagen, ich muss
jetzt selbst noch mal überlegen, was ich da gemacht hab, selbst
rausgeritzt war. Ja richtig, so ne, es
funktioniert zwar, aber ich check es halt nicht mehr und
dann bist du irgendwann senior def und denkst dir so, oh mein
Gott, das darf auf keinen Fall passieren, ich muss meinen Code
mit Absicht so simpel wie möglich schreiben, nicht
schlecht simpel bedeutet nicht schlecht ja sondern so nach dem
Motto wenn er irgendwie langweilig aussieht als wenn da
nichts Cooles passiert, dann ist das schon n gutes Indiz dafür,
dass er auch gut ist. Ne, weil dann ist er klar
strukturiert, einfach verständlich und.
Wie soll ich sagen, er ist halt für alle zugänglich und das
finde ich ist halt spannend, wenn man so diese 3 Level dann
sich. Durchschaut sozusagen.
Oder mal selbst überlegt, wie das bei einem war.
Ich hab da mal so n Spruch gehört, den finde ich eigentlich
ganz zutreffend und zwar wenn du sagst, du hast also du hast zum
Beispiel n komplexes Problem und guter Code.
Wenn du gut Code hast und dieses Problem dir anguckst, dann sieht
es einfach aus. Also dass du dir denkst, Oh, der
Code, das ist ja, da ist ja nichts Komplexes dran, das ist
ja super easy und das finde ich, ist irgendwie spannend so, weil
guter Code macht etwas komplexes einfach, weißt du.
Ja, also. Er sieht einfach aus, aber
covert ein komplexes Problem und sage ich mal cleverer Code, der
sieht. Zwar sehr, also der, der ist
halt schwer zu verstehen, sieht aber auch super esoterisch aus.
Weißt du, so ganz schick und toll und so weißt du, das ist
halt so so Code der Flex, so weißt du so nach dem Motto so ja
toll, aber es bringt ja auch nix wenn du dann zum Beispiel
wirklich mit deinem Kollegen irgendwie hingehst und der kommt
zu dir und sagt ja. Ich verstehe das irgendwie nicht
mehr ne und du sagst ja, das ist ja auch, lass mal gucken, wer
hat das denn da hin geballert ne und dann weißt du so dieses
typische gitblame ach ja, das war ich, das verstehe ich selber
nicht mehr, weil ich ja ja genau, also ich fand das ganz
schön, weil halt guter Code einfach ein komplexes Problem
einfach aussehen lässt und ich finde das ist irgendwie eine
ganz nette Beschreibung dafür. Ich hatte auch mal ein ganz
cooles Motto gehört, so nach dem Motto.
Am Anfang willst du viel Code schreiben, ne, du willst halt so
den Code reinhacken und schön am Coden sein und später gerade so
als Senior Death bist du froh, wenn du Code löschen kannst.
Ne, weil da genau darum geht es, dass du es geht nicht darum viel
zu schreiben, sondern den Halt effizient zu schreiben und
trotzdem verständlich ne und wenn du dann den Moment hast,
dass du sagst ha die Funktion brauch ich nicht mehr, das ist
halt denn so später so n so n Erfolg weißt du das?
Das fand ich halt auch ganz passend ja voll also definitiv.
Und ich find da kann man halt auch n bisschen das so abgrenzen
und sagen, OK, du hast es gibt cleveren Code ne so für die
Folge jetzt und es gibt guten Code ne und manchmal also es es
gibt sicherlich auch eine Schnittmenge zwischen cleverem
Code und guten Code, das will man ja gar nicht hinstellen,
dass man sagt das eine ist so und das andere ist so und es
geht nur entweder das oder das ne, aber man muss halt eben
gucken weil wie gesagt, es ist ja auch nicht, es ist ja auch
nicht schlimm wenn du bei so einem bei so einer Plattform wie
zum Beispiel Code Wars oder so, dann versuchst es möglich clever
zu machen, ne, also das ist ja auch völlig valide, nur man muss
halt immer gucken, das ist n abgekapselter Bereich, das hast
du ja auch so schon so schön gesagt ne und ich fand übrigens
den Begriff ganz lustig dazu, das heißt den hab ich vorher
noch nie gehört jetzt so. Beim bei der Vorbereitung auf
die Folge habe ich den Begriff Code Golfing gefunden und den
kannte ich nicht. Aber es ist halt so witzig, weil
du erst mal wie beim Golfen versuchst, du halt mit möglichst
wenig Schlägen ins Loch zu treffen, ne den Ball und hier
versuchst du halt mit möglichst wenig Lines auf Code deines
Problem zu lösen. Die Tests mit Code Wars zu
bestehen und dir das Licht zu kriegen, aber das fand ich
irgendwie ganz lustig, weil ich weiß nicht liebe zorin lieber
zoro, sag uns gerne ob du das schon vorher kanntest.
Also mir war es erst mal ein neuer Begriff mir auch, aber ich
finde den auch sehr witzig den Begriff.
Aber wie gesagt, was ich noch sagen wollte ist also du hast
ja, du hast ja auch gesagt, OK man muss gucken in welchem Scope
man sich befindet, ne und ja Code wars ist n scope, da kannst
du das ja machen weil dieser Code wird nirgendswo in dem
Sinne verwendet, aber wenn du jetzt wirklich sagst OK man
verwendet sowas in der Praxis oder zum Beispiel im sag ich mal
wirtschaftlichen Kontext, dann kann es natürlich echt n
bisschen schwierig werden ne wie zum Beispiel bei dem Beispiel
was du eben gebracht hast mit deinem.
Embedded Code? Ja, da können wir auch später
noch mal drauf eingehen, weil es gibt natürlich Situationen, wo
es nicht anders geht oder wo, wo es ja nicht mit Absicht so
clever dargestellt wurde, sondern wirklich ein
hochkomplexes Problem ist, was nicht mehr so einfach
dargestellt werden kann. Und erinnere mich da noch mal
dran, weil da ist Stichwort Library dann halt auch ein guter
Ansatz. Aber ich möchte mal vorher noch
mal kurz zu diesen One Line ankommen, also zu dem
vermeintlich cleveren Code. Welche Probleme siehst du denn
da drin? Also was für mich so ein
Riesenproblem ist und das habe ich ja gerade schon angesprochen
ist, wenn du später noch mal drauf guckst oder ein Kollege
dich da was zu fragt, dann ist es einfach schwer zu debuggen,
also wirklich ihn noch mal zu verstehen und Fehler da drin zu
finden, am besten noch unter Zeitdruck weißt du die Software?
Läuft nicht mehr, Tests sind rot und du sollst jetzt irgendwie
schnell n fix finden und guckst dann genau auf so n Code.
Denkst du so ey nee, bitte nicht, ja, da sind wir ja erst
theoretisch im wirtschaftlichen Kontext, oder nicht?
Ja, das ist ja, aber ich meine das, aber das ist so der das
Problem, weswegen so n Code da quasi produktiv sag ich mal
problematisch sein kann einfach was siehst n du dann noch was
für mich so n bisschen problematisch sein könnte an der
Stelle ist angenommen du bist jetzt zum Beispiel n Junior def
ne und hast jetzt. Arbeitest halt so für für die,
ich sag mal damit du ne bisschen Gehirnjogging betreibst, machst
du sowas wie Code was und siehst halt immer so hochoptimierte
Lösungen und denkst dann eventuell noch bevor du ins
Arbeitsleben einsteigst. Also in diesen wirtschaftlichen
Kontext ne hast du das Gefühl so wird programmiert, das ist diese
Art von Programmierung die angestrebt wird, das ist
unbedingt wichtig, dass ich das kann, ne und das ist vielleicht
schon n bisschen problematisch, weil angenommen.
Du drückst dir das so drauf, dass du alles immer komplett
ausoptimierst, ne? Dann, dann hast du irgendwann
tatsächlich n Problem in im wirtschaftlichen Kontext, weil
dann kommt es nämlich genau zu diesem Problem, die du
eigentlich gerade beschrieben hast.
Du musstest die backen, du vielleicht schnalzt es nicht,
was da genau passiert, also andere Schnallst nicht du
vielleicht selber irgendwann auch nicht mehr nach einer
gewissen Zeit und das ist halt einfach am Ende verbrennst du da
ne Menge an Geld. Ne, wenn du diesen diesen
zeitlichen Overhead hast, weil du erstmal angefangen hast.
Clevere, also clevere Lösungen zu schaffen, ne, so wie gesagt
ist ja nicht immer Schlimmes, hilft ja auch in diesen
Plattformen das zu machen, einfach um sag ich mal zu
trainieren um um überhaupt das Verständnis dafür zu kriegen,
was ist denn möglich, was geht denn so heißt aber noch lange
nicht, dass man dann auch wirklich unbedingt so coden muss
um halt eben nen guten Code zu haben, der halt eben auch
wartbar und verständlich ist. Ne?
Weil oft ist das ganze ja auch so n bisschen ego getrieben ne
und das finde ich halt auch schwierig.
Angenommen du zeigst ne Lösung oder so und dann siehst du halt
danach die Lösung zu One Liner oder so, dann denkst du so also
erstmal kannst dich selbst so n bisschen runterziehen,
vielleicht sogar n bisschen so das imposter Syndrom ankicken
ja, aber andererseits denke ich mir so warum kommen Leute um die
Ecke und sagen ja ich hab es aber in One Liner gemacht.
Das ist ja irgendwie auch so n Ego getriebenes Ding, so nach
dem Motto Ich kann das, ich kann damit beeindrucken ne also ich
hab das geschrieben um Leute zu beeindrucken oder vermeintlich
oder hoffentlich zu beeindrucken so das muss ja die Intention
dahinter sein und kauf mir aber dadurch dieses Unverständnis,
also im Team ein oder beziehungsweise auch das oftmals
der Test sag ich schon, darauf will ich hinaus der Code.
Schwer testbar wird ne, also so One Liner Abzutesten, die
oftmals dann auch nicht mehr modular sind, dann weißt du gar
nicht wie du die Testfälle dafür richtig erzeugen kannst.
Wie du überhaupt es schaffst das vernünftig abzutesten.
Ja, und das finde ich halt super problematisch dabei.
Ich hatte also ich hatte auch n Fall, ich glaub das hatte ich
auch mal in einer in einer Folge erwähnt.
Da hat ein alter Kollege von mir auch ein Modul geschrieben im
Frontend, da ging es um so Tabellen und in diese Tabellen
konnten verschiedene Daten rein, also zum Beispiel ein String,
also ein String. Jetzt aber zum Beispiel ein
Datum oder so, also wirklich ein String oder ein Daten, die einen
gewissen Kontext beinhalten, und da konntest du eine Menge
Reinschmeißen und du konntest aber jede.
Tabelle egal was für n Datentyp du für diese Spalte Reingegeben
hast, konntest du sortieren nach Größe so und damit man das jetzt
nicht tausendmal wieder machen muss und sagen muss, ja komm
ich, wenn dieser Datentyp da ist, müssen wir es so sortieren,
wenn dieser Datentyp da ist, müssen wir es so sortieren,
wurde halt ne sehr sehr allgemeine Komponente
geschrieben die egal was reinkam es irgendwie geschafft hat das
zu sortieren, so wie es gewünscht war.
Und an sich ist das ja auch erstmal gut.
Also es ist ja, klingt ja auch erstmal sinnvoll, das zu machen,
weil es ja auch dann, du kannst halt alles reinschmeißen, du
kannst es super entspannt verwenden, diese Komponente nur
wie ich meinte, es wird irgendwie sortiert, das war halt
tatsächlich so, es wurde irgendwie keine Ahnung, ich
wusste nicht wie, also wir mussten das dann erweitern und
da kam es dann zum Problem, habe ich mit einem anderen Kollegen
haben wir zu zweit versucht das zu erweitern oder anzupassen,
diese Komponente und das war. Echt richtig, richtig schwierig
also da haben wir glaub ich erstmal ne schon ne große Zeit
rein investiert um zu verstehen was da passiert um es dann
hinterher anzupassen und das ist genau der Punkt so.
Das ist ja bei manchen auch n Grund solchen Kurs zu schreiben.
Ne, das hab ich auch schon öfter gehört, dass es ne Art
jobsicherung ist und das find ich ist halt völlig der falsche
Ansatz zu sagen ich schreib mit absichtlich so komplizierte
Komponenten oder Module, damit nur ich als Autor dahinter.
Das noch verstehe ja also, dass ich quasi nicht ersetzbar bin am
Ende. Aber was ist, wenn du jetzt
wochenlang daran nicht arbeitest und drauf guckst und einer von
dem bist, der es nicht versteht, dann hast du ja dir zweimal ins
Knie geschossen, aber wie sagt man also das ist ja einmalig
gut, zweimal ins Knie schießen, auf gar keine, nicht gut, nicht
gut. Weil also Fakt ist ja einfach,
dass du halt, sag ich mal, in der Industrie, also wenn du
wirklich produktive Software entwickelst oder professionelle,
dann ist der Fokus immer auf Wartbarkeit, auf
Verständlichkeit, ne und Skalierbarkeit.
Das ist das sind so die Punkte die Gold wert sind am Ende und
nicht ja die Software ist an sich nicht so geil, aber Modul
XY der Teil da drin ist schon richtig clever geschrieben, das
sieht doch am Ende der Kunde eh nicht meistens ja richtig.
Ja, ich mein, bringt dir denn so n kryptischer Code gar nichts am
Ende? Nee, dem musst du dann 1000
Jahre lang eventuell noch debuggen, damit du verstehst ne,
was wir gerade gesagt haben, dazu hatte ich auch mal n ganz
lustiges Zitat gelesen und zwar von Brian Kerninghan und da geht
es im Kern darum, dass den Code zu debuggen eigentlich doppelt
so schwer ist oder doppelt so anstrengend, sag ich jetzt mal,
als wenn man den Code schreibt. Wenn du jetzt n super cleveren
Code schreibst, also wo du wirklich.
Alles Rausgepresst hast aus deinem Hirn.
Wie willst du diesen Code dann noch debuggen können, wenn es
halt noch doppelt so schwer ist? Ne, also ist dann irgendwie
nicht möglich, deswegen immer schön entspannten Code
schreiben, den man zur Not auch noch mal debuggen kann, ne?
Lassen somit die Backen. Nee, aber ich find das Zitat
auch extrem passend, weil es ist einfach so, wenn du Wochen
später denn drauf schaust, musst du halt gefühlt noch mehr
Aufwand reinstecken um ihn die backen zu können, um ihn
überhaupt wieder verstehen zu können und Fehler da drin zu
finden als in dem Moment wo du ihn geschrieben hast.
Also ich find das super zutreffend, ich mag das sehr,
das Zitat vor. Allem find ich auch wenn man
jetzt das Ganze noch mal n bisschen, wenn man jetzt da noch
mal n bisschen weiter geht. Merkt man eigentlich auch, wie
wichtig Code Reviews eigentlich sind, also was dahinter steckt
weißt du, weil wenn du jetzt zum Beispiel also debacken ist für
mich so n bisschen sowas wie ne du bist n kleiner Sheriff und du
guckst was für Probleme da ne wo wo die wo die Crimes versteckt
sind sozusagen. Und wenn du jetzt aber n Code
Review machst machst du im Endeffekt so n bisschen sowas
wie OK du hast so diese Prämisse, dass du sagst.
Es ist jetzt vielleicht kein Bug an sich erstmal mehr drin, davon
kann man vielleicht ausgehen. Ja, du checkst ja trotzdem, ob
du irgendwas findest, was vielleicht nicht ganz hinhaut
oder wo man vielleicht noch was optimieren kann und so, aber das
halt ohne die Bagger und ohne dass du im Normalfall den Code
ausführst. Ne.
Also wenn du jetzt einfach nur sagst, ey lass mal über die Divs
gucken, ne und deswegen ist es halt.
Wirklich wichtig und auch ne wirklich ne spannende Aufgabe.
Auch n richtiges Code Review zu machen und nicht einfach nur mal
drüber zu fliegen und sagen ja passt schon passt schon, passt
schon ne. Also das noch mal am Rande ja
aber zu Code Reviews haben wir auch schon mal ne Folge gemacht
also wer hat Interesse? N super wichtiges Thema, gerade
weil du halt dadurch n Feedback kriegst, ob dein Code den du
geschrieben hast, verständlich ist.
Ne, weil wie heißt das so schön? Klarer Code muss kein
Zufallsprodukt sein, du kannst gibt halt Methoden, Mittel und
Wege einfach zu einem klaren Code und zu einer guten Software
zu kommen und da 10 Reviews halt absolut mit rein, ne genauso wie
ne gute Planung wie du am Anfang meintest.
Ja wenn du jetzt natürlich. Sofort in die Richtung cleverer
Code denkst und dir überlegst, wie du im im kleinsten Detail im
wenigsten wenig Zeilen wie möglich irgendwie diesen Code
schreiben möchtest, um so ein kleines Problem zu lösen, dann
hat das Halt nicht viel mit Planung zu tun.
Das ist halt einfach Perfektionismus am Ende im
negativen Sinne meiner Meinung nach, sondern Planung, wie
integriert sich das in die Gesamtsoftware ja, also wie
sieht meine Struktur aus, ist die nachhaltig, muss ich was
refactern das sind ja alles. Punkte, die dann als Ergebnis
haben sauber zu coden. Ja, dass du halt sagst, ich
Teile zum Beispiel in kleine, logisch getrennte Codeabschnitte
oder Module auf ja Klassen von mir aus ja, wo auch immer wir
uns gerade bewegen oder oder ich definiere wirklich ne saubere
Schnittstelle zwischen Modulen, das sind alles so Punkte, die
reichlich überlegt werden müssen und da sitzt nachher.
Die eigentliche Cleverness sage ich mal zu sagen.
Wenn du das gut meisterst, dass wie gesagt der Code am Ende
langweilig aussieht, wie wir es ja eingangs erwähnt hatten, was
quasi n Ziel ist, was man erreichen möchte, wenn der Code
wirklich so auf den ersten Blick so, ja ist nichts Besonderes
drin, dann ist es wahrscheinlich gut gecoded ja genau, und das
ist das eigentliche Ziel dahinter, ne was man nie
vergessen sollte, sind natürlich auch die Tests dahinter, die
auch immer dafür sorgen, um auch zum Beispiel auch.
Gutem Code mögliche Bugs vorzuenthalten, weil wie gesagt
die Backen nervt, aber an der Stelle sei noch mal gesagt, dass
es natürlich auch wichtig ist und dass es hier auch ne Sache,
strukturplanung, vielleicht auch refactoring.
Auch in puncto Tests, weil es ist natürlich auch wichtig, dass
jetzt nicht zu viele Tests da sind, sondern halt wirklich
fokussierte Tests, also die wichtigen Tests.
Also du kannst so viele Tests schreiben, die am Ende belanglos
sind oder nicht wirklich das Abtesten worum es geht, hat man
auch selber schon erlebt, habe ich auch schon erlebt, habe auch
schon mal ein Test geschrieben, wo ich mir irgendwann dachte, so
eigentlich brauche ich den gar nicht, sondern dass man halt
wirklich die Basisszenarien halt eben ab testet, testet und
vielleicht dann noch die Edge Cases.
Ja, genau, das ist ein sehr guter Punkt.
Also es geht ja nicht nur darum, die die eigentliche Software,
den eigentlichen Code sauber zu halten und auch zu refactern,
sondern natürlich genauso dein Test Framework dahinter, was
mindestens genauso viel Aufmerksamkeit braucht um
einfach auch eine wirklich gute Testabdeckung am Ende bieten zu
können, ganz klar, aber dann lass uns, wir haben es ja jetzt
schon mal so ein bisschen gesagt, dass so.
Klarer, verständlicher Code, kein Zufallsprodukt sein muss.
Aber warum ist es denn am Ende aus deiner Sicht schwieriger,
das zu erreichen und eigentlich erstrebenswert oder die
Eigentliche, das eigentliche, was Applaus geben sollte, wenn
jemand schafft wirklich seine Software klar strukturiert zu
entwickeln und auch gut verständlich.
Na ja, also du hattest ja auch schon mal gesagt, Planung
beispielsweise, du musst das Ganze auch im Team normalerweise
abstimmen, weil du ja auch oft halt eben im Team arbeitest.
Und es kommt unter Umständen auch noch mal zu zusätzlicher
Dokumentation. Das ist jetzt auch wieder so ein
Punkt, ne, weil gerade jetzt, wenn es jetzt zum Beispiel um
Doku geht, ist es halt immer eine Frage, auf welcher Ebene
wird dokumentiert, was ich oder wo ich die Erfahrung gemacht
habe, ist, dass es durchaus hilfreich ist.
Manchmal also angenommen, du bist an einem bestimmten Punkt,
wo du Code schreibst und du dir denkst, mache ich es jetzt auf
die eine Weise oder mache ich es auf die andere Weise?
Ich weiß es nicht genau, dann fängst du an mit vielleicht noch
einem Kollegen oder einer Kollegin darüber zu diskutieren,
wie wollen wir es denn jetzt genau machen, A oder b.
Und dann entscheidet man sich im Normalfall irgendwann vielleicht
noch nach einem Handel mit dem gesamten Team für sagen wir mal
B. Und ich hab aber schon so oft
gehabt, dass du irgendwann an den Punkt kommst.
N halbes Jahr später, n Jahr später, wann auch immer, dass du
dir denkst, warum haben wir b genommen, warum haben wir nicht
a genommen, ich weiß, kennst du das, dass du dann sagst, so,
also vielleicht ist es sogar alles wieder gechallend genau,
vielleicht kommt n neuer Kollege rein oder was auch immer und
dann klar, neuer Kollege, neue Kollegin, neuer Wind, absolut
ne, man soll ja auch neue Ideen mit reinbringen, das ist ne
klare Sache was ich meine ist, dass man auch durchaus in diesem
Beispiel was ich gerade. Erwähnt habe auch oftmals an den
Punkt kommt, dass irgendjemand das Challengen sagt.
Wieso, wieso haben wir nicht a genommen, was war?
NA jetzt das Problem, wir können doch mal A ausprobieren und ich
weiß nicht ob du dich auch schon mal auf so n Experiment
eingelassen hast, wo man dann sagt ja komm wir probieren noch
mal a. Eigentlich hast du recht
wirklich gute überzeugende Argumente, man probiert A ist
irgendwann an dem Punkt wo man sagt und deswegen haben wir
nicht a genommen so was ja. Und.
Manchmal muss man durch den Paint noch mal durch und das ist
halt so bescheuert und deswegen das mein ich mit Dokumentation,
dass man sich an solchen Scheidewegen halt wirklich mal
überlegt, welche also warum haben wir uns für B entschieden
und das zu dokumentieren um hinterher wirklich noch mal
schneller abrufen zu können, ohne diesen Exkurs noch mal zu a
zu machen zu sagen, ja gut, das waren die Gründe und die
Situation hat sich nicht mehr geändert, b bleibt so wie es
ist. Ja, das ist n guter Punkt und
auch genau der Richtige, oder? Der richtige Scope, um zu
dokumentieren weil nehmen wir jetzt noch mal die Kehrseite,
wenn ich quasi jede Zeile Code anfange zu dokumentieren, und
das hatte ich auch schon in Projekten, wo es so von höherer
Ebene quasi gewollt war zu sagen, Nein, ihr müsst euren
Code dokumentieren, wo ich mir so denke, na warte mal.
Aber wenn ich jede Zeile Code irgendwann dokumentiere, dann
ist mein Code einfach nicht gut, das würde, da würde ich mir ja
selbst eingestehen, dass ich es nicht gut programmiert habe,
weil es ja anscheinend nicht verständlich ist.
Und das ist halt auch n Thema. Warum klarer Code auch
schwieriger ist, weil dein Ziel muss ja sein, dass jede Zeile
Code so klar und nachvollziehbar ist.
Ja, und so quasi wie hattest du mal gesagt, seine eigene
Geschichte erzählt, dass du genau weißt.
Diese Zeile macht das so. Ja, und das finde ich ist ja so
n Punkt Lesbarkeit einfach. Der super entscheidend ist.
Und wenn ich jetzt anfange meinen cleveren Code auszupacken
und schreib da drüber hier in dieser Zeile passiert jetzt und
dann hab ich so 10 Zeilen Kommentar, weil das halt so n
One Liner ist, wo einfach 1000 Sachen passiert da, da wird sich
nie jemand mit beschäftigen mit dem Code weißt du, dann ist das
so blöd gesagt gottgegeben so ja also das ist ne Blackbox jetzt,
diese eine Zeile ist schon ne Blackbox und die werd ich
niemals anrühren ich werd jetzt einfach hinnehmen was da
passiert und hoffen dass es funktioniert so.
Ja, und das ist halt einfach nie n guter Weg um zu sagen, im Team
wollen wir jetzt klar klaren Code schreiben, gute Software
entwickeln, dann ist das auf jeden Fall nicht das Wahl der
Mitte. Nee, das Mittel der Wahl so rum
ne. Aber man weiß.
Was ich meine, ich weiß es aber. Manchmal hast also manchmal hat
man ja, also man kommt ja nicht immer drumherum, ne, also gerade
wenn es jetzt um Dokumentationen über Kommentare geht, im Code
beispielsweise, das war ja jetzt so n bisschen dein Beispiel,
denn. Kommt man ja nicht.
Vielleicht nicht immer drum rum, also komplett auf Kommentare zu
verzichten und wie gesagt, manchmal ist es ja auch völlig
in Ordnung, ne also wenn du jetzt irgendwas hast wo du sagst
so Boah ey keine Ahnung, das ist halt einfach so, nimm es hin, es
ist jetzt leider Anforderung was irgendwie sowas, dann kommt man
ja auch nicht immer drumherum, dann ist es auch in Ordnung,
ansonsten ist es natürlich immer schön wenn Code irgendwie
selbsterklärend ist, vielleicht auch sogar noch mit.
Ich sag mal der Unterstützung der Tests zum Beispiel.
Das ist meine Erfahrung, dass das eine gute Sache sein kann.
Das ist auch eine gute Überleitung, weil ich meinte, am
Anfang erinnere mich noch mal dran.
Jetzt habe ich mich so ein bisschen selbst gedanklich daran
erinnert. Und zwar gibt es natürlich auch
Fälle, wie Du meinst, wo man kommentieren muss und es gibt
Fälle, wo auch einfach mal cleverer Code ich muss, man
sieht die Anführungszeichen nicht mehr, aber so dieser
clevere Code in Anführungszeichen auch mal
notwendig ist. Ja, wo ich halt wirklich mal
sage, ich muss jetzt richtig viel Hirn und.
Schmalz in so n Algorithmus reinpacken und der ist einfach
komplex. Das ist jetzt vielleicht auch
irgendwas mathematisches, dass irgendwas kompliziertes
berechnet wird, was einfach nicht jeder checkt, der da nicht
drin steckt in diesem Thema. Ne und das ist ja auch völlig OK
und manchmal passiert das einfach und dann gibt es halt so
n paar Best practices würde ich sagen.
Um einfach das gut in einer Gesamtsoftware oder in einem
Projekt einzugliedern, sag ich mal, dass du quasi dir dessen
bewusst bist, dass das jetzt so ne Art Code ist, sag ich mal und
einfach kommentieren musst du nicht.
Halt gucken, guck weg, ja genau, guck weg ja, aber Dokument also
dokumentierung ist halt im Prinzip schon genau das
Stichwort, ne wenn das notwendig ist, dann dokumentiere es gut,
Versuch zu erklären was. Schnittstellen sind ja also,
weil ich ja vorhin meinte, das war für ne Library, das ist auch
im Prinzip so geblieben. Es war aufwendig, denn das zu
debuggen oder oder zu erweitern, ja, aber diese Library wurde ja
quasi auch dementsprechend verwendet und die Schnittstellen
waren halt klar dokumentiert, was ist Input und Output?
Ja, und das hilft ja den Entwicklern beim Verwenden, die
Sagen ist mir egal wie der Algorithmus oder die Berechnung
da drunter aussieht, ich brauch aber einfach diese Berechnung,
ich brauch den Wert dahinter bei den und den Eingang und.
Das ist halt genau der Punkt, dass du sagst, OK, wenn ich
sowas mache, kann ich es Kapseln zum Beispiel mit einer klaren
Schnittstelle, die gut dokumentiert ist, dann ist das
legitim. Und was du meintest, da hab ich
auch noch was Witziges gefunden, das kannte ich auch nicht.
Es gibt so diesen Mythos, kann man es nicht sagen, aber so so n
fast schon so n meme, dass man einen Kommentar hier be Dragons
ranpackt und da hab ich mich fast totgelacht, weil ich das
witzig finde, dass das so etabliert ist, dass man so
sinngemäß. Ja, also so sinngemäß OK, pass
auf das, was du dir hier anguckst ist gefährliches
Gebiet. Ja, also hier können Drachen
sein, so ne stell dir keine Fragen, nimm es am besten genau,
stell keine Fragen, nimm es einfach so hin, wenn du den Weg
gehst es verstehen zu wollen und ändern zu wollen, dann wird es
hier richtig gefährlich so oder das ist so das Meme dahinter ja
der hier be Dragons Kommentar fand ich auf jeden Fall super
witzig, muss ich auch irgendwann mal einbauen, ich muss jetzt
irgendwo so ne so ne. Codezeilen schreiben, nur damit
ich diesen Kommentar setzen kann.
Welches Level brauche ich um diese Drachen zu besiegen?
Ja genau, ah das ist das ist echt witzig, also das kannte ich
auch noch nicht, dann auf jeden Fall danke fürs Teilen, also
Liebe zur lieber zurer sag uns mal ob du das kennst.
Also das würde mich jetzt mal interessieren, weil wir immer
Hass einen Kommentar schon mal verwenden genau also
zusammengefasst wenn ich sowas mache.
Versuchen das zu Kapseln, zum Beispiel in einer Bibliothek mit
einem klaren Interface, was dokumentiert ist.
Und dann halt der hier be Dragons Kommentar ran damit also
im Code ne sobald einer da reinschaut sich denkt ah OK
falsche Richtung hier ab umdrehen und zurück das ist
natürlich das ganze gut abtesten ne wie du vorhin meintest man
muss natürlich auch gewährleisten, dass es
funktioniert, immer wichtig ja aber wenn wir jetzt mal also ne
das sind ja jetzt so die ganzen Sachen die wir jetzt besprochen
haben, da kann man natürlich sich jetzt hinstellen und sagen
Boah. OK, angenommen ich bin jetzt
irgendwie noch nicht so weit oder was auch immer.
Wie was ist denn jetzt sozusagen der Weg um zu sagen, OK, was
soll ich denn jetzt machen, soll ich jetzt mich hinstellen und
bei Code wars beispielsweise einfach sagen, ja gut, dann
programmier ich halt immer nur irgendwelche stumpfen
Algorithmen, die sag ich jetzt mal einem sofort einfallen, ich
brauch eigentlich gar nichts mehr zu optimieren, weil ist ja
wahrscheinlich eh dann nur in Anführungsstrichen der clevere
Code den ich mir hier aus den Fingern drücke.
Sagt man so aus den Fingern, drückt also, wie geht man denn
jetzt am schönsten damit um? Was weißt du, das ist doch jetzt
eigentlich mal ne ganz gute Frage, um so langsam zum Ende zu
kommen vielleicht. Also so noch n Take away oder
was? Ja.
Zum Beispiel. Also ich hatte jetzt so n
bisschen daran gedacht, dass, wie wir auch schon gesagt haben,
ne bei Code wars, es ist ja hilfreich auch mal sag ich jetzt
mal diese. Challenge auf sich zu nehmen und
zu sagen, ganz bewusst, jetzt versuche ich das ganze mal
wirklich richtig hochoptimiert zu machen oder mit einem One
Liner, so dass es halt möglichst wenig Code ist.
Du kannst dir ja selber eigene Challenges setzen und zu sagen,
ich versuche diese Aufgabe jetzt mal so oder so oder so zu
machen, performant möglichst wenig Code heißt ja nicht immer,
dass es gleich performant ist oder halt vielleicht auch
einfach. Über eine ganz ausgefallene
Variante, so was auch immer so Versuch mal einen anderen
wegzunehmen als der, der dir sofort eingefallen ist.
Irgendwie sowas, und das sind ja auch Sachen wo du was dazu
lernst, wo du sagst, ey, das ist ja vielleicht noch mal, da habe
ich noch mal eine neue Gehirnbindung dazu bekommen, so
nach dem Motto und sowas hilft ja auch und gleichzeitig würde
ich sagen zu gucken wo, wie schreibe ich denn zum Beispiel
Code, sodass ich mir irgendwann mal.
Also mit dem Gedanken, wenn ich mir das jetzt zum Beispiel in 3
Wochen angucke, wenn ich mir das in einem Monat angucke oder wenn
ich es mir in einem halben Jahr angucke, verstehe ich das immer
noch so, vielleicht diesen Hintergedanken zu haben, dass du
verschiedene Möglichkeiten hast, Code zu schreiben.
Und gerade wenn du in einem produktiven Umfeld bist,
wirklich zu sagen, okay, es muss nicht mega clever sein, es
sollte guter Code sein, aber es sollte kein hochoptimierter Code
sein, den man selber irgendwann nicht mehr versteht so.
Das sind ja zum Beispiel so Mögliche.
Also so könnte ich es mir vorstellen, dass man diese
Herangehensweise nutzt, egal an welchem Level man ist.
Zum Beispiel ne. Es ist ja auch n guter Punkt so
ne Challenge zu machen und zu sagen, ich schreib jetzt so
hochkomplexen Code oder komplex nicht mal unbedingt komplex,
sondern so. Ja clever ist immer schon das
richtige Wort ne und ich zwing mich das zu machen um einfach
auch später wirklich erkennen zu können.
Was ist jetzt einfach nur cleverer Code und so n bisschen
ego gepusht oder was ist halt wirklich guter Code am Ende und
das ist halt auch essentiell zu sagen ich muss auch die
Erfahrung sammeln und versuchen sowas zu schreiben um später
einfach erkennen zu können ob ich wieder in diese Richtung
gerutscht bin oder vielleicht doch.
Noch auf dem richtigen Weg bin und wie gesagt das Zitat was du
vorhin meintest, das immer im Hinterkopf zu haben, ich muss
eigentlich per Definition irgendwann diesen Code debuggen,
irgendwann kommt der Tag wo ich mir das wieder angucken muss und
dann wird es doppelt so schwer sein wie in dem Moment wo ich
gerade locker flockig die Knöpfe drücke und den Code schreibe und
deswegen ist Klarheit. Quasi nicht nice to have so.
Naja, wäre schon cool, wenn man es so schnell verstehen könnte,
sondern es ist halt Pflicht, einfach weil du wirst auch
wieder in der Situation sein es verstehen zu müssen.
Ja wie war das mal? Code wird von Maschinen
ausgeführt, aber wird von Menschen gelesen so und deswegen
muss der Code auch lesbar sein, so bitte da haben wir es doch so
hätten wir doch die ganze Folge zusammenfassen können, direkt
eingangs nee, aber was wäre ein Einzeiler?
Genau. Aber was ich halt zum Beispiel
auch noch ganz interessant find ist, dass man auch gerade um
vielleicht auch guten Code zu schreiben, sich auch vielleicht
mal sagen kann, ich nehm mir jetzt so ne Art, so ne Art
guideline. Woran ich mich wirklich mal n
lang hangel, die kann sich ja auch entwickeln, ne, aber dass
man immer mal so n gewissen Abschnitt hat wo man sagt ich
ich folge jetzt einem Guide den ich mir vielleicht selber
auferlegt hab, nur mal als Beispiel also es geht jetzt um
Übung ne um dann zum Beispiel zu sagen OK ich zieh das jetzt mal
wirklich so durch und dann kann man ja auch mal evaluieren.
Ist es n ne gute n guter Guide den ich mir da überlegt habe.
Kannst dich auch austauschen mit anderen weißt du aber, dass du
und das hab ich auch ehrlich gesagt noch nie so krass
gemacht, dass ich wirklich mal gesagt hab, es gibt so ne
richtigen so n richtigen Guideline, zum Beispiel sowas
wie auch ey ich mach jetzt n Pfeil da, da kommen jetzt zum
Beispiel nicht 500 Zeilen Code rein, sondern es ist auf jeden
Fall, wenn es über die diese Anzahl von Lines of Code
hinausgeht, dann muss irgendwie die Business Logik da getrennt
werden oder so ne Sache weißt du.
Dann so mit statischen Analysen. Nee, aber weißt du, dass man
vielleicht auch so ein bisschen Erfahrung halt eben sammelt und
genauso zum Beispiel auch, was immer hilft, ist, dass wirklich
auch erfahrene Entwickler und Entwicklerinnen auch mal Reviews
vom eigenen Code machen, also dass man irgendwie auch mal sich
so was einholt und ich weiß nicht, da kann man sich auch mal
überlegen, ob zum Beispiel lieber zurer, wenn du mal Code
hast, wo man mal ein Feedback haben möchte, dann lass uns das
gerne mal auch auf der Podcast Mail zukommen.
Und wir können uns das zum Beispiel auch mal mit allen, die
auch oft bei Twitch zum Beispiel dabei sind, auch insgesamt mal
angucken. Dann können wir vielleicht ja
auch mal ein gewisses Feedback darüber geben, um einfach mal
auch ein Learning für dich zu generieren.
Genau. Ansonsten haben wir ja das
Rescue The Code Format noch, wo wir so freie Reviews in
regelmäßigen Abständen verlosen und dann halt auch Reviewen und
Feedback dazu geben, dass wir dann auch eine sehr gute
Anlaufstelle dafür ja. Cooles Thema gewesen, liebe
Zuhörer, liebe Zuhörer, du kannst ja auch dir mal ne
Challenge stellen. Hast du denn schon mal versucht,
deinen eigenen Code, wenn wir schon beim Thema sind oder den
du uns vielleicht zukommen lassen möchtest, nach langer
Zeit noch mal versucht zu lesen? Und wie waren da so deine
Erfahrungen, hast du ihn noch verstanden, wenn nicht, dann
willkommen im Club, das kennen wir, das Gefühl aber das ist auf
jeden Fall immer n sehr cooles Experiment zu sagen, ey ich
schau jetzt einfach mal so in alte.
Programmierung von mir rein und guck mal was ich daraus ziehen
kann. Ja und dann kommt man
wahrscheinlich relativ schnell zu dem Code, zu dem Code genau,
man kommt schnell zum Code, nein man kommt schnell zu richtig zu
dem Schluss, dass es durchaus sinnvoll ist lesbaren Code ne
höhere Priorität einzuräumen, als dass der Code jetzt
unbedingt clever sein muss ne also selbst wenn du schon
vielleicht auch schon fortgeschrittener bist in der
Entwicklung und nicht gerade am Anfang stehst oder dir Code vom
ganz am Anfang holst, sondern vielleicht auch Code von.
Sag ich mal schon erfahren deinem erfahreneren ich so.
Also ich kann mir vorstellen, dass ich mir auch mal Code
nehme, wo ich mir denke, so aha, ich hab aber ganz toll dachte
ich mir super Sache Fabian, da hast du aber richtig clever
versucht einen drauf zu machen, so und dann versteht man ihn
erstmal nicht mehr. Ja in dem Sinne würde ich sagen.
War auf jeden Fall n guter Punkt.
Hast du noch? Möchtest du noch was sagen zu
diesem Thema, Tino dann mal raus, wir haben es glaube ich
ausführlich besprochen, wir sind fertig und in dem Sinne würde
ich sagen, wenn dir die Folge oder der Podcast gefällt, dann
lass auf jeden Fall mal n like da beziehungsweise ne Bewertung
das würde uns mega helfen auch und ansonsten wie gesagt.
Schreib uns auf. Entweder der Podcast Mail oder
auf unseren Social Media Kanälen kommen auch gerne in unseren
Discord. Immer herzlich Willkommen auch
für neue Gespräche und neue Anregungen und sonst würde ich
sagen, wenn du sagst bevor wir uns jetzt hier verabschieden,
den beiden möchte ich noch eine Kleine sagen wir mal etwas Gutes
tun, dann kannst du auch eine kleine Spende auf den auf den
Spenden Link uns schicken findest du alles alle Links die
ich gerade genannt habe unten in den Shownotes.
Und ansonsten hören wir uns in der nächsten Folge wieder deine
Colling bollies. Gemeinsam besser.