#48: Buzzword-Bingo

Shownotes

In dieser Folge wird es spielerisch: Felix und Kay spielen Buzzword-Bingo. Einer wirft einen Begriff aus der Softwareentwicklung in den Raum, der andere muss erklären, was dahintersteckt. Anschließend ergänzt die Person, die den Begriff ausgewählt hat, um weitere Details, Hintergründe oder Praxisbeispiele. Dabei geht es um bekannte Konzepte wie DRY, YAGNI, Idempotenz, Early Return oder Crossfunktionale Teams und welchen Nutzen sie im Entwicklungsalltag haben.

Eine lockere Folge für alle, die ihr IT-Vokabular auffrischen möchten, schon immer wissen wollten, was hinter den kryptischen Buzzwords steckt oder einfach Spaß an Fachsimpelei haben.


🎧 Hosts:
Felix Dransfeld & Kay Domrose – Geenen IT-Systeme GmbH, Dortmund 🌐 geenen-it-systeme.de 📸 Instagram: @webcafepodcast

Transkript anzeigen

00:00:05: Hallo und herzlich willkommen zu einer neuen Folge von unserem Webcafé.

00:00:09: Und Kai, so spät haben wir noch nie aufgenommen und deswegen freue ich mich besonders, dass du heute hier bist.

00:00:13: Hi Kai!

00:00:15: Hallo Felix, ich freu mich auch da sich hier binn' und ja lass das den Chef nicht hören, dass wir hier zu so später Stunde im Prinzip im Feierabend noch sitzen.

00:00:22: aber wir haben heute ein lustiges Thema und deswegen finde ich's okay Genau,

00:00:26: cooles Thema.

00:00:27: heute können wir schon mal ganz kurz antiesern.

00:00:29: Wir wollen heute Buzzword Bingo spielen Und ich vermute, dass die ganzen Leute das ja auch schon im Titel gelesen haben.

00:00:35: Deswegen kein Geheimnis.

00:00:36: Aber es wird ganz spannend vielleicht wieder zu einer Serie, mal gucken wie gut's läuft.

00:00:40: Kai und so spät abends hast du dir aber bestimmt auch einen Getränk mitgebracht denn ohne gehts hier nicht.

00:00:45: Ohne können wir nicht reinstarten.

00:00:46: Sicher!

00:00:47: Ja, ich erzache erst was ist und dann erzähle ich euch, was so besonders ist.

00:00:50: Ich habe einen Minztee also ein Tee mit frischer Minze.

00:00:54: Da hab' ich mir gerade aufgesetzt und ich hab' die grade im Kühlschrank rumfliegen gesehen und der Hintergrund Das ist in meiner Lieblings-Stammdiskothek hier um die Ecke.

00:01:03: So gegen morgens, wenn langsam die Gäste rausgekehrt werden und die Bar schließt immer noch von den Cocktails... ...und dem Mojitos und weiß ich nicht was die ganzen Minnsblätter über sind.

00:01:13: Und ich mit dem freundlichen Mensch an der Bar, liebe Grüße an Timo, er abgemacht habe dass wir da dann vorbeikommend uns zum Feierabend ne leckeren Minstee aufblühen lassen!

00:01:23: Ich muss sagen so ein frischen Minztee abends nachem tanzen und weiß sich nicht was das is'.

00:01:28: Anders awesome, wie die Kids heute sagen.

00:01:30: Tust du da noch irgendwas rein?

00:01:32: Oder ist das wirklich nur Minze und heißes Wasser?

00:01:34: Nee, heißes water und Minzblätter!

00:01:36: Nicht schlecht ich bin ja ein großer Morito-Fan von Daim.

00:01:38: mit Minze kriegst du mich immer Und wir haben hier im Garten wirklich einen Minzbeet kannst du schon fast sagen Das Wuchert ja wie Unkraut.

00:01:45: zu unserer Freude muss man sagen

00:01:47: Ja das ist großartig.

00:01:48: Ich bin direkt wieder im Kopf nachts in Keller um fünf.

00:01:52: Aber Kai wenn Du den Backgeber kennst aber gut ich stell mal keine weitere Nachfrage.

00:01:59: Da bin ich heute Fahrrad gefahren.

00:02:01: Okay, pass auf!

00:02:02: Ich erzähle dir was ich dabei hab.

00:02:03: Ach

00:02:04: so ja Felix, was hast du denn dabei?

00:02:05: Ja,

00:02:06: ich bin jetzt zwei Wochen in Frankfurt und mache da Schulungen für angehende Web-Entwickler mit mehr oder weniger Kenntnissen und ist ganz spannend weil ich richtig zu dem Basics der Webentwicklung zurückkomme und mal gucke ob man wirklich noch Schleifen selbst programmieren kann und Funktionen selbst machen können und Objekte erklären kann und Vererbung usw.

00:02:26: oder zum Beispiel ein CSS Grid selbst schreiben.

00:02:28: Und kannst du?

00:02:29: Ich kann, tatsächlich!

00:02:30: Also Grid und Flex musste ich mir tatsächlich nochmal reinpacken.

00:02:33: also muss ich mich noch mal angucken weil so richtig auswendig konnte ich das alles noch nicht sodass man es auch lehren kann.

00:02:39: Alles andere, also PRP Javascript und so kriege ich schon richtig gut hin.

00:02:43: Ich muss aber feststellen dass viele Sachen anders sind als früher.

00:02:45: Zum Beispiel habe ich früher immer diese MySQL Funktion benutzt im PRP So MySQL S-Hoc und sowas und inzwischen benutzt man da PDOS, so PHP Data Objects Und das ist viel, viel komfortabler und ich bin ganz froh, dass es das gibt.

00:02:59: Weil ich den sonst noch mehr Sachen beibringen müsste die Leute verwirren.

00:03:02: Wie du jetzt jetzt sagst klingt das das wäre eine Sache, die letztes Jahr erst rausgekommen ist.

00:03:06: aber...

00:03:07: Wann ist denn raus gekommen?

00:03:08: Also als ich angefangen habe vor zehn Jahren gab's das schon würde ich sagen.

00:03:11: Oha

00:03:11: oha ohaa ja vielleicht bin auch nur blinden Auges kann man das sagen durch die Welt gewandert und vielleicht gab's es früher schon.

00:03:18: naja Ich wusste auch die ersten fünf Jahre meines Schaffens nicht dass es Joins gibt.

00:03:23: Das ist ein anderes Kapitel.

00:03:25: Jedenfalls war ich da jetzt ein paar Tage im Hotel, damit ich da morgens mal Achtung auf der Mathe stehen konnte.

00:03:30: und dann hatte ich mir für gestern Abend eigentlich einen alkoholfreies Bier da in Rewe geholt.

00:03:36: Dieses hier ... Ich halte gerade meine Kamera, das ist so eine Benediktina hell alkoholfrei Und da hatte ich große Lust drauf.

00:03:41: aber irgendwie habe ich vergessen es zu trinken.

00:03:43: Und das mache ich jetzt hier live auf.

00:03:45: du machst ja auch mal gerne ASMR, das machen wir jetzt hier auch.

00:03:47: Ich guck mal ob das hier überkommt

00:03:52: Fantastisch!

00:03:53: Oh und Klecker nicht mehr auf meinen Schreibtisch.

00:03:55: Und dann habe ich mir noch so ein brandingfreies Glas geholt, der werde ich jetzt einkippen.

00:04:03: Das ist doch der Wahnsinn oder?

00:04:07: Ist großartig!

00:04:08: Aber Kai, ich werde ein bisschen nachlässig was meine Tee eingeht weil ich hatte ja letztes mal schon keinen Tee dabei.

00:04:12: Das kommt aber wieder, so viel kann ich euch versprechen... ...aber von daher, ich genieße hier ein schönes Helles um neunzehn Uhr abends oder jetzt haben wir es schon zwanzig nach sieben und dann können wir ins Thema rein starten

00:04:23: oder?!

00:04:23: Also wenn ich das jetzt nicht live gesehen hätte, wie du es gemacht hättest.

00:04:27: Wettig dass du da irgendeine Klangspur abgespielt hätt.

00:04:30: Das hat ja so großartig geklungen, sagt man

00:04:33: viel geschäumt

00:04:33: Felix, das muss er noch mal üben.

00:04:35: Geil wir wollen heute Bassword Bingo spielen und was damit auf sich hat erkläre ich unseren Hörnern gerne.

00:04:41: und zwar haben Kai uns jeweils drei Basswords rausgesucht die wir hier mal besprechen wollen Und ich bin da so ein bisschen draufgekommen, weil ich ja zwar so ein bissel studiert hab das aber nie fertig gemacht habe und.

00:04:53: Ich hab immer so das Gefühl dass die Leute Die seffi von sich halt in der Programmierung und das kann es positiv oder negativ sein?

00:05:00: Die schmeißen halt immer mit buzzwords um sich und ich vermute dass wir das unter Wurst auch tun und ganz viele wörter verwenden die vielleicht gegenüber gar nicht so richtig versteht und die hören sie natürlich mal wahnsinnig gut an.

00:05:10: und jetzt habe ich gedacht wie macht man eine serie wo sich jeder so ein paar buzzwords nimmt und die dem anderen entgegenwirft?

00:05:16: Und dann gucken wir mal, ob der andere die überhaupt kennt und besprechen das mal.

00:05:19: Und versuchen so unseren Hörnern hier auch einmal ja ein bisschen aufzurampen, sodass man vielleicht in Zukunft ein paar mehr von diesen Wörtern versteht, die so Berater-und-Aitiler in die Welt werfen?

00:05:30: In der Hoffnung dass wir uns nicht doppeln weil wir haben das vorher nicht abgesprochen welche der jeweils andere hat und vielleicht haben wir heute auch nur fünf oder vier oder vielleicht wirklich alle sechs.

00:05:38: aber ich finde es ein spannender Punkt weil ich glaube so in der Karriere eines jeden entwickelnden Menschen Gibt es irgendwann so den Punkt, wo man genug fancy klingende Wörter kennt?

00:05:50: Um die so im Gespräch einzustreuen.

