Der nachfolgende Text wurden mit KI erstellt und kann Fehler enthalten. Fehler gefunden? Bei GitHub editieren

Shorts aus fünf Jahren Stream mit Eberhard, Lisa und Ralf

So, dann herzlich willkommen zu einer weiteren Episode von Software-Architektur im Stream.

Dieses Mal geht es um fünf Jahre Software-Architektur im Stream mit Ralf und Lisa.

Ich weiß gar nicht, ob ihr euch noch vorstellen wollt.

Ich glaube, wir sparen uns die Zeit, oder?

Ja, genau.

Einführung und Danksagungen

Es ist halt erstaunlich, es ist mittlerweile schon fünf Jahre her und ich finde, also mir macht das sehr viel Spaß und ich finde, das ist ein sehr schönes Format.

Und wir haben uns heute vorgenommen, so ein paar Shorts noch mal zu diskutieren.

Wir hatten ja die Shorts auch tatsächlich live gestellt und können hier jetzt sozusagen die live kommentieren.

Dank an Zuschauer

Bevor wir das tun, wollen wir uns alle bedanken bei den Zuschauer:innen.

Einmal fürs Zuschauen und zum anderen auch für das Feedback.

Also tatsächlich gibt es eine überwältigende Menge von positiven Feedback und ich glaube, das wirkt auch für uns alle sehr motivierend.

Vielen Dank dafür und halt auch sozusagen gerne weitermachen an der Stelle, logischerweise.

Und ich glaube, du sagtest es vorhin, Lisa, auch gerne Themen wünschen.

Also wir sind da irgendwie prinzipiell offen und damit muss ich mich halt sozusagen auch gleich, glaube ich, das erste Mal entschuldigen und zwar dafür, dass es also tatsächlich viele Vorschläge gibt und wir haben es halt nicht geschafft, glaube ich, irgendwie alle davon auf die Reihe zu bekommen.

Sorry dafür, aber so ist es bedauerlicherweise.

Dank an das Team

Sonst noch weitere Dinge, also Menschen, für die wir uns bedanken wollen, ist halt Martina.

Martina macht halt wahnsinnig viel hinter den Kulissen, hat auch zum Beispiel die Shorts zusammengebaut und hat dafür gesorgt, dass wir da jetzt eben diese Episode machen können.

Und er war tatsächlich die Person, die zum Beispiel dafür gesorgt hat, dass dann Lisa SketchNuts gemacht hat, weil das war ihr Vorschlag.

Das heißt also, sie ist irgendwie schon seit Ewigkeiten dabei und das hat, glaube ich, wahnsinnig wichtig.

Und bedanken wollen wir uns natürlich auch irgendwie bei den Gästen, die wir bisher hatten.

Und da wollen wir, glaube ich, also ich will auch gleich sozusagen sorry sagen, weil wir haben jetzt eine Stunde, wir haben irgendwelche Gäste ausgesucht, irgendwelche Shorts.

Und das können leider nicht alle sein, weil wir haben irgendwie, ich weiß gar nicht, das hier ist, glaube ich, die Folge mit der Zahl 272, es fehlen einige Zahlen, und mit der Nummer 272.

Und nicht, wenn wir halt irgendwie alle Gäste jetzt irgendwie drin hätten, wäre diese Folge halt ein bisschen sehr lang.

Und genau das ist so erst mal das, was ich am Anfang loswerden wollen würde.

Weiß nicht, Ralf, Lisa, habt ihr noch was, was ihr ergänzen wollen würdet?

Ich freue mich, dass es schon so lange Softwarearchitektur im Stream gibt und ich bin ganz schön fasziniert, dass es echt schon fünf Jahre sind, wenn ich überlege, wie das damals auch angefangen hat.

Jetzt fällt mir auch gerade auf, es wäre super witzig gewesen, hätten wir ein kleines Short noch aus der ersten Folge Softwarearchitektur im Stream.

Das haben wir, glaube ich, nicht mit drin, weil die war ja noch sehr anders als die Folgen.

Ja, und die ist vor allem halt insbesondere verunglückt damals.

Also da gab es halt irgendwie dieses Problem, dass ich halt versucht hatte, irgendwas zu zeichnen.

Und ich hatte dann versucht, das auf meinem iPad zu zeichnen oder live zu übertragen.

Und ich hatte natürlich irgendwie alles ausprobiert, aber dann in der Live-Situation ging es halt schief.

Ja, und ich wollte nochmal Danke sagen, dass ich das Team jetzt hier ergänzen darf, seit kurzer Zeit.

Das ist ja eure Leistung, dass ihr die fünf Jahre zusammengebracht habt.

Daher danke.

Ja, genau, sehr gerne und danke für deine Beteiligung.

Du warst auch schon mehrfach zu Gast vorher und bist dann tatsächlich eine von den Personen, die da eben auch schon vorher ihren Beitrag geleistet hat.

Eberhard, wenn mein kleines Miniskript jetzt richtig ist, haben wir 268 Folgen insgesamt auf der Seite.

Das sind schon ganz schön viele.

268, ja, das ist richtig, genau, das würde ich auch denken, also 4 in 3 Zahlen.

Gut, dann legen wir, glaube ich, mal los, wenn nicht noch weitere Themen sind.

Und genau, wir haben tatsächlich ein Video mit ein paar Shorts und die erste Person, die was sagt, ist Lisa.

Sketch Notes im Stream

Das war eine von den ersten Folgen, wo es halt überraschend ist, dass es um Sketch Notes geht.

Und da können wir uns jetzt mal irgendwie anschauen, was du damals gesagt hast.

Also vielleicht eine Schreibschrift, Großbuchstaben und so weiter.

Und es soll dir helfen, dich besser an Dinge zu erinnern.

Genau, wirklich definiert oder das erste Mal wirklich aufgeschrieben hat es der Mike Rohde.

Entwicklung der Sketch Notes

Der nutzt sogar gar nicht mal so viele Symbole, das finde ich ganz interessant.

Der ist eher so ein textlastiger Mensch, der definiert oder beschreibt in seinem Büchlein drei verschiedene Schriftarten, mit denen er gerne arbeitet.

Und genau, seine Sketch Notes sind eher sehr schriftlastig und weniger symbollastig.

Also jeder Sketch Note hat irgendwie seinen eigenen Stil.

Also eigentlich ist es dazu da, Notizen zu machen, sagst du.

Warum sollte ich das tun?

Folge 23.

Ja, auch eine von den magischen Zahlen, wie man sich vorstellen kann.

Irgendwas, was du dazu noch…

Also und die Sketch Notes sind, glaube ich, ein ganz wichtiger Teil vom Stream, weil die halt eine Zusammenfassung darstellen.

Und wir halt dort die Sachen, ohne dass man sich unbedingt vollständig anhören muss, dann eben nochmal sozusagen eine Zusammenfassung haben.

Und das ist halt auf jeden Fall eine super Sache gewesen.

Wie gesagt, ging letztendlich auf eine Idee von Martina zurück.

Und ich weiß gar nicht, Ralf hat es gerade schon gezeigt.

Es gibt das Buch von dir zu dem Thema.

Ja, witzig.

Nicht schlecht für Eigenwerbung.

Gibt auch einen Workshop zu dem Thema mittlerweile.

Da kriegt man das Buch sogar nach Hause geschickt.

Genau, von deinem Arbeitgeber Sokratori.

Sketch Notes Buch

Und wir haben tatsächlich ja auch ein Buch rausgegeben mit den Sketch Notes aus den Episoden.

Ich wollte jeweils so eine Seite die Sketch Note fahren, dann habe ich nochmal so einen Text zu der Episode geschrieben.

Das fand ich auch so eine ganz nette Sache, fand ich.

Und vielleicht an der Stelle noch ein Hinweis.

Also ein Teil für mich von dem Stream ist halt auch dieses so ein bisschen experimentell.

Also irgendwie Dinge zu tun, die halt dann vielleicht ganz interessant sind und eben nicht unbedingt jetzt so direkt zum Kernstream gehören.

Und da ist eben genau dieses Buch, glaube ich, eine von den Sachen, die da entstanden ist.

Das hatten wir, glaube ich, zum Einjährigen gemacht, meine ich, als wir das erste Jahr rum hatten.

Oder war es zum Zweijährigen?

Ich bin mir nicht ganz sicher.

Ich meine, es sind entweder alle Folgen, die wir im ersten Jahr hatten oder alle.

Und guck’s auch so verwirrt.

Okay, müssten wir recherchieren.

Ich bin mir nicht ganz sicher mehr.

Ich meine, wir haben, glaube ich, es nicht geschafft, noch eins zu machen.

