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.