00:05:53: Aber möglicherweise nicht hundert Prozent versteht was dahinter passiert.

00:05:57: und es gibt ja keinen leichteren Weg um sich direkt als Anfänger zu disqualifizieren Als ein Schlagwort in der Situation zu verwenden wo's nur ninety fünf Prozent passt aber nicht.

00:06:08: Hundert prozent passt

00:06:09: Ja oder noch weniger.

00:06:11: genau das ist dann direkt ein Zeichen von oh ja.

00:06:14: also Hätte lieber kein Fachwort gesagt, dann hätte auch nichts Falsches gesagt als ein Fachwort zu benutzen aber dich gleich zu outen.

00:06:21: Und das ist glaube ich ganz gefährlich.

00:06:23: also da vielleicht der Tipp an neue Menschen wenn man sich nicht wirklich hundert Prozent sicher ist was einzelne Wörter oder Begriffe bedeuten Lieber weglassen und mit eigenen Worten umschreiben Da ist man im Zweifel mehr auf der sicheren Seite als sich zuouten mit einem falschen Begriff.

00:06:37: Total.

00:06:38: Kai willst du durchstarten?

00:06:39: Oder willst du einen von mir haben?

00:06:44: Warm-Up-Facts.

00:06:45: Jetzt bin ich allein neugierig, was das ist?

00:06:47: Also, aus Frankfurt hab' ich mitgenommen es gibt in JavaScript kein Schaffel.

00:06:52: Was soll denn sein Schaffl

00:06:53: für Arrays?

00:06:54: Ist dir das bekannt?

00:06:55: Ich bin nicht bekannt aber ich wüsste auch nicht wozu ich's brauchen sollte.

00:06:58: Ja so wenn du so ein Array durchmächsen willst also zufällig anordnen willst

00:07:03: Nähnschaffel

00:07:04: Du brauchst nie nen Schaffle!

00:07:05: Ich brauch ständig Schaffels Und im PHP gibts so n schönes Schaffell.

00:07:08: Da kannst du einfach einen Array reingeben und der mutiert tatsächlich das echte Array.

00:07:12: Aber jedenfalls mixte das durch und dann kriegst du einen Random Array hinten raus.

00:07:15: Und in JavaScript um dann random array zu machen, wir hatten den Fall dass wir so ein Quiz Spiel gemacht haben.

00:07:20: Dann haben wir immer vier Antworten und wir wollten natürlich nicht immer die richtige Antwort oben links haben sondern wollten es da zufällig haben.

00:07:25: Ja und es gibt keinen Schaffel und das muss man dann aufwendig mit math.random machen.

00:07:30: minus null Komma fünf damit der Werte über oder unter Null ausgibt.

00:07:33: Das Problem ist math.Random ist nicht sicher also ist nicht gleichmäßig verteilt.

00:07:39: was daraus kommt Das ist natürlich jetzt für so ein Fragespiel egal, aber da hast du dann Probleme.

00:07:43: Aber ist das nicht interessant?

00:07:43: Dass es einfach kein Shuffle for Errors gibt und ja auch was gibt.

00:07:46: Aber dich scheint das schon immer nicht so weg zu hauen!

00:07:48: Nee also wenn ich Listen habe, dann will ich am meisten irgendwelche... Ergebnis aus der Datenbank oder sowas eintragen.

00:07:54: Und die haben in aller Regel schon irgendeine immernente Reihenfolge, dass sie irgendwie nach einem Namen sortiert sind und nach irgendwelchen anderen Kriterien, das die wirklich zufällig sortiert ist.

00:08:03: Das hast du glaube ich... Also mir fällt wirklich gerade nur so ein Spiele-Bibespiel ein.

00:08:07: Ich

00:08:07: habe zum Beispiel jetzt gestern noch Testimonials auf einer Website eingebaut und da sollten immer drei Stück angezeigt werden von nem Pool aus mehreren Testimoniels.

00:08:16: also so Kunden stimmen und die fand ich irgendwie ganz nett wenn nicht die zufältig anordne.

00:08:21: Da gab's jetzt in dem Fall, ich hab es mit Elementor gemacht.

00:08:24: Gabs eine Funktion dafür, dass sie zufällig angeordnet werden aber das wäre ein klassisches Beispiel dafür da sich was schaffeln.

00:08:29: Ja okay, geht zu!

00:08:30: Würde ich dann wahrscheinlich über den Query direkt machen, aber genau.

00:08:34: Und das Zweite ist... Ich habe gelernt im Kurs wie diese Loading-Spinner heißen.

00:08:39: Ich hab die mal Loading Spinner genannt, aber da gibt´s einen Begriff für, weißt du wie die heißen?

00:08:43: Diese Dinger, die sich drehen wenn der Website oder ein Element lädt.

00:08:47: Also ich kenne jetzt nicht so ein fancy Begriff für.

00:08:48: vielleicht, außer wenn du sagst dann sag ich's achja klar.

00:08:51: Ja heute lernen wir richtig was Kai das sind.

00:08:53: Throbber

00:08:54: hab' ich auch noch nie gehört.

00:08:56: THR-O-B-B E R

00:08:59: Throber

00:09:00: Ja so heißt es kann man googeln habe ich auch gemacht wusste ich auch nicht.

00:09:03: So heißen so Dinger und das kommt vom englischen Verb to throb Und das heißt pochen oder pulsieren.

00:09:10: Man kennt ja die Dinger die vor allem früher dann auch viel so pulsiert haben Und deswegen ist das Throbber, aber ich weiß nicht ob man das THG jetzt im Podcast gut hört.

00:09:20: Mal gucken!

00:09:21: Aber das mal so als deine Fun Facts voraus.

00:09:23: und jetzt darfst du mir einen Buzzword entgegenschmeißen...

00:09:25: Das ist ja vielleicht so ein klassisches Beispiel für, dass man es auch übertreiben kann mit so Buzzwords.

00:09:30: Weil auf der einen Seite kann natürlich zeigen was man alles für tolle Dinge weiß aber gleichzeitig im praktischen Alltag wenn man da auf einmal mit begriffen um sich schmeißt die sonst keiner kennt hat man halt nichts gewonnen außer das man wie ein Idiot dasteht und alle mal sagen hey dropper!

00:09:43: Was is denn das?

00:09:44: Während du jetzt sagst ich hab eine Ladeanimation auf der Seite eingebaut dann sagen die Leute Nicht techniker, viele Menschen.

00:09:51: Ach ne Ladeanimation!

00:09:53: Das versteh ich ja also... Total.

00:09:54: Man muss halt auch nicht overplayen mit diesen tollen Begriffen.

00:09:57: Apropos Begriffe?

00:09:59: Ich hab hier eine Reihenfolge von drei Begriff und ich fange damit an wo am wenigsten Satz so steht und wo es glaube ich am einfachsten ist zu erklären was damit ist.

00:10:06: und der erste Begriff wieder aus meinem Alltag entnommen weil er mir ständig in Merch-Request aufkommt ist.

00:10:11: Early Return.

00:10:12: Oh schön, schön

00:10:14: Felix, was ist ein early return?

00:10:16: Ja ich habe

00:10:16: ja erst mal gedacht dass sich mit allen von deinen Begriffen die du mir jetzt entgegen wir es nichts anfangen kann.

00:10:20: Da bin ich ja ganz

00:10:21: happy!

00:10:22: Ja beim Early Return meinen wir das wir eine Funktion oder einen Programmablauf möglichst früh abbrechen wenn wir schon wissen, dass alles was danach kommt nicht mehr so wahnsinnig viel Sinn macht.

00:10:32: also wenn zum Beispiel... ...einen Eintrag schon in der Datenbank vorhanden ist dann können wir sagen Ich spring hier schon raus weil ich an der Stelle nichts mehr zu tun habe und muss nicht die Funktion durchlaufen oder muss mich im Zweifel noch in den Elst-Teil von einer Abfrage reinspringen, der vielleicht gar nicht unbedingt nötig ist.

00:10:48: Und damit spare ich mir Performance... ...und der Code wird letztlich auch übersiedlicher, weil ich nicht mehr so tiefe Verschachtlungen bekomme am

00:10:54: Ende.".

00:10:55: Ganz genau das ist der Punkt!

00:10:56: Also es ist eine Maßgabe, gibt ganz viele, gibt early escape, es gibt fail early.

00:11:02: Fail early ist fast noch ein besseres Bass-Workzone?

00:11:05: Genau viele verschiedene Begriffe, die sich ein bisschen darum ranken.

00:11:08: Wie man so ein Programm strukturiert und da geht es üblicherweise um Methoden oder Funktionen also kleine gekapselte Bereiche im Programm und wie man sie aufbaut.

00:11:18: Und dieses Konzept von Early Return sagt eben insbesondere dass man Rahmenbedingungen, die zum Abbrechen des Codes führen möglichst früh identifizieren und daraus den Code abbrechen sollte statt das ewig mit sich herumzuschleifen oder umgekehrt, nicht den Happy Part in so einer Funktion.

00:11:37: Also das was man eigentlich mit so eine Funktion erreichen möchte innerhalb von ganz vielen If-Bedingungen verschachteln.

00:11:44: also wenn man sich vorstellt wir haben ne Passwortabfrage und dass Passwort mindestens drei Zeichen lang sein und maximal fünf Zeichen und ein Sonderzeichen enthalten Was schnell passiert?

00:11:55: Wenn man Anfänger ist, dass man so eine if Bedingung hat da schreibt man rein Zeichenlänge größer als drei, und dann macht man da noch eine If-Bedingung.

00:12:02: If-Zeichenlange kleiner als fünf oder machen wir noch eine if Bedingung?

00:12:06: Und hat dann so ne Pyramide auf der Seite und in dieser Pyramid irgendwo drin verschachtelt hat man das was eigentlich passieren soll.

00:12:14: Das hat ein paar negative Implikationen.

00:12:17: die Hauptimplikations ist dass es einfach sehr unübersichtlich wird so den Code zu lesen.