Das liegt irgendwie noch im Limbo.

Ja, genau.

Und aber an der Stelle, ich greife jetzt die Chance zu sagen, ich möchte gerne irgendwann wieder Sketch Notes machen, weil das, glaube ich, einige als wichtig und cool erachten.

Und ich habe aus persönlichen Gründen im Moment leider länger pausieren müssen und hoffe, wieder in die Richtung reinzufinden, dass das wieder regelmäßiger der Fall ist.

Dass es vielleicht auch noch ein Sketch Notes Buch geben kann zum Stream.

Ja, genau.

Also, sorry.

Ja, ich finde ja diesen Sketch Note Ansatz, den kannte ich ja schon vorher eigentlich.

Aber ich habe eigentlich eher so für Flipcharts oder so die Zeichnungen gekannt.

Und ich fand es jetzt mit dem Buch echt gut, dass ich dann eben auch mal angefangen habe, wenn ich irgendwo zuhöre, mich darauf zu konzentrieren, die Sketch Notes zu machen.

Und Lisa, ich fand das eben so gut, dass du eben auch dir Gedanken über die Library gemacht hast, wie man die Begriffe in der IT entsprechend grafisch darstellen kann.

Und das ist für mich echt ein guter Wert.

Also, danke dafür.

Danke für das Feedback.

Martina steckt uns gerade die Information zu, dass es tatsächlich zum Einjährigen war, also 2021.

Und genau, diese Sketch Note Library, die finde ich halt irgendwie auch super.

Ich glaube, mein Lieblingsmotiv ist das für die schlechte Idee.

Ja, das ist sogar das einzige Mal, dass irgendwas von mir mal viral gegangen ist auf Twitter damals noch.

Damals, als Twitter noch cool war.

Willst du noch erklären, wie das aussieht?

Oder ist das sozusagen der ZuschauerIn oder dem ZuhörerIn überlassen, das selber rauszufinden?

Also, ich weiß nicht mehr genau, in welchem Rahmen es war.

Ich habe die Beispiel-Sketch Note auf jeden Fall immer noch in meinem Vortrag drin.

Auf jeden Fall sagtest du irgendwann, XY wäre eine ziemlich scheiß Idee.

Und du hast das einfach auch genauso gesagt.

Und daher kam dann das Symbol ziemlich einfach zu mir geflogen.

Wegen der Idee, die man ja klassischerweise als Glühbirne darstellt.

Und dann hat sie natürlich ein kleines Hundehäufchen auf ihren Kopf bekommen.

Und das ist dann die scheiß Idee.

Sind eigentlich auch Fliegen?

Ich glaube nicht, oder?

Ich glaube in dem Originalbild nicht.

Aber wenn ich sehr motiviert bin und das nochmal male, male ich eigentlich immer Fliegen dazu.

Um das nochmal ernst zu betonen.

Irgendwie überlege ich gerade, ist das ein Hundehäufchen?

Oder ich habe gerade so einen Maulwurf im Kopf.

Maulwurf?

Ach, den.

Aber war es nicht da sogar auch ein Hund bei dem Maulwurf?

Jetzt bin ich mir nicht mehr ganz sicher.

Das ist ein Thema, was ich dann recherchieren werde.

Okay, sehr gut.

Im Nachgang mit deinem Buch.

Aber Ewa, ich habe eine Frage an dich.

Ja, gerne.

Du musstest ja quasi auch schon öfter Sketch Notes mitmalen oder so.

Beziehungsweise du hast das ja schon öfter miterlebt, dass ich so einen Workshop-Vortrag oder sowas mache.

Hast du jemals in deinem Leben zu irgendwas eine Sketch Note gemacht oder hat dich das so gar nicht gecatcht, das Thema?

Ich habe ja tatsächlich das Vorwort zu deinem Buch geschrieben und habe im Rahmen dessen das dann irgendwie ausprobiert und habe festgestellt, dass ich das prinzipiell kann.

Am Ende ist es halt so, dass ich tatsächlich eher Dinge aufschreibe.

Ich habe halt so meinen Druckbleistift.

Das habe ich gerade nicht griffbereit, dieses schöne Kreature-Büchlein von Leuchtturm.

Und das ist halt das, wo ich im Moment die Sachen irgendwie immer aufschreibe.

Das ist das, was ich mache.

Kein Hindernis für Sketch Notes, aber never mind.

Ja, genau.

Sollte ich vielleicht nochmal machen.

Aber ist es nicht eigentlich faszinierend, dass wir früher in der Schule eins auf die Finger gekriegt haben, wenn wir irgendwie ins Heft gescribbelt haben und du uns jetzt gezeigt hast, dass das echt sinnvoll ist, wenn man eben während des Vortrags dann wie zeichnet.

Aber heute, ich schreibe ab.

Ach so, genau.

Und es gibt tatsächlich…

Ach ja, sehr gut.

Genau.

Martina hat also, ich bringe das auch nochmal in den Chit, hat also gerade den Link gefunden dazu, wie man halt so eine schlechte Idee tatsächlich visualisiert.

Genau.

Dann können wir, glaube ich, weitermachen mit dem nächsten Video.

Und dazu muss ich einmal umschalten.

Und dann schauen wir mal, was das nächste ist.

Von Nils Forth stammt das Zitat.

Entwickler werden von Komplexität angezogen wie Motten vom Licht.

Meistens mit dem gleichen Ergebnis.

Sie verbrennen.

Das finde ich eigentlich ganz interessant, weil es resoniert mit Entwicklern.

Die stimmen dem zu.

Und das führt halt zu ganz interessanten Dingen.

Ja, man möchte eigentlich nicht die Komplexität, weil man weiß, irgendwann beherrscht man die eigene Komplexität nicht mehr.

Denn Debuggen ist etwas komplexer als den Code zu schreiben.

Und wenn ich mit dem Codeschreiben schon an meine Grenzen komme, dann kann ich nicht mehr debuggen.

Und auch die Arbeit im Team leidet extrem darunter, weil wenn du den Code verstehst, aber alle anderen nicht mehr, ist es schwierig.

Also ich habe sozusagen über die konkrete Arbeit hinaus…

Stopp.

Genau.

Das war auf den IT-Tagen.

Und das war das phänomenale Stream im letzten Jahr, wo ich nicht mehr aufhören konnte zu lachen.

Ganz professionell.

Ja.

Aber du hast es professionell geschafft, dann noch unter Tränen abzumodernieren.

Das war für mich beeindruckend.

Wir haben also ein verstecktes Talent erkannt, entdeckt an dem Tag.

Genau.

Ja.

Was waren nochmal die drei Fragen, die wir den Leuten gestellt hatten?

Was ist der wichtigste Skill?

Also es ging ja um die IT-Tage.

Die sind zehn Jahre alt geworden und sie sprachen gerade darüber, wie die Welt in zehn Jahren aussehen wird.

Und wir hatten die Frage, was ist der wichtigste Skill in der IT 2035?

Das weiß ich noch.

Das hatten wir noch.

Welches Problem bis dahin gelöst werden sollte in der IT?

Ich glaube auch, ja.

Ja.

Ich gucke mal schnell, ob ich auf die Schnelle meine Notizen noch finde.

Genau.

Und Martina, wir haben das herausgefunden, dass seit dieser Episode 25 mit Microservice Transaktion und Konsistenz, das war die, wo die Sache mit der schlechten Idee kam.

Genau.

Und die Fragen waren, welche Herausforderungen sollten wir bis 2034 in der IT gelöst haben?

Was ist 2034 der wichtigste Skill in der IT?

Was sollten wir jetzt tun für ein IT-Umfeld 2034, in dem wir gerne arbeiten?

Ach, das war diese phänomenale Ankündigung, wo Martina uns zehn Jahre altern lassen hat.

Ja, genau.

Ja, genau.

Das war cool.

Genau.

Und ich war auch, glaube ich, in einer sehr schönen Diskussion.

Ganz viele unterschiedliche Sachen haben wir da irgendwie angesprochen.

Ja.

Genau.

Das war auch ein cooler Rahmen.

Also auch, dass das Publikum mitgemacht hat und dann auch Leute aus dem Publikum Fragen hatten und so.

Und der Raum war so witzig.

Also ihr habt das ja, glaube ich, nicht gesehen, die ihr nur im Stream zugeschaut habt.

Aber es war quasi so eine riesige Fläche in diesem, wie heißt dieses Gebäude nochmal?

Irgendwas Europa?

Das Hub Europa oder sowas.

Hub Europa, genau.

Und das war irgendwie ganz weit oben.

