Dass man zusammen, sag ich jetzt mal als Leuchtturm, Duo, Trio, was auch immer auftreten kannst. Du weißt, du ist jetzt Richtung. Coding Babys. Dein Podcast Rund um. Softwareentwicklung und aktueller Tech News. Herzlich Willkommen. Ahh ja, herzlich Willkommen zur neuen Folge des Coding Bodies Podcast. Schön, dass du wieder eingeschaltet hast. Dabei sind natürlich wieder meine Wenigkeit Tino und der fantastische Fabi Fabi. Was geht ab, wie gehts dir? Mir gehts gut. Ja.
Ja, lass uns starten. Let's GO. Jetzt go. Wir haben uns ja für unsere Zuhörerinnen und Zuhörer heute eine besondere Folge. Überlegt. Und zwar wollen wir doch heute mal quasi mitteilen, was so unsere 5 Learnings der vergangenen Jahre im Bezug auf Software Entwicklung waren. Wir haben jetzt schon ein paar Jahre in dem Bereich gearbeitet und auch unsere Erfahrungen gesammelt und wollen heute einfach mal so die 5 großen Punkte raushauen. Hast du dich vorbereitet, sind die 5 eingefallen.
Ja, wir haben uns ja im Vorfeld schon mal ein bisschen Gedanken gemacht, dass wir zusammen auf so unsere 5 Learnings kommen. Genau, und dann würde ich sagen, lass uns doch mal mit dem ersten anfangen, wie wärs, wenn du einfach gleich hast du schon eingeleitet, wenn du gleich erstmal mit dem ersten Learning startest? Ja, kann ich gerne machen.
Den ersten Punkt, den wir uns überlegt haben, der fällt unter das Stichwort probieren, geht über studieren und das meint einfach damit, dass wir uns überlegt haben oder gelernt haben in den Jahren. Dass es immer gut ist, einfach loszulegen. Nicht lange grübeln also. Klar, man muss sich schon Gedanken machen, was man implementieren möchte, keine Frage, aber man neigt schnell
dazu. Das zu verkomplizieren, das heißt, dass man anfängt, sich schon über Probleme Gedanken zu machen, die eigentlich noch gar nicht die Problemstellung an sich sind. Weißt du, was ich meine? Ja, also es gibt ja zum Beispiel auch sogenannte MWPS. Das ist ja so minimal Valuable Product und die Zielen ja darauf ab, dass man sagt, OK, versuch erstmal das, was dein Produkt oder deine Software, die du dir überlegt hast. Was sie machen, soll wirklich im kleinsten Rahmen.
Was muss müssen für sag ich mal Funktionalitäten drin sein, die mindestens da sein müssen damit, dass deine Software ein Produkt was du machen möchtest, damit es überhaupt funktioniert. Und nicht mehr ne. Also was gibt es zum Beispiel? Genau, und da ist ja der Punkt, warum macht man sowas, weil sich genau so ne Anforderungen ändern können oder weiterentwickeln
können. Das heißt du weißt ja zum Anfang noch gar nicht, was alles noch so kommen könnte, jedenfalls in der Realität. Ne, ja, ich kenne das halt, zum Beispiel was ich auch öfters schon erlebt habe, selber ist, dass man irgendwie was programmieren möchte und sich denkt, hey, aber wenn wir jetzt zum Beispiel, wir haben jetzt
das und stell dir mal vor, aber. Später kommt noch irgendwie was Neues rein, ne, dass man sich dann überlegt, ja und dann kann man vielleicht schon mal irgendwas Neues rein programmieren, was eigentlich noch gar nicht da ist. Aber vielleicht kann man sich später Arbeit abnehmen, ne und das führt aber unweigerlich irgendwie dazu, dass zumindest meine Learning, was ich auf jeden Fall unseren Zuhörerinnen und Zuhörer mitgeben kann, dass man im Endeffekt.
Genau das Programmieren soll, was man erstmal überhaupt machen will, führt genau in diesem Gedanken vom MWP und alles andere, was darüber hinausgeht, verkompliziert erstmal nur den Code und bläht den logisch überhaupt irgendwie auf. Und das Ganze hat irgendwie hat auch einen Namen, also das heißt Janni, es klingt ein bisschen komisch, heißt im Endeffekt ausgesprochen UA, also wenn du es nicht brauchst, dann mach erstmal nicht und wenn du es brauchst, dann implementiert
hinterher. Genau, und dafür gibt es ja auch das wunderbare Refactoring später. Also genau das würde ich sagen, wäre auf jeden Fall so. Unser erstes Learning was du, liebe Zuhörerinnen und Zuhörer mitnehmen kannst. Commons doing fang einfach an, der Rest entwickelt sich während du s programmierst. Und Programmier nur das, was auch wirklich notwendig ist. Ganz genau. Ja. Zweites Learning was hast. Du ja, also ist ja auch ein Lieblingsthema von mir irgendwie.
Stichwort testen und zwar das zweite Learning ist nicht getesteter Codes fehlerhaft, bisschen provokant. Natürlich ja, aber es geht halt einfach darum, dass es durchaus wichtig ist, seinen Code zu testen. Ich weiß nicht, du, Tino kennst wahrscheinlich so n perfektes Beispiel, du hast das schon mal so ein bisschen gerade angesprochen, wofür beispielsweise ist? Wichtig ist, dass man Tests hat. Möchtest du das mal gerne? Uns, also ich weiß nicht was du meinst.
Ich denke mal du. Möchtest auch das. Refactoring hinaus. Genau dazu möchte ich mal kurz ausholen, testen also was damit gemeint ist. Ist ja auch vor allem automatisierte Tests, also wirklich Testfälle zu schreiben guter Paar, weil viele Leute die ich kennengelernt hab auch Entwickler neigen dazu manuell zu testen, gerade wenn es jetzt so Oberflächen sind, also Benutzeroberflächen. Dann testen Sie das durch was Sie gerade implementiert haben. Es funktioniert und dann ist das
Thema abgehakt. Weil klicken oder was? Dass man sich. Selber manuelles testen nicht, keine Ahnung. Das ist jetzt nur ein Beispiel.
Du kannst natürlich auch welche Funktionen schreiben und gibt ein paar Testwerte rein und guckst ob es läuft und dann ist das für dich in Ordnung. Das Problem dabei ist ja jetzt und deswegen hast du das wahrscheinlich gerade angesprochen, ist ja wenn ich jetzt anfange zu reflektieren oder sich meine Anforderungen ändern und ich am Code Sachen ändern muss, dann ist es ganz schön. Schwierig. Zuversichtlich.
Zu sein, dass alles noch läuft, wenn ichs nicht nochmal per Hand alles durch testen möchte und das ist ein enormer Aufwand, weil je größer die Software wird, desto aufwendiger ist es ja logischerweise alles manuell abzutasten oder auch noch alles im Kopf zu haben, was man abtesten möchte.
Und genau da kommen ja dann die automatisierten Tests quasi ins Spiel. Also zum einen Test Fälle schreiben die ich laufen lassen kann und sie bestenfalls auch noch zu automatisieren, dass alle Tests immer durchlaufen, wenn ich halt Änderungen gemacht habe da. Habe ich noch einen Kleinen, ein kleines Beispiel dafür, weil.
Mir wurde erzählt, dass quasi qua das war ne junge Frau, die eigentlich im Endeffekt gar nicht irgendwas mit IT zu tun hatte, aber ich sag mal, entfernter Kollege hat quasi so n Tool programmiert und er hat dann immer wieder ne nachgefragt bei der Jungfrau, ob es denn vielleicht möglich wäre, dass sie mal ein bisschen durch testen kann, ob das so funktioniert und dann hat sie mir erzählt, ja das hab ich dann auch gemacht und am Ende ist es aber so gewesen, dass er
irgendein Neues. Feature eingebaut hat und sag ich mal. Seite A hat super funktioniert, aber es war noch einmal Fehler auf Seite B, die vorher gar
nicht aufgetreten sind. Irgendwelche Seite Seite effekts und dann meinte sie halt eben auch ja dann teste ich das dann ne halbe Stunde durch und das ist OK und dann auf einmal sind aber Fehler irgendwo anders und da muss ich das danach wieder ne halbe Stunde testen, also ist unglaublich zeitintensiv manuell zu testen, deswegen ist unglaublich wichtig ist Test Automatisierung zu haben. Genau, sehr guter Punkt. Sehr gutes Beispiel, weil genau das ist es, denn am Ende größer
alles wird. Und das alles wieder abzutasten ist ne absolute Katastrophe. Ja genau da ein Punkt, den man dabei auch noch nennen könnte, ist das natürlich Tests auf eine gewisse Art und Weise von Dokumentationen ist. Wenn sie gut geschrieben sind, das heißt die Tests nahmen gut vergeben sind richtig. Ist auf jeden Fall wichtig. Also weil ich das ist zum Beispiel auch n wie gesagt, ist ja learning, was wir den Zuhörerinnen und Zuhörern hier
mitgeben wollen. Und genau das ist mir zum Beispiel, also hab ich mal erlebt. Auch dass ich hab mir angeguckt ne Komponente Code sag ich jetzt einfach mal und. Ich wusste nicht, was da passiert, hat mir dann den Test dazu angeguckt, weil ich mir dachte, es gibt, dass alles klar ist. Ja super und hab mir dann n bisschen herausgesucht, welcher
Test genau dafür zuständig ist. Was ich gerade wissen möchte und dann habe ich diesen Test gefunden und hab aber gemerkt, dass dieser Test. Einfach komplett gar nichts ausgesagt hat. Also das wurde überhaupt nicht beschrieben in in im Test Namen was eigentlich passieren soll. Also der Test war korrekt und hat genau das Abgetestet was r abtesten sollte aber. Ich wusste überhaupt nicht, was
dieser Test tatsächlich tut. Weil ich nicht wusste, was für ne Funktionalität steckt denn jetzt genau dahinter?
Also ich hab so n bisschen probiert und gemerkt k wenn ich das mache wird der Test rot, also muss der Test sicher wahrscheinlich irgendwie um diesen Part kümmern, das ist dieser Test sozusagen diesen diesen Code covert aber was der Test genau gemacht hat, welche Funktionalität wirklich dahinter gesteckt hat, hat sich nicht ergeben und dann habe ich mir halt im Endeffekt angeguckt und hab im Endeffekt diesen Test Namen einfach umgeschrieben, sodass man dann im Nachhinein
einfach besser merken. Konnte oder wenn du ne. Wenn du jetzt ausstehender rauskommen rauf guckst und dir wieder das gleiche passiert, dass du siehst AOK hier wird zum Beispiel, ich sag jetzt mal ganz blöd n Button des Abbild, wenn irgendeine Eingabe noch nicht stattgefunden hat, beispielsweise ne und das muss man halt aber auch in einem, sag ich mal in einem richtigen Namen verpacken, damit man damit auch
irgendwas anfangen kann. Ja gut, dafür gibt es ja aber auch Konventionen. Also es gibt ja, je nachdem welches Test Framework. Man verwendet gibt es ja, aber da schon Konvention, wie man die Tests benennen kann, um einfach eine Hilfestellung zu haben, dass da vernünftige, also dass man sogar also wie du erscheinst, Sätze bilden kann. Ne, es soll dem Button Disable, wenn Eingabe a fehlt zum Beispiel. Genau.
So ne genau ja ist auf jeden Fall ein wichtiger Punkt und ich merk Grad testen ist ein riesen Feld und da sind wir auch absolute Verfechter von wäre vielleicht einfach mal ne eigene Podcast Folge wert, hätte ich auf jeden Fall auch Bock. Auf jeden Fall sollten wir an der Stelle jetzt aber mal
unterbrechen. Ich denke, wir haben den Punkt ausreichend erläutert, nur nochmal abschließend zu dem ganzen Aufwand und den Vorteilen von testen, warum wir gesagt haben am Anfang nicht getestet, der Code ist fehlerhaft, weil man einfach davon ausgehen kann, dass sich über Zeit Fehler einschleichen werden und wenn du dann keine Tests hast, die diese Fehler erkennen. Hast du ein Problem? Wo willst du anfangen? Das ist ein Riesenaufwand.
Genau der Zeitaufwand ist am ist hinterher deutlich höher. Den Fehler zu finden als im Vorfeld vielleicht prophylaktisch zu vermeiden. Ganz genau. Ja, dann lass uns doch zum dritten Punkt kommen. Ja, als dritten Punkt hab ich lass dein Ego raus beziehungsweise sei kein Hero. Würde ich auch kurz fassen, weil wir haben eigene Podcast Folge dazu gemacht. Ich glaube die ist jetzt 2 folgen her.
Also die Verlegerin, die Zuhörer ein. 2 Folgen zurück, falls sich das Thema über das, was wir jetzt sagen, hinaus interessiert, hört ihr gerne die Podcast Folge an.
Ansonsten noch mal kurz zusammengefasst finde ich beschreibt es am besten wenn man sagt Teamwork ist alles, es schafft Vertrauen im Team. Man muss wissen teilen, man soll den Input Nutzen von anderen und nicht nur nutzen sondern auch Input geben, ganz wichtig ist es nicht der dem Projekt geholfen wenn man irgendwie wissen für sich.
Enthält beispielsweise ich hab jetzt verschiedene Zeilen Code geschrieben, die sind halt ein bisschen tricky und ich hab mir was geiles überlegt, aber das ist schon echt eine Meisterleistung. Also das werde ich jetzt mal nicht teilen oder irgendwie erklären wie ich das gemacht habe, weil das einfach zu geil ist. So ich meine Einstellung bringt niemanden weiter, aber was meine
da sind. Wir dann ja beim Thema Heroes ne. Also ich weiß nicht ob du das schon mal gehört hast, aber mir ist es schon mal über den Weg gekommen, ob das jetzt sag ich mal nur ein Spaß war oder? Total ernst gemeint oder vielleicht im Spaß n bisschen ernst mit dabei war. Aber ich habe auf jeden Fall schon sowas mal gehört wie HH, wenn ich das erzähle und kein anderer, also wenn kein anderer dieses Wissen hat, dann kann man sich ja gar nicht feuern, so also also.
Ja, da bin ich, da bin ich. Nicht ersetzbar. Genau ganz. Und das das ist so ne Sache, wo ich OK vielleicht Spaß, vielleicht ernst vielleicht von David n bisschen, aber im Endeffekt bringt das halt niemanden was, weil angenommen du möchtest irgendwie in der Arbeitswelt mal in Urlaub gehen und. Und du ne, irgendjemand geht in Urlaub, du sitzt da und denkst dir, OK, ich muss jetzt vielleicht anstelle x Komponente x was auch immer, muss sich etwas ändern.
So und jetzt denkst du dir, irgendwie hab ich gerade ein gutes Gefühl weil ich nicht genau weiß was da passiert, irgendwie fehlt mir da wissen um daran weiterzuarbeiten und das ist genau ein Hinweis darauf, dass es irgendwie so ne gewisse Art von Hero Bildung im Team gibt, das heißt wissen was quasi nur an einer Person hängt und. Das ist natürlich blöd und das sollte auf jeden Fall vermieden werden, damit einfach wirklich auch quasi jeder ein gutes Verständnis hat, dass jeder auch
frei im Team ist. Auch zum Beispiel Urlaub zu machen oder wenn jemand krank wird. Das sind alles natürlich Probleme, wenn man eben solche Wissenslücken aufgebaut hat. Man kann halt echt ganz klar sagen, dass das echt Gift für das Projekt ist. Ne, wenn sich so Heroes bilden, ja, weil wie gesagt.
Krankheiten kommen vor und wenn dann der Kollege ausfällt und da einfach das komplett brach, liegt das Thema unter niemand weiter dran arbeiten kann beziehungsweise extrem Zeit kostet sich da rein zu arbeiten, dann ist das pures Gift für das Projekt. Definitiv weil im Fokus sollte immer die Software Entwicklung und die Qualität der Software stehen und nicht irgendwie das Ego des Einzelnen also ich meine
was hat man davon? Es bringt also am Ende schadet man sich ja wieder selbst wenn man den Gedanken mal zu Ende geht ne du kannst zwar Hero sein, aber wenn das Projekt am Ende dann krachen geht. Weil ich einfach nicht fertig wird oder keine Ahnung. Dann stehst du auch nicht mehr so cool am Ende, ja. Das ist niemandem geholfen. Genau deswegen, als Learning. Liebe Zuhörerinnen, lieber Zuhörer, seid kein Hero Teamwork.
Ist alles. Und was ist auf jeden Fall sehr gut geeignet um sowas auch zu vermeiden, zum Beispiel per Programming haben wir auch eine Folge darüber gemacht auch. Anwendung Note hier genau, Programming ist natürlich super dafür, weil du da einfach das Wissen von Grund auf teilst und zusammen aufbaust. Genau. Ja, hast du noch einen weiteren? Punkt.
Der vierte Punkt, den wir uns überlegt haben, ist, schaue über den Tellerrand, das bedeutet im Endeffekt, dass man sich wirklich immer wieder neu ausprobieren soll, man soll am besten ist, wenn man neue Frameworks ausprobiert, die auch zum Beispiel neu aufdehnen ich sag mal Markt gekommen sind, neue Sprachen oder auch Sprachen, Frameworks, die es bereits gibt, einfach mal auszuprobieren um einfach n bisschen größeres Wissen in die Breite.
Masse aufzubauen, das heißt, wenn man überall so ein bisschen, sag ich jetzt mal, wissen aufbaut und dann irgendwann tiefer einsteigen muss, dann macht es ja Sinn, irgendwann zu sagen, OK, das wissen kann ich mir aneignen, aber dieses diesen groben Überblick zu haben am Anfang der macht Sinn und dazu kommt natürlich auch noch, dass es ja durchaus sein kann, dass neue Frameworks neue Sprachen
aufpoppen und andere ersetzen. Und wenn du zum Beispiel als Zuhörer und Zuhörerin dich schon öfter mal ein neues Framework eingearbeitet hat, dann ist das nächste auch viel. Viel einfacher, das heißt, es hilft einfach. Sozusagen über den Tellerrand zu gucken und nicht zu sagen, ich bleibe bei dem, was ich kann, sondern ich gucke auch und bewege mich aus meiner Komfortzone heraus. Ich guck mir neue Sachen an, das ist halt auch ein wichtiger Punkt. Naja, ganz genau, da möchte ich
noch ergänzen. Das ist ja auch nicht so, dass sich Frameworks immer zu 100% unterscheiden, das ist ja das was du meintest mit das nächste was du dir anschaust, fällt dir leichter zu verstehen, weil programmier Konzepte, die allgemein Paradigmen und Konzepte dahinter, die wiederholen sich ja klar. Die Syntax sieht immer ein bisschen anders aus und dann gibt es vielleicht doch so ein 2. Fancy Momente in der neuen Sprache. Wo denkst haben sie echt cool
gelöst. Aber wenn du alles irgendwie schon mal gesehen hast, fällt es dir auf jeden Fall wesentlich leichter, leichter einzusteigen und vor allem auch Probleme, neue Probleme die auftauchen zu verstehen und zu lösen. Also hast du, da hast du da ein Beispiel wo du sagst, OK, das ist zum Beispiel was, was mir geholfen hat aus verschiedenen Welten sag ich jetzt mal. Was zu kombinieren
beispielsweise. Pop ja, also ich hatte erzählt, dass ich mir als letztes Mal genauer das Electron Framework angeschaut hab und ein Punkt dabei war die ganze Prozess Kommunikation. Also ich will jetzt nicht zu sehr vertiefen, aber im Prinzip hast du 2 Prozesse und die müssen irgendwie miteinander kommunizieren und das hab ich halt relativ schnell verstanden, oder? Kapiert was? Sie von mir wollen.
Weil es halt einfach von der Theorie dahinter das Publish Subscribe Prinzip ist und dass ich keine Ahnung in der Robotik mit dem ROS schon mal verwendet habe beispielsweise das war dann C Plus plus eine andere Sprache, aber das Grundkonzept kannte ich und dann weiß halt OK ja gut so, über Channels muss ich halt miteinander kommunizieren, fertig.
Nur mal so als Beispiel und das ist genau der Punkt was ich meinte beim allerersten Mal denkst du dir vielleicht so ja nee das versteh ich gar nicht was da passiert. Dann irgendwann kommst du an den Punkt, hab ich schon mal gesehen, sieht sind taktisch jetzt anders aus, aber ich weiß grundlegend was zu tun ist und dann kommst du halt auch
schneller dahinter. Also du kannst es quasi im Prinzip aus der Robotik und hast du gesagt, OK, das kenne ich, das ist jetzt zum Beispiel, ich sag mal Web Bereich sehr sehr ähnlich oder Print eigentlich das gleiche Prinzip dahinter steht und deswegen das könntest du, das konntest du gleich verwenden. Es sind 2 verschiedene, grundlegend verschiedene Frameworks. Das eine ist ja so ein Operating System und das andere ja gut
ist. Ein Framework für Plattform übergreifende Software Entwicklung sagen wir mal so ne und nichtsdestotrotz hatten beide das Problem. Wie kann ich denn jetzt die Kommunikation Prozess übergreifend machen und haben sich beide dann quasi für dieses ähnliche Prinzip was so unter den großen Punkt steht entschieden? Ja so und dadurch war ich beim einen schon mal gemacht hab wusste ich ja beim anderen A ja OK gut das wird jetzt ähnlich laufen so.
Ja. Also das meine ich halt damit genau und das ist halt das über den Tellerrand schauen, keine Ahnung, da machst du halt mal was im Robotik Bereich, was auch
ein extrem cooler Bereich ist. Also technische Informatik oder auch Hardware nahe Embedded Embedded ist auch ein gutes Stichwort. Ich kann jedem empfehlen auch mal im Embedded Bereich was zu entwickeln damit man einfach sich mal wirklich mit anderen Problemstellungen befasst wie beispielsweise Speicher, Limitierung und rechen Limitierung, weil gerade im Web Bereich achten viele Entwickler gar nicht da. Effizient zu programmieren und
im Embedded Bereich ist das essentiell, weil du einfach wesentlich weniger Speicher zur Verfügung hast. Die Cores einfach wesentlich weniger rechen Taktung haben. Also du hast quasi da ja du du kriegst quasi aus diesem Bereich so ein bisschen das Verständnis über Effizienz, über komplett Komplexität, das genau. Genau und deswegen also das wäre zum Beispiel für meine persönliche Erfahrung, dass mir
das programmieren int. Bereich stark geholfen hat, sich darüber Gedanken zu machen, ne und um auch nochmal einen Punkt aus vergangenen Folgen aufzugreifen.
Das Ganze spielt natürlich in einem Punkt extrem rein und das ist üben, üben, üben, wenn ich gerade am Anfang der Software Entwicklung stehe, warum nicht sich verschiedene Bereiche angucken, klar kann man sich denken, oh ich kenne das eine noch nicht mal komplett richtig und jetzt soll ich mir angucken ja aber so what wenn du Bock drauf hast mach es schau s dir an das wird ja auch in dem anderen Bereich wieder helfen.
Ja, ja, auf jeden Fall. Das ist auf jeden Fall ein guter Punkt. Genau, ich fasse, kann ja nochmal zusammenfassen, also wir haben jetzt als erstes probieren geht über studieren, zweitens nicht getesteter Codes fehlerhaft, drittes Learning, lass dein Ego raus, sei kein Hero und der vierte Punkt, den wir gerade besprochen haben, schaue über den Tellerrand, guck dir ein paar neue Sachen an, bleibt nicht da wo du bist, erweitere deinen Horizont, ne. So ganz genau. Und dann haben wir.
Noch den entscheidenden Fünften. Punkt genau raus. Der ist natürlich das, was wir am Ende jeder Folge auch predigen. Und das ist gemeinsam besser. Dafür wollen wir auch stehen, und das ist ja auch genau das, was Coding Bodies überhaupt im Grundgedanken überhaupt erst, sag ich mal, hat entstehen lassen, und zwar voneinander zu lernen, denn es ist einfach unglaublich wichtig, dass man. Nicht nur alleine lernt, sondern auch zusammen lernt oder halt
auch von anderen lernt. Ne. Also für mich ist es immer so n ganz wichtiger Punkt, angenommen
man. Arbeitet mit jemandem zusammen und hat das Gefühl. Zum Beispiel weiß ich, du arbeitest vielleicht als 10 Jahre in der Softwareentwicklung oder länger und jetzt kommt jemand von der Uni, da könnte man sich natürlich hinstellen und sagen, ja gut, der kann ja nichts oder der kann definitiv weniger als ich und deswegen möchte ich, also kann, von dem kann ich nichts lernen und wenn man mit so einer Einstellung reingeht, das ist irgendwie
blöd, finde ich zumindest. Weil du also wenn du sagst, ich kann von jedem etwas lernen, dann sensibilisiert. Du dich dafür zu sagen, OK, ich höre der anderen Person zu, es ist vielleicht. Wertvoll, was diese Person zu sagen hat und somit fängst du überhaupt erst an, dich darauf einzulassen, auch von anderen zu lernen, also auch von Leuten, wo du vielleicht von vornherein vielleicht denken magst.
Ja, von dem kann ich ja oder von der Person kann ich ja gar nichts lernen, ne, und das ist für mich immer ein wichtiger Punkt. Ja, nächstes ja auch einfach verschiedene Sichtweisen, die dann aufeinander treffen, ne und ja so dieses böse Wort fachidiot trifft da manchmal auch ganz gut. Zu weil du hast deine Sichtweise und du hast es fünfmal so probiert und du wirst zum sechsten Mal auch wieder so lösen.
Das Problem jetzt kommt einer mit einer anderen Sichtweise und sagt so, ja wir können das so machen, weißt du und du bist halt manchmal fährt halt fest, das ist so und deswegen ist dieser Austausch so wichtig um einfach auch mal andere Sichtweisen mit dazu zu nehmen und zu betrachten und dann vor allen Dingen über Probleme auch zu sprechen, das fand ich persönlich immer sehr wichtig, wenn man vor einem programmier Probleme. Steht also, man soll was
implementieren, weiß noch nicht so wirklich wie einfach drüber sprechen, jeder kann seinen Input geben und man entwickelt zusammen eine Lösung beziehungsweise einen Lösungsansatz, weil wir ja vorhin schon meinten probieren geht über studieren, es wird wahrscheinlich nicht die hundertprozentige finale Lösung sein, deswegen Lösungsansatz und dann probiert man den aus und dann entwickelt sich daraus die finale Lösung sag ich mal ne, also auch dieses ganze Konzept
von Brainstorming dahinter gilt ja auch fürs Coden. Und auf der anderen Seite, weil ich jetzt auch grad vorhin nochmal meinte, dass man zum Beispiel was von Leuten lernen kann, wo man vielleicht das Gefühl hat, dass man vielleicht besser, also selber schon höheres oder ein umfangreicheres Wissen hat als ich zum Beispiel auch kenne.
Von mir selber ist, dass ich zum Beispiel, wenn ich jetzt auch wo ich am Anfang meiner Software Entwicklungs Laufbahn stand, sag ich jetzt mal, da hat zum Beispiel auch mal das so bisschen, das sagt man, dass die Angewohnheit, dass wenn jetzt zum Beispiel jemand war, der auch besser war und gesagt hat Ja, guck mal so und so, also offensichtlich. Für mich war das klar, der war besser oder die programmiererin Wasser, dann war für mich so ja aber hm ja.
Finde ich ja auch gut. Verstehe ich schon ne, also einfach so n bisschen so abblocken das Ganze entgegenzunehmen ohne wirklich zu sagen Moment warte mal. Ich kann jetzt wirklich was von dieser Person lernen, das ist richtig wertvoll und ich kenne das auch heute oft, dass es dann
das schnell mal gesagt wird. Ja das hab ich verstanden ja ja passt schon oder so, aber eigentlich wurde das gar nicht verstanden, das heißt generell so, ich kenne es von mir, ich kenne es von anderen, dass sich dann selbst nicht die Blöße gegeben wird zu sagen. Nee, ich hab das noch nicht
verstanden. Ich würde es gerne wissen, weil dann kann man ja wirklich was lernen und meistens ist der gegenüber oder die gegenüber liegende Person ja nicht so drauf, dass die sich dann denkt, ich habs dir jetzt einmal erklärt, ich will es jetzt nicht nochmal erklären, verschwende nicht meine Zeit. Lernen interessanterweise würde man ja als Person, die sich dann nicht traut nochmal zu fragen, ja schon quasi die Entscheidung dem anderen abnehmen, wie diese
andere Person das findet. Das ist halt immer das interessante dabei, eigentlich ne, also man sagt ja ich will ihn nicht nerven, ich will mir nicht die Blöße geben, aber man weiß ja gar nicht ob das den anderen vielleicht denkt er sich ja auch er kein Problem, ich möchte, dass du es verstehst. Ich werde es dir einfach nochmal erklären und ich versuchs die anderen Worten zu erklären, weil in dem Moment wenn man Sachen erklärt. Versteht man manchmal selbst auch noch ein paar Punkte genauer.
Ja, definitiv. Und zusätzlich kann es ja auch sein, dass der andere oder also die andere Person sich denkt, ja, Moment, ist ja cool. Der macht ja richtig mit ne. Also der andere macht richtig mit, die andere Person hat richtig Bock auf das, was wir hier gerade machen. Es wird nachgefragt und damit kannst du natürlich auch irgendwie hinkriegen, irgendwie vielleicht eine gewisse Art von Motivationsschub auf Seiten des Erklärens oder erklären. Zu erzeugen. Na, finde ich auf jeden Fall
mega. Punkt von dir gerade auch so als letzten Punkt zu diesem Learning. Weil ganz klar, coden macht Spaß und soll Spaß machen. Und das macht vor allem im Team Spaß.
Und wenn man da irgendwelche Ängste bei hat oder sich nicht traut, wissen irgendwie vorenthält und was wir alles jetzt besprochen haben, mindert das am Ende nur den den Spaß und schadet dem Projekt. Das kann man einfach, wenn man wirklich ganz klar so sagen und deswegen ist es auch einfach dieses Cash gemeinsam besser genau die Aussagekraft dahinter, die es braucht. Ja, auf jeden Fall.
Und da darf man sich dann auch nicht hinstellen und sagen, zum Beispiel, wenn man das zusammen programmiert und vielleicht noch nicht. So weit ist wie jemand anders,
der mit dabei ist. Dann darf man sich nicht sagen, o Mann, so ne Kacke, ich hab's nicht hingekriegt die Lösung zu erzeugen, was ja durchaus frusten kann ne, sondern vielleicht eher zu sagen A. Ich habe es diesmal noch nicht hinbekommen die Lösung selbst zu finden, aber man lernt dadurch und man hat es ja am Ende im Team geschafft und selbst wenn einer momentan von einem ab einem gewissen Punkt noch sozusagen so der Leuchtturm in einer Gruppe ist, heißt das ja
noch lange nicht. Dass der immer der Leuchtturm sein bleiben muss, sondern dass man zusammen, sag ich jetzt mal als Leuchtturm, Duo, Trio war auch immer auftreten kannst du es jetzt Richtung du weißt ja, ich weiß was du meinst, dass man halt eben sagt, Ey, man soll sich dadurch nicht frusten lassen, wenn irgendwie, wenn man nicht selber auf die Lösung kommt, das ist finde ich auch ein wichtiger Punkt, sondern sagt EY, das bedeutet, dass ich heute wieder was gelernt hab und
in einiger Zeit bin ich der oder die Person. Die quasi. Ja, anderen was beibringen kann. Und dann ist man gemeinsam besser. Ja, also in diesem Sinne würde ich sagen, können wir die Folge auch schließen, Jo, Ich hoffe euch als Zuhörerin und Zuhörer da draußen haben euch die 5 Learnings was gebracht und ihr könnt darüber vielleicht auch mal nachdenken und sagen, Hey. Irgendwie stimmt das, oder? Nee, sehe ich ganz anders, wenn
das so ist. Auf jeden Fall gerne mal auf uns zukommen, weil Diskussionen darüber macht ja auch Spaß, wenn ihr noch ein Learning habt, wo ihr sagt, das ist aber auch voll wichtig und das ist wichtiger als einer der 5 Punkte die ihr da grad geschrieben hat, aus meiner Sicht immer her damit, ihr könnt uns erreichen über Instagram beispielsweise, wir haben auch noch, wir sind auch noch auf anderen Plattformen aktiv oder wollen auf anderen Plattformen anfangen aktiv zu
werden, genau die Links dazu. Gibt es in den Noten. Ansonsten werden euch die Folge gefallen. Hat Lasten Like, da sagt es euren Freunden und Freundinnen weiter und ja, habt viel Spaß beim Programmieren in diesem Sinne, eure Coding war dies. Gemeinsam besser.