00:12:22: Einen sich schon dadurch weil wenn man dieses Muster verfolgt bedeutet es einen Umkehrschluss jede Funktion ein bisschen individuell ist, ob man sehr viel Gehirnschmalz darauf verwenden muss überhaupt schon visuell zu verstehen was da passiert.

00:12:36: Und da es eben diese Early Return Angabe so eine Möglichkeit zu sagen wir haben ungefähr immer das gleiche Konstrukt in so einer Funktion immer einen gleichen Muster wie des aufgebautes Und man kann in alle Funktionen reingehen, die es so gibt und findet sich direkt wieder weil sie alleine optisch schon recht ähnlich aussehen.

00:12:53: Also man kann das wirklich mal parallel aufmachen.

00:12:55: zwei Funktion die eine folgt dem early return und die anderen nicht.

00:12:58: Die haben wir schon direkt nur vom drauf sehen ohne dass ich ne Zeile gelesen habe.

00:13:02: sehr individuelle oder unterschiedliche Gestaltung dann kann ich mich direkt wiedererkennen.

00:13:08: Genau bei deinem Beispiel wäre ja jetzt die richtige Herangehensweise dass man sagt wenn der String nicht die länger hat Dann return string muss mindestens so und so viel Zeichen haben.

00:13:20: Und dann geht das so weiter, und dann hat man eben immer nur eine if-Bedingung kein else dabei.

00:13:24: Und die kann man dann untereinander schreiben ist immer auf Ebene eins im Prinzip.

00:13:28: Unser Linter ist auch zufrieden.

00:13:29: wir haben ja tatsächlich glaube ich so Alintingregeln.

00:13:31: Ich bin mir nicht ganz sicher ob sie bei uns aktiv sind?

00:13:33: Ich habe es solange nicht mehr gesehen.

00:13:35: aber es gibt so Linter die dann sagen wenn ich mehr als ich weiß gar nicht was dann ist fünf Ebenen tief bin Dann würde der Linter einmal entgegenspringen und sagen, wenn du es so tief verschacht ist irgendwas kann doch nicht ganz richtig sein.

00:13:46: Du hast das gerade schon gesagt?

00:13:47: Der große Unterschied während einer Funktion so schreibt ist dass sie nach unten wächst aber nicht in die Breite.

00:13:53: Das bedeutet jedes Return Statement if Passwort kürzer als eins dann direkt return ist ein kurzes Statement im paar Zeilen Code und direkt darunter geht es mit dem nächsten Statement weiter und so wächst die Funktion nach unten immer weiter und das ist insgesamt übersichtlicher als wenn sie verschachtelt ineinander dann in die Seite weiter legst.

00:14:12: Wir haben ja zum Beispiel auch so eine Maßgabe, dass der Code nicht weiter als Achtzig Zeichen breit sein darf.

00:14:18: aber wenn man sich jetzt vorstellt da so viele in der Nacht verschachtelte If-Bedingungen zu haben Dann wird es nach Ende hin sehr unübersichtlich um zu sagen okay man schreibt das untereinander führt dann wirklich dazu, dass man so ein einheitliches Schema hat wie jede Funktion aufgebaut ist.

00:14:33: Und das hilft einem auch einfach super schnell sich zu orientieren wenn man in der Funktion von dem anderen mal unterwegs ist.

00:14:39: Total!

00:14:39: Und man hat einen riesen Vorteil, dass wenn man das mit if else macht also if Zeichnänge ist kleiner als fünf Dann hat man ganz unten ja den else Block und wenn man da drin jetzt aber noch sehr viel Logik macht, dann ist er mitunter gar nicht mehr im Bildschirm.

00:14:52: Und dann weißt du natürlich einerseits nicht mehr, wenn du runter scrollst.

00:14:54: auf welcher Ebene bin ich jetzt gerade?

00:14:56: Welche Einrückung habe ich hier?

00:14:58: Und das ist natürlich logisch auch sehr, sehr weit voneinander getrennt werden.

00:15:00: Das mit dem Early Return meistens dann... ...das was logisch zusammen gehört ist auch eher weiter zusammen und man kann den Programmfluss so etwas besser folgen.

00:15:08: Cool!

00:15:09: Genau das kommt nämlich auch noch dazu.

00:15:11: So Early Return Funktionen sind viel leichter kognitiv zu begreifen.

00:15:15: Insbesondere wenn sie viel machen, weil ich im Kopf von oben durchgehe... Ich sehe ja die Parameter, die ich habe und dann gehe ich durch und sage okay dieser Fall ist schon mal ausgeschlossen.

00:15:24: Dieser Fall ist auch mal aus geschlossen.

00:15:25: Dann kann ich das schonmal, wenn ich mir das anschaue, aus meinem Kopfspeicher löschen und hab da nur noch unten den Block der wirklich das tut worauf es ankommt.

00:15:34: Und dass ist nämlich gleichzeitig auch noch so eine schöne Lösung, die man damit hat zu sagen.

00:15:38: Man hat den Happy Path unten in der Funktion und wirft möglichst früh schon die ganzen Szenarien raus, die einen nicht interessieren.

00:15:47: Und das Entscheidende hierbei ist dass man bei jedem Early Return Block imaginär ein Kommentat drüber schreiben kann welches real weltliches Szenario jetzt gerade aufgetreten ist um das abzubrechen.

00:16:01: Das ist ganz entscheidend.

00:16:02: also das entscheidet auch wie man solche Sachen gruppiert d.h.

00:16:06: unser Passwort.

00:16:07: Beispiel könnte man natürlich entweder ein röhrele teuren machen wo man sagt entweder das oder dass oder das ist nicht erfüllt dann geh raus.

00:16:15: ich würde argumentieren, das sind drei unterschiedliche bedingungen die da zum tragen kommen nämlich Passwort zu kurz passwort zu lang.

00:16:22: Passwort keine sonderzeichen und so was.

00:16:24: Da könnte man sogar eigene Early Returns drauf machen mit so einem imaginären Kommentar da drüber und sagen, hey das ist das.

00:16:30: Das macht es zum Lesen unglaublich leicht nachzuvollziehen was jetzt hier die einzelnen Szenarien sind weil das im Prinzip im Coach schon für mich ausgespuckt ist.

00:16:42: Total!

00:16:43: Da gibt's auch noch ein schönes Basswort das heißt irgendwie Fail Early und Fail Hard oder so?

00:16:48: Weißt du was ich meine?

00:16:49: Genau, Fail Early ist das gleiche Prinzip und Fail hard... haben wir schon glaube ich ewig darüber gesprochen ist, dass man wirklich in so einer Funktion das krasseste Tool verwenden sollte um einen Fehler zum Ausdruck zu bringen.

00:17:02: Also im Fall von einem Passwort sollte man nicht sagen irgendwie Passwort ist zu kurz Return Faults oder sowas sondern sowas machen wie Password to Short Exception und so was Das ist das mit diesem Fail Hard?

00:17:14: also wirklich ein harten Fehler werfen.

00:17:16: Irgendwo in der Anwendung muss man sich natürlich da noch darum kümmern, dass es abgefangen wird und der Nutzer eine schöne Fehlermeldung herausbekommt.

00:17:22: Aber das ist eben dieses Fail-hard mit der exception.

00:17:25: idealerweise kann man wunderbar mit arbeiten.

00:17:27: Cooles Buzzword also early return, merken wir uns.

00:17:32: Jetzt du!

00:17:33: Ja pass auf ich habe ne Anwendungen gebaut in der ich einen Zahlungsanbieter eingebunden hab, Stripe ganz konkret Und da habe ich natürlich viel AI wieder benutzt.

00:17:43: Und die AI hat in letzter Zeit mir ganz oft das Wort Idempotenz entgegengeschmissen, dass irgendwas Idem Potent ist.

00:17:52: Und deinem Blick ernehm ich jetzt schon mal ... Du kannst damit vielleicht noch nicht so viel anfangen?

00:17:57: Ich lass dich mal!

00:17:59: Den Begriff hab' ich noch nicht gehört, ich könnte vielleicht so raten.

00:18:01: Dann rat ma und dann klär ich dich auf.

00:18:04: Also du musst es wirklich nicht kennen, ich kannte es auch nicht, habe's auch ge-googelt und deswegen hiermit gebracht...

00:18:07: Ja, ich bin darauf auf falschen Pferde.

00:18:09: Bevor ich jetzt Quatsch erzähle, erzählst du mich lieber und wirklich nicht blöd weil ichs nicht gewusst hab'.

00:18:13: Pass auf, eine Funktion ist idempotent.

00:18:16: Wenn die mit jedem Aufruf das gleiche Ergebnis zurückliefert oder zumindest mit mehrfachen Aufrufen nicht kaputt geht, sagen wir mal so ganz grob und das kommt ursprünglich aus der Mathematik und ist in der Formatik übernommen worden.

00:18:29: Und das brauchen wir natürlich vor allem in so Funktionen wo zum Beispiel ich sage meine Zahlung ausgeführt wird dann wollen wir natürlich Dass die Zahlungen viel mehrfach ausgeführt wird durch irgendwas was im Code passiert.

00:18:38: oder ganz klassischer Fall ist, wenn du ein Formular abschickst dann drücken die Leute ganz oft auf abschicken.

00:18:44: Ganz oft auf dem Button und wir wollen natürlich dass die Funktion nur einmal passiert und das in den anderen Fällen entweder eine nette Nachricht kommt oder vielleicht auch gar nichts passiert.

00:18:52: und da spricht man von idempotent.

00:18:55: also dann ist eine Funktion idemprotent.

00:18:57: ne?

00:18:58: Genau als du es gesagt hast war ich erst auf der Schiene Immutable und mutable.

00:19:04: Mhm, aber auch ein schönes Passwort.

00:19:05: Es klang so bisschen in Richtung.

00:19:07: was du ja meinst ist eher so eine Abstraktion üben drüber dass man sagt Dinge darf man mehrfach ausführen ohne das es dramatisch irgendwie kaputt geht okay?

00:19:16: Genau ich gehe vor allem auch davon aus dass der Kunde oder die Kundin das vielleicht machen würde oder der Benutzer von der Seite oder von der Anwendung weil da ist natürlich ein Szenario etwas ganz oft passiert.