Und alles war fast verfenstert, dass man rausgucken konnte.

Es war sehr dunkel, weil es schon Dezember war.

Und die Leute lümmelten auf diesen riesigen Sitzdecken und in irgendwelchen Sofas ganz verteilt in diesem gigantischen Raum rum.

Und dann erzähl mal, wer gemeldet.

Und dann rannte man zu der Person mit dem Mikrofon und freute sich über die Beiträge.

Es war schon ziemlich cool.

Auch, dass wir so viele Zettel bekommen hatten.

Da war man ja doch eher skeptisch, weil wir eben, du hattest schon gesagt, wir experimentieren so viel.

Und das war ja auch ein volles Experiment.

Wir haben ja einfach Flipcharts im Kap Europa verteilt und gehofft, dass wohl irgendwer was dran pappt.

Es passiert.

Wobei das, glaube ich, die zweite Sache war.

Also das zweite Mal war, dass wir sowas gemacht haben.

Wir hatten ja davor diese Geschichte beim Java Forum Stuttgart, wo wir am Sekretarischstand gestanden haben.

Und dann zum einen die Menschen etwas sagen konnten zu dem Thema, was ist eigentlich der wichtigste Skill in IT und auch so Karten einwerfen konnten, wenn sie nicht erscheinen wollten.

Und das ist eine von den Episoden, die ich immer noch sehr gerne zitiere, weil da hat irgendwie mit einer überwältigenden Mehrheit so Soft Skills und so weiche Faktoren genannt worden sind.

Ich hoffe, du verzeihst mir das, Ralf.

Das ist für mich einer der Punkte in dieser AI-Diskussion.

Also man kann relativ gut reproduzierbar Techniken fragen, was ist denn eigentlich das Problem?

Dann kommt halt zurück Menschen oder Kommunikation oder sowas.

Und ich sehe halt nicht, wie eine AI da hilft.

Also zweifellos ist es halt so, dass es Bereiche gibt, in denen sowas vielleicht unterstützen kann.

Aber dieses Kernproblem löst es halt irgendwie nicht.

Und ich finde das halt so lustig, weil man kann die Leute halt irgendwie fragen.

Aber dieser Schluss ist halt, glaube ich, gar nicht so klar.

Und das ist halt so der Punkt.

Also ich glaube, wenn die AI wahrheitsgemäß antworten dürfte, würde sie auch sagen, ja, die Menschen sind das Problem.

Lass mich mal alleine machen.

Aber ja, wir haben damit AI und den Soft Skills.

Vor allem, wenn die AI so tut, als könnte sie.

Und wenn sie anfängt, dreist zu lügen und solche Geschichten und unsere Verhaltensmuster kopiert.

Und ja, ich stimme dir zu, da haben wir noch ein großes Problem.

Ja, ich meine insbesondere nicht.

Also nehmen wir mal an, wir würden jetzt damit tatsächlich Coding lösen und vielleicht auch irgendwie so Architekturdokumentation und Architektur.

Trotzdem haben wir halt irgendwie Teams und müssen miteinander interagieren.

Und das ist halt irgendwie so der Punkt.

Und ob es dann halt diese anderen Themen löst, das ist ja irgendwie auch noch so ein bisschen aufregend.

Ich glaube, in 30% der Welt gibt es gar keine Teams mehr.

Da sind das ja nur noch die KIs, die miteinander interagieren.

Das ist halt der große Traum von vielen, dass wir die Softwareentwicklungsteams durch KI ersetzen und wir nur noch sagen, ich will das und das haben, mach mal.

Aber ja, trotzdem haben wir irgendwie die menschliche Kommunikation miteinander.

Aber daran scheitert es ja nicht.

Also es scheitert an dem, ich möchte das und das haben, mach mal.

Also das ist unser Problem.

Absolut.

Guter Moment für den nächsten Clip.

Ja, genau, ich überlege da halt auch gerade, weil wahrscheinlich können wir jetzt noch eine Stunde über das Thema reden.

Genau, lass uns mal das nächste Video anschauen. Über die konkrete Arbeit hinaus auch viel gelernt über Menschen und wie Menschen miteinander umgehen und was wichtig ist bei der Zusammenarbeit.

Und das finde ich schön.

Das wünsche ich eigentlich jedem Menschen, der im Beruf steht, dass so etwas Zeitloses als Erkenntnis auch bleibt.

So sehr ich lächeln kann über meine zahlreichen Fehler, die ich selbstverständlich gemacht habe.

Oder manchmal lächle ich auch nicht, weil manchmal waren sie mir sehr unangenehm.

Aber dass wir so, dass wir aus unserem Beruf auch wirklich Einsichten schöpfen, die uns auch im Leben sozusagen tragen.

Das wünsche ich euch allen.

Wie kann ich jetzt aus den Vorschlägen …

Perfekte Überleitung, oder?

Ja, genau.

Also, wen wir gesehen haben, das ist Professor Christiane Flood, bei der ich tatsächlich das Vergnügen hatte, auch zu studieren, also einige Vorlesungen dort zu hören und mitzuerleben.

Und sie ist halt tatsächlich eine Informatikpionierin.

Der Ausschnitt aus dem Gespräch, das ich jetzt nicht gezeigt habe, ist halt irgendwie der, wo sie hat sagt, ich habe übrigens irgendwie die erste integrierte Entwicklungsumgebung gebaut.

Und die Episode geht halt um das Thema mit der menschenzentrierten Softwareentwicklung.

Und das fand ich halt auch sehr spannend, weil das, glaube ich, ganz verschiedenen Arten von Menschenzentrierung ist.

Also einmal die Menschenzentrierung gegenüber den Entwicklern, dann irgendwie die Menschenzentrierung gegenüber den Leuten, die die Software benutzen.

Und viele von den Dingen, also nicht, wir reden jetzt über sozio-technische Systeme, wir reden halt über Agilität und so weiter und so weiter.

Das sind halt irgendwie alles Themen, die sie zumindest in Grundzügen, also vielleicht nicht ganz so, wie wir es heute diskutieren, aber halt in Grundzügen damals auch schon diskutiert hat oder schon viel länger diskutiert hat, nicht, dass sich halt eine Integration entwickeln muss, dass halt dieser menschliche Faktor eine Rolle spielt und so weiter und so weiter.

Und das war halt, also es ist halt eben auch die erste Folge sozusagen mit einer Gästin, weil ich halt tatsächlich glaube, dass das eben ganz, ganz wichtig ist und dass es halt auch ganz wichtig ist, zu verstehen, dass wir diese Probleme und diese Ansätze halt eigentlich als Branche schon lange verstanden haben.

Und genau deswegen hatte ich das jetzt sozusagen rausgesucht als das erste Schritt, was ich zeigen wollte.

Ja, ich fand die Folge total klasse.

Also ich kannte die Professor Christiane Floyd vorher nicht, eben nur, weil ich wusste, dass du sie unbedingt einladen möchtest.

Und ich fand das total inspirierend und auch faszinierend, wie sie erzählte, dass sie schon in den 70ern oder wann es genau war, eigentlich genau die Probleme erkannt hat, dass man auch mal Kunden fragen sollte, was die denn möchten und dann eben eher auch so userfokussiert entwickelt und nicht so im stillen Kämmerlein.

Das fand ich total verrückt irgendwie, weil es fühlt sich in jedem Projekt, in das man kommt, wieder so an, als wäre das immer so, was, wir sollen userzentriert entwickeln, was, wir sollten die Nutzer mal fragen.

Und sie erzählte, dass es einfach vor 70 Jahren, in den 70er Jahren halt schon obviös war, dass man das tun sollte.

Genau, also tatsächlich war das ein Thema.

Also im Grundstudium hat sie meiner Ansicht nach, also ihre Gruppe hat eben gesagt, nicht Wasserfall ist ein Problem, und uns beigebracht.

Und ich habe dann später tatsächlich ein Praktikum bei ihr gemacht, also in den 90ern.

Und ich erinnere mich halt daran, dass sie uns dann losgeschickt hat und gesagt hat, also dass sie uns in dem Praktikum, haben uns die Leute dort, also die Mitarbeiter, dann losgeschickt.

Und ich habe irgendwie eine Krankenschwester in Eppendorf, im Krankenhaus Eppendorf, Universitätskrankenhaus Eppendorf, interviewt, wie sie eigentlich arbeitet.

Und das ist halt so, damit ist es halt klar, dass man halt so arbeiten muss und halt Menschen fragen muss, wie sie arbeiten, um dann die Software zu bauen.

Du hattest gerade auch Wasserfall gesagt.

