Nee, ich habe das schon immer so gemacht und so läuft das.
Und was willst du mir denn erzählen?
Keine Ahnung, ich habe schon gecoded, da bist du noch mit der
Trommel und Weihnachtsbaum gelaufen oder sowas Coding
Buddy, Dein Podcast rund um Softwareentwicklung und
aktueller Tech News. Herzlich Willkommen.
Halli Hallo und herzlich Willkommen.
Eine neue Folge vom Coaling Buddies Podcast steht an und
damit begrüße ich natürlich klare Sache.
Tino, Wie geht's dir, Moin Moin Fabi, mir geht's super, ich bin
fit, ich hab Bock es ist mal wieder soweit die Folge xx weiß
ich nicht, ich weiß gar nicht wo wir stehen, ich weiß es auch
nicht ne Menge schon. Aber ist ja ja auf jeden Fall
schon. Weiß nicht ungefähr eineinhalb
Jahre läuft der jetzt schon. Ne interessant auf jeden Fall.
Aber Mann, Mann, Mann, die 100. Folge, da müssen wir uns
irgendwas ausdenken und ich weiß, dass das noch nicht die
100. Folge ist.
Aber das ist gut, das ist gut, weil ich hatte jetzt gesagt oder
hätte gedacht, so was ist, wenn die 100.
Schon war, aber nein, ich glaube 100 sind es noch nicht.
Glaube ich auch nicht. Aber ich finde es auch immer so.
Ich weiß nicht, ist das eigentlich so ein so ein so der
allgemeine Monk, der so in jedem herrscht, dass man sagt, so ja,
bei einer 100 darfst du was Special mäßiges machen, aber
nicht bei der 98 auf gar keinen Fall auf der 98.
Ja, warum solltest du das bei der 98 machen?
Also wirklich. Vielleicht ist die Zahl bei der
Holla. Oder gar nicht, sonst auch nie
wieder. Nie wieder.
Nein, aber ich find's so witzig gut.
Aber das ist Zukunftsmusik, da sind wir ja noch nicht.
Aber ist wie bei wie bei Geburtstagen feiern so.
Du darfst halt, also weißt du so n großer runder Geburtstag, den
feierst du so richtig dolle dann ne also den richtig doll, aber
alle anderen sind eigentlich scheißegal.
Wenn. Du so denkst darauf.
Ja, ich finde du kannst aber jeden Geburtstag feiern, wenn du
Bock hast. Durch weißt du also so zieh es
durch, wenn wenn du wenn man darauf bock hat dann.
Let's Go, Man ist da geboren. Aber uns beide einladend, ja
sehr schön okay gut, das ist aber glaube ich nicht unser
heutiges Thema. Och Mann, aber spannend trotzdem
lass uns doch lieber darüber reden.
Nein, hau mal raus, du hast doch bestimmt n Thema mitgebracht,
habe ich aber. Ganz kurz bevor wir jetzt
wirklich reinstarten, möchte ich, dass wir uns noch.
Mal auf die Sache mit den Geburtstagen zurückkommen.
Ich möchte mich noch mal in unser beider Namen sozusagen
bedanken. Ganz herzlich bei Lynn für eine
wunderschöne Spende. Ja danke, vielen Lieben Dank, es
freut uns auf jeden Fall, dass. Dir, dass du Tipps und Hilfen
sozusagen aus unserem Podcast mitnehmen kannst.
Das ist natürlich richtig cool und das motiviert uns sowas von
hier auch auf jeden Fall weiter zu machen.
Ja, absolut vielen, vielen Dank dafür.
So und jetzt Tino können wir gerne richtig rein starten und
zwar geht es heute einfach mal darum, dass wir aus unserer
Sicht gucken, was macht einen guten Softwareentwickler oder
eine gute Softwareentwicklerin aus?
Ne, also da hat vielleicht auch jeder so seine eigene Meinung
von oder sein eigenes Bild, aber zumindest können wir ja unsere
Sicht der Dinge einfach mal darlegen und gucken, bisschen
darüber diskutieren, bisschen quatschen, paar Punkte auf den
Tisch legen, was denn so die Punkte wären, die aus unserer
Sicht wichtig wären. Ja, finde ich spannend.
Das Thema möchtest du das nur so aus technischer Sicht betrachten
oder auch sage ich mal so Soft Skills oder im Projekt
geschehen. Also ich würde schon sagen wie
gesagt ne Sichtweise von uns und ich würde auch sagen, dass die
technische Sicht ist auf jeden Fall ein Punkt, den wir
betrachten sollten. Also was ist technisch wichtig,
dass man sozusagen n guter Softwareentwickler oder ne gute
Softwareentwicklerin ist? Aber genauso find ich, zählt es
auch mit rein, dass man bestimmte Softskills mitbringen
sollte, die genauso wichtig sind, um eben halt auch als gut
dann in dieser Kategorie sag ich jetzt mal zu gelten.
Ne ja ich find doch schön, dass du gesagt hast, dass das genauso
wichtig ist. Die Softskills, weil das seh ich
auch so und da gibt es bestimmt n paar Punkte, die wir da mal so
herauskristallisieren können. Finde ich gut.
Das Thema würde ich sagen, lass uns damit starten, dann fangen
wir mit den technischen Sachen an würde ich sagen oder?
Genau da war ich auch gerade schon.
Hau mal drauf drauf. Zu sagen, erst technisch, dann
die softskill Sachen. Ich würde auf jeden Fall als
erstes und ich denke das ist so ein bisschen so ein No brainer,
dass man einfach sagt, OK, wenn man ein guter Softwareentwickler
oder eine gute Softwareentwicklerin sein
möchte, dann ist es schon wichtig, dass man auf jeden
Fall. Eine Sprache also.
Ich würde sagen, eigentlich nicht nur eine einigermaßen gut
beherrschen sollte und mit einigermaßen meine ich, dass man
auf jeden Fall in der Lage ist, größere Projekte zu erstellen
oder daran mitzucoden. Also man sollte zumindest einen
tiefen Sachverstand von einer Sprache haben, aber eigentlich
würde ich sogar dahin gehen, dass es eher 2 schon sein
sollten. Am besten je mehr, desto besser.
Aber wie siehst du das? Ja, also je mehr, desto besser.
Klar klingt das jetzt erstmal, sage ich mal einfach oder
richtig an der Stelle, aber es geht ja dabei nicht darum, ein
bisschen die Syntax zu kennen und einfache Algorithmen drin
schreiben zu können in der Sprache, sondern wie du schon
meintest, auch ein tieferes Verständnis zu haben, aber.
Und da fällt mir immer wieder ein das Interview, was wir mit
Anthony hatten, da hat er n sehr sehr coolen Punkt genannt, dass
er meinte für ihn ist es insofern wichtig, dass man quasi
für sämtliche Bereiche, die es so gibt in der
Softwareentwicklung vielleicht denn eine passende Sprache hat
und die auch. Kennt und sich damit auskennt,
damit man wie du so wie du ja gerade meintest, in gewissen
Projekten einfach mitarbeiten kann, dass man dich da quasi
reinwerfen kann ins Team und du so n bisschen dich umschaust.
OK, was für n Stack verwendet ihr hier, wo Codet ihr drin?
Und adaptierst dich quasi dann auf dieses Team und kannst aber
denn aktiv mitarbeiten und das finde ich, ist dann dabei
entscheidend, dass du halt auch wirklich weißt, OK, ich was wir
wollen jetzt n Backend machen. Ja, ich könnte das und das jetzt
so machen beispielsweise oder Frontend whatever you name it
und das finde ich, ist dabei entscheidend, dass du halt, sage
ich mal, gezielte Werkzeuge hast, mit denen du dann auch
sehr effektiv arbeiten kannst. Also ich finde halt wie ich mal
also. Eine Sprache zu haben, sollte
man auf jeden Fall, dass man zumindest Konzept von
Programmiersprachen wie etwas programmiert wird, auf jeden
Fall verinnerlicht hat und das auf jeden Fall echt kann.
Ne, das ist wichtig und dann aber genauso auch diese.
Also ich find erst mal den Punkt sehr gut, dass man sagt OK du du
hast, du kannst ne gewisse Masse abdecken ne jetzt kommt bestimmt
der ein oder andere und sagt ja gut das kann ich mit einer
Sprache ich brauch nur Rust oder so, kann damit alles machen.
Okay auch in Ordnung, ne, wenn du da richtig tief drin bist,
ist das ja, also finde ich ist es ja auch in Ordnung, nur ich
glaube es ist wichtig, dass man genauso dann aber auch in der
Lage ist, diese Transferleistung zu bringen und zu sagen, Ey guck
mal dieses Projekt an dem wir hier arbeiten, ist jetzt zum
Beispiel nicht in Rust, sondern vielleicht in Java und dann
sollte man aber auch einfach in der Lage sein zu sagen, alles
klar, Java okay wie geht die Syntax da ich bin raus okay
peace, ich bin raus. Nee, aber weißt du, dass du dann
halt einfach auch relativ schnell eben auch in der Lage
bist, umzusteigen und zu sagen, OK, ne andere
Programmiersprache, ich kenn die Syntax vielleicht nicht, aber es
ist am Ende irgendwo immer noch das gleiche.
Ne, vielleicht ist es noch mal hilfreich zu sagen, OK du hast n
Verständnis von objektorientierung, du hast n
Verständnis von funktionaler Programmierung, dass man da halt
eben auch noch diese Konzepte von verschiedenen Programmierart
und weisen kennt, sag ich jetzt mal und versteht.
Das zählt da für mich dann auch rein, wenn man sagt,
Programmiersprachen beherrschen. Es ist ja auch dann zum Beispiel
nicht so, dass du ne Programmiersprache hast, wo du
nur das eine oder nur das andere kannst.
Also zu beispielsweise Kotlin, da kannst du sehr viel
funktional programmieren, hast aber auch die Möglichkeit
Objektorientiert zu programmieren, also alles
möglich sozusagen. Ja, ich glaub der der der
Kernpunkt dabei was du. Meinst auch damit ist ja, dass
du halt allgemeines Verständnis von gewissen Algorithmen und
Datenstrukturen hast. Und da finde ich zeichnet einen
sehr guten Entwickler oder eine sehr gute Entwicklerin aus, wenn
dieses Verständnis auch sehr tiefgründig ist.
Also dass man wirklich n super Überblick darüber hat, was für
Datenstrukturen gibt es so? Also nicht nur ich bin jetzt,
ich fange jetzt an zu entwickeln sozusagen, und ja, ich, ich
brauche jetzt irgendwas, ja, ich nehme jetzt mal ne Liste oder
ich nehme jetzt n array oder so, sondern dass du halt wirklich
gezielt auch abhängig von dem, was du umsetzen möchtest von
deinen Randbedingungen auch gezielt Datenstrukturen
auswählst und dadurch auch effiziente Algorithmen entwerfen
kannst. Das finde ich, ist halt.
Sehr wichtig und entscheidend am Ende.
Und da hab ich auch mal n cooles Video gesehen wo ein Google
Mitarbeiter interviewt wurde der keine Ahnung 15 Jahre plus, also
wirklich lange schon in dem Unternehmen war und denen haben
sie mal ne ähnliche Frage gestellt ob er n Tipp geben kann
sozusagen und. Er meinte halt auch wirklich mal
die Basics bis ins Detail verstehen und verinnerlichen und
das wären jetzt für mich so Basics, die er hoffentlich auch
denn damit meinte. Weißt du also, dass man wirklich
mal weiß, was wie sieht, was ist ne Liste eigentlich, was sind
Bäume hashmaps ja ich mein man hört überall hashmaps wenn du
Probleme hast. Ja nimm ne Hashmap ist ja so so
n halbes Meme schon geworden und das aber wirklich mal alles
verinnerlichen finde ich zeichnet dann auch nen sehr
guten Entwickler oder eine sehr gute Entwicklerin aus.
Finde ich gut. Also auch einfach die Grundlagen
sozusagen nicht zu vernachlässigen, weil mein
kleines Beispiel, was mir dazu direkt einfällt, ist ja auch so
was wie man nimmt eine Variable, zum Beispiel ein integer, aber
wann hast du das letzte Mal wirklich darüber nachgedacht zu
sagen, ich nehme jetzt ein Scient oder ein unsign integer
beispielsweise, also es gibt ja rein theoretisch die Möglichkeit
zu sagen, ich nehme einen integer wert, der überhaupt
nicht negativ werden kann. Anstatt dessen wird aber häufig
zum Beispiel dann gesagt okay, ich nehme integer und prüfe, ob
er größer gleich 0 ist oder so. Und da ist halt die Frage okay
wieso muss man denn diese Überprüfung überhaupt noch rein
theoretisch machen, wenn du eh die richtige Datenstruktur schon
wählst? Von vornherein?
Also das sind ja auch so ein paar Dinger, wo man eigentlich
schon, also wo man, wo man wirklich mal auch im Alltag
spezieller drüber nachdenken kann oder sollte, dann am Ende.
Das ist ja also das sind, das sind auch Bequemlichkeiten und
Gewohnheiten, gerade so bei Variablen, das hatten wir auch
im im cleancode Kontext auch besprochen, ist ja sowas wie, ja
wann, wie oft verwendest du überhaupt const bei Variablen,
wann denkst du effektiv drüber nach, wär ja auch so n Punkt ne
für mich zum Beispiel bin ich da so n bisschen.
Gebrandmarkt aus meiner C. Welt, Weil da machst du dir sehr
viel Gedanken darüber, auch Richtung Speicher und wie groß
muss überhaupt der Datentyp sein, den Du da verwenden
möchtest für die Variable, aber man kommt auch schnell in den
Trott, wenn das keine Rolle mehr spielt, dass du sagst, ja komm
gib ihn, ich nimm jetzt einfach irgendein Datentyp, ob der jetzt
von der Größe passt oder nicht, ob er kleiner sein könnte, es
spielt keine Rolle, wir haben eh Speicher ohne Ende, so weißt du.
Genau. Und da aber diese Gedanken
Richtung Datentypen Datenstrukturen sich mal
wirklich effektiv immer wieder zu machen, das ist finde ich,
ist dann wirklich der entscheidende Punkt und da kann
jeder sich auch noch mal an die eigene Nase fassen, wie du so
schön meintest, dass man da quasi immer wieder drauf achtet
und nicht in so einen entspannten Flow kommt und sich
denkt, ach naja komm passt schon, passt schon.
Ja, ich meine, man kennt das ja selber so.
Du weiß ich nicht, wir programmieren ja auch gerne ein
type Script, so zumindest aktuell ist es eine Sprache, die
bei uns häufig so durch die Finger rutscht, sage ich jetzt
mal. Und ja, dann haust du da halt
mal ein Latin und kein const so und wie gesagt Mal an die eigene
Nase fassen mache ich auch mal gerade.
Aber ganz bestätigt hat er gemacht.
Aber was, was du auch meintest in Sachen zum Beispiel effizient
zu programmieren oder zum Beispiel, ja, wir haben ja
genügend Speicher, es ist, finde ich, auch zum Beispiel eine
sehr, sehr, sehr wichtige Eigenschaft, auch im technischen
Bereich als Entwickler oder Entwicklerin, wenn du eine sehr
gute Entwicklerin und sehr gute Entwickler sein möchtest, dass
du dir sagst, okay, ich habe jetzt vielleicht eine Aufgabe,
die ich coden muss und. Ich bin ja richtig gut und
deswegen mache ich die jetzt unglaublich effizient und
hinterher lasse ich mich dafür feiern, dass keine Ahnung, diese
Aufgabe, diese dieser Algorithmus, den ich geschrieben
habe, unglaublich effizient ist und super schnell ist und eine
sehr geringe Komplexität hat. Also was wie o von 1 so nach dem
Motto ne, also das ist eigentlich das Beste was geht
und. Dann verstehst du aber
vielleicht diesen Code nicht mehr und jeder andere sagt dir
dann am Ende ja gut, aber klar ist es jetzt super schnell, aber
die Anforderung ist hier überhaupt nicht gegeben, das
super schnell zu machen. Also weißt du, dass du zwar
sagen kannst, OK, ich kann zwar flexen mit meinen Fähigkeiten
sozusagen, aber es ist. Auch eine Fähigkeit zu
überprüfen oder auch dieser Erfahrungswert zu sagen, unter
welcher Situation ist es denn zum Beispiel wirklich sinnvoll
und wichtig, Sachen zu implementieren, die vielleicht
gar nicht so gut lesbar sind, also dass die Lesbarkeit ein
bisschen auf der Strecke bleiben darf, aber dafür sollte halt
eben die Performance unglaublich hoch sein versus es ist gerade
überhaupt nicht notwendig, dass es hier aus performt ohne Ende.
Aber es ist wichtig, dass der Code gut gelesen werden kann.
Weißt du, wie ich meine? Ich finde, das ist auch eine
wichtige Eigenschaft, eine wichtige Eigenschaft dazwischen
zu differenzieren, um zu sagen, welchen Weg gehen wir denn an
dieser. Stelle ja, also dass man denn
quasi in der Lage ist, gut einzuschätzen, was jetzt
wichtiger ist. Ob die Verständlichkeit und die
Wartbarkeit des Codes im Vordergrund steht oder es eine.
Stelle ist im gesamten Produkt, wo dieser Teilalgorithmus sage
ich mal hocheffizient sein muss, weil dann ist es ja absolut
legitim zu sagen, Hey, ich bin in der Lage, meine Komplexität
zu verringern, beispielsweise weil es gibt immer mehrere
Lösungen und meistens gibt es schlechte, also schlechte im
Sinne der Komplexität halt ne und schnellere.
Und dann muss man halt, dann muss man halt in der Lage sein
abzuwägen. Ich mein, wenn das so n
abgesteckter Bereich ist, wo nicht mehr viel dran passiert,
dann ob die mir ihnen so gut es geht ne ich mein das kennt man
ja aus verschiedenen Libraries, beispielsweise wenn du aber
sagst da arbeiten sehr viel Entwickler dran und da ist
richtig Bewegung drin, das muss ständig verändert und erweitert
werden, dann ist es nicht so vorteilhaft zu sagen OK ist egal
ob man es lesen kann oder nicht, aber das Ding rennt sowas.
Und da bin ich ganz bei dir, das ist ne sehr wichtige
Eigenschaft, wirklich an den richtigen Stellen das Richtige
zu tun, klingt jetzt so abgedroschen, aber mache das
Richtige an den richtigen Stellen einfaches ja voll
beendet, das war es aber, was auf jeden Fall, was mir auch
noch einfällt und was ich auch finde, was ne gute
Programmiererin oder n guten Programmierer eben halt auch
ausmacht oder Softwareentwickler besser gesagt.
Ist auch der Punkt, dass es geht, natürlich auch viel
natürlich um die Sprache, in der man schreibt, oder die
Datenstrukturen, die man anwendet.
Ne genau diese Differenzierung zu machen, die über die wir
gerade gesprochen haben und und und.
Es ist aber auch wichtig, dass man eben nicht nur sich auf die
Programmiersprache fokussiert, weil es wie gesagt auch wirklich
nur ein kleiner Teil ist. Weil du hast ja zum Beispiel
auch viele verschiedene andere Sachen, die an der Stelle
wichtig sind, die über sozusagen dein Programm hinausgehen.
Also zum Beispiel sowas wie, wo packe ich meine Daten persistent
hin, Stichpunkt Datenbanken, wo zum Beispiel wie, wie lasse ich
meine Anwendungen laufen in einem Container zum Beispiel,
wie ist meine Infrastruktur für die Auslieferung der Software,
am Ende habe ich Tests zum Beispiel.
Solche Sachen, das ist ja auch alles wichtig.
Also diese ganze Architektur drumherum und diese
Architekturentscheidungen, wie etwas passiert, genauso auch zum
Beispiel versioniere ich meine Software, also dieser ganze
Punkt drumherum, das ist ja, also du hast diese
Softwareentwicklung und da drin ist ein Punkt, und der nennt
sich Programmiersprache, und da drum gibt es unglaublich viel,
und manchmal habe ich das Gefühl, wie gesagt, ist nun ein
Gefühl, dass es gibt Leute, die sich denken, ey, ich kann jetzt
hier, ich habe jetzt ein Python Skript geschrieben,
programmieren ist ja gar nicht so schwer, das Problem ist aber,
dass du halt sehr sehr viele Bereiche hast, die du am Ende
noch die am Ende noch oben drauf kommen und es ist nicht einfach
nur mal ein kleines Python Skript zu schreiben, so also
viel Arbeit steckt ja auch außerhalb der idi.
Das ist ja nicht nur das Coden an sich oder?
Lass lass den mal kurz wirken, aber da geb ich dir halt absolut
recht, weil die, die also die Zeit am Tag, wo du wirklich
effektiv Codezeilen schreibst ist nicht so hoch wie manche das
wahrscheinlich erwarten werden. Ich finde, sie sollte schon ein
gewisses Maß haben. Also es gibt ja auch Leute, die
sagen ja hier ich Code, also fast gar nicht mehr so, ich bin
ja nur noch am Drumherum machen, das ist nicht so meine meine
Vision davon und auch nicht mein Ziel bei mir persönlich, weil
ich liebe programmieren, aber es ist absolut klar was du meinst,
das viel Drumherum steckt und testen zum Beispiel ist auch ein
riesen Punkt ich finde. Dass ein Entfahren, ein
erfahrener Entwickler oder Entwicklerin schon diese
intrinsische Motivation haben sollte, den eigenen Code
abzutesten und wirklich Wert darauf zu legen, das ist für
mich dann auch der Punkt zu sagen, das ist eine gute
Entwicklerin oder ein guter Entwickler.
Wenn das der Fall ist. Ein anderer wichtiger Punkt ist
auch zum Beispiel das Thema Debugging, dass.
Kommt über Erfahrung meiner Meinung nach.
Also man muss einfach sich schon oft durch Code gewühlt haben und
Fehler gesucht haben um da besser drin zu werden, weil da
ist es ja immer anders sozusagen man kann sich quasi so gewisse
Strategien zurechtlegen, wie man sich denn annähert, versucht
diesen Bug zu finden, aber am Ende ist es viel Erfahrung finde
ich und das ist dann auch noch so ein Punkt wo man sagen kann,
das sollte man. Drauf haben.
Man sollte in der Lage sein so was finden zu können
beziehungsweise ist es eher so ein Punkt finde ich wenn ich so
drüber nachdenke, dass es eine Frage von Ausdauer und
Hartnäckigkeit ist. Dabei ja, ich weiß.
Nicht wie du das siehst, aber nee, definitiv.
Also man, ich glaube jeder, der eine Zeit lang schon Software
entwickelt, ist auf jeden Fall schon mal an diesen Punkt
gekommen, dass man irgendwie mal verzweifelt war.
Und sich dachte, warum zur Hölle, wie geht das?
Ich verstehe diesen Fehler nicht, warum tritt das so auf,
wieso ist das so und saß dann auch mal eine Zeit lang da mit
weiß ich nicht den Kopf in den Armen vergraben, weil man sich
denkt, so ach wie mache ich das denn jetzt, wie mache ich das
denn jetzt und am Ende schafft man es halt irgendwie, also ich
oder man macht es irgendwie anders, ich weiß nicht, also
rückblickend habe ich jetzt noch nie so was gehabt, wo ich sage
das. Hat nicht funktioniert, es geht
nicht. Der Fehler ist da, Tschüss, ich
gehe nach Hause oder ich lass den ganz.
Ja, genau das ist die Hartnäckigkeit, dass du sagst,
nein, es muss funktionieren und ich will den Weg finden, dass es
funktioniert. Ja genau.
Also das ist auf jeden Fall ein wichtiger Punkt und am Ende ist
es ja auch so, dass man sich natürlich hinstellen kann und
sagen kann, okay ein starkes Verständnis von
Programmiersprachen sollte man haben, man sollte ein
detailliertes Verständnis darüber haben, wie zum Beispiel
Datenstrukturen. Funktionieren welche man
verwendet, wie man das genau verwendet, dass man zum Beispiel
auch differenzieren kann, muss ich jetzt irgendwie performanten
Code schreiben oder muss ich lesbaren Code, also ne
beziehungsweise worauf sollte ich den Fokus legen, das ganze
testen, die backen, diese ganzen wissen, also Kenntnisse über
verschiedene Technologien, die außerhalb der Programmiersprache
sind, das sind ja alles Sachen wo man sagt OK.
Klar kannst du jetzt eine Checkliste schreiben und sagen
Okay hier, Technologie XY kenne ich, kann ich das und das das
Ding ist aber das viel auch wie du meintest.
Über die Erfahrung kommt das heißt klar kannst du dir jetzt
eine Checkliste machen und sagen ich drücke mir geht drauf ich
drücke mir Docker drauf, ich drücke mir keine Ahnung 3
Programmiersprachen drauf und so weiter aber wenn du das
innerhalb von einem Jahr machst, dann wirst du aber trotzdem noch
einen wichtigen, dann wird dir ein wichtiger Punkt fehlen und
das ist die Erfahrung und die kannst du.
Nur über Zeit gewinnen und nicht über wie sagt man, die kannst du
nicht erzwingen. Weißt du was ich meine?
Ja, absolut. Also da muss man sich auch die
Zeit geben und dann nicht so streng nach Checkliste
versuchen, das in einem halben Jahr oder so alles abzuhaken,
weil das wird halt nicht funktionieren.
Und ich finde, was auch ein sehr, sehr wichtiger Punkt ist
nochmal um vielleicht das Thema technische Skills sozusagen,
also was technischen guten Entwickler oder eine gute
Entwicklerin ausmacht. Um das noch mal abzuschließen,
falls du nichts noch hast. Dazu ist auch der Punkt, dass
nur weil man jetzt zum Beispiel sagt Okay, das ist ein guter
Entwickler oder das ist eine gute Entwicklerin, heißt das
noch lange nicht okay. Die Personen können jetzt alles
so, weil manchmal wird auch so angenommen, ja guck mal hier, du
sagst du bist gut okay, dann kannst du das auch und dann nee,
das kann ich nicht, damit habe ich noch keine Erfahrung, ja
siehst du bist halt doof. So weißt du.
Bist halt nicht gut. Und das das ist halt auch, finde
ich n wichtiger Punkt, den man auch differenzieren sollte, weil
es gibt ne Menge und du kannst nicht in allem perfekt sein,
aber du kannst trotzdem ne gute Softwareentwicklerin oder n
guter Softwareentwickler sein. Ja, auch wenn du nicht alles
kannst. Ja, das ist ja, glaube ich,
einer der ersten Punkte gewesen, vorhin zu sagen, es gibt eine
gewisse Transferleistung, die man schaffen muss, dass du
sagst, okay, ich kenne ähnliche Probleme oder ich habe schon in
anderen Programmiersprachen so was entwickelt und dass du in
der Lage bist, dein Wissen dann quasi zu transferieren auf die
neuen Technologien, die zum Beispiel verwendet werden, und
dann dich sehr schnell einleben kannst und mitentwickeln kannst.
Das ist ja das Entscheidende am Ende, definitiv.
Ja, muss ich sagen, aber schön zusammengefasst die technische
Seite. Jetzt kommen wir mal zur zur
Softskill und so projektgeschehen Seite, die ich
mich auch sehr wichtig und spannend finde und was mir halt
auffällt oder immer wieder auffällt ist, dass eine gute
Entwicklerin oder einen guten Entwickler der folgende Punkt
ausmacht und zwar Teamarbeit beziehungsweise Zusammenarbeit.
Ich finde, man merkt daran schnell, wie gut man zusammen
arbeiten kann und wie wie gut das float.
Daran merkt man, ob der andere quasi sehr erfahren oder gut
ist. Sagen wir mal in dem Falle, das
heißt es ist ja also Softwareentwicklung, ist ja
irgendwo ein gemeinschaftlicher Prozess.
Ab einer gewissen Projektgröße wirst du es ja alleine nicht
mehr bewältigen können und das ist auch relativ schnell
erreicht. Ich glaube man überschätzt
immer, was man alleine umsetzen kann in einer gewissen Zeit, was
zum Beispiel auch ein Punkt ist. Wenn du merkst okay mein
Gegenüber hat wirklich eine realistische Schätzung, die sich
mit meiner deckt. Naja gut, schwer zu sagen, wenn
ich selbst. Unerfahren bin werde ich
wahrscheinlich mich auch überschätzen.
Dann deckt sich es nicht mehr, aber ich sag mal, wenn jemand
auf die Bremse tritt und sagt EY, bleiben wir mal realistisch,
das schaffen wir in der Zeit nicht, wir müssen das und das
und das berücksichtigen, dann zeichnet das finde ich auch
einen guten Entwickler aus an der Stelle.
Ja, ich hab da mal ne lustige Geschichte zugehört.
Und zwar ging es jetzt mehr so in Richtung Montage, aber
vielleicht kann man das irgendwie auch so übersetzen.
Und zwar ging es dann irgendwie darum, dass so ein neuer
Lehrling kam. Irgendwie kommt so rein und der
Meister sagt Ja, komm hier, ich zeig dir alles und so weiter und
dann kommt irgendwie der weiß nicht der Chef an und sagt
Leute, wieviel schafft ihr von den Teilen die ihr da bauen
sollt, wieviel schafft ihr davon heute und der Lehrling sagt, EY
ich schaffen, wir schaffen davon heute locker 10 Stück und der
Meister sagt Ja pass mal auf wir machen 5 okay wir machen 5 ja so
ne wir schaffen locker 10 so und dann ja der Tag.
Geht los. Der Tag ist beendet, die haben
10 geschafft und der Lehrling sagt die Zimmermeister 10 Stück.
Also was ist los und er so ja okay und wie fühlst du dich
jetzt? Ja, war schon echt anstrengend
und er so und kannst du das jetzt so 3040 Jahre machen oder
wie sieht das jetzt aus? Ja, okay, das geht ein bisschen
in eine andere Richtung. Ja, aber irgendwie erinnert mich
das dann ein bisschen daran. Weil im Endeffekt ist.
Weißt du, wenn du, wenn du dich hinstellst und sagst okay, du
kannst vielleicht auch, wenn du sehr motiviert bist und sagst
okay ich, ich mach das und Softwareentwicklung ist ja auch
ein bisschen kognitiv auch, also finde ich auch anstrengend, also
man muss halt auch gehirnschmalz reinstecken, so wenn du das aber
die ganze Zeit wirklich sehr exorbitant machst und vielleicht
auch nicht mal eine kleine Pause machst am Tag, die auch
vielleicht wichtig ist, dann. Kannst du vielleicht bestimmte
Sachen schaffen, aber es ist langfristig halt auch nicht
wirklich wie sagt man gesund, weißt du was ich meine?
Ja, ja, das wird nachhaltig dem Projekt entscheiden.
Wenn du immer bei 100% läufst, von Anfang an ganz klar.
Und außerdem ist es umso schlimmer, wenn du dann zum
Beispiel irgendwelche Ziele reist, weil du es einfach dich
komplett überschätzt hast. Dann lieber realistisch an die
Sache rangehen und ich finde, dass also ich glaub da muss
jeder durch am Anfang, dass man das maßlos überschätzt.
Aber das das passt sich an über die Zeit.
Also das wirst du ein 2 mal falsch einschätzen, dann wirst
du schon genauer merkst. War wieder ein bisschen zu knapp
oder jetzt hat man doch wesentlich mehr Zeit also das
sind Erfahrungswerte am Ende und ich finde das zeichnet dann auch
wie gesagt eine gute Entwicklerin und einen guten
Entwickler aus, anderer Punkt den ich dabei auch sehr wichtig
finde ist das Thema Unterstützung, sich gegenseitig
helfen und vor allem wissen teilen.
Das ist für mich auch n wichtiger Punkt.
Wissen in das Team zu geben, was man mitbringen kann und
vielleicht nicht ganz so erfahrenen oder Junior
Developern, das Wissen auch zu teilen und zu sharen, dass du
einfach sagst, hey ich, ich möchte, dass ihr alle auf diesen
Stand kommt oder ich ich habe guten Input zu dem Thema und ich
möchte euch das mitteilen um euch um euch zu helfen besser zu
werden sozusagen. Ich finde, das ist auch eine
Verantwortung. Also wenn du guter
Softwareentwickler oder eine gute Softwareentwicklerin bist,
dann bist du normalerweise irgendwo auch schon, hast ein
paar Jährchen auf jeden Fall hinter dir, wie ich meinte, das
kannst du nicht dir erkaufen sozusagen, sondern das musst du
halt wirklich über die Zeit bringen, dass du halt auch
einfach diese Erfahrung mitbringst.
Und ich finde, das ist auch einfach eine Verantwortung, dass
man eben auch zum Beispiel jüngeren oder unerfahreneren
Leuten dann. Auch das Wissen möglichst
weitergibt, genauso aber auch offen ist für neue Sachen, die
dann vielleicht auch von ne, also vom Mindset her von dort
kommt, weil man ja auch nicht selber nicht eingefahren sein
soll und sagen soll, ja, das was ich jetzt erlebt hab in meiner
ganzen Vergangenheit, das ist die Wahrheit, ne, aber
nichtsdestotrotz hat man ja bestimmte Sachen einfach auch
erlebt, die man dann auch einfach weitergeben sollte, auf
jeden Fall also. Ich würde mich auf jeden Fall
hinstellen und sagen, wenn man irgendwie das nicht machen
möchte, dann wäre das eigentlich schon wirklich ein Minuspunkt,
weil, wie ich meinte, eben, es ist einfach die Aufgabe auch
oder die Verantwortung, halt das wissen, was man erarbeitet hat,
auch einfach weiterzugehen. Das ist schon ein wichtiger,
nicht guter Punkt, dass du das auch jetzt gerade genannt hast.
Auch diese Innovationsbereitschaft, die du
so angerissen hast gerade. Zu sagen, ich muss mich auch
selbst weiterentwickeln und bin nicht derjenige, der sagt, NÖ,
ich hab das schon immer so gemacht und so läuft das und was
willst du mir denn erzählen? Keine Ahnung, ich hab schon
gecoded, da bist du noch mit der Trommel und Weihnachtsbaum
gelaufen oder so, weißt du. Alter, ich laufe immer noch mit
der Trommel und Weihnachtsbaum. OK, was soll das jetzt?
Ja und ich hab schon gecoded in der Zeit OK.
Nein, aber es gibt ja nur Sonne. Leute werden einem begegnen und
da denkst du dir denn so ja okay, wie soll ich jetzt mit
dieser Person vernünftig zusammenarbeiten, die so fest
gefahren ist und man muss da selbst halt einfach
innovationsbereit sein zu sagen, ey okay es gibt neue
Technologien, ich schaue mir die an, vielleicht ist das überholt
wie ich es machen würde, es gibt bessere Möglichkeiten finde ich
es halt super essentiell dabei. Ja, definitiv.
Ich finde auch generell zu dem überhaupt zu dem ganzen Punkt.
Team Zusammenarbeit ne, Ich finde es ist immer so.
Also das ist ja diese ganze ich sag mal alles was mit
zwischenmenschlicher Interaktion zu tun hat, also ob man jetzt
zum Beispiel Feedback geben und aufnehmen kann, ob man jetzt zum
Beispiel wissen weitergibt, ob man einfach nur gut zusammen im
Team mit anderen Leuten, also eine Software programmieren
kann. All das, dieser Ganze überall,
wo du interagieren musst, sozusagen mit anderen Leuten, ne
so. Da muss ich ganz ehrlich sagen,
Tino ist das eine Sache, die habe ich am Anfang total
unterschätzt, weil ich mir mal dachte, man kommt doch irgendwie
mit jedem klar so, und ich habe unglaublich unterschätzt, wie
essentiell es erstens ist zu sagen, wenn du ein Team hast,
was läuft und was sich gut versteht, wie unglaublich gut
das dann arbeiten kann. Und genauso habe ich.
Unterschätzt, wie Schlimmes ist, wenn du jemanden im Team hast,
mit dem du nicht ganz so gut klar kommst und was das für
einen unglaublichen Impact am Ende für den Outcome hat.
Ja. Also es gibt nichts Schlimmeres,
als wenn du morgens anfängst zu arbeiten und irgendwie einen
bestimmten Kollegen oder ne Kollegin oder so.
Wirklich, wenn du keinen Bock da drauf hast, so weißt du oder zum
Beispiel auch weiß nicht, sagen wir mal, du arbeitest vielleicht
auch im Pair programming ne und dann?
Musst du vielleicht mit jemandem arbeiten?
Den ganzen Tag oder so, den du vielleicht?
Vorsichtig, jetzt ganz, ganz vorsichtig jetzt.
Nicht du Mann, aber weißt du, also hatte ich auch schon und ne
dann dann hat dann hast du so ein Team aus mehreren Leuten und
mit mit einem aus diesem Team arbeitest du dann auch mal
irgendwann zwangsläufig zusammen an einem Tag und das das.
Wie, wie, wie die Motivation steigt oder sinkt, dass man dann
sozusagen genau mit dieser einen oder mit einer anderen Person
zusammenarbeitet, und das hab ich total unterschätzt, auch am
Anfang, weil ich irgendwie immer dachte, ach, ist doch egal, man
kommt doch irgendwie mit allen Leuten klar und Spoilerwarnung,
es ist nicht der Fall. Ja, und das, was ich mit der
Motivation meins, das Münzt sich ja den 1 zu 1 auf die
Performance des Teams und das ist n riesen Punkt und.
Ich finde dieses umgänglich sein oder auch einfach professionell,
kann man sagen. An der Stelle zeichnet einen
denn auch aus, also dass man einfach sagt, OK, das ist jetzt
n Thema bei uns, wir müssen aber jetzt professionell damit
umgehen und dann sei es auch zum Beispiel dieses Feedback
annehmen und geben, auch Kritik, das nicht persönlich nehmen an
der Stelle, sondern sagen, OK, wie schaffen wir es denn jetzt.
Gut miteinander zu arbeiten und wie können wir das lösen?
Und ich finde, das ist halt auch dann n sehr essentieller Punkt
und sehr gut, dass du den hier ansprichst und n anderer Punkt,
was auch in Richtung Kommunikation geht ist was mir
aufgefallen ist, gehen wir gehen wir mal von dem Szenario aus, du
kriegst n Feature request vom Stakeholder und er sagt ich
brauche jetzt funktional Funktionalität XY das muss das
und das können. Dann gibt es Entwickler A, der
sagt alles klar, ich leg los, ich weiß Bescheid und Haut in
die Tasten und Entwickler b sagt OK hab ich soweit verstanden.
Wie sieht es denn mit den und den Bedingungen aus, was soll
denn passieren wenn das und das Eintritt der quasi das Ganze
kritisch hinterfragt und auch an Fälle denkt die auftreten
können, die vielleicht ein Stakeholder nicht im Kopf hat.
Und da finde ich, unterscheidet sich dann auch schon gut.
Also ein sehr guter Entwickler und ein Junior Developer.
Ich will jetzt nicht schlecht sagen, weil schlecht ist es
nicht vielleicht ein Junior Developer auch diese Fragen zu
stellen, weil man will auf keinen Fall doppelt
implementieren am Ende oder in die falsche Richtung
implementieren? Du willst ganz klar definieren
was zu entwickeln ist und. Und dann das umsetzen, weil die
Gefahr bei, ich glaube es war als Entwickler A gerade ne der
einfach direkt loslegt, ist natürlich, dass am Ende der
Stakeholder sagt, Hey, warte mal.
Nee, so habe ich mir das nicht gedacht.
Nee, das müssen wir noch mal, das müssen wir noch mal umbauen
und dann ist es einfach Wasted im im im schlechtesten Falle ne,
dass du dann vielleicht sogar 80% wieder wegwerfen kannst.
Ja, richtig. Und das, finde ich, ist dann
halt auch so ein Punkt am Ende. Und das weißt du was das der
Teufelskreis an der ganzen Sache ist oder wo sich die Katze ihren
Schwanz beißt. Du kennst das und ich kenn das
und weißt du warum wir das kennen?
Weil wir genau das schon warten. Na ja klar und das sind ja
deswegen sagen wir das ja das, also das sind die
Erfahrungswerte, die du sammelst und dann in Zukunft vermeiden
möchtest. Und das ist ja dieser Progress
am Ende vom Junior Developer zum Senior Developer beispielsweise,
dass du da nicht wieder jedes Mal reinläufst.
Definitiv. Ich mein, Das werden viele
erlebt haben, ja, dass man einfach übermotiviert in diese
Aufgabe reingeht und sagt, ich hab schon, weißt du, du hörst
es, hast ne Idee wie du es umsetzen kannst.
Du willst einfach nur anfangen zu coden, so weißt du.
Aber das ist halt dann am Ende nicht der beste Weg, ja kritisch
das zu hinterfragen und dann halt, wie du auch eben meintest,
natürlich das Ganze auch irgendwie auf einer
professionellen Ebene abarbeiten, so ne also weil
genau. Es ist halt manchmal auch dann
sozusagen schwierig. Ich hatte dann auch zum Beispiel
schon mal so, so n so n Gespräch ne in so nem über nen Feature wo
es dann heißt ja das und das ist jetzt zum Beispiel gewünscht, ja
mal unabhängig auch von edgecases man diskutiert über
die Edgecases, redet darüber ne legt die auch auf den Tisch, am
Ende ist es dann aber manchmal auch so, dass man ja nicht nur
die Edgecases hinterfragt, sondern eigentlich auch das
Feature selber, weil man ja auch durchaus sagen kann okay warte
mal, also du hast jetzt zum Beispiel eine Anwendung und der
Kunde sagt, ich möchte gerne Feature X in dieser Anwendung
haben, aber diese Anwendung, dieses Feature passt nicht in
dieser Anwendung, also warum oder ist es total sinnlos, warum
willst du das jetzt wirklich haben, also weißt du auch mal zu
sagen, ist es denn über also zu challengen ist es denn notwendig
das überhaupt zu implementieren, was da gerade gewünscht ist,
weil das ist auch wieder n erfahrungswert.
Wenn du ne Software entwickelst, dann wollen User gerne bestimmte
Sachen, aber die auch durchaus sinnvoll sind, aber es gibt
manchmal diese Punkte, wo n User sich denkt ja keine Ahnung, wenn
ich jetzt hier so n so n. Telefon eine anruf App habe wo
ich Videotelefonie machen kann wenn ich da warte, dann möchte
ich auch nebenbei noch ein Spiel spielen, weil dann ist mir nicht
langweilig so aber es passt da halt einfach nicht rein so.
Es ist halt einfach ein Feature wo ein User sich denkt ja das
wäre irgendwie cool aber es ist einfach nicht sinnvoll und dass
man auch genau so was challenged und sagt wollen wir noch mal
ganz kurz über diesen Wunsch reden, weil es vielleicht gar
nicht zielführend ist oder vielleicht auch manchmal hat man
ja auch so. Dass man abdriftet, auch als
Stakeholder und sagt, das wär auch noch cool, das wär auch
noch cool. Und auf einmal kann dein
Taschenrechner auch noch Notizen schreiben, so aber.
Das wär cool, das. Dann lass uns das doch
entwickelt Tino einen Taschenrechner los geht Notizen
hat. Ich denke wie lange.
Brauchst nicht weiter, du brauchst nichts mehr sagen.
Ich fange an, wie lange brauchen.
Wir 2 Tage. Ich denke da sind wir fertig,
ja. Da sind wir durch.
Nein, aber du weißt, was ich meine.
Und das sind auch wichtige Punkte, über die man reden
sollte. Und das ist aber auch n
Erfahrungswert, nicht einfach zu sagen, OK ich leg los, sondern
halt Edge Cases, aber auch die Sinnhaftigkeit manchmal zu
hinterfragen. Ja, ja, weil das spielt so in
den nächsten Punkt, den ich noch hab rein, der auch sehr wichtig
ist, ist, dass du halt ne Eigenverantwortung hast.
Also für das was du entwickelst und für das Produkt hast du.
Trägst du die Verantwortung für den Code und musst halt auch
proaktiv handeln, dann, wenn es zum Beispiel, wenn du das Gefühl
hast, das würde den Code verschlechtern, es würde
irgendwie, Sachen wären unlogisch da drin, wie du zum
Beispiel meintest, dass man sowas hinterfragt, also du bist
der Herr über diesen Code, sag ich mal, oder dein
Entwicklerteam und ihr müsst dafür dann auch einstehen,
sozusagen und immer bestrebt sein, präzise detailgenau zu
arbeiten und. Die höchste Codequalität zu
gewährleisten, das ist ja am Ende dein Job auch.
Ja, und ich finde, das ist n wichtiger Punkt, den man
vielleicht jetzt Junior Developer noch nicht so sieht,
dass man sich denkt, nee, ist wirklich, ich lasse jetzt nicht
zu, dass hier irgendwas passiert, so nach dem Motto,
sondern sich denkt, ja, ich hab es erledigt und jetzt nach mir
ist mir egal, so ne was damit passiert find ich ist halt auch
noch n wichtiger Punkt dabei ja. So n bisschen diese Weitsicht zu
haben. Zu entwickeln.
Na ja, und halt auch zum Beispiel gegen Slay Coiler zu
argumentieren und zu sagen ist vielleicht jetzt nicht so geil,
wenn wir das machen aus dem und den Gründen und nicht quasi
alles immer aufnehmen und versuchen das irgendwie rein zu
basteln und die Codequalität sinkt und sinkt auch, zum
Beispiel hinsichtlich Projektdruck.
Ne, also mal angenommen, der erste sagt Na ja, Pass auf die
Tests kannst du später schreiben wenn wir noch mal beim Testen
sind, dass du dann sagst nee, auf gar keinen Fall werde ich
das so tun, meine Software ist Abgetestet, sonst keine fertigen
Features. Ja, ja, also auf jeden Fall gehe
ich total mit, dass man auch einfach diese Verantwortlichkeit
auch ernst nimmt. Und da bin ich auch ehrlich, das
hatte ich zum Beispiel auch. Am Anfang hatte ich so nicht,
also für mich war das so, ich hab ne, ich hab angefangen mit
dem, also wirklich so im ersten Job und du.
Ich habe eine Aufgabe bekommen und ich habe gesagt, ich ich
code das halt runter so ich ich so getting work dann so ne
einfach das mal fertig machen. Mittlerweile ist es natürlich
was anderes mittlerweile wie du meintest so man kommt an den
Punkt dass man sagt erstens schreibe ich die Software also
soll das eine gute Software sein zweitens jetzt habe ich zweitens
vergessen. Ich habe einen, zweitens es soll
halt auch wartbar und nachhaltig sein für auch andere Entwickler.
Ist ja auch so. N Punkt war mir früher auch
egal. Ganz ehrlich, also Fakt ist doch
einfach das was wir am Anfang hatten als Junior Developer und
was wie wir es jetzt angehen sind ja auch Punkte die sich
jetzt hier in dieser Folge widerspiegeln, weil du es ja
gerade noch mal gesagt hast. Ne sind ja unsere
Erfahrungswerte und vor allem auch unsere Entwicklung dabei.
Und unsere Sichtweisen. Und wie gesagt, also.
Ich weiß nicht, ob du noch einen Punkt hast.
Ich würde noch eine Sache noch mal ganz kurz auf den Tisch
legen, weil ich es vorhin angesprochen hatte.
Und das ist das Feedback, weil Feedback zu geben ist das eine
und zu sagen okay, ich möchte jetzt konstruktives Feedback
geben und ich finde, es ist auch ein sehr, sehr wichtiger, sehr,
sehr wichtiger Soft Skill Punkt Feedback anzunehmen und es ist
unglaublich schwierig manchmal Feedback anzunehmen, wenn der
Feedbackgeber oder die Geberin nicht diesen Skill so sehr
beherrscht. Und das finde ich manchmal
schwierig, weil man relativ schnell in Rechtfertigung
verfällt oder dann halt irgendwie sich angegriffen
fühlt. Und das muss man nicht machen.
Es ist aber verständlich, wenn das Feedback nicht gut gegeben
wird, deswegen kann man halt nur selber gucken, dass man gutes
Feedback gibt, also konstruktiv und auch nicht verletzend
sozusagen, aber es kommt halt nicht immer so zu einem hin und.
Und ich finde, das ist halt n unglaublich schwieriger Punkt
damit umzugehen. Und das ist aber auch n Soft
Skill, der unglaublich wichtig ist um sich aber zum Beispiel
auch selber weiterhin zu verbessern, weil es bringt ja
nichts, wenn du n Feedback bekommst.
Klar, wenn das Feedback blöd rübergebracht wird, dann ist das
natürlich nicht schön und das will ich auch gar nicht
bestärken. Ich finde man sollte gutes
Feedback geben und nicht irgendwie beleidigendes Feedback
geben, definitiv, aber man muss halt damit irgendwie lernen
umzugehen und. Das ist wichtig, aber wir haben
auch einmal schon ne Folge. Ne ausführliche Folge ist schon
n bisschen länger her, über Feedback gemacht und ich find
das ist sogar eine sehr sehr sehr gute Folge.
Also liebe Zuhörer, lieber Zuhörer, wenn es dich
interessiert, hör da auf jeden Fall gerne mal rein.
Es geht ja genau darum, was du gerade meintest zu sagen, ich
muss es auf die richtige Ebene bringen.
Am Anfang des Gesprächs schon, und das also nicht in dieser.
Es ist ne persönliche Angriffebene, da darfst du auf
gar keinen Fall reinkommen, sondern es muss.
In diese konstruktive Ebene kommen, dass beide den Mehrwert
aus diesem Gespräch dann auch ziehen.
Der, der das Feedback gibt und auch der, der es erhält.
Und das ist halt ein Punkt, der leider sehr oft auch schief
läuft und da kann man wirklich auch an sich selbst viel
arbeiten, wie du gerade so schön gesagt hast.
Und Feedback ist auch ein gutes Stichwort.
Liebe zuhören, liebe Zuhörer, falls du Feedback zu dieser
Erfolge hast und Anmerkungen. Auch zu den einzelnen Punkten
vielleicht oder ergänzende Punkte hast?
Dann lass es uns gerne wissen. Die Mail, worüber du uns
schreiben kannst, findest du in den Shownotes.
Tino, hast du noch einen Punkt? Nee, also das waren so für mich
eigentlich die wichtigsten Punkte.
Mal zusammengefasst war auf jeden Fall eine sehr coole
Folge, vielen Dank dafür. Das Thema fand ich cool.
Ja danke dir auch was auf jeden Fall wichtig noch mal zu sagen
ist, es sind natürlich jetzt unsere Erfahrung gewesen, auch
unsere Sichtweisen, die. Wie zum Beispiel also was einen
guten Softwareentwickler oder eine gute Softwareentwicklerin
ausmacht. Und es würde uns natürlich auch
brennend interessieren, wie du, Liebe Zurin, lieber Zurer, das
siehst, also ob du das genauso siehst, ob du andere Punkte
hast, ob du ergänzende Punkte hast, dann lass uns auch genau
das gerne über die Podcast Mail zukommen, ansonsten falls du.
Allgemeine Anmerkungen zum Podcast hast kannst du uns auch
gerne schreiben. Alle Links zu den Plattformen
findest du wie immer in den Shownotes.
Da findest du auch einen Link zu einer Spendenseite.
Falls du uns unterstützen möchtest.
Das würde uns mega mega freuen. Ansonsten empfiehl doch auch
gerne den Podcast weiter, wenn er dir gefällt.
So vielleicht 23 Freunden, das wäre auch mega und ansonsten
würde ich sagen, hören wir uns alle beim nächsten Mal wieder
und bis dahin eine gute Zeit und ciao ciao deine Coding Bodys
gemeinsam besser.