00:19:27: dann gibt's natürlich Funktionen die sind Von haus aus idempotent also zum beispiel sowas wie delete.

00:19:32: wenn ich jetzt den delete mache auf eine bestimmte i d. Dann ist das beim ersten mal deleted und beim zweiten mal würde einfach nichts passieren weil er die nicht findet.

00:19:40: das heißt da muss ich mich nicht richtig drum kümmern können natürlich trotzdem abfragen machen sagen hier gibt es schon gar nicht mehr, aber im prinzip kann ja nicht viel passieren.

00:19:48: Und dann gibt's natürlich andere geschichten wie dem post wo dann zb neue beitrag angelegt wird Wo ich schnell ein problem kriegen kann weil der Beitrag dann vielleicht doppelt angelegt werden oder ... wo ich einen plus eins auf jeden Fall so ein Like vergebe.

00:20:01: Ja, guten Like wäre jetzt noch eher bursch aber... Ich sag mal wenn ich irgendwas hochzähle zum Plus Eins das kann natürlich öfter passieren will ich aber vielleicht in dem Moment nur einmal zählen und da muss sich natürlich sehr darauf aufpassen dass das dann eben idempotent ist.

00:20:14: und da gibt es natürlich schöne Methoden die wir jetzt glaube ich hier nicht alle durchkauen.

00:20:18: Aber ich sage mal nur eine Geschichte dass man zum Beispiel auf einer Datenbank ... einen Constraint hat mit einem Unique.

00:20:25: Also, dass ich zum Beispiel sage... ...ich nehme das Beispiel von eben unser Fragenspielchen,... ...da füge ich Fragen ein und ich will natürlich... ...dass jede Frage möglichst nur einmal drin ist.

00:20:34: Und dann könnte ich mir auf das Fragenfeld... ...könne ich mir einen Unique draufpacken... ...und da kann ich so schon in der Datenbank sicherstellen,... die Frage mit diesem Titel gibt es nur ein einziges Mal.

00:20:43: Bestenfalls fange ich das natürlich trotzdem im Code auch noch mal ab.

00:20:46: Aber so stehe ich schon auf Datenebene sicher.

00:20:48: Die Funktion ist idempotent, weil beim zweiten Mal zumindest ein Error geworfen würde.

00:20:52: Aber meine Daten waren nicht auseinanderfliegt.

00:20:54: Ein fantastischer Begriff von Dingen, die man eh schon macht aber wahrscheinlich den Namen dahinter nicht kennt.

00:20:59: und ich bin sicher morgen habe ich es auch hier vergessen.

00:21:02: Das haben alle was wir jetzt gemeint!

00:21:06: Ich hab's mir jetzt gemerkt, weil ich da ein bisschen drüber nachgelesen hab und das tatsächlich in letzter Zeit auch häufiger gehört hat.

00:21:10: Und ich glaube damit kann man schon gut angeben mit dem Begriff kennt, aber man sollte direkt eine Erklärung hinterher schieben.

00:21:16: Ich glaube man kann nicht davon ausgehen, dass den jeder kennt.

00:21:19: Aber die AI verwendet ihn wirklich.

00:21:21: also überbohrend sage ich mal.

00:21:23: Das stimmt das ist mir auch schon aufgefallen jetzt in einer ganz kleinen Tangente.

00:21:27: das sind Sachen wir haben jetzt viel mit so Migrationen rumgemacht wo irgendwelche Daten mal von A nach B geschoben werden mussten weil sich bei so eine Projektstruktur was geändert hat.

00:21:36: und es ist eigentlich ein klassisches Beispiel wenn man da so ein Skript schreibt was das um schreibt von A nach B, dann hat man immer den Fall bei einer Million Dateien das eine davon irgendwie korrupt ist und das denkt man sich im Vorfeld ja nicht aus.

00:21:49: Und dann hast du das Problem dass dein Programm irgendwie in der Mitte von so einem Durchlauf gestoppt ist und da ist es dann auch total wichtig so ne IDEM-Protenz zu haben.

00:21:58: Hundert Prozent!

00:21:59: Das perfektes Beispiel

00:22:00: um zu sagen... Wir müssen das Skript immer wieder von vorne durchlaufen lassen können, wir wollen das Skrip nicht umschreiben.

00:22:06: Und das muss intern checken.

00:22:08: okay dieser Datei ist schon kopiert diese nicht.

00:22:10: dann bin ich jetzt beim zweiten Durchlauf komme ich bis achtzig Prozent und so weiter.

00:22:14: Ich hätte es nicht besser sagen können.

00:22:16: also Migration von E-Mail Postfächer an solche Geschichten und dann stürzt ihr der Rechner zwischendurch ab und da muss es trotzdem irgendwie weiter laufen.

00:22:22: genau solche Sachen sind Situationen in dem wir den Potenz brauchen.

00:22:25: Und vielleicht aus real life noch das hatte ich auch bei Google gefunden als ich danach gesucht habe Der wird ganz auf der Aufzug genannt, weil wenn ich jetzt im Aufzug stehe und dann auf Etage drei drücke aber mehrfach.

00:22:35: Dann fährt er eben nur einmal die Etage Drei an Und nicht wenn irgendwie was anderes zwischendurchdrücke.

00:22:40: also ich könnte auch drei drücken dann vier drücken da nochmal dreidrücken.

00:22:44: Also währenddich aber in einer Fahrt bin und trotzdem würde der Aufzug nur einmal Die drei anfahren was natürlich total richtig ist und das sich stecken und ja sich nicht feiern.

00:22:52: Das sind die kleinen Dinge die man sonst nicht denkt idempotenz über sage schreibst mir auf Na ja.

00:22:59: Du bist nicht so begeistert?

00:23:00: Ich bin total begeistered, ähm... Ja, froh du!

00:23:05: Schön.

00:23:05: Von welchem Basswort warst du da noch begeisterd?

00:23:08: Okay mein nächstes Basswort ist das Dry Principle.

00:23:13: Dry Prinzip.

00:23:15: Kei ich hab überlegt es mit reinzunehmen.

00:23:17: Es sind auf Deutsch ein bisschen sperrig und ich find's besonders deswegen spannend weil leicht zu sagen, leicht zu merken aber schnell falsch anzuwenden ist.

00:23:26: Aber du kennst das dann wahrscheinlich?

00:23:27: Ja

00:23:27: ich spreche es immer aus.

00:23:28: Ich sage mal don't repeat yourself.

00:23:30: dafür steht er eben d ja y Don't Repeat Yourself und das finde ich unfassbar wichtig.

00:23:36: also wer das nicht verinnerlicht hat in der Programmierung Der muss nochmal einen Schritt zurück machen oder sollte sich ganz schnell durchlesen was das ist.

00:23:43: Und jetzt geht nicht darum das password zu kennen Es geht darum danach zu leben weil don't Repeat Youself ja sagt wir wollen im Code Erkennen, wenn wir Sachen mehrfach gleich schreiben.

00:23:53: Also Teile von Code gleich schreiben oder vielleicht auch ganze Blöcke gleichschreiben und wenn wir das identifizieren müssen wir schleunigst drüber nachdenken ob da Sinn macht was wir da tun?

00:24:03: Das kann unter Umständen der Fall sein aber in den allermeisten Fällen will ich dass irgendwie sagt man abstrahieren ist auch so schönes Passwort also will ich das irgendwie extrahieren welch es vielleicht eine eigene Datei auslagern will ich damit jedenfalls irgendwas machen dass sich diese Wiederholung auflöse Und das hat natürlich ganz viele Implikationen, wenn ich das nicht mache.

00:24:22: Dass ich da zum Beispiel eine Änderung machen will und es an zwei Stellen ändern muss ist vielleicht noch die einleuchtendste aber da kann natürlich auch ganz andere Sachen daraus entstehen.

00:24:30: Ich finde das großartig weil so wie du das gesagt hast... Das ist so glaube ich die Standarderklärung weil du ja schon ein paar wichtige weitere Basswörts untergebracht habe.

00:24:38: Könntest ihr heute von Baum zu Baum

00:24:40: schwingen?

00:24:41: Wir müssen so ne Glocke einbauen wenn wir

00:24:44: einen Bassword machen!

00:24:47: Die Kurzfassung ist genau Wiederhole dich nicht und wenn du in deinem Code zwei Dinge schreibst, die schon mal irgendwo waren dann musst du es irgendwie zusammenfassen.

00:24:54: Zusammen abstrahieren hast du gerade gesagt.

00:24:57: aber das ist nur die halbe Wahrheit und führt leicht dazu dass auch da wieder Programmieranfänger in so eine Falle tappen von alles auf Teufel kommen raus zusammenzuschreiben weil das zufällig gleich aussieht.

00:25:09: und genau darum geht's nämlich nicht.

00:25:11: und was grad?

00:25:12: das geheime Zauber wird Abstraktion genannt und das ist nämlich das wo es eigentlich geht.

00:25:17: ich habe einen Auszug gefunden aus dem The Pragmatic Programmer, wo angeblich dieses Wort zum ersten Mal herkommen.

00:25:24: Und jetzt zitiere ich mal auf Englisch... ...and da geht es nämlich nicht darum dass man einfach irgendwelche Codeblöcke kopiert sondern geht es darum dass man Abstraktionen, wie sagen Sie, Pieces of Knowledge so formuliert, dass man sie an einer zentralen Stelle verwaltet.

00:25:54: Und das geht nämlich weit darüber hinaus.

00:25:56: einfach zu sagen fünf Zeilen Code zählen gleich aus – wir machen da eine Funktion draus!

00:26:02: Sondern Abstraktionen die man ins System einbringt sollen an einer Stelle gesammelt werden damit es aus dieser Sicht der Abstraktion die eine Source-of-Truth gibt.

00:26:12: Und das wollte ich genau sagen.

00:26:13: Das war übrigens ein Buzzword, was ich fast mit reingenommen hätte die Single Source of Truth weil ich das wirklich neben Dry auch sehr oft verwende.

00:26:20: Das wäre jetzt gerade so eine bisschen schwammige Umschreibung finde ich dafür dass man eine Quelle der Wahrheit haben will.