Ich habe ganz schnell die Sketchnote aufgemacht und habe mich gefreut, weil ich noch in Erinnerung hatte, dass sie so ein lustiges Zitat hatte aus ihrer Arbeit mit Amerikanern, glaube ich.

Und das ist auch mit auf der Sketchnote, weil sie sagte, zum Wasserfallmodell sagten ihr die mal irgendwie, all the Germans, they take it literally.

Das fand ich so witzig, dass das sogar in der Sketchnote gelandet ist.

Ja, genau.

Das ist dann auch.

Gut, das dazu.

Und die Person, die wir jetzt gleich sehen, ist tatsächlich eine Person, die bei der Professor Christiane Froth promoviert hat.

Also das hat wirklich einen Impact, auch an der Stelle.

Und nächste Woche der Martin Lippert, wir reden da über MCP, diese Stützstelle für LLMs, der hat auch bei ihr studiert.

Und das ist tatsächlich so, dass da halt ganz viele Leute auch eine Verbindung zu ihr haben.

Und damit können wir, glaube ich, das nächste Video uns anschauen.

Also wie kann ich jetzt aus den Vorschlägen was raussortieren?

Das ist natürlich eine Frage der Priorisierung.

Und das hat ganz viel aus meiner Sicht mit dem Kontext zu tun, wo diese Software entwickelt wird.

Hat man die Leute?

Hat man das Geld?

Gibt es bald eine Erweiterung?

Also aus meiner Sicht ist das abstrakt ganz schwer zu beantworten, welchen Vorschlag man auswählen soll.

Meine Erfahrung ist, das machst du ja auch oft genug, Eberhard, dass man in so einem Workshop dann mit den Leuten diskutieren kann und herausfinden kann, was sollte man denn jetzt in eurer Situation, in diesem Moment als erstes tun?

Also ich glaube, das hängt viel ab von dem Kontext, wo man da ist.

Das siehst du ja auch so, denke ich.

Genau, ich habe mir irgendwann letzten Monat auch mal Gedanken gemacht, gehabt auf einer Konferenz in der Nacht.

Genau, und das war die Episode zu langlebigen Softwarearchitekturen, worüber Carola ja auch ein Buch geschrieben hat und wo es eben darum geht, wie man jetzt tatsächlich mit solchen Sachen umgeht.

Und man sieht ja, das ist eben auch so ein bisschen eine Fortsetzung zu dem, was wir vorhin diskutiert haben, dass man mit Menschen darüber reden muss und dann halt gemeinsam da sozusagen Entscheidungen fällen muss.

Ich habe auch den Sketch-Doc noch mal schnell aufgemacht, weil du ja auch gerade sagtest, dass sie ja bei Professor Christiane Floyd promoviert hat.

Und da sind auf der Sketch-Doc auch zwei Sachen von Carola, die sie gesagt hat, die total gut dazu passen, finde ich.

Weil sie hat einmal nämlich gesagt, ich möchte die Welt verbessern, ich möchte helfen, dass Leute gute Software entwickeln können.

Und ich glaube, das geht auch so in die Richtung.

Und das andere, was sie noch gesagt hat, was ich sehr für mich mitgenommen habe, beziehungsweise vielleicht auch schon gemacht habe vorher, aber zusammen mit dem Team arbeiten, anstatt gegen das Team zu ermitteln.

Das ist auf jeden Fall auch noch so ein offensichtlich wichtiges Zitat.

Sonst hätte ich es nicht mit auf die Sketch-Doc damals genommen.

Also ich dachte, da wollte ich jetzt zwar nicht mal was sagen, aber dann können wir uns das Nächste sozusagen anschauen.

Das sah man kurz auch schon.

Das ist halt Michael Vieth.

Und jetzt muss ich mal schauen.

Da hat mir irgendwann letzten Monat ja auch mal Gedanken gemacht, gehabt auf einer Konferenz in der Nacht, wo ich nicht schlafen konnte, über was bedeutet denn wichtig sein?

Also wann ist eine Person wichtig für ein Unternehmen?

Und da habe ich halt dann angefangen, so klischeehaft über so Stereotypen nachzudenken.

Und da ist mir halt dann auch die Räumerin oder so in den Sinn gekommen.

Also eine Person, die viele interne Aufgaben macht, die sonst niemand machen möchte, die müssen gemacht werden, aber sind nach außen nicht sichtbar.

Und ich glaube, es gibt halt Personen, die so Themen eher machen.

Und da darf man, also genau, man darf die halt nicht übersehen oder für selbstverständlich erachten.

Aber das ist halt genauso ein wichtiger Beitrag wie jemand, der jetzt in so einer Consultancy den Mega-Umsatz im Jahr macht oder so.

Also beide haben halt irgendwie ihre Stärken.

Und beides ist wichtig, halt auf verschiedenen Arten wichtig.

Und das lässt sich schwer miteinander vergleichen.

Genau.

Das habe ich damals gemacht mit Michael, ne?

Ja, genau. Über Technikexzellenz beziehungsweise Engineeringexzellenz.

Und das war, wie soll ich sagen, das war damals, hatte ich so das Gefühl, so ein bisschen so ein Mutthema.

Ich hatte das ja auch mal diskutiert mit einigen Leuten vor Ort, damals bei Jibo, mit dem Johannes Meinusch.

Und die andere Person ist mir gerade entfallen.

Und was ich da, also das hat auch eigentlich, das zieht sich so ein bisschen durch, nicht?

Also das habe ich nicht so geplant, das haben wir nicht so geplant.

Aber man redet ja jetzt über ein scheinbar hartes Thema, nicht?

Wie kriege ich irgendwie Software hin, die ja besonders super ist oder Technische Exzellenz hin?

Und man landet dann irgendwie bei so einer soften Diskussion, die halt irgendwie sagt, nicht?

Also Menschen, unterschiedliche Menschen, haben halt unterschiedliche Dinge, die sie halt irgendwie beitragen.

Und das ist halt, da muss man sozusagen drauf achten.

Und wenn man halt die entsprechende soziale Umgebung hat und die entsprechende Organisation, dann kommt das halt eben auch mit der Technischen Exzellenz.

Und das ist, fand ich, auch nochmal eine ganz spannende Sache, nicht?

Zieht sich jetzt so ein bisschen, glaube ich, durch.

Nur zur Vollständigkeit, weil du gerade sagtest, du sprachst mit Johannes Meinisch und Robert Eilbrecht und die Folge ist Folge 136, Encouraging Engineering Exzellenz.

Genau, danke.

Ich finde es so spannend, dass wir jetzt hier viele Beispiele für Soft Skills haben.

Und wir hatten ja auch mal in einer Folge darüber gesprochen, dass Soft Skills wichtig sind.

Aber ja, wie kann ich mir die aneignen?

So im Studium oder so wird nie davon gesprochen.

Wir kennen aber die Probleme in Projekten und trotzdem beachten wir sie oftmals nicht, erst wenn es zu spät ist, dass wir merken, ja, da hätte man anders zusammenarbeiten müssen.

Fühlt ihr, was ich denke?

Ja, und das ist, glaube ich, eine ganz hervorragende Überleitung zum nächsten Video.

Nicht, dass falsche Gedanken entstehen, aber nicht, wir haben das tatsächlich nicht abgestimmt.

Soll ich das mal zeigen oder wollen wir noch was diskutieren?

Mach mal.

Okay, genau.

Und zwar, das Thema Auftragstaktik führt irgendwie zu der logischen ersten Frage, was ist denn überhaupt Auftragstaktik?

Auftragstaktik und Führung

Auftragstaktik für uns im Militär ist im Grunde genommen unsere Führungsphilosophie.

Das ist die Art und Weise, wie wir miteinander kommunizieren, wie wir Aufträge vergeben und wie wir auch Aufträge ausführen sollen.

Und das heißt bei uns im Grunde genommen in der Kürze, wir geben vor, was gemacht werden soll, aber wir geben nicht vor, wie ein Untergebender etwas ausführen soll, weil wir uns darauf verlassen, dass der Untergebende das im Grunde genommen selber am besten lösen kann, weil er zum wichtigen Zeitpunkt an der richtigen Stelle auch die richtigen Entscheidungen treffen kann.

Also, selbes Wording, anderer Tonfall.

So, und das ist halt eine von den Episoden, auf die ich halt tatsächlich auch immer wieder zurückkomme.

Und ist auch eine von den Sachen, wo es halt irgendwie günstig ist, diesen Stream zu haben.

Man kann halt irgendwelche Menschen anfragen, kann halt sagen, hey, hast du nicht irgendwie Lust, was zu einem Thema zu sagen?

