Was macht gute Software-EntwicklerInnen aus? - podcast episode cover

Was macht gute Software-EntwicklerInnen aus?

Oct 24, 202445 min
--:--
--:--
Download Metacast podcast app
Listen to this episode in Metacast mobile app
Don't just listen to podcasts. Learn from them with transcripts, summaries, and chapters for every episode. Skim, search, and bookmark insights. Learn more

Episode description

Bist du ein guter Developer? Hast du dich gefragt, welche Aspekte dabei entscheidend sind? Wir haben uns in diese Frage in der Folge gestellt und herauskristallisiert, welche Punkte für uns wichtig sind. Du bist auf der Suche nach einer IDE, die keine Wünsche öffnen lasst? Hol dir jetzt deine Jahreslizenz für jede JetBrains IDE und spare 25% mit dem Code "CODINGBUDDIES". Hat dir die Folge gefallen? Wir freuen uns natürlich auch über eine kleine Spende unter: https://streamlabs.com/thecodingbuddies/tip Dies ermöglicht uns unseren Content weiter zu verbessern. Vielen Dank! Folge uns doch zusätzlich auf unseren anderen Plattformen oder schau auf unserer Website vorbei: Discord: https://discord.gg/C2Zntw6Sq4 Instagram: https://www.instagram.com/the_coding_buddies Youtube: https://www.youtube.com/@thecodingbuddies Twitch: https://www.twitch.tv/thecodingbuddies TikTok: https://www.tiktok.com/@thecodingbuddies Du hast Feedback für uns? Schreib uns über [email protected]!

Transcript

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.

Transcript source: Provided by creator in RSS feed: download file
For the best experience, listen in Metacast app for iOS or Android
Open in Metacast