00:26:25: Das müssen wir im nächsten Buzzword Bingo mal mit reinbringen sein.

00:26:28: und das ist dein dritter Begriff den du heute mitgebracht hast?

00:26:30: Nee!

00:26:31: Aber ich wollte nicht so lange unterbrechen.

00:26:32: erzähl mal weiter.

00:26:33: Ich

00:26:34: habe ein Beispiel mitgebracht wo es nämlich nicht passt und zwar stellen wir uns vor Wir haben in unserem System das wir selbst geschrieben haben einen Produkt für einen online shop und jetzt haben wir zwei apis.

00:26:43: Und wollen das nach wuco merse oder nach shop war schicken dieses produkt um es in beiden shops anzubieten.

00:26:49: Und dann schreiben wir ja irgendwie so request für die beiden shops weil wir die per api bespielen wollen und stellen dann fest ich habe den request für shop a geschrieben und für shop b auch stelle fest, aber beide shops wollen irgendwie ein titel haben und eine description unten image und vielleicht auch im preis.

00:27:07: Ja dass hab ich jetzt an beiden stellen geschrieben Aber es ist ja irgendwie jetzt repeated, dann fasse ich das mal zusammen und hab mich nicht repeatet.

00:27:15: Weil ich nur an einer Stelle sage hier schick mal los den Titel oder sowas.

00:27:21: Das ist genau der falsche Ansatz weil es keine übergeordnete Abstraktion gibt die mir garantiert dass das absichtlich gleich ist und nicht zufällig.

00:27:30: In diesem Fall haben weder Shopwear noch WooCommerce eine Absprache miteinander die sagen unsere Produkte haben ein Feldtitel Sondern die haben beide zufällig das Gleiche genommen.

00:27:42: Und genauso bei der Description und beim Price, aber es garantiert mir nichts, dass nicht einer von den Beidern das irgendwann mal ändert.

00:27:48: Und dann zu sagen streng nach dem Don't Repeatrin-Seab mache ich jetzt irgendwie einen zusammenhängenden Container, der beider ausspielt wäre genau der falsche Ansatz weil es keine übergeordnete Abstraktion gibt, die das garantiert.

00:28:02: In dem Moment wo du das wirklich mal ändern willst müsstest wieder auseinander fummeln und das ist wahrscheinlich auch weniger als das einmal Roppel zu machen?

00:28:08: Genau!

00:28:10: Anders herum, wenn wir uns jetzt überlegen gleiches Beispiel zu beiden Shops soll der Preis geschickt werden.

00:28:17: Und für die Preisberechnung haben wir ein total fancy Algorithmus in der Firma, der sagt Einkaufspreis plus zwanzig Prozent Marge oder sonst irgendwas.

00:28:25: dann ist das eben eine Sache, die wir nicht in beiden Produkten separat reinschreiben wollen sondern das wiederum ist ja eine Gemeinsamkeit, die wie als Firma haben.

00:28:34: und da dann zu sagen Wir haben Eine Funktion, die für all unsere Produkte so eine Preisberechnung macht ist dann genau die richtige Dry Variante.

00:28:43: Nehm ich zu sagen?

00:28:44: Preisberechnungen, eine Quelle wo wir das für alle Shops hinschreiben

00:28:48: und in jedem Shop kommt der gleiche Preis an was auch noch irgendwie ganz wichtig wäre.

00:28:51: Genau Das Problem bei solchen Abstraktionen ist du weißt nie ob Du die Richtige hast Bist du die falsche erwischt?

00:28:58: Weil genau bei solchen Preisen könntest ihr eben auch sagen, aber was ist denn jetzt wenn Wocommerce fünf Prozent Marge nimmt und Shopwear zehn Prozent.

00:29:07: Dann muss ich das ja irgendwie bei meiner Preisberechnung berücksichtigen.

00:29:10: Das heißt, ich kann nicht wieder die einheitliche preisberechnungen für beide nehmen.

00:29:14: also man sieht schon Es ist nicht immer alles der goldene Weg, aber das sind vielleicht mal zwei anschauliche Beispiele dafür wie man so ein Dry-Prinzip richtig anwendet.

00:29:23: Nämlich die gemeinsame Abstraktion oder wie man es dann vielleicht falsch anwendete nur weil zwei Sachen zufällig gleich aussehen?

00:29:30: Ich finde dass es unglaublich individuell was Sinn macht und war nicht.

00:29:33: Und jetzt gibt's bestimmt auch Leute da draußen die sagen bei dem ersten Beispiel Yo!

00:29:37: Das können wir eigentlich schon zusammen fassen Weil ich meine das ein Produkt im Titel hat.

00:29:41: also das wird sich einfach nicht ändern.

00:29:43: Und da muss man wirklich sehr, sehr individuell in der Situation gucken.

00:29:46: und es gibt ja auch noch ganz andere Gründe, warum man Sachen nicht zusammenfasst.

00:29:49: Zum Beispiel in dem Kurs.

00:29:50: Da komme ich jetzt immer wieder darauf zurück hier im Frankfurter, den ich mache, dass du oft das Problem wenn du dann Sachen abstrahierst, dann wird's auch komplexer zu verstehen.

00:29:58: Wenn du dann ... Ich sag mal, da hast du zum Beispiel einen if-else wo du eine Erfolgs-, oder eine Negativmeldung ausgeben willst.

00:30:05: Das kannst natürlich mit so einer Inline fls machen, sodass du nicht eine Variable zweimal aufmachen musst usw.

00:30:11: Aber das wird natürlich alles schwerer verständlich.

00:30:13: und das ist jetzt vielleicht so ein einfaches Beispiel, aber da gibt es natürlich andere Beispiele.

00:30:16: Du musst ja im Wesentlichen dann in eine andere Funktion reinspringen muss vielleicht der Funktion noch Parameter übergeben usw.

00:30:22: Und sofort.

00:30:23: Da muss man sich im Einzelfall wirklich fragen lohnt sich das hier oder ist die Überschneidung so Ja So sauber oder wird sie auch nie angefasst dass es vielleicht so Sinn macht das hier in dem Fall umzusetzen?

00:30:35: Ich sage mal grundsätzlich und ich habe eingangs schon gesagt Das Prinzip finde ich ganz wichtig.

00:30:39: In ganz vielen Fällen kann man sich merken, wenn man Sachen zweimal schreibt.

00:30:42: Dann sollte man mindestens mal drüber

00:30:43: nachdenken.".

00:30:44: Genau und wichtig.

00:30:45: das haben wir auch in unseren Virtue Quests immer in der täglichen Arbeit.

00:30:49: Wichtig ist dass wenn ich solche Sachen dann anbringe und sage guck mal, hast du dich wiederholt?

00:30:53: Ist es so schlau, dass die Leute sagen ja klar hier Dry-Prinzip und so weiß ich.

00:30:58: aber in diesem spezifischen Fall macht es total Sinn sich zu wiederholen und da bin ich auch fein damit.

00:31:03: also sind ja alles immer nur Impulse von.

00:31:06: habe ich mal gehört Kai, Onkel Kai hat vom Dry-Prinzip gesprochen und beim nächsten Mal wissen wir's.

00:31:11: Ich hab ein richtig gutes Basswort daran im Anschluss.

00:31:15: Abstraktion!

00:31:16: Nee ich habe nämlich Jagdnie mitgebracht.

00:31:18: Y, A, G, N, I ... Jagdni kann man bestimmt auch irgendwie Englisch aussprechen?

00:31:23: Hast du das schon mal gehört?

00:31:24: Das hab' ich noch nicht gehört.

00:31:25: Ist auch wieder so ein Ding was mir die AI tatsächlich entgegengeschmissen hat Und was ich aber auch schon öfter gehört hab Und das hat mich nur wieder drauf gestoßen, dass es das gibt.

00:31:33: Da hab ich gedacht, das bring' ich mal mit!

00:31:35: Weil ich wollte extra so ein bisschen Buzzwords mitbringen die du vielleicht nicht kennst und die vielleicht auch die Leute da draußen nicht so gut kennen.

00:31:40: Jagd nie steht für you ain't gonna need it.

00:31:44: Muss jetzt gerade noch mal an... You aren't going to need it steht hier also kommt ja aus gleich heraus.

00:31:49: Das find ich ein ganz wichtiges Prinzip auch weil mich das in der Vergangenheit schon oft eingeholt habe.

00:31:54: wenn ich das nicht eingehalten hab kannst du dir darunter was vorstellen?

00:31:57: Ja ist großartig, weil ich schon wieder zwei Merch-Requester hatte wo das vorgekommen ist.

00:32:02: Es geht darum dass man beim Programmieren nur das wirklich programmieren sollte was man wirklich braucht und nicht alle Eventualitäten in die Zukunft schon abdecken.

00:32:13: Einhundert Prozent!

00:32:14: Brauche nichts ergänzen.

00:32:17: Also wie alles was man so sagt, Prinzipien lassen sich leicht sagen aber dann stoßen sie oft an der Realität.

00:32:25: manchmal weißt du halt schon jetzt hier in der kunde wünscht sich später noch das und dass dann mache ich dafür vielleicht schon mal ein paar vorbereitende baumaßnahmen.

00:32:34: die idee dahinter ist ja, dass der code so schlank wie möglich bleibt.

00:32:38: Und alle eventualitäten die man vielleicht mal sich überlegt kann sich immer viel überlegen aber ob sein eintritt ist unwahrscheinlich Und deswegen zu Lasten macht man den eigenen Code übersichtlich.

00:32:49: Deswegen immer so schlank, so elegant wie möglich und dann im Zweifel auf Probleme reagieren wenn sie dann kommen.

00:32:55: das ist mal so mein Kredon.

00:32:56: Genau und das Prinzip sagt einem eigentlich du gehst davon aus dass du vielleicht irgendwas in Zukunft brauchen wir es aber in vielen Fällen ist es eben nicht der Fall.

00:33:04: und dann hast du diesen Code erschaffen, hast größere Entwartungsaufwand, hast vielleicht performance technisch Themen Du hast eine große Komplexität und am Ende für was?