Und nicht, wenn man irgendwie Glück hat, und dann kann man irgendwie sagen, ich guck mal, und wir sind irgendwie erfolgreich, wir haben so und so viele Follower.

Wenn man Glück hat, sagen die halt irgendwie zu.

Und in diesem Fall war es halt der Sönke, der halt über Auftragstaktik diskutiert hat.

Und man sieht es halt gerade, das ist halt etwas, was auf Vertrauen aufbaut.

Er sagte ja, dass man halt sozusagen darauf setzt, dass die Menschen, denen man einen Auftrag gibt, idealerweise das Ziel erreichen.

Und es ist ein klares Delegationskonzept.

Das heißt, ich gebe halt ein Ziel vor, das halte diese Brücke oder wie auch immer, und dann müssen die halt irgendwie schauen, wie sie es halt irgendwie machen.

Und ich finde das halt immer wieder lustig oder interessant, weil ich glaube, dass wir halt in der, also ich habe tatsächlich jetzt die letzten drei Tage ein Training gegeben, so ein Flextraining.

Und da geht es halt irgendwie auch um flexibles Softwarearchitekturen.

Und da geht es halt irgendwie auch darum, was man jetzt irgendwie Teams sozusagen vorgibt.

Und dann ist halt immer die Frage, will man den Teams die Technologien vorgeben?

So, und wenn ich halt diesem Maßstab folge, dass ich sage, ich sage euch, was ihr machen sollt, aber nicht wie, dann sollten die Teams das eigentlich präferentiell entscheiden.

So, dann kommt halt irgendwie unter Technikern häufig sowas raus wie, ja, aber wenn die jetzt irgendwie so einen krassen Kindergarten machen und halt irgendwie unverantwortliche Entscheidungen treffen, und das ist hier halt jetzt irgendwie eine Geschichte, wo der Sönke halt sagt, also das macht man halt irgendwie anders.

Und man muss denen halt da sozusagen vertrauen.

Und das andere, das war jetzt nichts, was man in dem Short gesehen hat, aber das ist bei mir irgendwie auch hängen geblieben.

Also wenn wir uns die Wirtschaft angucken, dann haben wir dort irgendwie Betriebswirtschaftler, von der Ausbildung her im Wesentlichen.

Das sind Menschen, die ja sozusagen mit Zahlen sich auskennen.

Wir verstehen halt, wie Gewinn-Verlust-Rechnung und Bilanz und so ein Zeug halt irgendwie funktionieren.

Was Sönke halt irgendwie sagte, war, die Bundeswehr, beziehungsweise die militärischen Organisationen, sind, so seine Behauptung, die einzigen Organisationen, die systematisch Führung in größerem Maßstab lehren.

Und ja, guter Punkt.

Und das ist so ein bisschen das, was da irgendwie bei mir hängen geblieben ist.

Und weswegen ich halt die Episode total spannend fand.

Und für mich ist es halt, also ich hatte das in der Episode auch gesagt, und ich sage das halt auch sonst immer wieder nicht.

Also ich komme zwar noch aus der Generation, die halt irgendwie Wehrdienst hätte leisten müssen.

Ich habe aber Zivildienst gemacht.

Und ich hätte das, nachdem ich den Laden von drinnen nicht kenne, nicht erwartet, dass eine Armee so funktioniert.

Also man hat irgendwie andere Vorteile.

Und deswegen fand ich halt gerade diese Diskussion sehr, sehr bereichernd und sehr hilfreich.

Und insgesamt halt eine sehr schöne Sache an der Stelle.

Ich muss ganz ehrlich sagen, als du gesagt hast, dass du den Sönke zu Gast haben wirst und mit dem Thema.

Das war das erste Mal, dass ich so richtig skeptisch war bei irgendeiner Folge.

Ich dachte, was soll das denn jetzt?

Passt das überhaupt und was kommt dabei raus?

Also ich war wirklich im Vorhinein echt skeptisch über die Folge.

Das hat mich aber im Endeffekt doch ziemlich überrascht, einfach zu sehen, dass es ganz anders ist, als man erwarten würde.

Also ich hätte jetzt halt auch eher gedacht, beim Militär kriege ich quasi auf einem Zettel ganz, ganz genau detailliert aufgeschrieben, welchen Auftrag ich zu erfüllen habe.

Also auch wie.

Das war auf jeden Fall eine sehr bereichernde Folge, einfach weil man doch vieles davon auch auf unsere Arbeit übertragen kann.

Unabhängig davon, dass das jetzt Militär ist und wie man dazu stehen mag.

Genau.

Dann können wir eigentlich daran, also das wäre jetzt auch das, was ich da nochmal unterstreichen wollen würde.

Und dann können wir eigentlich sozusagen die nächste Episode nehmen.

Wenn Ralf was sagen würde, würden wir das mitbringen, ohne nicht, dass Ralf hier total übergangen wird.

Nein, nein, ich bin nur im Hinterkopf, bin ich da ein bisschen noch am überlegen.

Ich bin etwas langsamer als ihr.

Deswegen frage mich gerade, ob das auch bei uns so gelebt wird, dass wir eine Aufgabe übergeben und einfach vertrauen, dass die richtigen Entscheidungen getroffen werden.

Und das ist ja gerade in der Softwarearchitektur, da möchte man ja die wichtigen Entscheidungen vorneweg treffen.

Und nicht dann den Leuten, die es umsetzen, überlassen.

Oder liege ich da jetzt falsch?

Aber das ist ja so ein bisschen für mich das Ergebnis.

Also die Aussage, dass halt die Menschen, die näher am Problem sind, tendenziell die besseren Entscheidungen treffen, halte ich jetzt für, wie nennt man das, ein Truism, also offensichtlich wahr.

Und das bedeutet halt, die EntwicklerInnen, die Entwicklungsteams, die dicht am Code sind, sind die, die eigentlich erstmal die besseren Entscheidungen treffen, weil sie mehr Informationen haben.

Und das führt irgendwie zu dieser Konsequenz, dass man eben da delegieren muss.

Und wenn man da irgendwie tiefer einsteigt, kommen halt ganz viele interessante Sachen raus.

Also zum Beispiel diese Geschichte mit auch einem Bundeswehrkonzept Führung von vorne, also dass ich halt irgendwie vorne stehe und halt tatsächlich mit den Einheiten selber dort eben im Kampf stehe.

Und da hat der Sönke halt auf LinkedIn so ein schönes Ding halt auch veröffentlicht, genau, dass wir noch mal drüber reden, als Kommentar irgendwo, da hat er irgendwie geschrieben, Führung erfolgt von vorne, sonst hieß es nämlich schubsen.

Und das finde ich halt irgendwie auch, also ist nachvollziehbar.

Und das sind halt genau die Sachen, weswegen ich das halt irgendwie so spannend finde, die halt diese Erfahrung gemacht haben.

Und wenn man näher drüber nachdenkt, ist es gar nicht zu überraschen, weil das Problem ist ja, das lässt sich gar nicht planen.

Also wenn ich jetzt irgendwie sage, das ist halt mein Plan und ich mache halt irgendeinen Pass, wie sich der Feind verhält, was halt irgendwie passiert, ist unvorhersehbar.

Und das ist genau das, wo diese starke Beziehung meiner Ansicht nach existiert zur Softwareentwicklung.

Weil das ist ja auch unser Problem.

Also wir fangen halt am Anfang an und sagen, hey, wir machen das Projekt, alles klar, wir planen es halt folgendermaßen.

Und dann stellen wir nach einiger Zeit fest, ups, alles totaler Quatsch.

Die Kundinnen wollen dann was anderes und so weiter und so weiter.

Gut.

Dann können wir das nächste Video uns angucken.

Wenn ich das hier hinbekomme.

Doch, das bekomme ich hin.

Anderer Tonfall, ganz andere Wirkung.

Kommunikation und Soft Skills

Es fängt ja bei der Sache an, wie kommuniziere ich?

Also da im Klassiker Schulz von Tun das Vier-Ohren-Prinzip vielleicht.

Sagt euch das was?

Es ist ja schon alleine, wie bringe ich Sachen rüber?

Also wenn Steffen und ich zusammen fliegen würden und ich würde ihm als Kapitän sagen, Steffen, fahr doch mal das Fahrwerk aus.

Dann kommt das ganz anders rüber, als würde ich ihm sagen, Steffen, fahr doch mal das Fahrwerk aus.

Tonfall und Wirkung

Also selbe Wording, anderer Tonfall, ganz andere Wirkung.

Ich glaube, Oliver Trothbaum ist traurig, dass er gerade kann.

Genau.

Und das war Olli, mit dem ich eine Episode gemacht habe, zusammen mit Steffen über das Thema Crew Resource Management.

