Latest / Coding Buddies | Tech & Dev-Mindset / Unsere 5 Learnings als Softwareentwickler

Transcript

Unsere 5 Learnings als Softwareentwickler · Coding Buddies | Tech & Dev-Mindset

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