00:33:13: Eigentlich oft für nichts.

00:33:15: Selbst wenn's gebraucht wird, wird es oft anders gebraut als man es implementiert hat.

00:33:19: Und deswegen lieber direkt weglassen haben wir die Zahlenaufwand nicht so hoch.

00:33:22: das kommt ja auch aus der agilen Softwareentwicklung aus dem Xtreme Programm inkoppt ist glaube ich ursprünglich und da sehr eben ganz wichtig dass man nur die Sachen erst mal baut die tatsächlich auch benutzt werden ne?

00:33:32: Das haben wir in vergangenen Projekten als wir ja als die Firma noch ein bisschen in Kinderschuhen steckten sind wir da mindestens bei einem Projekt auch drüber gestolpert wo wir für den Kunden eigentlich eine individuelle Anwendung gebaut haben.

00:33:44: Die wollten wir aber so generisch aufbauen, also die wollten mir so allgemein aufstellen... dass wir das vielleicht auch für andere Kunden schippen können.

00:33:53: und dann haben wir da Funktionen eingebaut, die in einen Multi-User berücksichtigt haben und die ganz unterschiedliche Szenarien mitgedacht haben.

00:34:03: Und am Ende haben wir eine Anwendungen gebaut, die super unperformant war, die ganz komplex war, viel Wartung bedeutet hat oder viel Programmieraufwand und am Ende war die Software nicht erfolgreich.

00:34:16: Und ich glaube vor allem, weil wir viele Sachen gebaut haben und viel Zeit in Sachen gesteckt haben, die wir eigentlich nie gebraucht haben.

00:34:22: Kostiales Geld ne?

00:34:23: Genau!

00:34:25: So mein letzter Begriff.

00:34:27: weiß nicht ob das so richtig jetzt in die Methode reinfällt aber das war ein Begriff der mich drüber gestolpert und habe direkt gedacht ja was heißt das eigentlich?

00:34:35: und der Begriff ist Threat häufig in Verwendung mit dem Single oder Multi Thread und da geht es ganz grob, um irgendwelche Dinge die auf den Prozessor passieren.

00:34:48: Aber bevor ich jetzt nicht verrate Felix kannst du dir darunter was vorstellen?

00:34:52: Also ein Thread ist für mich, naja so einen... also ich habe eine gute Vorstellung davon.

00:34:59: Jetzt muss ich mal im gucken wie ich das in gute Wörter bringe.

00:35:01: Also es sind ein Teil von einem Programm der separat ausgeführt wird.

00:35:08: der auch vielleicht parallel ausgeführt werden kann.

00:35:11: Also das ist eigentlich ein Ausführungsstrang von der Software?

00:35:16: Boah, du siehst schon!

00:35:16: Ich ringen so bisschen nach Wörtern und hast bestimmt eine tolle Erklärung dafür.

00:35:20: Na ja, Thread steckt ja schon so'n bisschen drin.

00:35:22: Strangen bist du gar nicht so verkehrt... Und jetzt mögen wir hier die Hardcore-Itiler bitte verzeihen.

00:35:28: Keine Schulungen in dem Bereich haben es jetzt nur grob zusammengereimt.

00:35:31: aber das ist nämlich genau auch der Grund warum mich das interessiert hat.

00:35:34: Und zwar geht es ganz grob darum wie der Computer Aufgaben abarbeitet.

00:35:38: Und da geht es mich schon los, je nachdem auf welcher Ebene des Computers man so unterwegs ist hat das unterschiedliche Bedeutungen.

00:35:45: aber wir stolpern in der Entwicklung immer wieder drüber.

00:35:48: zum Beispiel PRP bekannterweise ein Single Thread, Javascript auch ein Single thread.

00:35:53: Da geht's damit sowas wie Async und Erweightlos und so was.

00:35:56: deswegen hat nicht das mal interessiert und ich versuche es mal grob runter zu brechen und möge den ganzen Menschen da draußen bitte jetzt schon einmal im Verzeihung bitten wenn ich dabei irgendwas falsch mache.

00:36:06: Aber die Idee ist, in einem total simplen Computer mit einem ganz langsamen Kern bedeutet ein Thread eine Reihe von Aufgaben, die der Computer der Reihe nach abarbeiten kann.

00:36:18: also nur dass er sie in einer Reihe abarbeiten können.

00:36:20: und wenn ne neue Aufgabe dazukommt dann kommt die hinten an und wird erst dann abgearbeitet wenn der Computer die Fertigen aufgelöst hat.

00:36:27: oder das bedeutet in so'n ganz ganz runter gedummten Beispiel von so ner PAP-Applikation Ein Request kommt rein, belegt den Thread.

00:36:36: Den einen, den es gibt.

00:36:37: Dann wird der nach und nach abgehandelt.

00:36:39: In der Zwischenzeit kommt ein zweiter Request rein.

00:36:42: Der Thread ist aber schon belegt, deswegen reitet er sich hinten an.

00:36:45: Erst wenn der erste abgeschlossen ist kann der zweite dran kommen.

00:36:48: Das ist so ganz grob trivialisiert.

00:36:51: Und die große Gefahr, die dann dazu kommt, dass Computer unglaublich modern sind inzwischen und viele Kerne haben, die mehrere Threads machen können.

00:37:03: Das heißt zum Beispiel, wieder ein Beispiel von PAP.

00:37:06: Aus der Sicht vom PRP läuft zwar alles auf dem einen Thread aber irgendwann in so einem Ablauf kommt dann z.B.

00:37:12: eine Datenbankabfrage und aus der Sicht von PRP warten wir jetzt in diesem einen Thred bis die Datenbank abfrage im Hintergrund erfolgt ist.

00:37:21: Aber aus Sicht des Computers sieht ja jetzt oh dieser eine Thread da passiert gerade nichts.

00:37:26: ich kann den pausieren oder in der Zwischenzeit einen anderen Thread aufmachen Also nicht gleichzeitig läuft, sondern stattdessen läuft der diese Datemangabfrage löst.

00:37:35: Wenn die Datemagabfrage fertig ist mache ich den ein Thread zu und in den anderen wieder auf dem Ergebnis.

00:37:40: also da sieht man schon je nachdem aus welcher Perspektive man darauf guckt wird es schon sehr kompliziert.

00:37:46: und dann kommt jetzt noch komplizierter mit Multicord CPUs die wirklich Sachen gleichzeitig machen können.

00:37:52: Und die entscheidenden Buzzwords sind da Concurrency versus Parallelism weil das nämlich bedeutet Concurency.

00:38:00: Also es wird ja ganz schnell zwischen verschiedenen Threads hin und her gewechselt.

00:38:04: Die CPU schaut sich immer an, der Thread ist gerade irgendwie Stale oder Stale ist wahrscheinlich jetzt schon wieder so ein falscher Begriff aber da passiert gar nix.

00:38:11: ich mach in den Zwischenzeiten anderen die einzelnen Programme merken davon nichts.

00:38:15: aus deren Sicht ist das alles Single Thread aber ich als CPU kann dazwischen her wechseln oder gleichzeitig parallel bedeutet einfach mehrere Thread laufen wirklich parallel zur selben Zeit auf unterschiedlichen Kernen oder sonst irgendwas.

00:38:30: Da ist ja Node.js für bekannt, dass die viele Sachen parallelisieren auf mehrere Threads aufteilen können.

00:38:36: Genau!

00:38:36: Während an einem Programmi sparen du hast PAP genannt das vielleicht nicht so gut könnten?

00:38:40: Und da ist es jetzt nämlich wieder total spannend auf uns zurückzukommen weil obwohl wir ja keine so Hardware-Menschen sind kommt das trotzdem immer wieder unter weil es eben bedeutet wie wird Last verteilt?

00:38:50: und bei PAP um dabei vielleicht zu bleiben Ist es eigentlich ganz gut dass das ein Tringle Thread Geschichte ist So wie wir es klassisch kennen ja dafür aufgebaut ist, dass so ein Request kommt rein.

00:39:02: Der wird gestartet ausgeführt und danach stirbt der wieder.

00:39:05: Und das ist für uns ja total elegant weil wir alles mögliche in den Arbeitsspeicher laden können was wir jetzt gerade für diesen Request brauchen welcher Nutzer gerade authentifiziertes und irgendwelche Daten.

00:39:14: Wenn die Abfrage fertig ist werfen wir alles komplett weg!

00:39:17: Alle Authentifizierungsdetails und sonst irgendwas.

00:39:20: Und wenn ein Neuer reinkommt, ein neuer Thread, können wir das ganz wieder von vorn aufmachen.

00:39:23: Das ist aus unserer Sicht ein total elegantes Konzept, weil wir uns eben nicht damit bemühen müssen irgendwelche ... weiß ich nicht Sachen wieder wegzuwerfen selber explizit, wenn wir sie nicht mehr brauchen die Authentifikierung im Auge zu behalten oder sonst irgendwas?

00:39:37: Das heißt allerdings gleichzeitig dass wir nur diesen einen Thread haben um Dinge zu tun.

00:39:42: Wenn wir da Dinge drauf tun, die sehr aufwendig sind dann blockiert es uns den ganzen Thread.

00:39:46: Und das klassische Beispiel dafür ist so eine E-Mail verschicken, dass es üblicherweise auch in diesem einen Thread Cosmos drin dauert aber verhältnismäßig lange und deswegen hält alles andere auf.

00:39:57: also wenn der Nutzer ein Kontaktformular ausgefüllt hat und abschickt zeigen wir eine Ladeanimation auf der Seite erst bis dieser ganze Thread bis zum Ende durchgelaufen ist Also auch die E-mail verschickt wurde oder sonst irgendwas und das kann natürlich ewig dauern.

00:40:10: Deswegen gibt es da so magische Dinge wie Cliffhanger Queues zum Beispiel, das ist so ein Konzept wo man einfach sagt aufwendige Aufgaben lagern wie in separat System aus.

00:40:23: Da wird dann separator Thread für aufgemacht der sich darum kümmert.

00:40:26: Asynchronität ist da so ein Zauberwort und das kann uns helfen so ein bisschen daher der Lage zu werden.