Da geht es also darum, wie man in der Luftfahrt noch mehr Abstürze verhindert.

Und das ist so ein Konzept aus den 70ern, wo man gemerkt hat, dass eben die, das heißt Crew Resource Management, weil die Idee ist, alles was, oder Crew Resource Management, ich glaube so heißt das.

Das heißt genauso Crew Resource Management.

Du bist da nur so oft drüber gestolpert.

Und das Ziel ist halt, dafür zu sorgen, dass man eben die gesamte Kapazität aller Menschen sozusagen nutzt und dafür sorgt, dass die halt irgendwie alle tatsächlich erfolgreich gemeinsam zusammenarbeiten.

Und ich fand dieses Schrott eigentlich ganz interessant, weil das ist genau so einer der Punkte.

Also mein Tonfall, die Art und Weise, dass ich eben vielleicht durch meinen Tonfall schon so eine Missgunst, Kritik oder so übe, kann dazu führen, dass halt so, dass die Zusammenarbeit im Cockpit eben knirscht.

Und das führt dann irgendwie im Extremfall dazu, dass jemand halt sich nicht wagt, etwas zu sagen.

Und das führt dann wiederum im Extremfall dazu, dass eben tatsächlich Flugzeuge abstürzen, weil sich irgendwie Leute dann etwas nicht wagen zu sagen.

Und die Geschichte hinter der Episode ist eben, dass ich halt einige Zeit Aircrash Investigations geguckt habe, wo es eben tatsächlich um Abstürze geht, wo man genau das feststellt, dass also so, wie Ollisger gerade gesagt hat, wenn also der Kapitän so seinen Missfallen gegenüber einem ersten Offizier oder so ausdrückt und das da dauerhaft ausdrückt, dann führt das dazu, dass eben die Kommunikation nicht funktioniert.

Und dann führt das eben im Extremfall dazu, dass der Offizier jetzt seinen Job nicht macht.

Und dann führt das wiederum dazu, dass das Flugzeug abstürzt.

Und ich finde das halt irgendwie im hohen Interesse spannend, weil ich glaube, in unserer Branche, also ich kenne Fälle, wo man halt sagt, naja, hier kann ja jeder sagen, was er oder sie will.

Es gibt halt keine formale Bestrafung und das wird schon funktionieren.

Nee, ist nicht so.

Also im Cockpit ist es eben so, dass einige Leute ihre Themen, die sie eigentlich haben, nicht nennen, weil es eben ein unangenehmes Umfeld ist, obwohl es eigentlich ihr Job ist und sie am Ende halt abstürzen.

Und das bedeutet halt für uns, dass wir halt darauf irgendwie wahnsinnig viel Wert legen müssen.

Und deswegen finde ich halt genau diesen Ausschnitt, den Olli da, wo Olli sich halt gerade darüber aussetzt, ist halt so spannend, weil das ist halt eigentlich ein Nichts.

Also es ist eigentlich kein Thema, aber das ist etwas, wo eben in der Luftfahrt darauf geachtet wird.

Und davon können wir uns, glaube ich, irgendwie was abschneiden.

Und ich erstelle jetzt gerade mit einem Kunden für einen Kunden und mit einem anderen Externen noch zusammen so einen Interaktions-Retreat, wo wir genau das üben wollen.

Also wie hat Mensch miteinander interagieren.

Was in unserer Branche ja auch nochmal total extrem ist, also da wurde jetzt gerade dieses Vier-Ohren-Ding genannt, das gilt ja auch für asynchrone Kommunikation.

Asynchrone Kommunikation

Also ich kann ja auch im Slack schreiben, hey, fahr doch mal dein Triebwerk aus oder fahr Werk aus und das kann aber dann auf andere Arten gelesen werden.

Und das ist ja also, was ich sagen möchte, ist für asynchrone Kommunikation via Slack, E-Mail und so weiter gelten ja ähnliche Regeln.

Nur dass ja stets geschriebene Worte deutlich negativer aufgenommen werden, als dass sie eventuell gemeint waren.

Also das macht, gibt uns nochmal so eine kleine Extradimension, je nachdem, wie verteilt wir im Team arbeiten, die man halt immer im Hinterkopf haben sollte, wenn man selber irgendwas schreibt oder wenn man selber eine Nachricht empfängt.

Das finde ich gerade eine sehr schwere Komponente und ich denke gerade an Präsentationen, dass wenn wir auf einer Konferenz eine Präsentation halten, dann haben wir meistens nicht viel auf den Slides drauf, weil wir es über die Präsentation, über unsere Stimme, unser Interagieren mit dem Publikum rüberbringen.

Und in vielen Unternehmen ist ganz viel Text auf den Slides, wenn man nachfragt.

Ja, die Präsentation, die wird ja auch weitergeleitet und dann lesen andere sie und dann kommt es nochmal ganz anders rüber, als wenn man es eben vorträgt und die Chance hat, eben auch Nachfragen zu stellen.

Ich finde, das ist ein sehr schweres Thema, den richtigen Thronfall da eben hinzubekommen und die richtige Information rüberzubringen.

Ich habe noch etwas, was meine Chefin, die Claudia, in letzter Zeit immer mal wieder sagt, was ich aber total wertvoll finde, weil es mir jetzt wirklich schon geholfen hat.

Ich gehe immer davon aus, dass die andere Person eine positive Intention hat.

Ich weiß nicht, aus welcher Ecke dieses Mindset kommt, aber mit dem Mindset kommt man auf jeden Fall weiter.

Es gibt einfach Leute, die sich sehr knapp ausdrücken und dann gibt es Leute, die es sehr fröhlich ausschweifen mit 100 Emojis tun oder sowas.

Warum sollte die knapp ausgedrückte Person das negativ meinen, nur weil sie sich knapper gefasst hat in ihrer Aussage?

Also erstmal davon ausgehen, dass die andere Person eher positive Intentionen hat und nicht negative Intentionen.

Also der Punkt, den Ralf gemacht hat, dazu sozusagen aufbauend.

Es gibt diese Geschichte, wo tatsächlich ein damaliger Kollege von mir von dem Kunden berichtet hat und gesagt hat, die haben also eine reine Schichtleichtektur gebaut, also mit UI, Geschäftslogik und Persistenz und haben nichts gemacht, um das fachlich aufzuteilen.

Dann zeigte er freudestrahlend eine alte Folie von mir, wo genau das draufsteht.

Tatsächlich ist es so, dass ich in dem spezifischen Kontext, das ist so ein Training, was ich früher gemacht habe, habe ich natürlich exakt diese Folie gezeigt.

Der Punkt ist nur, dass zwei Folien weiter kommen und außerdem solltest du es fachlich aufteilen.

Und das ist halt ein Beispiel für dieses Problem, was man so als Konferenzspeaker irgendwie hat.

Und das ist halt, ich stelle mich vorne hin, ich erzähle irgendetwas, irgendwas kommt bei den Menschen an und im Extremfall ist es halt das Gegenteil.

Dagegen gibt es keine ernsthafte Hilfe, weil die Leute auch gerne das hören, was sie gerne hören wollen und nicht das, was man sagt.

Und dann gibt es halt jede Menge Chaos sozusagen.

Die einzige Möglichkeit, daraus zu kommen, wäre, nie wieder einen Vortrag zu halten.

Und das würde ich jetzt irgendwie gerne nicht tun.

Und dann müssen wir in dem Zug auch gleich den Stream noch einstellen und das ist halt nicht die Lösung.

Das im Umkehrschluss bedeutet, fragt uns gerne, wenn es nicht klar ist, diskutiert es gerne aus.

Und ich habe auch diesen virtuellen Kaffee, wo man mit mir nochmal drüber reden kann.

Das machen wir halt alles sehr gerne.

Und genau, ich kann noch die andere Anekdote erzählen, wenn wir dafür noch Zeit haben.

Da war diese Geschichte, wo dann irgendwo eine Diskussion war über LinkedIn und die betreffende Person hat dann eben Carola zitiert und hat halt gemeint, in dem Buch steht das halt so und so.

Und die Diskussion ging dann halt noch ein bisschen weiter bis zu dem Punkt, wo er sagte, hast du denn für deine Meinung halt eine Quelle?

Und ich war halt irgendwie sehr kurz dabei zu sagen, okay, ich gehe jetzt zu Leanpub, ich baue mir ein Buch, in diesem Buch steht genau diese Aussage, dann veröffentliche ich dieses Buch mit nur dieser Aussage und dann ist es halt in dem Buch.

