Ganz normaler Vorgang. Ich steigere mich auch gern in Dinge die mich begeistern. Man sollte von Zeit zur Zeit immer das gelernte und angewandte zu reflektieren. Die Mitte machts :) Als ich noch in den Anfängen der Softwareentwicklung stand, habe ich auch versucht alles "perfekt" zu machen. Versucht viel zu lernen, das gelernte "perfekt" umzusetzen usw. Irgendwann hat es keinen Spaß mehr gemacht und ich schien mehr Verwirrt zu sein, als besser zu werden. Da habe ich angefangen das ganze zu hinterfragen, ich verstand das die ganzen Informationen lediglich empfohlene Richtlinien zu bestimmten Sachverhalten darstellt und man kann einfach nicht alles umsetzen. Also versuchte ich nicht mehr alles perfekt umzusetzen, sondern habe immer wieder ausprobiert, refactoring gemacht und für mich eben den empfohlenen Weg gefunden. Heute habe ich mich an ein älteres Projekt von mir hingesetzt und habe angefangen die alten Bugs zu beheben. Den Code würde ich heute so nicht mehr schreiben ABER! die Bugs zu beheben und den Code zu erweitern war gar nicht schwer. Der Bug ist weg, umgeschrieben habe ich nichts und bestimmt, so muss es halt laufen. Separation of Concerns sei Dank 😄
ich würde mir bei uns mehr Perfektion wünschen da eher durch eingeschränktem Budget und Zeit die Qualität leidet und es eher darum geht schnellst möglich funktionierende Software an den Kunden auszuliefern. Reift dann beim Kunden...🫣 da bleibt der Spaß dann auch auf der Strecke wenn man seinen Beruf nicht profesionell in bester Qualität ausleben kann und weiß dass es besser geht aber man kann/darf nicht.
Kommt aber auch auf die Art an, wie man diese Optimierungen angeht. Wenn man bei der Softwareentwicklung vernünftig in Richtung Geschwindigkeit optimiert, dann steigt in der Regel auch die Qualität. Um das mal zu konkretisieren: Manuelles Deployment dauert lange -> man richtet einen automatisierten Deployment-Prozess ein. Man verbringt zu viel Zeit mit manuellen Tests und/oder Bugfixing -> man fängt an automatisierte Tests zu schreiben, um die meisten Fehler früh abzufangen. Das schreiben der Tests ist zu aufwendig -> man strukturiert den Code besser (erlaubt einfacheres Testing) und lernt bessere Tests zu schreiben. Code reviews dauern zu lange und es gibt immer wieder zu viele Änderungswünsche -> man entwickelt mehr im Pair (erspart den nachfolgenden Code-Review meist vollständig) und entwickelt die Features in kleineren Abschnitten (zum Beispiel mit Einführung von Feature-Flags). Plötzlich hat man mehrmals täglich kleine, gut getestete merges mit jeweils kleinem impact und damit einen permanenten Value-Stream. Features werden plötzlich nicht mehr monatlich oder wöchentlich, sondern sogar täglich deployed. Die sind dann zwar für gewöhnlich noch nicht ganz fertig, aber die Anwender können schon sehr früh ihr Feedback geben und Änderungen können umgesetzt werden, bevor man gegebenenfalls zu weit in die falsche Richtung gebaut hat. Man muss sich darauf einlassen und es muss auch von allen vernünftig verstanden werden, aber wer mal so gearbeitet hat, möchte es erfahrungsgemäß nicht mehr anders haben. Wir haben damit schon Projekte in einem Bruchteil der Zeit umgesetzt und dabei gleichzeitig eine deutlich höhere Qualität erreicht, als wenn wir alles von Anfang an durchgeplant hatten. Natürlich setzt das aber auch eine recht hohe Erfahrung in der Softwareentwicklung (und idealerweise zumindest deren wichtigsten Pattern sowie wann und wo diese eingesetzt werden sollten) voraus. Ich kann es nur empfehlen das mal so auszuprobieren :)
"Das Bessere ist der Feind des Guten" (Voltaire). Das bestätigt sich immer wieder. Gewohnheiten sind mächtig. Wenn man das sich verbessern zur Gewohnheit macht, landet man beim Perfektionismus. Manchmal muss man den richtigen Zeitpunkt finden auszusteigen. Immer wieder die 80:20 Regel im Auge behalten.
hallo im schönen Dresden! Erstmal Danke für deine Videos; sie sind informativ und, besonders die Naturaufnahmen, nett zu schauen. Ich selbst bin Maschinenprogrammierer (also SPS mit Siemens oder Beckhoff), habe aber gerade durch deine Videos meine Sichtweise auf meine Arbeit stark überdacht: ich fahre diese Woche zum Kunden und muss aus den teils wilden Ideen mit dem Kunden ein Konzept erarbeiten. Und genau da ist mir aufgegangen wie wichtig die Unterscheidung zwischen Vision, Anforderung, Architektur, etc. sind! Ich hoffe deshalb, dass ich durch deinen Input meine Rolle nun besser und effektiver erfüllen kann. Mal schauen, vielleicht habe ich fürs nächste Video schon eine Antwort ✌️
Hey Marcel, schön - das freut mich sehr! Das ist auch Softwareentwicklung, nur halt auf einer anderen Plattform. Bin gespannt wie es gelaufen ist, halt uns mal auf den laufenden! Gruß David
@@DavidTielke Hallo David, ich bin nun zurück aus München und habe viele interessante Erkenntnisse mitgebracht: Vorbereitend für das Brainstorming hatten alle Stichpunkte geliefert die diskutiert werden sollten. Vor Ort haben wir uns nen gemütlichen Raum gesucht und erstmal alle Punkte aufgelistet. Anschließend hat jedes Thema eine Whiteboardseite bekommen, wo sämtliche Anforderungen notiert und in Verbindung gebracht wurden. Da dies aus der allg. Sicht des/der Bediener und der Handhabung heraus passierte sind selbst "einfache" Themen wie User Management schnell eskaliert und haben Anforderungen aufgezeigt an die ich vorher nie gedacht hatte. Nun besteht meine Aufgabe die gesammelten Anforderungen in eine geeignete Struktur zu gießen... mir grauts davor, aber ich sehe auch, dass ich diesmal tatsächlich die Chance habe eine ordentliche, wartbare und v.a. erweiterbare Maschine programmieren zu können. Ich hoffe nur, dass ich die, die für mich neue, Rolle des SW-Architekten gut genug umsetzen kann bevor ich wieder in die Rolle des Entwicklers zurück falle ✌️😅
Finde man muss hier klar unterscheiden. Den Prozess zu sehr zu perfektionieren kann nach hinten los gehen wie du schon sagst. Den Code versuchen zu optimieren sollte man schon zumindest versuchen, allerdings auch nicht ewig damit aufhalten.
Ich bin der derzeit einzige Programmierer in einem Start-up. Die Software ist komplementär zu ausgelieferter Hardware. Bis jetzt, zum Ende der Prototyp-Phase, habe ich einen 80-20-Ansatz gefahren, das heißt, die essentiellen (und oft auch schnellsten) 80 % eines Features setze ich um, und dann schaue ich kritisch auf die Arbeit und die Zeit, die mir zur Verfügung steht, ob ich die letzten 20 % (die bekanntermaßen auch gern nochmal so viel Zeit kosten wie die 80 % vorher) jetzt, oder überhaupt, wirklich nötig sind. Wenn nicht, kommt das nächste Feature (oder sonstige Aufgabe, Software ist ja nicht das einzige, das ich mache). Nach einiger Zeit nehme ich mir dann auch etwas Zeit, um die "übrigen" Inhalte zu priorisieren und etwas davon abzuarbeiten. Bald bekomme ich dann einen Studenten, der es mir hoffentlich irgendwann einmal erlaubt, da weniger Inhalte liegen lassen zu müssen.
Könntest du das Thema Zeiteinschätzung für Aufgaben/Projekte behandeln? Was sind realistische Zeitangaben? Ich habe da Probleme mit weil mein Teamleiter meint ich brauche zu lange und das geht ja viel schneller. Bei mir ist die Ordentlichkeit sehr wichtig und dann brauch ich zb fürs planen länger als die anderen. Liebe geht raus❤
Ich nehm echt viel mit aus deinen Videos. Da ich Scrum bei uns einführe, kam ich auf deinen Kanal. Nach 3 Monaten geht es jetzt so ziemlich in Richtung Besserung. Das Beispiel, wo du zeigst, dass Scrum sich an das Unternehmen anpasst...da sind wir gerade dabei =D
was für ein witziger Zufall, ich bin Mitte April in Dresden, komme gebürtig auch aus dem Sauerland, lebe aber mittlerweile in Köln Zum Thema: ich hab das Gefühl, dass es in allen Bereichen des Lebens so sein kann, wie du beschreibst. Retros sind echt richtig und wichtig, aber der schmale grad, es nicht zu übertreiben, dass klassische "overthinking", man kennt's!
Ich finde eine gute Regel dazu ist KISS. Immer wenn ich Verbesserungen find, die den Code komplizierter macht, höre ich auf. Weil es muss ja vielleicht ich oder jemand anderes später den Code für ein neues Feature anpassen. Am Anfang hatte ich häufiger Code hatte, der so komplex war, dass Änderungen ein Horror waren.
Hey, ja für den Quellcode ist das ein guter Anfang, allerdings gibt es ja noch viel mehr (Prozesse, Architekturen, Infrastrukturen. etc.) - da wird es dann etwas schwieriger. Gruß David
Was mir fehlt ist ein konkretes Hands On zu Thema XY. Ich finde sehr viele Videos zur Theorie, aber wie ich dann wirklich Praktisch ein Clean Architecture Modulith in Typescript/Go/... baue gibt es gefühlt nicht. Und da hängt es bei mir noch. Wie strukturiere ich meinen Code (Ordner Struktur). Wie schreibt man einen Use case. Das kommt bei mir nicht mit der Theorie über ein.
Loslassen zu können ist für mich eine sehr Unterschätzte Eigenschaft. Als Beispiel Blender, Blender hatte eine schreckliche UI, aber man hat sich dazu entschieden das alles zu entfernen und eine neue zu bauen. Anderes Blender Beispiel Blender hatte eine Game engine integriert, man hat sich ihrgentwann dazu entschieden sie Komplet aus Blender zu entfernen. Auf jeden fahl führte diese Entscheidungen, dass Blender fast zum Industrie Standert wurde im 3D Bereich. Worauf ich eigentlich hinaus wollte ist, selbst wenn man was "falsch" macht, weiß man es häufig erst im Nachhinein. Dann braucht es Mut um das alte fallenlassen und neu anzufangen. Weil Perfektion kommt nicht aus dem nicht sondern aus einen interaktiven Prozess des versuchen und scheitern.
Ach ja, könntest du bitte ein Video darüber machen welche Kriterien eine gute Anforderung (laut Scrum) ausmacht und wie man von der Vision zur Anforderung kommt? Das wäre extrem hilfreich! 😁
Habe ich schon auf der Liste, gibt aber schon eine ganze Playlist mit vielen Videos zu Anforderungen, schau mal ob da schon was passendes bei ist. Gruß David
Kann man auch andersrum sehen. 80% aller Maßnahmen in einem Unternehmen scheitern, und aus den unterschiedlichsten Gründen. Sollte man deswegen keine Maßnahmen mehr anfangen, und sich nur auf 5 konzentrieren, auch wenn diese zwischendurch ihren Impact oder die Relevanz verlieren können? Deswegen glaube ich, dass dieses “Fokussieren” oder “Priorisieren” wenig Wert hat, denn die wirklich relevanten Themen setzen sich meist durch, und dass sind dann die 20% der Maßnahmen, die nicht hinter den Erwartungen zurück bleiben. Was bedeutet auch “fertig” in dem Kontext? Ich habe letztens gehört, dass jemand meinte in der Vergangenheit hätte man seine Ziele immer nur zu 80% erreicht… und ich dachte mir “Mega, in OKR wär das ja jedesmal leicht überm Sweet Spot” Grundsätzlich ist aber die Kunden- bzw Nutetzentrierung das entscheidende Thema, wenn man die aus dem Blick verliert spielt man sich schnell selbst am Bauchnabel 😂 und da muss ichsagen, wenn das Team die Nutzer/den Stakeholder aus den Augen verloren hat ist son bisschen der PO in der Verantwortung, oder?
Hey, hier Punkt - es geht hier aber nicht darum, sich auf 5 Maßnahmen zu beschränken, sondern auf 5 Punkte die optimiert werden sollen - es können auch 100 Maßnahmen sein, solange alle auf diese 5 Punkte einzahlen. Gruß David
@@DavidTielke ah verstehe, “Punkte” sind dann eher so übergeordnete strategische oder Qualitätsziele oder bestimmte KPIs? Also z.B. change/defect ratio, average lead time etc?
Reicht für die Videoaufnahme nicht ein hochpreisiges Smartphone? Dazu eine kleine Lampe und ein Ansteckmikro. Ich schaue mir genug Videos von RUclipsrn an die sich mit dem Handy filmen und ich bin dort auch immer zufrieden.
Hey Robert, ja - das reicht absolut, wie in dem angesprochenen Video zu KI - die war vergleichen mit meinem "normalen" Equipment sehr günstig, aber mir ist die Qualität einfach nicht ausreichend. Das ist ja genau meine Erkenntnis, ich habe irgendwann die Videos so optimiert, das sie primär mir gefallen haben und viele Optimierungen nicht dem Hauptziel gewidmet waren, sondern meinen persönlichen Nebenschauplätzen. Gruß David
Ja, das Problem der Überoptimierung von Nebenschauplätzen kenne ich leider auch zu gut. Ein Problem ist aber leider auch, wenn man einen Chef hat, der genau so einen unnötigen Perfektionismus bei völlig überflüssigen oder "Nice-to-Have"-Projekten fordert, der für die eigentliche Zielgruppe einfach keinen Mehrwert mehr liefert.
Könntest du mal ein video machen zum thema structured logging. Wie man effizient logs in den code einfügt, um fehler zu finden, die z.b. beim Kunden zur Lauzeit auftreten. Mit Hinweisen zu logstrategien etc.
Man sollte lernen, mit einer Sache auch mal zufrieden zu sein, anstatt ständig optimieren zu wollen. Ständige Optimierung ist ein sicherer Garant für Unzufriedenheit.
@@DavidTielkeUnd was soll das richtige Maß sein? Denkst Du nicht das ständige Effizienz und Optimierung in egal welchem Bereich nicht maßgeblich für Unzufriedenheit und Depressionen sorgt? Was ist mit den Daten der letzten Jahrzehnte bezüglich dessen?
Softwareentwicklung lebt von Trade-Offs. Meiner Erfahrung nach fängt Professionalität dann an, wenn mehrere Optionen gesehen und abgewogen werden, statt "die eine perfekte" Lösung zu finden und umzusetzen.
Ich mag Deine Videoqualität sehr, finde es aber Overkill, zu einem Kundentermin den ganzen Krempel mitzuschleppen. Ich hätte überhaupt nichts dagegen, dass die "Unterwegs-Videos" nicht so perfekt sind. Man könnte am Anfang kurz erwähnen, dass die Folge reduziert produziert ist und auf ein Erklärungsvideo verlinken. Wie Du schon sagst, geht es um dem Inhalt, nicht um Schönheit. Es wird Dir wohl keiner den Kopf abreißen, wenn 1 von 10 Videos nicht optimal ausgeleuchtet ist.
zu viel des Guten ist seehr schwer zu finden/definieren. Viele Aspekte zahlen nicht direkt sondern indirekt oder eben erst später ein. Von dem du redest nennt sich in meinen Ohren „Qualität“. Qualität ist halt auch ein schlimmes Wort was von jedem anders verstanden, betrachtet und interpretiert wird.
![ROSÉ (로제) - number one girl [더 시즌즈-이영지의 레인보우] | KBS 241129 방송](http://i.ytimg.com/vi/A9oByH9Ci24/mqdefault.jpg)
Ganz normaler Vorgang. Ich steigere mich auch gern in Dinge die mich begeistern. Man sollte von Zeit zur Zeit immer das gelernte und angewandte zu reflektieren. Die Mitte machts :)
Als ich noch in den Anfängen der Softwareentwicklung stand, habe ich auch versucht alles "perfekt" zu machen. Versucht viel zu lernen, das gelernte "perfekt" umzusetzen usw. Irgendwann hat es keinen Spaß mehr gemacht und ich schien mehr Verwirrt zu sein, als besser zu werden. Da habe ich angefangen das ganze zu hinterfragen, ich verstand das die ganzen Informationen lediglich empfohlene Richtlinien zu bestimmten Sachverhalten darstellt und man kann einfach nicht alles umsetzen. Also versuchte ich nicht mehr alles perfekt umzusetzen, sondern habe immer wieder ausprobiert, refactoring gemacht und für mich eben den empfohlenen Weg gefunden.
Heute habe ich mich an ein älteres Projekt von mir hingesetzt und habe angefangen die alten Bugs zu beheben. Den Code würde ich heute so nicht mehr schreiben ABER! die Bugs zu beheben und den Code zu erweitern war gar nicht schwer. Der Bug ist weg, umgeschrieben habe ich nichts und bestimmt, so muss es halt laufen. Separation of Concerns sei Dank 😄
So sieht es aus, genau das ärgert nicht an "meinem Fehler", das ich das nicht erkannt habe :)
Gruß David
ich würde mir bei uns mehr Perfektion wünschen da eher durch eingeschränktem Budget und Zeit die Qualität leidet und es eher darum geht schnellst möglich funktionierende Software an den Kunden auszuliefern. Reift dann beim Kunden...🫣 da bleibt der Spaß dann auch auf der Strecke wenn man seinen Beruf nicht profesionell in bester Qualität ausleben kann und weiß dass es besser geht aber man kann/darf nicht.
Absolut, gibt meist ist eher das Gegenteil, das zu wenig verbessert wird... Aber da ist der Fehler ja offensichtlich :)
Gruß David
Kommt aber auch auf die Art an, wie man diese Optimierungen angeht.
Wenn man bei der Softwareentwicklung vernünftig in Richtung Geschwindigkeit optimiert, dann steigt in der Regel auch die Qualität.
Um das mal zu konkretisieren:
Manuelles Deployment dauert lange -> man richtet einen automatisierten Deployment-Prozess ein.
Man verbringt zu viel Zeit mit manuellen Tests und/oder Bugfixing -> man fängt an automatisierte Tests zu schreiben, um die meisten Fehler früh abzufangen.
Das schreiben der Tests ist zu aufwendig -> man strukturiert den Code besser (erlaubt einfacheres Testing) und lernt bessere Tests zu schreiben.
Code reviews dauern zu lange und es gibt immer wieder zu viele Änderungswünsche -> man entwickelt mehr im Pair (erspart den nachfolgenden Code-Review meist vollständig) und entwickelt die Features in kleineren Abschnitten (zum Beispiel mit Einführung von Feature-Flags).
Plötzlich hat man mehrmals täglich kleine, gut getestete merges mit jeweils kleinem impact und damit einen permanenten Value-Stream.
Features werden plötzlich nicht mehr monatlich oder wöchentlich, sondern sogar täglich deployed. Die sind dann zwar für gewöhnlich noch nicht ganz fertig, aber die Anwender können schon sehr früh ihr Feedback geben und Änderungen können umgesetzt werden, bevor man gegebenenfalls zu weit in die falsche Richtung gebaut hat.
Man muss sich darauf einlassen und es muss auch von allen vernünftig verstanden werden, aber wer mal so gearbeitet hat, möchte es erfahrungsgemäß nicht mehr anders haben.
Wir haben damit schon Projekte in einem Bruchteil der Zeit umgesetzt und dabei gleichzeitig eine deutlich höhere Qualität erreicht, als wenn wir alles von Anfang an durchgeplant hatten.
Natürlich setzt das aber auch eine recht hohe Erfahrung in der Softwareentwicklung (und idealerweise zumindest deren wichtigsten Pattern sowie wann und wo diese eingesetzt werden sollten) voraus.
Ich kann es nur empfehlen das mal so auszuprobieren :)
"Das Bessere ist der Feind des Guten" (Voltaire). Das bestätigt sich immer wieder. Gewohnheiten sind mächtig. Wenn man das sich verbessern zur Gewohnheit macht, landet man beim Perfektionismus. Manchmal muss man den richtigen Zeitpunkt finden auszusteigen. Immer wieder die 80:20 Regel im Auge behalten.
Hey,
super Zitat, das hätte ich vor dem Video gebraucht - trotzdem Danke :)
Gruß David
hallo im schönen Dresden!
Erstmal Danke für deine Videos; sie sind informativ und, besonders die Naturaufnahmen, nett zu schauen.
Ich selbst bin Maschinenprogrammierer (also SPS mit Siemens oder Beckhoff), habe aber gerade durch deine Videos meine Sichtweise auf meine Arbeit stark überdacht: ich fahre diese Woche zum Kunden und muss aus den teils wilden Ideen mit dem Kunden ein Konzept erarbeiten. Und genau da ist mir aufgegangen wie wichtig die Unterscheidung zwischen Vision, Anforderung, Architektur, etc. sind! Ich hoffe deshalb, dass ich durch deinen Input meine Rolle nun besser und effektiver erfüllen kann. Mal schauen, vielleicht habe ich fürs nächste Video schon eine Antwort ✌️
Hey Marcel, schön - das freut mich sehr! Das ist auch Softwareentwicklung, nur halt auf einer anderen Plattform. Bin gespannt wie es gelaufen ist, halt uns mal auf den laufenden!
Gruß David
@@DavidTielke Hallo David,
ich bin nun zurück aus München und habe viele interessante Erkenntnisse mitgebracht:
Vorbereitend für das Brainstorming hatten alle Stichpunkte geliefert die diskutiert werden sollten. Vor Ort haben wir uns nen gemütlichen Raum gesucht und erstmal alle Punkte aufgelistet. Anschließend hat jedes Thema eine Whiteboardseite bekommen, wo sämtliche Anforderungen notiert und in Verbindung gebracht wurden. Da dies aus der allg. Sicht des/der Bediener und der Handhabung heraus passierte sind selbst "einfache" Themen wie User Management schnell eskaliert und haben Anforderungen aufgezeigt an die ich vorher nie gedacht hatte.
Nun besteht meine Aufgabe die gesammelten Anforderungen in eine geeignete Struktur zu gießen... mir grauts davor, aber ich sehe auch, dass ich diesmal tatsächlich die Chance habe eine ordentliche, wartbare und v.a. erweiterbare Maschine programmieren zu können.
Ich hoffe nur, dass ich die, die für mich neue, Rolle des SW-Architekten gut genug umsetzen kann bevor ich wieder in die Rolle des Entwicklers zurück falle ✌️😅
Finde man muss hier klar unterscheiden. Den Prozess zu sehr zu perfektionieren kann nach hinten los gehen wie du schon sagst. Den Code versuchen zu optimieren sollte man schon zumindest versuchen, allerdings auch nicht ewig damit aufhalten.
Der Code und die Architektur kann ganz klar auch überoptimiert werden, sehr schnell sogar, Stichwort KISS und YAGNI :)
Gruß David
Ich bin der derzeit einzige Programmierer in einem Start-up. Die Software ist komplementär zu ausgelieferter Hardware. Bis jetzt, zum Ende der Prototyp-Phase, habe ich einen 80-20-Ansatz gefahren, das heißt, die essentiellen (und oft auch schnellsten) 80 % eines Features setze ich um, und dann schaue ich kritisch auf die Arbeit und die Zeit, die mir zur Verfügung steht, ob ich die letzten 20 % (die bekanntermaßen auch gern nochmal so viel Zeit kosten wie die 80 % vorher) jetzt, oder überhaupt, wirklich nötig sind. Wenn nicht, kommt das nächste Feature (oder sonstige Aufgabe, Software ist ja nicht das einzige, das ich mache). Nach einiger Zeit nehme ich mir dann auch etwas Zeit, um die "übrigen" Inhalte zu priorisieren und etwas davon abzuarbeiten.
Bald bekomme ich dann einen Studenten, der es mir hoffentlich irgendwann einmal erlaubt, da weniger Inhalte liegen lassen zu müssen.
Könntest du das Thema Zeiteinschätzung für Aufgaben/Projekte behandeln? Was sind realistische Zeitangaben? Ich habe da Probleme mit weil mein Teamleiter meint ich brauche zu lange und das geht ja viel schneller. Bei mir ist die Ordentlichkeit sehr wichtig und dann brauch ich zb fürs planen länger als die anderen.
Liebe geht raus❤
Ich nehm echt viel mit aus deinen Videos. Da ich Scrum bei uns einführe, kam ich auf deinen Kanal. Nach 3 Monaten geht es jetzt so ziemlich in Richtung Besserung. Das Beispiel, wo du zeigst, dass Scrum sich an das Unternehmen anpasst...da sind wir gerade dabei =D
Hey,
sehr schön, das freut mich. Wenn Du diese Anpassung selbst schon merkst, seid ihr auf einem guten Weg - Glückwunsch!
Gruß David
was für ein witziger Zufall, ich bin Mitte April in Dresden, komme gebürtig auch aus dem Sauerland, lebe aber mittlerweile in Köln
Zum Thema:
ich hab das Gefühl, dass es in allen Bereichen des Lebens so sein kann, wie du beschreibst. Retros sind echt richtig und wichtig, aber der schmale grad, es nicht zu übertreiben, dass klassische "overthinking", man kennt's!
vielleicht hilft dabei ja die viel gepriesene 5W-Methode: 5 mal "Warum" fragen, dann kommt man doch recht schnell aus diesem Fokusdenken raus
Sehr cool, wieder kommst du denn?
Gruß David
Ich finde eine gute Regel dazu ist KISS. Immer wenn ich Verbesserungen find, die den Code komplizierter macht, höre ich auf.
Weil es muss ja vielleicht ich oder jemand anderes später den Code für ein neues Feature anpassen.
Am Anfang hatte ich häufiger Code hatte, der so komplex war, dass Änderungen ein Horror waren.
Hey, ja für den Quellcode ist das ein guter Anfang, allerdings gibt es ja noch viel mehr (Prozesse, Architekturen, Infrastrukturen. etc.) - da wird es dann etwas schwieriger.
Gruß David
Was mir fehlt ist ein konkretes Hands On zu Thema XY. Ich finde sehr viele Videos zur Theorie, aber wie ich dann wirklich Praktisch ein Clean Architecture Modulith in Typescript/Go/... baue gibt es gefühlt nicht. Und da hängt es bei mir noch. Wie strukturiere ich meinen Code (Ordner Struktur). Wie schreibt man einen Use case. Das kommt bei mir nicht mit der Theorie über ein.
Loslassen zu können ist für mich eine sehr Unterschätzte Eigenschaft.
Als Beispiel Blender, Blender hatte eine schreckliche UI, aber man hat sich dazu entschieden das alles zu entfernen und eine neue zu bauen.
Anderes Blender Beispiel Blender hatte eine Game engine integriert, man hat sich ihrgentwann dazu entschieden sie Komplet aus Blender zu entfernen. Auf jeden fahl führte diese Entscheidungen, dass Blender fast zum Industrie Standert wurde im 3D Bereich.
Worauf ich eigentlich hinaus wollte ist, selbst wenn man was "falsch" macht, weiß man es häufig erst im Nachhinein.
Dann braucht es Mut um das alte fallenlassen und neu anzufangen.
Weil Perfektion kommt nicht aus dem nicht sondern aus einen interaktiven Prozess des versuchen und scheitern.
Hey,
mega Beispiel mit Blender, passt wirklich sehr gut!
Gruß David
Höre deine Videos meist nur an tbh 😃
Der Schlag sitzt tief... :D
Gruß David
Ach ja, könntest du bitte ein Video darüber machen welche Kriterien eine gute Anforderung (laut Scrum) ausmacht und wie man von der Vision zur Anforderung kommt? Das wäre extrem hilfreich! 😁
Habe ich schon auf der Liste, gibt aber schon eine ganze Playlist mit vielen Videos zu Anforderungen, schau mal ob da schon was passendes bei ist.
Gruß David
Kann man auch andersrum sehen. 80% aller Maßnahmen in einem Unternehmen scheitern, und aus den unterschiedlichsten Gründen. Sollte man deswegen keine Maßnahmen mehr anfangen, und sich nur auf 5 konzentrieren, auch wenn diese zwischendurch ihren Impact oder die Relevanz verlieren können? Deswegen glaube ich, dass dieses “Fokussieren” oder “Priorisieren” wenig Wert hat, denn die wirklich relevanten Themen setzen sich meist durch, und dass sind dann die 20% der Maßnahmen, die nicht hinter den Erwartungen zurück bleiben. Was bedeutet auch “fertig” in dem Kontext? Ich habe letztens gehört, dass jemand meinte in der Vergangenheit hätte man seine Ziele immer nur zu 80% erreicht… und ich dachte mir “Mega, in OKR wär das ja jedesmal leicht überm Sweet Spot” Grundsätzlich ist aber die Kunden- bzw Nutetzentrierung das entscheidende Thema, wenn man die aus dem Blick verliert spielt man sich schnell selbst am Bauchnabel 😂 und da muss ichsagen, wenn das Team die Nutzer/den Stakeholder aus den Augen verloren hat ist son bisschen der PO in der Verantwortung, oder?
Hey, hier Punkt - es geht hier aber nicht darum, sich auf 5 Maßnahmen zu beschränken, sondern auf 5 Punkte die optimiert werden sollen - es können auch 100 Maßnahmen sein, solange alle auf diese 5 Punkte einzahlen.
Gruß David
@@DavidTielke ah verstehe, “Punkte” sind dann eher so übergeordnete strategische oder Qualitätsziele oder bestimmte KPIs? Also z.B. change/defect ratio, average lead time etc?
Reicht für die Videoaufnahme nicht ein hochpreisiges Smartphone? Dazu eine kleine Lampe und ein Ansteckmikro. Ich schaue mir genug Videos von RUclipsrn an die sich mit dem Handy filmen und ich bin dort auch immer zufrieden.
Hey Robert, ja - das reicht absolut, wie in dem angesprochenen Video zu KI - die war vergleichen mit meinem "normalen" Equipment sehr günstig, aber mir ist die Qualität einfach nicht ausreichend. Das ist ja genau meine Erkenntnis, ich habe irgendwann die Videos so optimiert, das sie primär mir gefallen haben und viele Optimierungen nicht dem Hauptziel gewidmet waren, sondern meinen persönlichen Nebenschauplätzen.
Gruß David
"Er stirbt in Perfektion". Der Spruch fällt mir gerade ein. Aber Du hast vollkommen Recht, ich tappe immer wieder in diese Falle. VG.
Ja, das Problem der Überoptimierung von Nebenschauplätzen kenne ich leider auch zu gut. Ein Problem ist aber leider auch, wenn man einen Chef hat, der genau so einen unnötigen Perfektionismus bei völlig überflüssigen oder "Nice-to-Have"-Projekten fordert, der für die eigentliche Zielgruppe einfach keinen Mehrwert mehr liefert.
Ja, ich denke das Problem zieht sich durch alle Hierarchieebenen :)
Gruß David
Könntest du mal ein video machen zum thema structured logging. Wie man effizient logs in den code einfügt, um fehler zu finden, die z.b. beim Kunden zur Lauzeit auftreten. Mit Hinweisen zu logstrategien etc.
Man sollte lernen, mit einer Sache auch mal zufrieden zu sein, anstatt ständig optimieren zu wollen. Ständige Optimierung ist ein sicherer Garant für Unzufriedenheit.
Jain, ich denke wenn Optimierung mit dem richtigen Maß durchgeführt wird, kann auch ständige Optimierung grundsätzlich gut sein :)
Gruß David
@@DavidTielkeUnd was soll das richtige Maß sein? Denkst Du nicht das ständige Effizienz und Optimierung in egal welchem Bereich nicht maßgeblich für Unzufriedenheit und Depressionen sorgt? Was ist mit den Daten der letzten Jahrzehnte bezüglich dessen?
Kunst isr dran den Goldenen Mitte zu finden
Wenn die Lösung das Problem ist.
So ist es :)
@@DavidTielke - Es gibt hierzu einen gleichnamigen Fachvortrag von Paul Watzlawik hier auf RUclips - von 1987.
Softwareentwicklung lebt von Trade-Offs. Meiner Erfahrung nach fängt Professionalität dann an, wenn mehrere Optionen gesehen und abgewogen werden, statt "die eine perfekte" Lösung zu finden und umzusetzen.
Grüße aus Dresden! :D
Maß und Mitte!! :)
Das warum es bei dir Passirt ist der Grund warum du als fremder gebucht wirst. Für solche Aufgaben
Ich höre nur mit Knopf im Ohr, Bild ist egal 😂
Interessant, ich mache einfach nur noch Podcasts :D
Ich mag Deine Videoqualität sehr, finde es aber Overkill, zu einem Kundentermin den ganzen Krempel mitzuschleppen. Ich hätte überhaupt nichts dagegen, dass die "Unterwegs-Videos" nicht so perfekt sind. Man könnte am Anfang kurz erwähnen, dass die Folge reduziert produziert ist und auf ein Erklärungsvideo verlinken. Wie Du schon sagst, geht es um dem Inhalt, nicht um Schönheit. Es wird Dir wohl keiner den Kopf abreißen, wenn 1 von 10 Videos nicht optimal ausgeleuchtet ist.
Perfektion? Wenn mal alle gut debuggen könnten und gut dokumentieren....
zu viel des Guten ist seehr schwer zu finden/definieren. Viele Aspekte zahlen nicht direkt sondern indirekt oder eben erst später ein. Von dem du redest nennt sich in meinen Ohren „Qualität“.
Qualität ist halt auch ein schlimmes Wort was von jedem anders verstanden, betrachtet und interpretiert wird.