00:40:32: Das sei unsere Lara-Weltfolge noch mal ins Herz gelegt, da gehst du glaube ich auf die queues zumindest in Lara Welt nochmal ein.

00:40:37: ne?

00:40:38: Genau!

00:40:38: Einfach ist es in Javascript, da haben wir gerade auch schon drüber gesprochen Da gibt es dieses Konzept von Async Await quasi eingebaut.

00:40:45: Das muss jetzt nicht immer hundert Prozent bedeuten, dass das wirklich multi-threaded ist.

00:40:49: Es kann auch wie gesagt bedeuten da zwei Threads theoretisch aufgemacht werden aber sich die concurrent abwechseln.

00:40:57: aus der Sicht von Ja was gibt's sieht es so aus als würden wir zwei Dinge parallel laufen lassen und da benutzen wir das eben auch mehrere Thread in Anführungszeichen um aufwendige Aufgaben aus dem Main Thread rauszunehmen und separat parallel laufen zu lassen.

00:41:12: Du musst mir noch mal sagen, also eben JavaScript und Single Thread gesagt hast, da habe ich direkt eine Assoziation im Kopf gehabt zur Web-Worker.

00:41:20: Ich hab lange nichts mehr von gehört und vielleicht autig mich jetzt hier weil das ist vielleicht ein full state of the art ist.

00:41:26: aber wann das nicht so Dinger die man eben auch parallel in einem separaten Thread laufen lassen konnte?

00:41:30: Weil es nicht genau das Prinzip

00:41:32: Genau Service Worker!

00:41:33: Das hat aber nochmal einen Sonderfall.

00:41:35: Das ist auch dafür da, dass man Dinge im Hintergrund laufen lassen kann während der Browser zum Beispiel geschlossen ist und so was.

00:41:40: Also die sind deutlich mächtiger aber grundsätzlich stimmt das schon.

00:41:44: Da könnte man theoretisch auch Aufgaben hin auslagern.

00:41:47: Spannend ist es ja bei Javascript

00:41:48: z.B.,

00:41:49: wie wir arbeiten weil wir Single Page Applications haben.

00:41:53: Ja, was kippt sich auch um das ganze UI kümmert.

00:41:56: Irgendwelche Dinge im Browser rendered und darauf reagiert wenn man drauf klickt.

00:41:59: Und da ist natürlich dramatisch, wenn irgendwas den einen Thread blockiert, den wir haben weil das bedeutet dass der Nutzer auf dem Button klickt und nix passiert, weil er gerade mit E-Mail versenden beschäftigt ist oder sowas und da das dann auslagern zu können sind bedeutet eben, wir haben den Main Thread frei für diesen ganzen visuellen Kram.

00:42:18: Ganz klassisch ist das für mich immer gewesen in den PAP-Anwendungen wenn man da eine Datenbankabfrage drin hatte und wenn die Datenbank Abfrage hängt dann hängt nicht nur der ganze Server sondern mindestens mal diese Seite.

00:42:29: Und die Lösung kam letztlich mit den Single Page Applications wo man dann die einzelnen Teile von der Seite also ich sag mal eine Datentabelle und dann hat man vielleicht oben ein Benutzermenü oder vielleicht noch Nachrichtenmenü.

00:42:41: Da hat man diese Teile separat geladen und hatte dann den schönen Vorteil, dass wenn mal ein Teil hängt.

00:42:46: Dann ist da zwar einen Throbber also eine Lade Animation aber die anderen Teile können schon laden Und das ist natürlich dann so.

00:42:53: hat man die Probleme so bisschen gelöst und vorher war es so egal Wenn irgendein Teil auf der Seite lange lädt, dann hat auch die ganze seite gehangen und hat natürlich diesen Userflow total zerschossen.

00:43:02: genau also am besten überlegen Wenn ich irgendeine noch so aufwendige Aufgabe habe, wie kann ich die ausleeren?

00:43:09: Und da immer dran denken.

00:43:10: Aufwändig und zeitaufwändig immer aus Computerperspektiven betrachtet.

00:43:15: Da sind halt hundert Millisekunden auch schon viel wo wir als Menschen uns denken.

00:43:18: nach Hundert Millizekunden bekomme ich nicht mehr mit.

00:43:20: Total!

00:43:21: So jetzt bin ich gespannt auf dein letzten Begriff.

00:43:23: Ja ich hab noch ein allerletzten.

00:43:25: Ich glaube der dauert jetzt ja auch nicht wahnsinnig lange.

00:43:27: Aber das ist ein Begriff der mich vor Jahren immer wieder untergekommen ist und er im Scrum-Bereich ganz geflügelt ist Und das sind die sogenannten cross-funktionalen Teams.

00:43:37: Und da, Kai würde mich vor allem interessieren was du von dem Konzept hältst und ... Du weißt aber vermutlich was es ist oder?

00:43:45: Genau Cross Funktionale Teams heißt dass einem Team... Da ist ja schon die Frage was das ist unterschiedliche Leute mit unterschiedlichen Disziplinen versammelt sind

00:43:54: Ja oder anders gesagt sogar wir haben alle Disziplin die wir für eine bestimmte Aufgabe brauchen in dem Team was es auch umsetzt so das glaube ich so das Kernprinzip davon

00:44:03: Genau.

00:44:04: Und das ist halt so ein Wort, dass es schnell gesagt, da kann man gut darüber diskutieren.

00:44:09: aber was bedeutet das in der Realität eigentlich?

00:44:11: Weil wenn wir ein Projekt haben dann ist natürlich total hilfreich Wenn die Leute mit dem Projekt beschäftigt sind.

00:44:17: Leute haben sich mit den ganzen Bauteilen auskennen und wenn wir dann einen Team bauen was nur Fronten Entwickler hat Aber keine Backend brauchen dann bringt's das natürlich nicht.

00:44:26: also Frage ist es wahrscheinlich eher so für große Teams, wo man ein Projekt hat.

00:44:32: Wo es Teams aus Teams gibt und wo man dann die vielleicht ein bisschen anders kopiert?

00:44:36: aber ich weiß nicht als du ja ein spezielles Beispiel für

00:44:39: Ja Ich bin da das erste Mal richtig aufgestoßen Als ich in Remscheid bei Weyland war seinerzeit Und da haben wir halt mit ganz vielen teams gearbeitet und Die teams sollten idealerweise kostfunktional sein und dass war eben sehr gefügeltes fort und ich habe das damals Als nicht nur positiv kennengelernt, was ich total cool fand ist dass wir Becken und Frontend in den Projekten hatten.

00:45:01: Das war ein Java Backend so ein Spring Boot.

00:45:04: Geschichte war das... ...und im Frontend war das unterschiedlich.

00:45:07: aber da war so ein bisschen Headless Framework auch dabei oder Headless CMS war dabei First Spirit Katastrophe.

00:45:14: also sei jedem von abgeraten.

00:45:15: Ich weiß nicht ob die sich weiterentwickelt haben Aber ich kann es mir kommen vorstellen Und dann waren aber auch so Single Patch Applications Die damals im View gemacht wurden Waren auch dabei Und da habe ich das total genossen, dass wenn man eine Backend API irgendwie brauchte, irgendwelche Informationen aus dem Backend brauchte.

00:45:29: Dass man dann den Backend irgendwie gleich neben sich sitzen hatte.

00:45:33: Bestenfalls noch mehrere und da konnte man direkt die API abstimmen und man hatte super kurze Wege, konnte super effizient das Ganze machen.

00:45:39: Und bestenfalls hatte man dann noch einen Designer danebensitzen.

00:45:42: Das heißt, wenn man sich jetzt überlegt hat wie geschallt ich jetzt die neue Seite der Anwendung hier?

00:45:46: Dann hatte ein Designer auch schon mal ein kleines Design hingeschmissen, hat hinterher nochmal drüber geguckt Und so ist man zum guten Ergebnis gekommen.

00:45:53: Dann hattest du noch POS, also Product Owner dann hattet du noch DevOps.

00:45:57: das war auch wieder sehr praktisch jemanden zu haben der sich um diese ganzen Server-Infrastruktur Themen und so kümmert und ja einfach so sehr servernah unterwegs war... ...und da räumt man schon ein bisschen raus hat vieles gut von funktioniert.

00:46:10: aber meine Erfahrung an diesen wirklich strengen cross funktionalen Teams war eigentlich immer beste Beispiel wahrscheinlich der Designer.

00:46:16: am Anfang machst du ganz viele Design Ja und dann hast du eigentlich nicht mehr so richtig viel zu tun, dann sollen die Leute mal umsetzen.

00:46:22: Und wenn du Programmierer hast, die Design auch ein bisschen weiter denken können?

00:46:26: Dann musst du jetzt nicht jeden Button designen sondern kannst du dir auch mal laufen lassen.

00:46:29: Ja und da hatten die Designer nicht so wahnsinnig viel zu tun.

00:46:31: das führte dann am Ende dazu dass man eigentlich hinter einem Design Team hatte was den anderen Teams dann zugearbeitet hat.

00:46:39: Das war dann nicht so richtig cross funktional weil es dann letztlich ein eigenes Design Team war.

00:46:43: Und das ist vielleicht auch so der Kritikpunkt, den ich dran üben würde.

00:46:46: Also wenn du jetzt wirklich einen Produkt hast, ein crossfunktionales Team dann ist es schon schwierig Front und Backend gleichmäßig auszulasten.

00:46:53: Da bin ich eher ein Fan davon dass man sich in dem Moment die Ressourcen holt wie man braucht oder zumindest für die Zeit die Ressen holt die man braucht.

00:47:00: Das ist wahrscheinlich ein Problem was man hat wenn man wirklich größere Projekte betreut.

00:47:04: Ich finde das mit diesem Team bisschen irreführend weil es kommt ja letztens eines aufs Projekt an.

00:47:09: Kostfunktionale Projekte sind es ja dann eher.

00:47:12: Und dann kommst du eigentlich gar nicht drum herum, dass die Leute im Projekt hörst du dafür brauchst um das umzusetzen?