Also nicht nur, weil es irgendwo steht, bedeutet das auch noch lange nicht, dass es halt irgendwie falsch oder richtig ist.

Das bedeutet nur, irgendjemand hat es halt geschrieben.

Und ja, also kritisches Denken ist da glaube ich hilfreich.

Damit sind wir wieder bei LLMs und wie man die Ergebnisse von LLMs kritisch hinterfragen sollte.

Ich wollte gerade sagen, du hast jetzt viel einfacher, du kannst dieses Buch von einem LLM schreiben lassen und es kommt noch glaubwürdig rüber.

Das ist eine Sache von fünf Minuten nur noch eine gute Quelle zu erzeugen.

Genau.

Okay, gut.

So, und jetzt bin ich gespannt, wie dieser Abschnitt dieses Streams später missverstanden wird.

Juhu.

Genau.

Lass uns das nächste Video anschauen.

Bert Rothbaum ist traurig, dass er gerade keinen Kontra geben konnte.

Er schrieb auf jeden Fall im Chat, es macht ja auch niemand Hypermedia, um der Hypermedia willen, sondern um die Anwendung evolviebar zu halten.

Also natürlich ist Olli jemand, der genau weiß, wovon er da redet und ich kaufe das alles und unterschreibe das voll.

Wie gesagt, leider kommt das Argument halt nicht an.

Also ich glaube, Olli war auch nicht zu 100% einig, was dieses ganze Zeug angeht.

Ah, jetzt hat er mir Kontra gegeben.

Aber eigentlich, wenn wir machen dürften, was wir wollen, dann käme da das gleiche raus.

Ich habe das Gefühl, dass draußen in unserer Branche…

Genau.

Und wem wir da gesehen haben, das ist der leider verstorbene Stefan Tilkoff, der auch einer der Geschäftsführer von InnoQ war und der halt die Umgebung halt geschaffen hat, in der dieser Stream eben tatsächlich auch passieren konnte.

Also ich habe zu dem damaligen Zeitpunkt bei InnoQ gearbeitet, Martina und Lisa auch.

Also das ist eigentlich etwas, was da sozusagen rausgekommen ist.

Und man sieht ja auch, glaube ich, noch einen Aspekt, dass eben der Oliver Drodrum in dem Fall tatsächlich eben, obwohl er gar nicht da war, nicht das war so eine Geschichte, wir bei der RheinJug gemacht haben, auch so etwas, wo wir eben sozusagen vor Ort waren.

Da war ein InnoQ-Event in dem Hotel, dann haben wir halt irgendwie mit der RheinJug zusammen die Veranstaltung gemacht.

Das war so eine Diskussion, wo Stefan und ich irgendwie da waren.

Und das ist irgendwie auch so ein experimentelles Ding gewesen.

Und man sieht halt, es geht halt so um ganz von den Themen, die natürlich irgendwie für Stefan ganz entscheidend waren, eben das Thema mit REST.

Genau.

Irgendwas dazu ist natürlich irgendwie in nachvollziehbarer Weise, führt das halt irgendwie zu einer etwas anderen Stimmung.

Aber ich glaube, dass es halt tatsächlich nochmal total wichtig ist, eben auch nochmal auf ihn hinzuweisen und die Rolle, die er da zweifellos gespielt hat.

Wir haben einen Kommentar auf LinkedIn.

Ich weiß nicht, ob ihr es schon gesehen habt.

Ich lese das jetzt einfach vor.

Ich glaube, das war noch zu der Diskussion davor.

Und bei irgendeinem von euch ist gerade voll das Flugzeug oder Rasenmäher oder so.

Bei Ralf, okay, sorry.

Mich ein bisschen irritiert.

Von Jens Rehsack auf LinkedIn.

Ich überlege mir oft sehr genau, ob ich eine Entscheidung treffen muss oder mir lieber überlege, wie gut ich meinen Wunsch formuliere.

Ich bin schon sehr oft positiv überrascht worden.

Ach, das war sogar noch die Geschichte mit der Auftragstaktik.

Das ist ja auch schön zu sehen, dass auch ihr Leute da draußen besser fahrt mit.

Ich gebe nicht alles klitzeklein vor, sondern schaue, was das Team aus meinem Wunsch weitermacht.

Finde ich einen schönen Kommentar.

Das ist, glaube ich, tatsächlich sehr gut und ist vielleicht etwas, was man sozusagen mitnehmen kann, um es halt zu Hause mal auszuprobieren.

Ich habe nur geguckt, was als nächstes kommt und musste lachen.

Architekten und Coding

Für das draußen in unserer Branche gesagt wird, ich bin ein Coden-Architekt und deswegen bin ich der bessere Architekt.

Ich bin der Architekt, der garantiert nicht im Elfenbeinturm ist.

Und ich finde das irgendwie problematisch, weil ich ganz ernsthaft glaube, dass das eine zu starke Simplifikation ist.

Nur weil ich Code produziere, bedeutet das nicht, dass ich einen besseren Job mache als Architekt.

Nehmen wir jetzt mal, wir haben jetzt irgendwie eine Webseite.

Genau, ich hatte mir eigentlich aufgeschrieben, dass das etwas ist mit dem Stephan Todt.

Und nicht mal am Ende gesehen, wie er meine Meinung sozusagen ertragen musste.

Das war dieses Ding mit dem Schlag den Eberhardt und Stephan.

Fand ich halt auch ein ganz spannendes und interessantes Format.

Ich weiß gar nicht, wer da drauf gekommen ist.

Also es ist eigentlich immer, wenn etwas Cooles ist, ist es Martina.

Und das war ja in Wien, das spricht noch ein wenig mehr dafür.

Kontroverse Diskussion

Und da hatten wir sogar das Format quasi, dass ihr eine These bekommen habt.

Und wir haben euch vorher eingeteilt, wer Pro sein wird und wer Contra sein wird, weil ihr beide gute Argumente finden seid, egal für welche Seite.

Und da hatten wir sogar immer noch eine Kundenabstimmung, eine Publikumsabstimmung mitgemacht.

Das war ziemlich witzig, ja.

Genau, und da ging es jetzt offensichtlich darum nicht, also sollen Architekten Coden oder irgendwie nicht.

Und ich hatte das gruselos, also tatsächlich ist das auch mehr oder minder meine Meinung nicht, dass das nicht so zwingend ist.

Und Stephan hat dann das Gegenteil behauptet.

Dann haben wir danach nochmal so ein Ding gemacht, wo wir uns ausgetauscht haben und unsere wirkliche Meinung, nicht die uns zugewiesene Meinung von uns gegeben haben, und darüber nochmal reflektiert haben.

Und das war, glaube ich, tatsächlich ein sehr spannendes Format, weil es halt zwar zu einer Kontroverse führt, aber eben trotzdem nicht dazu, dass man halt jetzt irgendwie so nur krass Ja oder Nein hat, sondern nicht darüber nochmal reflektiert und diskutieren kann.

Und ich glaube, das war so wirklich eine gute Sache.

Ich glaube, Ralf will was sagen.

Ich finde nur, ja, also die Statements, das passt.

Und ich finde es halt so interessant, diese Unterscheidung.

Ich meine, ja, ich kenne so Elfenbein-Architekten, die halt überhaupt nicht rauskommen und nicht mit den Teams reden.

Und ich kenne eben auch Architekten, die zu sehr im Coding sind und eher so die One-Man-Army und ihre Entscheidungen alleine treffen, weil sie es halt können.

Und beide Situationen erfordern halt so eine Gratwanderung, dass man eben das erkennt, die Probleme, und da rauskommt.

Und beide Situationen sind nicht ideal, und das dazwischen, das passt.

Aber ich finde das so toll.

Ich meine, ich bin jetzt erst später hier dazugekommen, und ihr erzählt immer noch so ein bisschen drumherum, wie ihr das erlebt habt, was das für eine Situation war und so.

Den lausche ich gerade ganz gerne.

Das war auf jeden Fall wirklich cool.

Das Live aus Wien war uns sehr, sehr beeindruckend.

Und das war, so viele Live-Formate haben wir ja gar nicht gemacht.

Von daher, das war ja, glaube ich, erst unser zweites Live-Format im Rahmen eines InnoCure-Events auch wieder.

Genau, und da hatten wir eben den Vorteil, dann eben das Equipment von InnoCure an der Stelle benutzen zu können.

Also im Chat war jetzt auch nochmal der Hinweis von Martina, dass wir das auch nochmal auf der OOP wiederholt haben.

Im Prinzip dasselbe Format.

Und genau, das war, glaube ich, auch nochmal eine ganz gute Sache.

Und ich fand das, also das war jetzt ein Resümee von beiden Folgen, ich fand das so witzig.

Ihr konntet so richtig hart gegen das eine oder das andere wettern.

Und dann war ja immer dann Auflösung, was ist eure Meinung.

Und das war einfach so richtig gut, weil es so dieses typische, kommt drauf an, bei jedem Mal, was ja eigentlich auch der Wahrheit entspricht, in jedem Falle.

Aber es war schon lustig, wenn man vorher so diese ganzen Argumente gehört hat.

Das war Hallervorden mit diesem Film, wo er nur irgendwie zwei Sätze sagen musste.

Und für Architekten gilt es eigentlich auch, kommt drauf an.

Und welches Problem löst das?

Damit kommt man, mit diesen zwei Sätzen kommt man sehr, sehr weit.

Ich dachte, das war, ich brauche mehr Details.

Ja, ja, bei Hallervorden waren das andere Sätze, genau.

Aber ich beschäftige mich später damit.

Zwei oder drei solche Sätze waren es.

Aber bei der Architektur gilt das auch.

Da kommt man mit zwei Sätzen sehr, sehr weit.

Ja, also dazu sozusagen.

Also dieses, es kommt drauf an, ist halt super generisch und ich muss halt gestehen, ich habe halt ein bisschen eine Aversion dagegen, weil natürlich passt das halt irgendwie immer.

Und was mich halt irgendwie immer interessiert, sind die Begründungen.

Und ich muss halt gestehen, dass, wenn man einfach nur nach den Begründungen fragt, das an vielen Stellen schon schwierig wird.

Ich mache ja Architektur-Reviews, ich bin so in Beratungssituationen und natürlich frage ich dann irgendwie notorisch, okay, warum habt ihr das so gemacht, was war der Grund dafür?

Und die Frage alleine führt halt oft zu Denkprozessen, die dann halt irgendwie dazu führen, dass man eben neue Erkenntnisse halt rausbekommt.

Aber das ist halt in gewisser Weise so ein bisschen schade, weil wenn man halt sagt, it depends, es hängt eben davon ab, da muss man eigentlich sagen, und ich habe hier etwas entschieden und ich habe das eben deswegen entschieden.

Und da muss ich halt eine Begründung haben.

Und dann wird die Begründung halt irgendwie wichtig.

Und da sind jetzt irgendwie auch solche Begründungen wie, aber das macht man ja so.

Oder das andere, was ich auch mal gehört habe, was ich halt irgendwie, also habe ich von Kollegen gehört, habe ich selber nicht erlebt, das war halt irgendwie diese Geschichte mit, warum ist das so entschieden?

Und dann hat halt die Person das Buch mit ihren Aufzeichnungen rausgeholt und hat da irgendwie nachgeschlagen und hat gesagt, auf der Konferenz hat diese Person gesagt, dass man das so macht.

Und das finde ich halt irgendwie ganz schwierig, weil das bedeutet halt, dass man die Verantwortung, die man ja nun objektiv trägt, delegiert hat an eine Person, die halt keine Ahnung davon hat und dann sind wir, also nicht, die halt von der Situation keine Ahnung hat und dann sind wir wieder bei dieser Geschichte mit den Vorträgen und diesen Geschichten und das führt dann irgendwie wieder zu Schwierigkeiten, wie das halt so ist.

Aber ja.

Ganz schnell zum nächsten Thema.

Konferenzgetriebene Softwarearchitekturen kennen wir ja alle.

Nächstes Thema, genau.

Gut, nächstes Thema.

Frontend-Architektur

Wir haben jetzt irgendwie eine Webseite, auf der man Ferienhäuser buchen kann.

Server-Side Rendering

Dann könnte es auf der Startseite ein Formular geben, auf dem ich die Parameter eingebe für meine Suche.

Beispielsweise, ich möchte gerne für fünf Personen buchen.

Ich möchte gerne von dem Zeitpunkt bis zu dem Zeitpunkt buchen.

Ich möchte gerne einen Pool haben, aber keine Sauna.

Das wären alles Sachen, die kann ich in einem Formular einfach eintippen.

Dafür brauche ich gar kein JavaScript.

Und dann drücke ich auf Suchen, dann kommt eine Suchergebnisseite und dann kann ich mir ein Haus aussuchen, anklicken.

Dann könnte ich mir das Haus anschauen, wenn es mir gefällt und ich buche.

Zahlungsdaten eingeben, gebucht.

Für den gesamten Vorgang brauche ich kein JavaScript.

Das ist nicht notwendig.

Genau, das war Lukas.

Was war das Thema der Folge?

Contentarchitektur.

Ja, Architekturoptionen für moderne Webfrontends waren das.

Man hat jetzt den Teil gesehen, wo es um Server-Side-Rendering geht.

Und wo Lukas dann den Punkt aufmacht, dass man für viele Anwendungen schlicht kein JavaScript, kein Single-Page-App und nur so oldschoolig, wobei mittlerweile ist das ja auch wieder newschool, einfache Webfrontends haben möchte oder Webanwendungen haben möchte, die auf dem Server zusammengebastelt werden.

Und das war da der Hintergrund.

Genau, das ist eine von den Sachen, die die Menschen da nicht müde werden zu sagen.

Und ich sollte noch kurz erzählen.

In der Episode war halt Lukas, die Franziska Desart und Joy Herron, alle von InnoQ.

Und ich habe tatsächlich die Moderation gemacht.

Ich hatte dich sonst im Verdacht, Lisa, aber tatsächlich war ich das.

Ich habe erst bei der dritten.

Es gab ja drei Folgen zur Frontend-Integration.

Ich habe die dritte, Folge 69, moderiert.

Und 20 und 27 hast du gemacht.

Genau, so war das damals.

Genau, und was bedeutet dieses Frontend-Architektur-Thema, das zieht sich so ein bisschen durch.

Und Lukas ist tatsächlich mehrmals da gewesen mit Frontend-Architektur, mit diesem Hilfe-Wir-Sünken-Thema.

Und mit KI.

Ja, genau.

Das zieht sich irgendwie so ein bisschen durch.

Genau, das Hilfe-Wir-Sünken war damals mit Adam Lars Huppel zusammen.

Und dann haben wir noch vergessen, HTTP, das war auch noch eine Episode, die wir mit die Lukas-Armee gemacht hatten.

Und das war, glaube ich, auch ganz wichtig, dass man nochmal versteht, wie dieses Protokoll funktioniert, was ja nun die Basis von ganz viel ist.

Ich hätte noch was kurz, um den Kreis zu schließen, quasi.

Nämlich, das Witzige ist, zu der Folge 20 von der Frontend-Architektur-Klappe, die erste, das ist auch eine Sketch-Note, die ich immer wieder in meinem Workshop zeige, weil das ist eins meiner liebsten Beispiele für, man sollte in Sketch-Notes Emotionen verwenden.

Weil Lukas hatte nämlich da erzählt, wie schrecklich es ist, wenn irgendjemand CSS-Important verwendet.

Ich habe dann quasi mein Gesicht, als er das erzählte, weil ich dann an meine Erlebnisse damit denken musste, mit in die Sketch-Note aufgenommen.

Also, falls ihr da draußen Sketch-Notes macht, nehmt auch Emotionen mit auf.

Das hilft auf jeden Fall ganz, ganz doll.

Genau, und dann sind wir am Ende der Zeit sozusagen angekommen.

Ich weiß nicht, ob noch Sachen sind, die ihr jetzt auf dem Herz habt.

Tatsächlich haben wir die Videos alle durchbekommen.

Dann wäre jetzt der Hinweis auf die nächste Episode.

Die nächste Episode ist Model-Context-Protokoll-Schnittstellen für LMS schaffen mit Martin Lippert.

Das ist nächste Woche am Freitag.

Und die übernächste Episode machst du, Ralf?

Genau, das Thema ist noch nicht so ganz raus.

Ist auf jeden Fall was mit KI.

Ich glaube, das hätte man sich auch so denken können.

Barbara Lampe haben wir da im Stream.

Und da freue ich mich total drauf.

Genau, Barbara Lampe mit irgendwas zu KI mit Ralf zusammen.

Sehr schön.

Dann haben wir es, glaube ich, so weit.

Dann würde ich sagen, vielen Dank.

Vielen Dank nochmal an alle Beteiligten, alle ZuschauerInnen, ZuhörerInnen und alle Gäste und wer auch immer daran sozusagen beteiligt ist.

Und wir schauen, was die nächsten fünf Jahre so bringen.

Und freuen uns darauf.

Und habt ein schönes Wochenende.

Und bis dahin, würde ich sagen.

Danke für alles.

Ciao.