00:47:17: Aber dann wirklich die ganze Zeit so ein Designer da drin zu haben der eigentlich nichts macht nur um einen Designer als kostfunktionaler Komponenten im Team zu haben Das ist es ja irgendwie auch nicht.

00:47:29: Genau.

00:47:29: aber wenn der Designer eben woanders sitzt oder vielleicht so eine externe Agentur ist oder so Dann hast du halt immer das Problem, dass du einen langen Kommunikationsweg hast und Das sind über so Reibungsverluste oder klassischerweise mit den DevOps, dass du irgendwo eine Abteilung hast die sich um die Server kümmert und du willst aber eigentlich nur schnell zum Ergebnis kommen bei eben Test-Server aufsetzen.

00:47:47: Und das geht natürlich in so einem kostfunzialen Team was wirklich eng zusammensitzt.

00:47:51: Natürlich fantastisch!

00:47:52: Aber mit den Downsites, wie ich auch gesagt habe.

00:47:55: Ich hab das jetzt in... Ich weiß gar nicht, in letzter Zeit habe ich kostfunzielles Teams gar nicht mehr so häufig gehört.

00:47:59: Früher war immer, wir haben ein Projekt, abends haben wir ein kostfunziales Team aufstellen Jetzt in letzter Zeit sowie Scrum auch, weil ja lange Zeit ultra beliebt.

00:48:06: Inzwischen würde ich sagen nehmen sich alle so die Teile raus, die gut funktionieren.

00:48:12: aber ich kenne kaum einen der jetzt wirklich täglich noch Dailies macht.

00:48:15: also gibt es sicherlich auch in größeren Teams oder die dann die ganzen Scrum-Rituale wirklich immer ganz konsequent durchführen bin ich mir auch nicht sicher wie sinnvoll das immer ist.

00:48:24: Aber ich glaube wenn man da sich die richtigen Teile raussucht und macht das Sinn Und ich glaube so ähnlich muss man sich crossfunktionale Teams auch halten dass man sagt Ja So ein bisschen gemischte Kompetenzen wollen wir schon haben.

00:48:34: Aber so ganz streng müssen wir es eigentlich nicht umsetzen und wir brauchen ganz sicher nicht irgendwie einen New Extra, der sich den ganzen Tag langweilt nur damit er irgendwie dabei ist.

00:48:42: Kann

00:48:42: ja auch noch hinten losgehen.

00:48:43: dann muss er sich irgendwie im Team rechtfertigen und kommt auf einmal auf die absurdesten Ideen weil er gerade Freizeit hat und alle anderen stecken aber zu Hundertfünfzig Prozent in der Arbeit und haben da nicht noch Lust irgendwelche wilde Ideen auszubrüten oder umzusetzen, die er da ausgebrütet hätte?

00:48:57: Absolut!

00:48:58: Das ist nämlich auch ein Punkt, den ich aufgeschrieben habe.

00:49:00: In so einem crossfunktionalen Team will jeder mitreden.

00:49:03: Das heißt du veröffentlichst nichts... Ich werde jetzt gar nicht zu sehr auf den Designern rumhacken aber du veröffentlicht nichts ohne dass der Designer auch drüber geguckt hat oder ohne das einen Tester zum Beispiel da drübergeguckt hat.

00:49:13: beim Tester eher positiv, beim Designer manchmal positiv und manchmal nicht so weil dich das natürlich auch auffallen kann.

00:49:19: Aber letztlich Danny dem Team will auch mitrede?

00:49:21: Ja

00:49:22: genau!

00:49:22: Das definitiven Nachteil Und was wir bei uns in der Firma machen.

00:49:26: um den Bogen mal zu schlagen Man könnte jetzt vielleicht neues Wort erfinden, wir sind ja eigentlich kostfunktionale Programmierer.

00:49:31: Also wenn ich mir mich selbst angucke... Ich mach Design Front and Backend so.

00:49:36: man kann natürlich einfach Fullstack sagen ist auch ein schönes geflügeltes Wort.

00:49:39: aber zum Fullstacks gehört glaube ich Design und so nicht unbedingt dazu.

00:49:42: Und eigentlich wollen wir natürlich bei uns Leute ausbilden die so breit aufgestellt sind dass sie zumindest nirgendwo an eine Grenze kommen wo sie sagen da könnt ihr es gar nicht mehr helfen.

00:49:52: also nehmen wir mal mich selbst vielleicht.

00:49:55: Wenn's jetzt um Deployment geht Da bin ich sicherlich kein Experte, sondern da komme ich gut zurecht.

00:50:00: Ich könnte einen Git aufsetzen und keine Pipeline aufsetzten... ...ich weiß was da ungefähr los ist und mit ein bisschen Hilfe jetzt mit AI erst recht würde ich da schon zum guten Ergebnis kommen.

00:50:10: Aber ich genieße es auch sehr wenn ich einfach an Kai fragen kann der da super trittsicher ist oder andere Leute bei uns.

00:50:15: Und trotzdem wollen wir natürlich Leute über uns haben die von allem schon mal zumindest eine Idee haben und sich dann die Hilfe holen können oder aber auch selbst die Sachen umsetzen können ohne jetzt blockiert zu sein.

00:50:27: Und das finde ich fast wichtiger als ein ganzes kostfunktionales Team, finde ich eigentlich wichtig dass man einen Team hat aus Leuten die sich in allen Situationen vielleicht gegenseitig helfen können.

00:50:38: Genau und vor allem auch wissen wo sie die Expertise herbekommen wenn sie mal welche brauchen.

00:50:41: also man muss ja nicht die ganze Zeit ein Designer danebensitzen haben, wenn man weiß wo man auf kurzem Dienstweg an einen dran kommt und dann wirklich mal was zu fragen.

00:50:49: Genau wichtig!

00:50:50: Und

00:50:50: das ist glaube ich schon das Wichtigste dass die Leute wissen an wen sie sich wenden können wenn sie halt irgendwelche Expertise brauchen.

00:50:56: Genau nicht erwarte von unseren Leuten eben auch dass mein Design weiter denken kann.

00:51:00: ganz klassisches Beispiel Designer...nei ich werde jetzt nicht so sehr auf Design rumhaken ich mach's nochmal anders an.

00:51:07: Ich sag immer einem Kunden uns reicht ein Design von der Startseite von der Website.

00:51:11: also wenn ich das Startseitendesign hab Da sind oft ja viele Elemente drauf, da wird der Stil von der Website klar.

00:51:16: Da werden die Farben von der Webseite klar und dann wird die Schrift all klar und so weiter und sofort.

00:51:21: Und wenn ich eine Start-Seite habe kann ich daraus auch oft eine Content Unterseite in einem Blog-Seit oder sowas eigentlich nennen und extrapolieren.

00:51:29: Ich weiß gar nicht.

00:51:29: Ja also jedenfalls kann ich mir dann auf Basis dieser Start-Site überlegen wie müsste jetzt ein Blog-Side aussehen?

00:51:36: Und dafür muss ich jetzt kein Wahnsinns Designer sein um den Stil letztlich weiterzudenken.

00:51:40: Und das sind so Sachen, die erwarte ich eigentlich von den Leuten bei uns und das finde ich so ein bisschen gehört zu dem Anspruch.

00:51:46: So ein bisschen dieser crossfunktional Entwickler vielleicht zu sein.

00:51:49: Vielleicht

00:51:49: sitzen wir da ja ein bisschen im goldenen Turm weil wir coole Projekte und coole Menschen haben wo es so einfach geht.

00:51:54: Wenn wir jetzt natürlich auch so einen Riesenprojekt hätten, wo man irgendwie zehn Leute über ein Jahr beschäftigen muss oder zehn Jahre beschäftigen müssen dann hat man da vielleicht ganz andere Anforderungen was das Team eigentlich aus sich heraus mitbringen muss als wie wir das hier alles ein bisschen Freestyle mehr oder weniger.

00:52:10: Ich hab mich gefreut, dass wir nichts gedoppelt haben Felix.

00:52:12: Das ist mein großer Erfolg des Abends und wenn ich hier so rauskucke dann glaube ich auch wie man bei mir den Sonnenaufgang jetzt bewundern kann.

00:52:19: also wir haben ja angefangen

00:52:21: in

00:52:21: tiefschwarzer Nacht und jetzt scheint mir die Sonne ins Gesicht.

00:52:24: also man könnte meinen es ist morgens um vier aber ist es nicht.

00:52:28: und Ja das klingt ein bisschen nach Feierabend.

00:52:32: Ja ich fand's auch ganz spannend Kai.

00:52:35: Und das Beste ist natürlich, dass die Lisa endlich mal knackige Kapitelmarken machen kann.

00:52:40: Weil wir hier im Prinzip sechs Themen haben, die wir nacheinander abgearbeitet haben und da können sich schöne Überschriften drauf schreiben.

00:52:46: Das fällt uns bei anderen Folgen mit unter schwer weil wir so sehr zwischen den Themen dann springen.

00:52:52: Und hier ist es glaube ich mal ganz schön umzusetzen.

00:52:54: Großartig Felix hat mich gefreut wie immer, dass du da bist und ich jetzt ... Ich wollte deswegen Namen sagen, schon wieder alles, wie ihr vergessen, das Jagd-Sieb-Prinzip!

00:53:03: Ich jag nie Kai, du musst es dir auch merken.

00:53:05: Jag nie!

00:53:06: Ah!

00:53:07: Kai ich wünsche dir noch einen schönen späten Feierabend.

00:53:11: Ja

00:53:11: danke

00:53:12: und wir hören uns morgen in aller Frische.

00:53:14: Ja bis morgen.

00:53:15: Tschüss.

00:53:16: Mach's gut tschau tschaus.

Neuer Kommentar

Dein Name oder Pseudonym (wird öffentlich angezeigt)
Mindestens 10 Zeichen
Durch das Abschicken des Formulars stimmst du zu, dass der Wert unter "Name oder Pseudonym" gespeichert wird und öffentlich angezeigt werden kann. Wir speichern keine IP-Adressen oder andere personenbezogene Daten. Die Nutzung deines echten Namens ist freiwillig.