wie gelintet wird, gearbeitet und Tests dafür geschrieben. Also klassisches Algorithmen, lustige Bäume durchtraversieren und solche Geschichten, was man halt so macht an dem Wochenende.

Sehr spannend. bist ja CTO und Co-Founder, aber noch richtig hands-on in der Entwicklung drin. Nimmst du dir da die Zeit dafür oder ist das eine Leidenschaft, die dich begleitet?

Ja, das ist tatsächlich eine Leidenschaft, weil ich wollte eigentlich nie Unternehmer sein. das ist ich bin da mehr so reingerutscht, reingewachsen und ich komme aus der Technologie. habe mit 12 Jahren plus minus habe ich angefangen zu programmieren und das ist eigentlich so mein größtes Hobby geworden, Software zu entwickeln. Und das ist dann irgendwann zum Beruf geworden und das daraus irgendwann

meine Selbständigkeit entsteht und dann irgendwann ein Unternehmen daraus entsteht. Das war natürlich am Anfang überhaupt nicht absehbar. ja, inzwischen wir sind gewachsen, wir sind ein paar Leute und irgendjemand, sage ich mal, muss halt die Geschäftsführung und Ähnliches machen. Wir machen das zum Glück zu zweit. Ich habe mehr den taktischen, operativen Anteil daran. Aber es ist mir sehr, sehr wichtig, schon sozusagen den Bezug zum täglichen Geschäft.

nicht zu verlieren und dafür mag ich Code und codieren oder entwickeln auch einfach zu gerne und ich beschäftige mich einfach zu gerne mit Technologie als dass ich das freiwillig sozusagen hergeben würde.

sehr spannend. Deine Firma heißt The Native Web. Was macht ihr genau und wie seid ihr aufgestellt? hast schon gesagt, ein paar Leute, du bist nicht allein in der Geschäftsführung.

Genau,

genau. wir uns gibt es jetzt seit 14 Jahren. Wir sind 2012 gegründet und wenn man vom Firmennamen her geht, wir kommen ursprünglich mal aus der Ecke der Web Technologien und der Firmenname ist so entstanden, dass wir damals gesagt haben, das war so eine Zeit, da gab es noch Flash, da gab es noch Silverlight und halt so diverse Plugins für den Browser. Und wir haben damals gesagt, wir glauben daran, dass die Zukunft für Technologien

in offenen Protokollen, in offenen Standards liegt quasi in dem, der Browser von Haus ausschauen kann. Die nativen Web-Technologien und nichts Proprietäres. Und deswegen heißen wir The Native Web. Und wir haben tatsächlich angefangen mit JavaScript-Beratungen, JavaScript-Workshops und Ähnlichem. Und wobei wir JavaScript nicht im Frontend gemacht haben, anders als viele andere, sondern wir sind direkt am Anfang mit Node.js.

eingestiegen mit JavaScript auf der Serverseite, haben uns viel mit Architektur beschäftigt und ähnlichen Themen. ja, da ist einfach im Laufe der Zeit dieser dieser dieser Teil, sage ich mal, der nicht technologisch spezifisch ist, der ist mehr geworden. Und wir haben dann festgestellt, wir zu Hilfe gerufen worden oder zu Rate gezogen worden.

häufig von Unternehmen, gesagt haben, sie brauchen Unterstützung im JavaScript-Umfeld auf die eine oder andere Art und Weise. Und wir haben immer wieder festgestellt, dass das eigentliche Problem nicht primär ist, dass Unternehmen mit Technologie zu kämpfen haben, sondern dass eigentlich das Problem schon häufig viel früher anfängt auf der Metaebene. Dass häufig auch Know-how fehlt, wie man einen Entwicklungsprozess vernünftig gestaltet, wie man eigentlich sicherstellt, dass man das Richtige entwickelt. Also nicht nur, dass man richtig entwickelt, sondern auch, dass man das Richtige.

entwickelt, dass man quasi zielorientiert vorgeht, wo du dann schnell an den Punkt kommst, wo die Entwicklungsabteilung und die Fachabteilung sich miteinander austauschen müssten, was oft erschreckend schlecht funktioniert. Und wir sind immer mehr in diese Richtung sozusagen gegangen und haben da sozusagen den Brückenkopf oder den Mediaturpart übernommen. das heißt so, die Fachlichkeit in den Vordergrund rücken, das ist bei uns sehr früh sozusagen in die DNA reingewandert.

Und Technologie ist im Grunde genommen immer irrelevanter geworden. insofern, wir haben natürlich auch heute noch so unsere, ich nenne es immer so, unsere Haus- und Hoftechnologien, mit denen wir besonders gerne arbeiten. Aber letztlich ist es eigentlich relativ zweitrangig und wir beraten Unternehmen heutzutage sehr viel, bevor Projekte starten. Das heißt, wenn jemand ein Projekt beginnen möchte und sozusagen so bisschen Hilfestellung von außen haben will.

dass man sicherstellt, dass man in die richtige Richtung losläuft, dass schon mal ein paar Leitplanken aufgestellt werden und ein Wegweise und einfach eine zweite Meinung haben möchte, dann kommen wir mit dazu. Und ich sage immer, wir entwickeln nicht für den Kunden, sondern wir entwickeln mit dem Kunden. Das ist ein ganz wesentlicher Unterschied, weil ich finde, ein Projekt des Kunden sollte auch das Projekt des Kunden bleiben. Ansonsten entsteht da eine Abhängigkeit auf ein externes Unternehmen. Und das ist eigentlich das Letzte, was du als Unternehmen gebrauchen kannst.

Und von daher, das heißt, bei uns ist auch immer ein Anteil an Wissensvermittlung mit involviert. Und im Endeffekt sind wir sozusagen die externen Trainer, die externen Berater, die dir helfen, eigene Softwareentwicklung besser zu machen. Und im Idealfall brauchst du uns nach einer Weile nicht mehr, weil du dann von uns das gelernt hast, was bei dir halt gefehlt hat. Und das ist das, was wir machen.

Dein

Ziel ist dich dann sozusagen selbst abzuschaffen, damit die Leute selbstständig weiterarbeiten können. Aber gleichzeitig vermittelst du natürlich deinen großen Wert auch, dich jederzeit wieder einzuladen, weil diese Abhängigkeit nicht enforced wird. Wenn du jetzt zu deinen Kunden kommst, ist natürlich die Erwartungshaltung groß, dass du der Experte bist. Wenn du im Node.js Umfeld bist, da gibt es ja gefühlt jede Woche

Ja, genau.

weil so Running Gag immer ein neues Framework was aus dem Boden kommt, jetzt im AI-Umfeld, überschlagen sich auch die Trends. Wie bleibst du denn eigentlich auf dem aktuellen Stand? Wie bildest du dich denn fort bei all dem, was du zu tun hast? Wird natürlich von dir erwartet. Ich denke mal, der Einstieg kommt trotzdem über die Kompetenz und du löst das dann später auf. Wir reden hier über Fachlichkeit, aber es wird trotzdem erwartet, dass du...

immer auf dem neuesten Stand bist und die Technik natürlich beherrschst. Wie machst du das? Wie bleibst du aktuell?

Ja, also die Frage, die wird mir tatsächlich des Öfteren gestellt. erwarten dann immer irgendwie so eine magische Antwort, wo ich irgendwie die 40 Stunden am Tag hernehme, um diverse Nachrichten, Portale und sonst was alles lesen zu können. Und der Punkt ist auch mein Tag hat Überraschung, keine 40 Stunden. Und die Lösung oder wie ich das mache, ist viel. Also ich gucke schon mehrfach am Tag.

in Nachrichtenportale rein, wobei das sehr überschaubar ist, wie viele das sind. Also das ist im Wesentlichen bei mir Hacker News und heise Developer. Ab und an mal noch Golem, aber eigentlich war es das dann schon. Die Dinge, die wirklich wichtig sind und die wirklich auch nachhaltig wichtig sind, selbst wenn du sie beim ersten Mal übersiehst, die werden dir ein zweites, drittes, viertes, fünftes Mal begegnen. Und das heißt, über kurz oder lang wirst du sie mitbekommen. Und ein ganz wesentlicher Faktor ist, dass ich vieles erst mal nur scanne

Das heißt, ich lese natürlich nicht jeden einzelnen Artikel, einzelnen Blog-Eintrag, was ich finde, sondern ich gucke im Grunde genommen, sieht die Schlagzeile interessant aus? Wenn ja, klicke ich mal drauf, gucke mal rein. Ich überflieg's. Meistens reicht das. In neun von zehn Fällen ist das nämlich dann doch nicht so interessant, wie man dachte. Und dann kann man es wieder adakter legen. Und wenn es wirklich interessant sein sollte, dann gehe ich entweder hin und lese es halt direkt.

Oder wenn ich die Zeit gerade nicht habe, dann bookmark ich es mir und so. bin viel unterwegs. Und alle paar Wochen, wenn man dann mal irgendwie im Restaurant abends alleine sitzt, dann sitze ich dann halt da mit dem Notebook oder mit dem iPad und gehe halt mal meine Bookmarks durch und lese halt mal so, was sich in letzten Wochen angesammelt hat. Und je älter ich werde und je mehr man weiß, desto einfacher fällt es dir auch Dinge, die du aufschnappst.

sozusagen in das großes Gesamtbild einzufügen, weil du mehr Ankerpunkte hast. Das ist wie so ein Puzzle. Und wenn du halt jung bist, wenn du unerfahren bist, dann kriegst du halt einfach nur eine Million Puzzleteile vor die Füße gekippt und du hast keine Ahnung, wo du anfangen sollst. Aber irgendwann verbindest du mal die ersten zwei Teile, irgendwann baust du mal den Rand und dann bilden sich so bisschen Cluster. Und je weiter du da halt voranschreitest, desto größer werden diese Cluster. Und dann taucht irgendwann ein neues Puzzleteil auf und du siehst direkt, ach, das muss an die und die Stelle.

und du hast eine Querverbindung mit anderen Themen, die du schon kanntest. Das heißt, das Methodenwissen, das Konzeptwissen, das entwickelt sich immer stärker. Und das, finde ich, macht es einem sehr viel einfacher, Neues zu lernen und auf dem Laufenden, also natürlich nicht auf das Aktive, die Informationen suchen. Aber wenn man eine Information sieht, wenn die vorbeigeschwört kommt, die sozusagen aufzugreifen, in eine bestimmte Ecke zu packen

und dann dort mit Querverknüpfungen zu versinnen, einzuordnen. Das ist in ganz vielen Fällen erst mal ausreichend, einen Überblick, einen guten Überblick zu haben. Und ich glaube, das ist das Geheimnis. Und dann gibt es natürlich ein paar Themen, wo du tiefer reingehst. Aber ich muss nicht jedes Thema im Detail kennen, ⁓ einen guten Gesamtüberblick erst mal zu haben. Aber der gute Gesamtüberblick ist notwendig, halt Themen adäquat einordnen zu können.

Ja, sehr schön. die, wenn man bisschen länger dabei ist, wiederholen sich auch der eine oder andere Trend, vielleicht in einer anderen Form, aber man hat das dann schon mal so gesehen, passt, kann das zu den Clustern, wie du es schön bildlich beschrieben hast, zuordnen. Und ist dann erstaunt, dass gar nicht so viel sich dann verändert. Also es gibt so ganz marginale Sachen, die dann irgendwie die Welt verändert haben, aber viele Sachen gab es schon in anderen Schläuchen sozusagen, diesen Wein.

Ich habe in dem Podcast ein Format etabliert, wo ich eine Frage mitbringe aus dem vorherigen Podcast, die ich dir stelle. Und der Gast wusste nicht, wer der Empfänger der Frage ist. Und für dich schon mal eine kleine Vorwarnung. Ich werde dir auch am Ende dich darum bitten, eine Frage für den nächsten Gast mitzugeben. Und die Frage, die ich dir stelle, ist als Erstes, wie sieht es mit Fußball aus? Stehst du auf Fußball?

Es geht. sagen wir es mal so, wenn so alle zwei Jahre Europameisterschaft oder Weltmeisterschaft ist, dann gucke ich es manchmal. Ich lasse mir auch alle zwei Jahre erneut wieder erklären, was der Unterschied zwischen aktive und passiven Abseits ist. Das kann ich mir nicht merken. Ansonsten ist mir Fußball zugegebenermaßen eher nicht so wichtig, es mal ganz vorsichtig auszudrücken.

Es geht.

Alles klar.

Ist auch kein Problem. Die Frage hat nichts mit Fußball zu tun, aber sie kommt von Alexander Altenhofen. Er ist bei der DFL Director of Product and Technology. Wir hatten in der Episode 13 zusammen ein Interview, haben reingeschaut, wie sieht es in der Bundesliga-App aus, was Massen an Daten werden dort aufgenommen und wie geht die Bundesliga mit dem Big Data um.

Danke.

Mhm.

Also wer es nicht sich angehört hat, gerne noch mal reinhören in die Episode. Und jetzt zur Frage. Er war ganz neugierig, wie wird es zukünftig die Programmiersprachen gestellt sein? Brauchen wir die noch oder wird das obsolet? aus dem Grund werden diese Agents das alles übernehmen. Also brauche ich die Programmiersprachen noch so in der Form, wie ich sie heute habe? Oder machen das einfach Agents, die wir

steuern durch Promts und die dann alleine mit der Maschine irgendwie sprechen.

Das ist eine sehr spannende Frage. Und das ist eine Frage, bei der ich mir schwer tue, direkt mit einem ganz klaren Ja oder Nein zu antworten. erst mal sind so verschiedene Gedanken, die mir dazu direkt durch den Kopf gehen. Also ein Punkt ist erst mal, selbst wenn wir keine Programmier-Sprache mehr verwenden im Sinne von C oder von Basic oder Assemblers vielleicht ein blödes Beispiel.

C, Basic oder ich bin jetzt bei diesen ganzen alten Programmiersprachen, Pascal und Kobol oder halt wie die modernen Sprachen halt heißen, C-Sharp, Java, sonst was. Selbstverständlich nicht mehr verwenden, weil wir prompt schreiben. Die Frage ist, was definiert man denn als Programmiersprache? Weil letztlich ist ja dann die Sprache, in der ich den prompt formuliere, die Anweisung oder die Sprache, in der ich das Programm beschreibe. Das heißt, man könnte die Frage aufwerfen, ist dann halt nicht die neue, in Anführungszeichen, Programmiersprache.

halt englisch oder deutsch. also insofern eine Sprache, in der du programmierst, wird es dieser Logik zufolge natürlich immer geben. Die Frage, die dabei sich ergibt, ist, wie gut funktioniert das? Und ich meine, ein Punkt, warum wir in der Vergangenheit Programmiersprachen hatten, ist, weil natürliche Sprache sehr viel Interpretationsspielraum lässt und sehr unscharf und sehr ungenau ist. Und das ist was, was wir versuchen.

mit Programmiersprachen einzuschränken. Und das funktioniert auch bei Programmiersprachen nicht hundertprozentig. Auch da gibt es manchmal sehr interessante Effekte, weil die Sprachdefinition vielleicht ein bisschen, ja, irgendeine Lücke übersehen hat oder Ähnliches. Aber da bin ich noch nicht so überzeugt von, dass jetzt auf natürliche Sprache zu gehen, da so die Lösung sein soll, weil wir damit die ganze Unschärfe, die wir in den letzten Jahrzehnten

erfolgreich vermieden haben, dass wir die halt einfach auf dem Weg wieder rein kriegen und dass das halt so viel nicht Determinismus führen wird. Die Frage ist natürlich, ob wir noch neue Programmiersprachen dazu bekommen werden, ob es weitere Programmiersprachen geben wird und das wiederum. Also ich würde es mir wünschen, weil es viele spannende Entwicklungen und Forschungen in dem Bereich gibt. Und ich finde einfach eine gewisse.

Varianz, eine gewisse Manig-Faltigkeit an der Stelle zu haben, ist eine Bereicherung. Ich fände es bisschen traurig, wenn wir jetzt die 10.000 Jahre nur noch mit dem aktuellen Stand von Java und C-Sharp und C++ bauen würden und sich da einfach nichts mehr tun würden. Auf der anderen Seite, am Ende sind sie alle irgendwo touring vollständig. Das heißt, die Frage kann man natürlich auch aufwerfen, braucht man überhaupt hunderte oder tausende von Programmiersprachen?

Dann kommst du schnell an den Punkt, was ist die beste Programmiersprache, wo dann wieder die Frage sich anschließt. Definier mal die beste, also an welchen Qualitätskriterien misst man das dann? Naja, also man sieht, man kommt da ziemlich vom hundertsten ins tausendste. Deswegen, das ist der Grund, warum ich mir schwer tue, die Frage mit so einem einfachen Ja oder Nein zu beantworten. Also ich glaube schon, long story short, ich glaube schon, dass es zukünftig noch Programmiersprachen geben wird, einfach weil natürliche Sprache zu viel Varianz.

enthält und zulässt und wir Mathematiker drücken sich auch nicht in natürlicher Sprache aus und das hat einen Grund und das ist auch gut so. Und ich glaube nicht, dass wir uns insgesamt uns als Branche oder uns als Gesellschaften gefallen tun, wenn wir sagen ach ja so die die Exaktheit die werfen wir jetzt mal über Bord und wenn wir das alles total unscharf formulieren das reicht dicke aus also das mag für eine 08152 ToDo Anwendung ausreichen.

Ob ich da jetzt kritische Infrastruktur dann wirklich auf dieser Basis haben wollen würde oder medizinische Geräte, wo man Leben von abhängt, da würde ich mal ein sehr großes Fragezeichen dran machen. Also insofern, ich glaube schon, dass es noch Programmiersprache geben wird.

Ja und ich... Sehr gut.

Ich habe das auch schon gemerkt, wahrscheinlich wie jeder andere auch, wenn man zum dritten Mal versucht, der LLM irgendwas in natürlicher Sprache zu erklären und sich gesagt hätte, ach, wenn ich das in eine Funktion geschrieben hätte, die einfach aufgerufen hätte, wo es ganz klar eine Anweisung gäbe. Das merken wir. Ich denke aber, die Richtung geht ja auch so, muss ganz viel Code noch geschrieben werden oder...

Vielen

übernehmen die Agents und wir haben dann quasi so eine direkte Steuerung mit den Interfaces, die wir jetzt schon haben, also wo wir dann sehr viele Applikationen einfach gar nicht mehr brauchen, die wir jetzt schon, manche sagen auch so SaaS Services. Viele SaaS Services wird man einfach nicht mehr in der Richtung brauchen, weil das einfach durch Agents dann direkt bedient werden. Es gibt auch eine zweite Geschichte, aktuell von der viele sprechen, das sind die Dark Factories, also das heißt,

dass man wieder so eine Softwareentwicklungsstraße bauen möchte. Also das kommt aus dem Ansatz Light-Out Manufacturing, wirklich aus der, wo man sagen kann, hier wird durchautomatisiert, hier gebe ich eine Anforderung rein und am Ende des Tages kommt das fertige Auto oder irgendein Produkt raus. Und genau so was sieht man jetzt in der Agent-Welt, dass man sagt, ich gebe eine Anforderung rein, es werden Haufen Drucken verbrannt, viele Agenten iterieren darüber, arbeiten daran und dann habe ich das fertige Produkt.

Teilst du diesen Gedanken? Siehst du das irgendwo? Und wie ist deine Meinung dazu?

Halt ich also sind zwei Dinge drin oder zwei zwei Trugschlüsse meines Erachtens der erste oder der zweite Punkt in dem Fall ist es heißt ja Software Entwicklung, nicht Software Produktion und Software Entwicklung zeichnet sich dadurch aus im Kern. Das ist auch so diese uralte Frage.

Ist das eine Kunst oder ist das ein Handwerk? Und diese ganzen Software Factory Software Engineering Software Production Ansätze, die gehen alle davon aus, dass man quasi Software Entwicklung in ein bestimmtes Korsett pressen kann, dass es vorhersagbar wird, dass es schätzbar wird, dass es reproduzierbar wird und so weiter. Das ist die Idee einer Fabrik, dass du Dinge automatisierst, die immer immer immer wieder passieren. Der Punkt ist aber.

dass wir ja eigentlich in der Softwareentwicklung keine Produktion in dem Sinne haben. Weil wenn einmal Code geschrieben ist, muss ich ihn ja nicht nochmal entwickeln, ich kann ihn ja kopieren. Das heißt Softwareentwicklung im eigentlichen Sinne ist ja das, Definition, das Erschaffen von Neuem. Und das wiederum ist was, was halt eigentlich orthogonal zu dieser Anforderung steht, dass du ein immer wiederkehrendes Etwas reproduzierbar automatisiert sozusagen aufgleisen möchtest.

Das ist wie wenn du keine Ahnung nimm Picasso und stell die Frage Ja, können wir eine Fabrik machen oder können wir eine Fabrik bauen, die Picasso Bilder herstellt? Also ja klar, wir können das Bild, was mal gemalt wurde, da können wir natürlich Kopien von Anfertigen automatisiert. Aber wir werden auf dem Weg kein neues Bild bekommen. Und das ist halt die die spannende Frage, ob man das in der Softwareentwicklung überhaupt braucht. Und klar ist, was wir jetzt auch gerade mit Agents im Kleinen sehen. Und das ist ja dann quasi das mit den

Dark Factories im Großen ist natürlich den zehn millionsten HTTP Server. Den muss man vielleicht tatsächlich nicht mehr von Hand schreiben, weil das kriegt die KI ganz gut hin. Das kann ich auch automatisiert in einer Software Fabrik machen. Der Punkt ist, das ist aber bisher auch nur Fleißarbeit gewesen. Da steckt keinerlei intellektuelle Leistung mehr drin. Also das ist einfach schon oft genug gemacht worden. Dafür gibt es genug statistische Vorlage und Kopiervorlagen, was auch immer.

Aber wenn du in dem Moment, du versuchst, etwas wirklich neuartiges zu machen, da funktioniert der Ansatz nicht, weil das halt genau diesem reproduzierbaren ja diametral entgegensteht. Und insofern glaube ich an den Ansatz nicht, weil der sozusagen von der falschen Prämisse ausgeht. jetzt der Code, der immer wieder auf dieselbe Art und Weise geschrieben wird. Ja, das kann man natürlich über KI oder mein wegen eine Software Factory.

automatisiert herstellen, sozusagen. Das ist aber nicht der Teil, spannend ist. Das ist im Endeffekt nur das, was halt bisher auch jede Entwicklerin, jeder Entwickler, halt mehr oder weniger ohne Nachdenken nachts halb drei mal nebenher mit einer Hand und ohne nur mit einem Auge und einem, der eine Gehirnhälfte mal eben runtergetippt hat, weil es einfach nur reine Fleißarbeit ist. Aber das ist ja nicht das, wo die wirkliche Wertschöpfung stattfindet. Und insofern glaube ich,

Hm?

Da gibt es ja auch die Code-Generations-Frameworks,

die dann solche Value-Objekte und sowas einfach für dich generieren. Was für mich immer noch entscheidend ist, wie bekomme ich die Lernschleife dort mit rein? oft ist es so, dass, egal wie lange du diese Anforderungen auf Papier schreibst, wie ausführlich du sein willst in der Tiefe und wie viele Gedanken du dir machst, meine These ist, du wirst es beim ersten Wurf nicht richtig machen. Und diese ...

Vielen

Ja, wirst du auch nicht.

Diese Iteration, dieser Gedanke, das noch mal zu... ...wieder durchzudenken, noch mal andere Flows durchzugehen. Einfach Sachen, an die du zwangsläufig nicht gedacht hast, weil du diese Erfahrung noch nicht gemacht hast. Die sind im Moment, oder vielleicht ist es auch ein Teil von diesen Factories, aber ich glaube, da brauchst du halt immer noch das Business und die Fachlichkeit, um dort dann sich wieder mit der realen Welt abzugleichen.

Mh.

Ja, Mir hat gestern jemand noch was sehr, ein sehr schönes Beispiel auch erzählt, Stichwort Agents, weil natürliche Sprache, was wir eben von hatten, von natürlicher Sprache und Programmiersprache, wie missverständlich natürliche Sprache ist, weil er hatte ein Feature gebaut und wollte dann dieses Feature noch erweitern und sagte dann dem Agenten, ja, kannst du das Feature bitte ausbauen? Ja, das hat die KI gemacht, sie hat es halt ausgebaut im Sinne von verworfen, ja.

So. Rausgenommen,

Das war

dann, ja.

halt nicht das, was gemeint war. Und das ist ja nun noch was, relativ offensichtlich ist, wo du halt direkt merkst, da ist was nicht mehr da, was vorher da war und was hätte erweitert werden sollen. Aber das kann dir ja auch mit sehr viel subtileren, sehr viel kleineren Sachen passieren, wo du gar nicht mitbekommst, dass die KI gerade in eine völlig falsche Richtung rennt. Und alle freuen sich, ach, das ist so toll automatisiert. Und da wird es gefährlich, wenn du nicht mehr weißt, was da passiert. Weil dann ist es so eine magische Kiste.

wo du dann halt davor sitzt und halt hoffst, sie wird schon das Richtige machen.

Da würde ich mich jetzt nicht darauf verlassen wollen. das ist halt im Endeffekt so eine Software Factory oder eine Dark Factory, ist diese magische Kiste in groß. Und es wird nicht besser, indem wir es größer machen. Also es wird eher schlimmer, indem wir es größer machen.

Hm.

Und wenn du jetzt schon teilst,

was du in deiner Praxis siehst, wie fällt denn dein Reality-Check aus? wenn wir die Bubbles LinkedIn, YouTube und so was sehen, es wird sehr darauf hingearbeitet, dass wir weniger Menschen brauchen, sehr viel durch Agents unterstützt werden, voll automatisiert, dass das der nächste Quantensprung ist. Wo stehen wir denn? Also, wie siehst du das denn in deiner Praxis? Du sprichst mit vielen Firmen, du

Mh.

kommst viel mit. Was siehst du dort? Sind wir noch bei Code Completion oder wo stehen wir?

Es sehr unterschiedlich. es gibt zum einen eine Menge Unternehmen da draußen, wo Entwicklerinnen und Entwickler sich mit Händen und Füßen dagegen wehren. So nach dem Motto, nee, ich will doch meinen Code selber schreiben. Mehr als eine zu einem gewissen Grad intelligente Autovervollständigung soll das nicht sein, weil ich bin immer noch die Person, denkt und nicht der Computer. Dann hast du auch die Unternehmen, wo du irgendwas gezeigt bekommst.

Du musst dir dann ganz stolz zeigen, was sie gemacht haben. Du fragst, okay, hätte ich jetzt persönlich anders gemacht? Warum habt ihr es denn so gemacht? Und dann kriegst du so was als Antwort wie, müssen wir auch nicht. ChatGPT hat gesagt, wir sollen das so machen. Wo du denn halt deinen Teil denkst. Ich erlebe bei sehr vielen Entwicklerinnen und die dem Thema KI aufgeschlossener gegenüberstehen, so ein Aha-Effekt.

Wenn man so wegkommt von das ist eine Autovervollständigung in der IDE hinzu, das ist so dein virtueller Sparing Partner, mit dem du dich quasi unterhalten kannst. haben gerade diese Kommandozeilen basierten Tools wie beispielsweise Cloud Code haben. Das ist oft so ein Mind Switch sozusagen, der auf einmal oder so ein Eye-Opener, der auf einmal so eine ganz neue Welt und ganz neue Möglichkeiten eröffnet, wo aber halt ganz wichtig ist, du darfst halt nicht das Denken abgeben, sondern

Die KI muss genutzt werden, dich halt in deinem Denken zu challangen. Und ich glaube, das Schlimmste, was ich im Moment immer wieder sehe, das ist, wenn man das Management genau auf diese LinkedIn und Co-Märchen hört und reinfällt mit irgendjemand hat am Wochenende mal eben nebenher was gevibecoded und ach, wie toll das jetzt alles ist. da wird eine Erwartungshaltung geschürt, die die Realität überhaupt nicht erfüllen kann.

und wo dann auf einmal das Management davon ausgeht oder Product Owner davon ausgehen, dass jetzt auf einmal die hundertfache Entwicklungsgeschwindigkeit an den Tag gelegt wird oder dass man von 100 Leuten nur noch drei bräuchte, denselben Outcome zu haben. Und was dabei halt so gerne vergessen wird, ist zum einen, dass bei diesem, ich habe mal am Wochenende was gevibe-coded, da kräht kein Hahn nach der Qualität.

und wie das Ganze nachher in Operations, ob das stabil läuft und ähnliches. Und der zweite Punkt ist, das was Agenten oder LLMs oder wie auch immer man es nennen will, das was sie beschleunigen, ist das Schreiben von Code. Aber das Schreiben von Code war eigentlich nie das Problem, sondern das Richtige erst mal zu ermitteln, was du überhaupt bauen sollst. Das Ganze auf eine konzeptionell durchdachte Grundlage, ein solides Fundament zu stellen. Das ist das viel Herausfordernde.

Und das nimmt dir die KI halt auch nur sehr, sehr, sehr bedingt ab. Biss halt gar nicht ab. Und wenn du halt nicht weißt, was du bauen sollst und einfach kein solides Fundament hast und keine guten Konzepte, auf denen du aufbauen kannst, dann baust du einfach nur sehr viel schneller deutlich mehr Schrott. Und das braucht halt dieser digitale Schrott, der tut noch nicht genug weh als das...

Unternehmen merken würden, vielleicht ist es doch nicht so eine schlaue Idee, keine Juniors mehr zu holen und die zu investieren, Leute zu entlassen, die langjähriges Fachwissen haben und quasi immer an der Geschwindigkeitsschraube zu drehen, damit wir noch ein bisschen schneller werden, weil dabei die Qualität halt oft hinten runterfällt. das ist so... Ich bin sehr gespannt, wie lange das noch gut geht und wann so dieser... Es gibt ja diesen Gardner Hype Lifecycle.

Wir sind irgendwo auf diesem Hype-Niveau so mehr oder weniger, glaube ich, angekommen. Und die spannende Frage ist jetzt aus meiner Sicht, wie lange dauert es, bis wir in dieses Tal der Tränen abstürzen? Was über kurz oder lang meiner Meinung nach definitiv passieren wird. Die Frage ist nur, wann und wie hart wird der Aufprall werden?

Ja,

was man auch sieht ist, das hatten wir hier in dem Podcast auch schon mal diskutiert, dass unser Tooling, unsere Kapazitäten der Systeme sind ja auf eine andere Menge von Code ausgerichtet. Also eine andere Menge von PRs, eine andere Menge von Scanning-Mechanismen. Und das ist ja das, was GitHub jetzt aktuell auch trifft, ist, dass wir in einer rasenden Menge oder in einer rasenden Geschwindigkeit eine riesengroße Menge an Code plötzlich bekommen.

Und wenn der Rest dieser Delivery Pipeline, ich meine jetzt nicht nur die ICDs, sondern auch die Menschen, dahinter stehen, die das reviewen müssen, dann werden wir am Ende des Tages vermeintlich vielleicht doch nicht schneller werden.

Ja, also wie gesagt, wird das Schreiben schneller und das Schreiben ist das kleinste Problem in der Softwareentwicklung. Und von daher, ich bin gespannt.

Du hast von den CEOs gesprochen und von denen, gerade in USA, sich Menschen werden rausgeschmissen, die sollen durch KI ersetzt werden. oder die letzten Tage ging von Coinbase so ein interessanter Artikel rum, wo die klare Ansage kommt, dass sie die Management-Schichten ausdünnen wollen und die Erwartungshaltung an das Management ist. auch die Nicht-Techies sollen Code in Produktion bringen, was natürlich erst mal zu Aufsturm im Social Media geführt hat.

Das bedeutet aber auch gleichzeitig, und das ist das, ich auch mitbekomme, wir kriegen neue Player mit in unsere Arena sozusagen. die wahren Citizen-Developer kommen jetzt an, die haben auch Zugang zu diesen Tools. Und ich finde das erstmal gut. Also das heißt, wir sind in der Technik ja willkommen. Wir wollen, dass Leute auch Software schaffen. Aber wir kommen mit einem anderen Background dahinter.

Wie schaffen wir das, diese Leute mit zu inkludieren? Muss das Tooling besser werden? Weil es geht nicht nur allein mit Schulungen oder mit irgendwie Beschallungen durch irgendwelche Informationen. Ich glaube, wir kommen auf eine andere Ebene, wo wir auch nicht Engineers haben, jetzt plötzlich, wo die KI sagt, das ist kein Problem, mach das mit Python, hier ist das Skript, ich installiere das und dann läuft irgendwas auf deine Maschine und die Leute davor haben keine Ahnung.

Siehst du das auch?

Nein, Also sehen im Sinne von wahrnehmen, dass das da draußen propagiert wird. Ja, sehen im Sinne von, ich an diese Story glaube, überhaupt nicht. Weil der Punkt ist, natürlich sollten wir mal aufhören so zu tun, als wäre es eine intellektuelle Meisterleistung, wenn jemand eine Vorschleife schreiben kann oder eine IF-Anweisung schreiben kann. Das ist jetzt nicht so übermenschlich kompliziert vielleicht. Auf der anderen Seite

ist Programmieren oder Softwareentwicklung aber halt weit mehr als halt eine Vorschleife und ein paar Ifs drumherum schreiben. Ein ganz wesentlicher Punkt. Und das ist das, was Informatik oder halt Softwareentwicklung so schwierig macht und warum da so viel Zeit vergeht und warum sich damit so viele so schwer tun. Der Kern des Ganzen ist Abstraktion. Und dass du sehr gut abstrakt denken kannst, dass du sehr gut logisch analytisch denken kannst.

dass gedanklich gut auf verschiedenen Abstraktionsleveln gleichzeitig spielen kannst. Und das ist einfach was, das muss dir halt liegen. So wie es halt Leute gibt, die halt gut mit Blumen und Pflanzen umgehen können. Wo man immer so schön sagt, du hast einen grünen Daumen. Ich habe zwar ein grünes T-Shirt an, aber ich habe definitiv keinen grünen Daumen. Ich wäre vielleicht jetzt nicht der weltbeste Gärtner, aber das bei weitem nicht.

Hab's.

Das ist halt so das, was glaube ich dabei übersehen wird, dass zu schnell der Glaube entsteht. Es funktioniert, weil es oberflächlich so aussieht, als würde es funktionieren. Aber wenn du keine Ahnung hast von dem, was da drunter passiert, dann nimmst du gar nicht wahr, welche Probleme es potenziell wie heißt es so schön, die unknown unknowns. Und die sind das, was dir nachher dann potenziell Riesenprobleme verursachen kann.

Mhm.

Und deswegen glaube ich da nicht dran. wenn das alles so wäre, also ich glaube, auch gerade KI gerade eine wunderbare Ausrede ist bei vielen Unternehmen, halt Leute zu entlassen, damit man nicht sagen muss, ja uns geht es wirtschaftlich nicht so gut oder uns ist die geopolitische Lage zu heikel oder was auch immer. Das klingt halt cooler, wenn du sagst, ja, mit KI sind wir jetzt irgendwie 1000 Mal effizienter als vorher. Aber wenn das alles so einfach wäre, das ist immer so dann meine etwas ketzerische Frage.

Warum stellen denn dann Unternehmen wie Anthropic und Open AI und Google massenhaft Leute ein? Die suchen für den AI-Bereich. Warum? Wenn die AI so toll ist und das alles alleine könnte und jeder hinz und kunst ohne jegliche Informatik-Erfahrung das bewerkstelligen könnte. Also da könnten sie das... Erstens, warum suchen sie überhaupt Leute? Und zweitens, könnten sie die Leute, die sie suchen, viel billiger haben, als sich die...

Hm.

die hochspezialisierten Experten und Expertinnen zu suchen. Und wenn das bei denen schon nicht funktioniert, die ja an der Quelle des Ganzen sitzen, warum sollte es dann beim Rest funktionieren? Also das überzeugt mich irgendwie nicht so richtig, Storyline sozusagen.

Interessante Frage. Ich würde ja trotzdem noch mal da reingehen. Haben wir jetzt vielleicht so einen Moment wie damals bei den Digitalkameras und bei den Telefonkameras, wo man früher gesagt hat, hier brauchst du eine Ausbildung, Fotograf zu werden. Und jetzt habe ich in meinem Handy eine hochauflösende Kamera, die genauso gute Bilder schießt, ohne dass ich das ganze Wissen haben muss, dass ich eine Ausbildung brauche.

Ja.

haben wir hier so ein Baumarkt-Momentum, wo wir wirklich gefährliche Geräte für dich und mich einfach so zur Verfügung stellen und ich kann dann plötzlich auch sägen und ich brauch dafür keine Ausbildung und so was. Sind wir nicht an der Schwelle zu so einem Change jetzt gerade, dass wir einfach noch mit unserem Ego jetzt kämpfen müssen, weil wir die Ingenieure sind und sagen, ja, wir haben das noch gelernt, wir wissen, wie es richtig geht und kann ich auch ein bisschen fühlen.

Mhm.

Ich was du Ich glaube, das hängt sehr stark an der Frage, was ist gut genug? Weil, also gerade Fotografie ist ein schönes Beispiel dafür. Also natürlich ist es sehr viel einfacher geworden für jemanden, keine Ahnung von Fotografie hat, gut aussehende Bilder zu machen und Bilder zu machen von denen vor 30 Jahren. Da hättest dir einen Profifotografen holen können, hättest dich von zu träumen gewagt.

Insofern hat das natürlich schon zur Demokratisierung und zur Verbreitung der Fotografie beigetragen. Jetzt ist der Punkt aber zum einen, ob du jetzt gute Fotos machst oder nicht, da hängt nicht so viel ab von. Also das ist das Schlimmste, was passieren kann. Ja, du hast halt nicht so tolle Fotos gemacht. Das ist der eine Punkt. Der zweite Punkt ist, dass es ja trotzdem immer noch professionelle Fotografinnen und Fotografen gibt. Ich glaube nicht.

dass wenn Taylor Swift oder BTS auf Welttour gehen, dass die dann sagen, lass mal auf die professionellen Kameraleute und Fotografinnen Fotografen verzichten, irgendwie der Nachbarssohn von meinem Neffen, der kann das auch, der hat ein iPhone. Ja, lass denen das einfach. Also die Story geht ja irgendwo nicht auf. Das heißt, es gibt einen gewissen Anspruch. Da brauchst du immer noch Leute, die ihr Handwerk beherrschen. Und es ist halt dann doch mehr als nur der Apparat.

sozusagen und das jetzt auf Software übertragen. Das wirft halt die Frage auf. Also das heißt zum einen es wird immer Bereiche geben, nämlich da, wo die KI schwächelt, nämlich immer das, wo es keine statistische ausreichende Grundlage gibt, sondern wo es Spezialfälle, Extremfälle, Ausnahmesituationen, wirklich neue Dinge geht. Da wird die KI dir nicht groß helfen können. Da wirst du Leute haben müssen, die sich halt mit dem Thema wirklich, wirklich, wirklich gut auskennen.

Und der zweite Punkt ist, dass bei Software dieses gut genug schnell nach hinten losgehen kann. Weil anders als bei einem Foto, was du halt machst und was dann halt neben deinen anderen 17.395 Fotos auf deinem Telefon rumgammelt, die Software, die du halt so baust und in Betrieb bringst, die führt halt vielleicht dazu, dass dein Unternehmen paar Hunderttausend Euro verliert oder ein paar Millionen oder das...

Leib und Leben von jemandem beeinträchtigt. Also im schlimmsten Fall, dass jemand stirbt. Deswegen, weil vielleicht war es doch nicht so eine gute Idee, den Herbstschrittmacher von irgendjemandem entwickeln zu lassen, der das Vibe-Coded. Und das ist halt so die Frage. Jetzt entwickelt natürlich nicht jeder oder jede, die oder der Software entwickeln, einen Herbstschrittmacher oder Software für ein Atomkraftwerk oder solche Sachen. Aber das sind so die extremen Beispiele, wo, glaube ich, sehr schnell sehr deutlich wird. Wo man sich fragen kann, hm.

Ist das oder wäre das so eine gute Idee, da dann zu sagen, wer braucht schon noch Softwareentwickler? An die Story, also ja, wie gesagt, das glaube ich nicht so richtig. Aber klar, solange es halt so 0815 Sachen geht wie ich habe hier meinen Raspberry Pi, da hängt ein Temperatursensor dran und ich will eine HTTP API haben, wo ich mit einer App auf meinem Telefon nach der Temperatur im Garten zu Hause gucken kann. Jo, dafür werde ich wahrscheinlich keinen Softwareentwickler mehr brauchen.

Das ist aber auch ein schon 1000 mal gelöstes Problem. da schließt sich der Kreis zuvor hin, wo ich sagte, das ist halt auch keine Softwareentwicklung in dem Sinne mehr. Das ist wirklich Softwareproduktion, weil das gibt es schon. Das ist nur Fleißarbeit, das zusammenzutragen. Aber selbst da weiß die Person, die das ohne Hintergrundwissen macht, die ist nicht in der Lage zu verifizieren, was das potentiell unter der Haube für Sicherheitslücken, für Schwachstellen, für Performance, Engpässe.

Mwe.

Ja.

oder oder oder mit sich bringt. Und da wird es halt unter Umständen gefährlich.

Wie setzt du eigentlich KI in deinem täglichen Leben ein? Was empfiehst du deinen

Also ich glaube der eine beste Tipp, den ich habe und das ist zumindest so das, was auch glaube ich im Wesentlichen gut beschreibt, wie ich mit KI umgehe, ist die KI, ich habe es vorhin schon mal gesagt, also nicht das Denken an die KI auszulagern, nicht zu sagen hier liebe KI, ich will das und das machen, mach mal, sondern die KI zu nutzen, dein eigenes Denken herauszufordern, also zu sagen hier liebe KI, ich will das und das das machen, das und das habe ich mir als Ansatz überlegt.

Stell mir dazu mal kritische Fragen. Und das meinte ich vorhin so mit Virtual and Sparing wo jemand vielleicht daneben dir sitzt und dann so das Vier-Augen-Prinzip so, ja, aber warum machst du das denn jetzt so? Hast du mal drüber nachgedacht, dass man das auch anders machen könnte? Was ist denn mit dem Fall? Und so weiter. Und wenn du das machst, dann bringt es dich dazu, mehr oder intensiver und tiefer über dein Problem nachzudenken, weil du auf Fragestellungen kommst, auf die du

ohne externe Hilfe. Und da ist es eigentlich ziemlich zweitrangig, dass das eine KI und kein Mensch ist, weil du ohne jemand externes nicht sozusagen auf diese Fragestellung gekommen wärst, weil du halt einfach alleine in deinem Tunnel bist und halt in deinem stillen Kämmerlein und manchmal vergisst nach links und nach rechts zu gucken. Und das ist, glaube ich, so das das Wichtigste, was man machen kann, dass wenn man jetzt zum Beispiel bei einer Softwareentwicklung, dass wenn man ein Feature entwickeln will, dass man halt nicht das Feature beschreibt und dann sagt, so jetzt schreibt mal den Code, weil

Dann sind wir wieder bei hoffentlich kommt das richtige bald aus, sondern vielleicht eher zu sagen hier, ich will das und das Feature umsetzen. Ich habe mir die und die Struktur überlegt. Was hältst du denn davon? Und es dann durchzudiskutieren, wenn man das dann mal zwei Stunden gemacht hat und man dann ein sehr viel klareres Bild hat von wo man eigentlich hin will, dann kann man vielleicht auch der KI sagen, okay, so wie wir das jetzt besprochen haben, setzt das mal so ⁓ Aber dann bist du auch in der Lage.

das was die KI gemacht hat im Hinblick darauf zu reviewen ob das deinen Vorgaben entspricht. Wenn du nämlich einfach nur sagst hier das und das will ich haben mach mal hast du ja gar keine Vorgaben gegen die du es sozusagen überprüfen könntest. Und das ist finde ich so das ganz große Problem wenn man so in Richtung komplett Vibe-Coding auch geht. Du hast vorhin angesprochen dass die Reviews nicht mit skalieren im gleichen Maße wie wir Code produzieren. Es ist ja noch schlimmer wenn ich den Code gar nicht kenne.

kann ich den Review ja in vielen Fällen gar nicht sinnvoll machen, weil ich gar nicht weiß, ob das in der Software im Code an den richtigen Stellen andockt und dann wird halt so ein Review ganz schnell zu, dann winke ich es halt durch, wird schon gut gehen und dann kann ich mir den Review im Grunde genommen auch sparen. Von daher, also das mehr so als virtuellen Sparing-Partner zu nutzen, der dir im positiven Sinne dumme Fragen stellt. Das ist, ich, so der

der Haupttwist und natürlich klar bei Dingen, die du wirklich automatisieren kannst, die immer wieder gleich ablaufen. Natürlich kannst du dann auch irgendwann auf den Skill ausweichen und das Versuch mit der KI zu automatisieren. Aber das sind dann, glaube ich, relativ überschaubare Fälle.

Interessanter Use Case. hatte das mal auf einer Konferenz. hat der Speaker angefangen, hat gesagt, wie ich LLMs nutze. Ich sag ihm erst das Ergebnis und dann stelle ich ihm die Fragen. Und alle haben natürlich sich gefragt, warum erst ihm das Ergebnis sagen, wenn du gar nicht das Ergebnis weißt. Aber ich glaube, das geht genau in diese Richtung, die du gerade beschrieben hast.

Vielen

Mhm.

auch das ganze Wissen, das Internet ein bisschen einzugrenzen, sagen, hierüber möchte ich jetzt sprechen und gib mir deine Einschätzung, sag mir zwei, drei Ansätze, wie ich das verändern könnte. Wissensaufbau auch, also was hast du da gemacht und wie ist das gut, was dort rauskommt? Sehr mächtig.

also quasi so das rumdrehen nicht du stellst der k i fragen sondern benutzt die k i dir fragen stellen zu lassen dass da auf die formel kann man es glaube ich ganz gut unterbrechen

Aber so Standardcode lässt du die auch generieren.

Ja,

aber das ist halt der springende Punkt. Ich habe den Anspruch, dass ich den Code, generiert wird, lesen und verstehen können möchte. Also es darf nur eine Schreib oder eine Tipp Beschleunigung sein. Ich gucke mir auch an, was dann auf dem Wege passiert. Und wenn ich dann halt an Stellen stoße, wo ich denke, na ja, das hätte ich jetzt aber anders gemacht oder ich verstehe nicht, was die KI da gemacht hat, dann ist das eine ganz große Red Flag. Dann musst du da an der Stelle sofort innehalten.

und noch mal drei Schritte gedanklich zurücktreten. Weil wenn du das nicht verlierst du die Kontrolle. Und dann, wenn es irgendwann einen Fehler gibt, wenn ein Bug auftritt, dann bist du ja auf Gedeih und Verderb dem System, also der KI ausgeliefert, diesen Fehler zu finden und zu beheben. Und dann lässt du halt das System, was den Fehler produziert hat, den Fehler finden und ihn beheben. Und du kannst die Fehlerkorrektur ja noch nicht mal nachprüfen.

Mhm.

Weil du kannst zwar gucken, ob der Fehler raus ist, aber hast keine Ahnung, ob das, was die KI jetzt geändert hat, welche sonstigen Effekte das vielleicht in deinem Code hat, weil du den Code gar nicht mehr überblickst. Und deswegen, Gottes Willen nicht das Denken und das Ganze, das Projekt Überblicken und das Verständnis dafür, das Himmels Willen nicht auslagern. Das ansonsten, das endet in einer Katastrophe. Das wird vielleicht eine Weile dauern, aber es wird in der Katastrophe enden

Also klare Worte.

Und da bin ich gespannt, wer die ersten sind, dann am rumheulen sind, dass es eine Katastrophe ist.

Wir können gespannt bleiben. Du hast schon oft gesagt, die richtige Fachlichkeit abzubilden. Das wirst du auch Software entwickeln, nicht nur coden. Wie kommen wir denn zu der richtigen Fachlichkeit? Was sind denn solche Konzepte, die dir deinem Alltag helfen?

Hab nicht so meine These, aber warten wir mal.

Ja, im Prinzip, also das ist ja eigentlich auch kein neues Thema, dass Software sich mehr um fachlich, also wir sollten, das ist ja so der Standardsatz von mir, Software, sollten Software nicht bauen, weil zu geiles Software zu bauen, sondern wir sollten Software bauen, um ein fachliches Problem zu lösen. Und das funktioniert halt einfach besser, wenn du das fachliche Problem verstanden hast. Und das ist halt keine technische Aufgabe. Und das ist der Grund, warum wir uns als Branche da halt seit 10, 20, 30, 40, 50 seit immer.

so schwer mit tun, weil wir sind ja nun mal, das war eine bewusste Entscheidung von uns ein, in die Technologiebranche gegangen, weil wir uns halt für Technologie begeistern. ja, wenn ich jetzt Software für, also ich hab mich gestern mit jemandem darüber unterhalten, das fand ich ein sehr lustiges Beispiel, wenn du jetzt Software für eine Waschmaschine baust, Software, eine Waschmaschine steuern soll, wo du dir denkst, wie schwer kann das schon sein? Und wir kamen dann drauf, stell dich mal vor, deine Waschmaschine, also ich glaube, jede und jeder

jetzt von den Zuschauerinnen, Zuhörern, die hier dabei sind. Jeder besitzt eine Waschmaschine oder benutzt zumindest regelmäßig eine Waschmaschine. Macht euch mal Spaß, stellt euch mal vor eure Waschmaschine und guckt mal, wie viele Programme die hat. Pflegeleicht, Baumwolle, Nurwolle, Unterwäsche, sonst was.

Hoffentlich.

30 Grad, 40 Grad, 60 Grad, 90 Grad, mit 800 Umdrehungen schleudern, mit 1000 Umdrehungen, mit 1200 Umdrehungen, mit Öko-Waschgang oder ohne Öko-Waschgang, mit einer Einfüllkammer oder mit zwei Einfüllkammern. Da gibt es unglaublich viele Kombinationen. Dann erklären wir mal, wann welche Kombination am besten ist. Da merkst du, dass du wahrscheinlich keine Ahnung von deiner Waschmaschine hast.

weil du dir halt eigentlich immer auf dieselben ein oder maximal zwei Programme einstellst und du machst dunkle Wäsche und helle Wäsche und Thema erledigt. Und das zeigt, dass selbst in so was Lapidarum wie einer Waschmaschine ja eigentlich eine Menge Know-how, sehr viel mehr Know-how drin stecken würde, als man so allgemein tagtäglich annimmt. Und da ist jetzt die Frage, wenn du jetzt Software für eine Waschmaschine programmieren sollst.

wäre es dann nicht sinnvoll, das vielleicht zu durchschauen und zu verstehen, warum man manche Sachen vielleicht auf 30 Grad und manche auf 90 wäscht und was der Unterschied zwischen Pflegeleicht und Baumwolle und Wolle und Dessous und so weiter vom Waschgang ist und wann der Ökomodus Sinn macht und wann nicht und so weiter. das ist aber keine technische Frage mehr im Sinne der Implementierung. Das ist dann rausgehen und den Waschmaschinenhersteller oder Designer fragen.

Was steckt denn da dahinter? Dann sind wir auf einmal bei, erklär mir mal deine Welt. Dann wirst du mit Begriffen die Ecke kommen, die ich noch nie gehört habe. Irgendwas von Phosphaten erzählst du mir dann vielleicht. Ich weiß, okay, irgendwas Chemie in der Schule werde ich wohl mal was mit Phosphaten zu tun gehabt haben. Ich habe keine Ahnung, was Phosphate sind, aber sie sind, glaube ich, in Waschmittel drin. Wofür brauche ich die genau? Welchen Einfluss haben die?

Und erst wenn ich das so wirklich verstanden habe, und da sind wir halt schnell auf dem Punkt, wo es halt ⁓ aktives Zuhören geht, Dinge hinterfragen, sich auch mal trauen, vermeintlich dumme Fragen zu stellen, da sind wir inzwischen menschlicher Kommunikation, Zuhören, Empathie, all diese Themen, das ist alles halt sowas von un-technisch. Und deswegen haben da so viele dann auch keine Lust, sich mit zu beschäftigen, weil dafür müsste man ja aus seiner technischen Sitzkuhle, aus seiner Komfortzone raus.

Das ist so schön viel einfacher über ist jetzt React oder Angular cooler zu diskutieren, aber das ist halt nicht zielführend und genau das so dieses Erklär mir mal deine Welt. So ich habe keine Ahnung davon und es muss ja jetzt keine Waschmaschine sein. Ist völlig beliebig, was du da als Beispiel nimmst. Nimm halt ein Sägewerk. Wie arbeiten die? Wie wird so ein Brett produziert? Wie entsteht aus einem Baum ein Tisch? Weiß ich nicht. Also was es da im Detail zu beachten gibt.

Welche Sägeblätter und mit welchen Rotationsgeschwindigkeiten und Sicherheitsmaßnahmen und und. Erklär mir deine Welt. Im Prinzip, was du dafür brauchst, ist eigentlich nur so Offenheit und die Neugier wie so ein kleines Kind, was in die Welt rausgeht und alles irgendwie spannend findet und staunt. Und das muss man sich halt bewahren. Und das ist das, was dir unheimlich hilft, wenn du Fachlichkeit verstehen willst.

und das bewusste sich lösen von, geht nicht darum, du das nachher mit einer Datenbank oder einer Message queue oder mit einem Monolithen oder einem Microservice oder mit welcher Programmiersprache du das Ganze implementierst. Das ist nämlich nur das Mittel zum Zweck. Aber wir tun in der IT-Branche so gerne, als wäre die Technologie ein Selbstzweck. Und das ist es halt nicht.

Viele sagen dazu start from the customer oder backwards vom Kunden kommen, also dass man wirklich dort versteht, wie wird das denn eingesetzt und dann gilt es auch oft zwei- oder dreimal zu fragen, weil die Kommunikation, sprechen ja unterschiedliche Sprachen, wir Techies und die Leute, die dann einfach die Waschmaschine bedienen und auch da gibt es dann halt Frameworks und Sachen, die uns helfen, die uns guiden.

Vielen Dank.

Hm?

Was ich allerdings sehe, ist, das ist eine Erfahrungsskill. Das ist eine Sache, das kriegt man nicht auf anhieb hin Auf der einen Seite darüber zu sprechen, kriegt man hin, neugierig zu sein. das dann in was zu mappen, was wirklich ausführbar ist und was das auch trifft. Die Junior-Senior-Diskussionen haben wir ja schon gehabt. Wie unterstützt du jetzt Firmen, dass sie da nicht irgendwie so einen Misserfolg ...

Mh.

Hmm?

Die haben sich jetzt entschieden und ich pick jetzt mal eine Methode, Domain Driven Design. Magst du auch? Da gibt es ein blaues Buch, was sehr abstrakt das ganze in vielen Seiten niedergeschrieben hat. Ich lese mir das durch im Wochenende. Komm rein, hab keine Erfahrung, sag in meinem Unternehmen, heute machen wir Domain Driven Design und es geht erstmal richtig nach hinten los. Hast du da?

Ja.

Mh.

Tipps, wie man diesen Blues umgehen kann

Ja, es gibt einen schönen Satz, geht auf die Navy Seals, soweit ich weiß, Der heißt, Slow is Smooth and Smooth is Fast. Im Sinne von, naja, man sieht es da hinten, da steht ein Tasteninstrument, ich spiele Klavier. Und wenn du zum Beispiel ein neues Stück lernst, das hat eine gewisse Geschwindigkeit, dann ist der 0815 Standard-Tipp, was hier jede Klavierlehrerin und jeder Klavierlehrer sagt, spielst erst mal langsam.

Weil wenn du es langsam machst, dann kannst du erstmal deine Finger sortieren und dann findest du raus, wann du wie umgreifen musst und welcher Fingersatz am besten passt und so weiter. dann kannst du erstmal dich darauf konzentrieren. Und das geht dann so nach und nach. Lernst du das? Das geht so ein bisschen in der Muscle Memory über und dann kannst du es ein bisschen schneller machen, weil du dann es geschmeidig sozusagen hinbekommst. Und je öfter du es dann spielst, desto schneller wirst du irgendwann. Und dann kannst du es irgendwann in einer

sehr hohen Geschwindigkeit spielen, aber trotzdem sauber. das, was die meisten halt falsch machen, ist an der Stelle halt, sie wollen zu schnell zu viel, die versuchen halt gleich das Tempo drauf zu kriegen. dieses Beispiel, das kannst du auf alles Mögliche übertragen. Und das gilt halt hier auch. Also ich würde gar nicht mit dem Anspruch dran gehen, dass wenn ich jetzt so eine Domäne habe und die will ich modellieren und ich habe mich jetzt für die DDD entschieden, ich hätte gar nicht den Anspruch, dass mein erstes Modell gut ist. Wird es

Egal wie du es machst, es wird nicht gut sein, weil du so viel unterwegs erst noch lernen wirst, über wie du an bestimmte Dinge dran gehen kannst. Und da ist jemand von außen, der dich bisschen an die Hand nehmen kann und der schon mal gewisse Fragen stellen kann aus Erfahrungswerten und so. Das ist natürlich hilfreich, aber du bist ja in vielen Situationen vielleicht gar nicht in der Lage, die adäquate Antwort zu liefern. Entweder weil du sie nicht kennst oder

weil du noch gar nicht verstehst, worauf die Frage letztlich abzielt, weil du noch gar nicht siehst, was sozusagen die Tragweite deiner Antwort kannst du noch gar nicht einschätzen. Und das wiederum kann aber jemand Außenstehendes nicht beurteilen, weil er kennt die Antwort ja nicht. Also er weiß ja nicht, wann die Antwort in dem Sinne richtig gibt in der DDD-Welt, gibt es den schönen Satz, all models are wrong, some are useful. Und insofern

Lebt damit. Also das ist normal, dass es am Anfang nicht gut sein wird und dass es halt einfach seine Zeit braucht. Aber wenn du dir halt, wenn du sozusagen zu dir selber ein bisschen nachsichtig bist und dir halt Zeit gibst und halt vielleicht von vornherein startest mit, wir machen es mal, aber wir machen es nicht mit dem Anspruch, unsere erste Version ist das, was wir nachher ausliefern, sondern wir machen es mal einfach nur mit dem Ziel, Erkenntnis gewinnen zu haben. Und dann schmeißen wir es weg und dann machen wir es nochmal neu. Da wird mehr bei rauskommen.

Okay.

Hm.

Und das meine ich mit Slow is Smooth and Smooth is Fast. Und du musst quasi erst mal auf die Bremse treten, später durchstarten zu können. Und da kommt dann oft der Einwand, ja, das dauert aber zu lange, das können wir uns nicht leisten. Ja, und das sind, ich glaube, den Witz oder die Karikatur kennen ganz viele von diesen Leuten im Wald, die mit einer stumpfen Säge versuchen, Baum zu fällen, wo jemand vorbeikommt und sagt, schärft doch mal eure Säge, die ist auch total stumpf. Und wo sie dann sagen,

Nee, keine Zeit, wir müssen Bäume fällen. Das ist genau dasselbe in Grün.

Ganz genau. Und wie navigierst du denn

solche Situationen, wenn du bei einem Kunden bist? Also ich für mich male ich jetzt ein Bild, Team programmiert schon seit Jahren an irgendeiner Lösung, die kommen mit ihrer Architektur an die Grenzen und dann ist jetzt wirklich einer, der kommt von der Konferenz, hat das Buch gelesen, hat gesagt, ja wir machen DDD und

Ja.

Ein Haufen halbwissender Leute steigen jetzt mit ein und die merken, jetzt kommen wir wieder an Grenzen. Dann haben sie diesen Podcast gehört, haben gesagt, ja, das erste Modell musst du wegwerfen. Und die sagen dann zu ihrem Product Owner, Project Manager, ja, das ist doch ganz dauert jetzt doppelt oder dreifach zu lang, weil wir müssten mindestens drei bis vier Modelle wegwerfen und dem geht die Farbe aus dem Gesicht. Das sagt hier, wir haben Deadlines, wir haben hier ein Budget. So läuft das nicht. Und du sitzt mittendrin. Wie entschärfst du diese Situation?

Hm? Hm?

Mh.

Mh? Mh? Mh?

Ja.

Also Punkt Nummer eins, das muss natürlich vorher mit dem Project Owner oder Product Owner, mit dem Project Manager, wie auch immer, der muss mit im Boot sein, weil das ist so ein Kardinalsfehler, der gerne gemacht wird, zu sagen, ja, hier Fachlichkeit und DDD, das ist ein Entwicklungsthema, sollen sich die Entwicklerinnen und Entwickler drum kümmern, das Management drum herum und der ganze Rest vom Unternehmen hat damit ja nichts am Hut.

sollen die gucken, wie sie zurechtkommen. wenn die dann auf einmal feststellen, hey, wir haben wirklich Erkenntnisgewinn und wir müssten jetzt gewisse Entscheidungen nochmal über Bord werfen und revidieren und nochmal nachfragen und nochmal eine Iteration drehen, ja klar kommen dann Rückfragen so, äh, warum dauert denn das so lange, warum ist denn das so teuer? Aber die kommen ja nur, weil dir der Irrglaube vorherrschte, dass das ein reines Entwicklungsthema wäre. Das heißt, wenn du das von vornherein startest mit dem Bewusstsein auch bei

meinst wegen dem Product Owner oder dem Project Manager, das ist kein gradliniger Weg, den wir da gehen, sondern das ist ein Weg, den wir in Iterationen gehen werden und wir werden die ersten 1-2 Iterationen nur machen das Erkenntnisgewinn willen, das Lernungswillen, dann kommt die Frage auch nicht auf. Also das ist Punkt 1. Das ist ein ganzheitlicher Ansatz. Das wird so gerne vergessen.

Ja und der zweite Punkt ist natürlich, DDD ist auch zugegebenermaßen, du hast eben schon das etwas unglückliche Blue Book erwähnt, was super abstrakt und sehr wenig zugänglich geschrieben ist. Ich finde das, by the way, so ironisch, dass DDD als eine Methodik, die sich ja auf die Fahnen schreibt, so hey, lass uns ⁓ gute Kommunikation und gemeinsames Verständnis und Empathie und so kümmern, dass die daran scheitert, wie sie vermittelt wird. Das ist so...

Also mehr Ironie geht nicht. Also wenn du DDD auf DDD anwenden würdest, käme nicht DDD bei raus Weil DDD einfach so so dermaßen überakademisiert und überverkopft teilweise, wie es verkauft wird zumindest. Und der Punkt ist halt, also das kann sehr frustig sein, sich da einzuarbeiten. Es gibt sehr wenig Literatur. Vieles von der Literatur ist, wie gesagt, nicht besonders welcoming.

Es gibt wenig gute Beispiele für das Ganze und das ist sehr mühsam. Du hast es vorhin ein Erfahrungskill genannt und das ist nichts, was du dir mal über Nacht anlesen kannst, sondern was du dir mühsam erarbeiten musst. Und was halt ganz wichtig ist, ist, und das ist so ein Standardding, was ich Unternehmen auch immer wieder sage, fangt nicht an mit eurem Hauptprodukt das zu machen, sondern sucht euch irgendeine eine ganz kleine Baustelle.

wo ihr das mal ausprobieren könnt, wo es im dümmsten Fall, wenn es komplett schief geht, kein Riesendrama ist, wenn es schief geht, wo aber, wenn es funktioniert, ihr ein nettes Aushängeschild habt, wo ihr vielleicht ein Problem löst, was seit 20 Jahren alle im Unternehmen nervt. Und es ist, vielleicht ist es nur eine Kleinigkeit, aber wo dann auf einmal Leute kommen und sagen, das ist ja toll, dass das endlich jetzt mal geht, wir haben dir das gemacht. Und wenn du dann mit der Antwort kommst, ja.

Wir haben da DDD angewendet und wir haben halt unsere Entwicklungsansätze mal geändert, dass wir mehr auf die Fachlichkeit gucken, blablabla. Dann kommen die Leute, weil sie es auf einmal wollen und nicht, weil es von oben aufoktoriert wird. Und das ist auch so ein Kardinalsfehler. Du kannst DDD nicht einführen, indem du sagst, so liebe 2000 Entwicklerinnen, Entwickler, die ich hier in meinem Unternehmen habe, ihr macht jetzt ab morgen alle DDD. Wir haben Workshops gebucht. Macht das bitte und dann legt los. Das ist mit Anlauf gegen die Wand rennen.

Mhm.

So wird das nicht funktionieren.

wird aber leider zu oft so gemacht in vielen Bereichen. Das heißt, du brauchst irgendwie so

dieses Leuchtturmprojekt. Ich mag den Begriff nicht besonders, halt was Kleines, was eine gewisse Strahlkraft hat, wo dann Leute von sich aus kommen, die neugierig sind und die dann sagen, das ist so toll, das will ich auch. Dann kannst du gewinnen sozusagen. Dann kannst du das verbreiten. Das ist auch einer der Gründe, warum

DDD ich meine, ist ja nicht neu, das gibt es jetzt auch seit fast einem Vierteljahrhundert, warum sich das nicht in Mainstream durchgesetzt hat, weil es halt nicht technisch ist, weil es an ganz viel zwischenmenschliche Skills anknüpft, wo ich sag mal zumindest zu viele in der Tech-Branche keinen Bock drauf haben, was eine gewisse Unternehmensstruktur voraussetzt, die oftmals nicht gegeben ist oder wo du nicht in Situation bist, es ändern zu können.

Und da müssen schon einige Faktoren zusammen kommen, damit das funktioniert, weil es halt nicht einfach nur die nächstbeste Entwicklungsmethodik ist. Und das ist halt leider schwierig.

Ein interessanten Seiteneffekt, ich oft beobachte, dass wenn du dich mit dem Business dann unterhältst, wird man auch intensiver die Prozesse, die man abbildet, beleuchten. Und je länger diese Prozesse in der Produktion, also die Prozesse schon etabliert sind,

⁓ so schwieriger wird es Leute zu finden, die die ganzen Prozesse verstehen. Die dann einfach nur das abspulen, was sie immer abspulen. Und wenn du zwei, drei Fragen stellst, oder je größer die Konstrukte ist, hast du nicht eine Person, die die ganze Kette überblicken kann. Und das führt oft dazu, dass man auch über diese Prozesse noch mal nachdenkt. Was natürlich auch wieder dann später jetzt in so einem AI-Fall hilft, diese Sachen genauer zu beschreiben. Ich muss erst mal verstehen, also auch dort wieder diese Anforderungen.

Hm?

Mhm.

müssen

verstanden werden und das Business muss natürlich auch diese Prozesse verstehen. Und ich glaube, das ist ein sehr interessanter Effekt.

Da ist auch so dieser, es geht auf Henry Ford angeblich zurück, so dieses, was der Kunde will, was er dir erzählt, ist nicht das, was er braucht. Und genau den Punkt, was du gerade gesagt hast, wenn du dir dann fragst, wie sehen denn eure Prozesse aus? Du kriegst nie erzählt, wie der Prozess aussieht. Du kriegst immer nur erzählt, wie die jeweilige Person diesen Prozess individuell lebt. Frag drei Leute, du kriegst fünf Antworten. Und da zwischen den Zeilen zu lesen und dann überhaupt mal rauszufinden, was ist denn überhaupt deren gemeinsamer Standard?

Mhm.

Ja.

Ja.

Und warum machen die das? Was ist der Sinn davon? Und könnte man das nicht vielleicht... Wie erreicht man diesen Sinn? Wie kann man den möglichst effizient erreichen? Und dieses immer wieder nach dem Warum-Fragen, nach der Intention, das ist die Geheimwaffe, Anführungszeichen an der Stelle, Umverständnis aufzubauen und sich halt nicht mit der erstbesten Antwort zufrieden zu geben. Das ist halt auch wieder mühsam.

Ja, sehr

diese Sache oder dieses Statement, wir lösen Probleme als Entwickler auch ein bisschen schwierig, weil oft ist es so, dass zwar wir Probleme geschildert bekommen, aber unsere Aufgabe ist das noch zu übersetzen. Also wir bringen unser Engineering-Wissen rein, wie Systeme aufgebaut werden, wie Datenflüsse modelliert werden. Und wir sollten keinesfalls eins zu eins das, was wir geschildert bekommen, einfach so.

Hm?

Ja.

Also dieses

Problem lösen, wir geschildert bekommen. Also so ein typisches Beispiel ist, mach mir hier ein Feld rein, wo der Owner drinsteckt. Kein Problem. In einem halben Tag habe ich das Feld, da schreibe ich den Owner rein. Und auf der Gegenseite impliziert das eine Freigabe, eine Ownerschaft, eine Freigabe Workflow, vielleicht irgendwie eine Historie, die dahinter hängt. Also diese ganzen Sachen, die hinten dranhängen. Und es wird das Problem kommuniziert, ich brauche hier ein Feld nur. Super easy, ganz schnell zu machen. Und deshalb...

Mh.

Ja.

Ja.

sollten wir also dringend diesen Übersetzungsschicht, das ist ja unser Value, dann wieder als Engineer mit reinbringen.

Ja. Ja. Ja,

also das ist auch ein lustiger Punkt, weil da ist auch wieder dieses Warum Fragen sehr hilfreich, weil du kriegst oft gar nicht das Problem geschildert, sondern die vermeintliche Lösung. Also genau dieses Jahr machen wir mal hier ein Feld für den Owner rein. Warum? Wofür brauchst du das? Wozu ist das gut? Dann muss die Person erst mal erklären. Und dann ist das dein Hebel, über den du rausfinden kannst. Okay, wenn ich da jetzt bewusst zuhöre.

und mal ein paar Mal nachhake, was will die denn eigentlich wirklich? Was ist denn eigentlich der Painpoint dahinter? Und dann kannst du eine viel bessere, also häufig eine viel bessere Lösung bauen. Aber das ist so schwierig, weil generell Leute immer meinen, sie würden ihr Problem schildern, tun sie aber gar nicht. Sie kommen mit der vermeintlichen Lösung. das ist, ja, das ist halt auch, es braucht viel Hartnäckigkeit, viel Frustrationstoleranz, aber es lohnt sich halt am Ende des Tages, weil du nur so auf den eigentlichen Kern.

Ja.

der ganzen Sache halt wirklich vorstoßen kann.

Domain Driven Design wird oft mit Event Sourcing kombiniert, das ist auch ein Schwerpunktthema von dir, du hast sogar eine eigene Datenbahn geschrieben. Wann war denn Event Sourcing, wann ist das so in dein Leben gekommen und woran hast du gemerkt, das ist was, da muss ich tiefer reingehen und vielleicht für die Leute, es nicht kennen, ganz kurz mal anreißen, was das eigentlich ist.

Mhm.

Ja,

also ich glaube, ich könnte behaupten, so mit sechs Jahren oder so ist Event Sourcing in mein Leben getreten, weil also jede und jeder nutzt tagtäglich Event Sourcing. Die meisten wissen nur nicht, dass das Event Sourcing heißt, nämlich so wie die Bank euer Girokonto verwaltet. Das ist Event Sourcing, also dass die Bank nicht hingeht und den Kontostand speichert.

Und immer wenn was eingezahlt oder abgebucht wird, dass der aktuelle Kontostand mit einem Update überschrieben wird und wenn das Konto irgendwann aufgelöst wird, dann wird das Konto halt mit einem Delete gelöscht und dann ist es weg. Weil das wäre sehr traurig, wenn die Bank das so machen würde, weil dann guckst du irgendwann auf dein Konto, stellst fest komisch, da ist viel weniger Geld drauf, als ich gedacht hätte. Du rufst die Bank an und fragst Leute, wo ist denn mein Geld? Und die sagen dann, wissen wir auch nicht. Da steht halt der Kontostand, der wird schon stimmen.

Keine Ahnung. Und was die Bank macht, und das ist ja ganz essentiell wichtig für Transparenz, für Vertrauenswürdigkeit, für Nachvollziehbarkeit, Compliance, Auditing, you name it. Was die Bank macht, ist, die speichert nicht den Status quo, also deinen Kontostand, sondern die speichert die Transaktionen, also die Einzahlungen, die Abbuchungen, die im Lauf der Zeit zu deinem aktuellen Kontostand geführt haben. Und darüber können sie deinen aktuellen Kontostand berechnen.

Darüber können Sie auch deinen Kontostand von vor drei Wochen berechnen. Darüber können Sie auch ermitteln, ist der höchste Kontostand, du jemals hattest. Daraus können Sie ermitteln, wie viel Prozent deines Einkommens gibst du denn für Miete aus. Also lebst du über deinen Verhältnissen. Lohnt sich Glücksspiel. Wie oft im Monat gehst du essen? Tendierst du dazu, in dem Moment, wo du Gehalt bekommen hast, das Geld mit vollen Händen rauszuwerfen und dann

Ja, so gegen Monatsende hin wird es schwierig oder bist du erstmal sehr sparsam und dann am Monatsende stellst du fest, toll noch 1000 Euro übrig, jetzt kaufe ich mir irgendwas. Ja, also so Charakteristika, wie du dich verhältst, da kann man unglaublich viel rauslesen aus so einem Kontoauszug. Und das Lustige ist ja, dass all diese Fragen, die ich jetzt gerade skizziert habe, dass man die Fragen und beantworten kann, einfach nur aufgrund der Tatsache, dass die Bank Einnahmen und Ausgaben der Reihe nach speichert statt...

den Status quo und die wussten ja nicht, dass mal jemand fragen wird, lohnt sich Glücksspiel oder wie viel Prozent deines Einkommens gibst du für Miete aus? Die Frage ist ja in diesem System Kontorauszug niemals vorgesehen gewesen. Aber weil du die Rohdaten hast, die sozusagen eine Geschichte erzählen, deswegen funktioniert es halt. Das ist Event Sourcing und das kannst du natürlich übertragen auf alle möglichen. Deswegen habe ich das halt mit sechs Jahren plus minus, weil wenn du das erstmal ein Sparbuch hast oder so, das funktioniert ja auch noch.

Ich wusste halt nicht, dass es sich für Sourcing heißt. Das kannst du dir aber auf alles anwenden. Also was weiß ich, du bist Veranstalter von Entwicklerkonferenzen. Naja, hast du halt nicht eine klassische Datenbank-Tabelle, wo du pro Besucher eine Zeile drin hast und wenn jemand noch ein Ticket nachbucht, dann aktualisierst du den Datensatz, sondern du hältst die Ereignisse fest.

Wir haben die Location gebucht, haben den Caterer beauftragt, wir haben das erste Ticket verkauft, da wurde noch ein Ticket nachgekauft, da wurde jetzt ein Ticket storniert, der Sprecher hat abgesagt, wir haben einen Sprecherersatz gefunden und so weiter. All die Dinge, die so im Laufe der Zeit passieren, die am Ende dazu führen, dass du quasi eine Konferenz veranstalten kannst, das kannst du ja so aufschreiben. Ja, wenn du einen Online-Shop betreibst, welcher Artikel wurde gerade in den Warenkorb gelegt?

Auf welcher andere Seite hat der kunde gewechselt wonach wurde gesucht welcher artikel wurde dann in den wahren korb gelegt also diese reise das festzuhalten das ist event sourcing weil du halt ereignisse festhält also aus business sicht relevante ereignisse deswegen event sourcing und die bilden wiederum die quelle daraus alle möglichen abgeleiteten informationen ziehen zu können deswegen event sourcing und das ist ein

Das Ganze lebt natürlich davon. Deswegen wird das so oft mit DDD verbunden, dass du eine semantisch reichhaltige fachlich aufgeladene wertvolle Sprache hast. Also bei dem Bankbeispiel zu bleiben, das funktioniert ja nur, wenn deine Events so was sind wie Miete wurde abgebucht, Gehalt ist eingegangen, Lotto wurde bezahlt und so weiter. Wenn das immer nur ist, dein Kontostand wurde aktualisiert, dein Kontostand wurde aktualisiert, dein Kontostand wurde aktualisiert.

dann ist das ja völlig witzlos. Also es funktioniert nur, weil du halt eine gewisse Reichhaltigkeit in der Fachsprache drin hast. Und da kommst du halt mit Create, Update, Delete nicht besonders weit. Und das ist quasi so der Hebel, warum Event Sourcing und DDD, wo es ja die Fachsprache geht, warum das so gut zusammenpasst. Und wenn du da halt Event Sourcing machst, dann kriegst du halt so was wie ein Audit Log und für Compliance Anforderungen und Co. kriegst du im Prinzip for free.

Und du kannst unglaublich viele sehr spannende Analysen, Reports, Business Insights und Co. fahren und generieren, an die du sonst nicht drankommen würdest. Und vor allem, und das ist halt das Coole, das kannst du halt rückwirkend machen auf die Daten der Vergangenheit und nicht, ⁓ jetzt sind wir was gefragt worden, was wir nicht beantworten können. Ja, dann bauen wir mal unseren Code ⁓ Dann führen wir in der Datenbank mal eine neue Spalte ein. Dann fangen wir mal an, diesen Wert zu sammeln, warten sechs Monate und dann können wir vielleicht eine Antwort auf die Frage geben.

Und das ist halt ein sehr viel reichhaltigeres Modell. Das ist eine andere Art, quasi Daten zu speichern. Und da bin ich auch so vor, ja, geht so ungefähr mit der Gründung von The Native Web einher. Also auch so vor ungefähr 15 Jahren drauf gestoßen. Und das hat eigentlich sehr schnell eine sehr große Faszination auf mich ausgestrahlt. So dieses, vielleicht liegt es einfach daran, dass es die natürlichste Art ist, wie Menschen Geschichten erzählen. Ja, heute ist mir das passiert und dann hat der angerufen.

Und dann war ich noch da und da und dann habe ich den und den getroffen. dann war ich noch in einem Podcast eingeladen und so weiter. Wenn wir sonst Software schreiben, wir fokussieren uns immer so auf die Substantive. Und das wäre halt so, wie wenn du abends nach Hause kommst und deine Partnerin oder dein Partner dich fragt, und wie war dein Tag? Und du sagst dann Telefon, Chef, Straße, Podcast. Das ist ja keine Geschichte. Und Geschichten leben von Verben.

Die Verben, die reduzieren wir sonst immer auf Create, Update, Delete. Create, Update, Delete. Weil wir halt seit Jahrzehnten beigebracht bekommen, mehr als das braucht's nicht. Aber das ist eine super verarmte Sprache, wenn man das so macht. Und da kann man so viel mehr rausholen, wenn man diese Sprache quasi reichhaltiger gestaltet.

ist dein Default jetzt immer Event Sourcing?

fast immer. es gibt Szenarien, wo es eine dumme Idee ist. oft kommt dann so die Frage, ja, das ist doch aber aufwendig, das lohnt sich ja bei kleinen Sachen nicht. Doch, gerade bei kleinen Sachen ist das eigentlich eine gute Idee meiner Meinung nach, weil da ist der Aufwand nämlich gerade nicht besonders hoch, es mal zu machen und das ist eine gute Übungssituation. Aber wo sich zum Beispiel nicht rentiert ist, das Ganze setzt ja voraus, dass du eine gewisse Fachlichkeit hast. Und es gibt halt

Software-Systeme, da gibt es keine großartige Fachlichkeit. Also was weiß ich, du hast irgendwie eine IoT-Anlage oder so ein Industrie 4.0-Ding und da ist ein Temperatursensor und der ermittelt alle 10 Millisekunden die aktuelle Temperatur und schickt die und die soll gespeichert werden. Das ist so das Standardbeispiel aus dem Industriebereich, wo Industriekunden dann sagen, wir haben einen Fall für Event-Sourcing, wo sie dann happy sind, dass sie einen gefunden haben.

Das tut mir immer so leid, zu enttäuschten und zu sagen, nee, weil das eine Temperatur gemessen wurde, alle 10 Millisekunden. Das ist in der Regel kein fachlich relevantes Ereignis, wo sich drei Jahre später noch jemand für interessiert. Da interessiert sich vielleicht jemand dafür, dass der Grenzwert überschritten wurde oder unterschritten wurde. so was in der Art. Oder aggregierter Wert über einen gewissen Zeitraum, von mir aus. Aber nicht im 10 Millisekunden Abstand.

Temperatur wurde gemessen, Temperatur wurde gemessen, Temperatur wurde gemessen, Temperatur wurde gemessen, Temperatur wurde gemessen und so weiter. Da ist Event-Sourcing mit Kanonen auf Spatzen geschossen und da ziehst du auch keinen Wert raus. Und sowas gehört in meinetwegen eine Zeitreihen-Datenbank. hast du tausendmal mehr von. Insofern, es gibt Ausnahmen, aber ansonsten so für alles, eine gewisse Domäne drinsteckt. Und wenn es nur die vermeintlich ach so simple To-Do-Anwendung ist.

würde ich grundsätzlich erst mal unterstellen, weil ja jede Software einer Fachlichkeit dient oder einer Fachlichkeit genügen muss, bietet es vielleicht an, diese Fachlichkeit erst mal zu modellieren mit DDD und wenn ich das schon mache, dann habe ich ja eigentlich die Grundlage für die Events schon und es ist viel einfacher nach einem halben Jahr, wenn ich feststelle, Eventsourcing brauche ich nicht, einmal aus den Events den Status Quo herzuleiten und dann halt einfach die Historie von den Events wegzuwerfen und dann mache ich halt

mit klassischer Crud-Datenhaltung weiter, als erst mal ein halbes Jahr lang ohne Event-Sourcing zu arbeiten mit klassischem Crud und dann festzustellen, jetzt sind wir schon zum siebten Mal in der Situation, wo wir mal historische Daten bräuchten, die kannst du halt nicht wieder herzaubern. Und insofern würde ich schon sagen, so in neun von zehn Fällen ist mein Default, lass mal Event-Sourcing machen, weil es meistens sich als eine sinnvolle Idee rausstellt, auch wenn dir das am Anfang oft keiner glaubt.

Was ist deine Einschätzung? Warum immer noch der Default Create, Update, Delete ist, also CRUD?

weil es so schön einfach ist. musst nicht über nachdenken, jeder Idiot, Entschuldigung, aber es ist nicht schwierig. Du kannst was neu dazutun, du kannst was ändern, du kannst es löschen. So funktioniert Excel, so funktioniert ein Dateisystem, so funktioniert halt jede Datenbank auf diesem Planeten mit Insert, Update, Delete. Und das wird dir so eingebläut. Und wenn du dann immer nur aus der technischen Perspektive drauf guckst, da kommst du ja gar nicht auf die Idee mal zu fragen, ja, sollten wir...

Okay.

da vielleicht mehr machen als nur diese drei Verben und du kannst ja alles damit abbilden. Also vielleicht nicht besonders gut, aber es funktioniert irgendwie. Und dann gehst du halt hin und was machst du dann? Jetzt hast du eine Datenbank geschaffen. Jetzt baust du halt noch ein Weblayer drüber, irgendeine API. Was machen wir da für ein Interface? Lass uns ein Rest Interface machen. Warum? Ja, das machen alle. Dümmster Grund ever. Und

Ja, also ein Create, also ein Insert. Ja, das ist ein Post, ein Update. Das ist ein Put und ein Delete. Das ist ein Delete. Ach, wie praktisch. Wir müssen noch nicht mal bei der Balanced Workshilfe-Schnittstelle drüber nachdenken. Du kannst es wirklich einfach gießkannenartig Augen zu und gießkannen. Du kannst es einfach eins zu eins mappen. Und was du machst, ist du exportierst die technische Sprache der Datenbank über deinen API über deinen API Layer. Und wo drin das dann gipfelt, ist eine UI, die, weil sie

keinelei fachliche Informationen von der API bekommt, weil die UI im Endeffekt nur eine hübsch angemalte Oberfläche ist, Datenbankentitäten zu verwalten. Dann kriegst du halt einen Grid, so Excel-artig, kannst du eine neue Zeile hinzufügen, kannst du in irgendwelchen Zellen irgendwelche Werte ändern, kannst du das löschen, am Ende drückst auf Speichern. Und dann sind die Leute stolz, yay, wir haben eine Software gebaut, aber die unterstützt dich halt technisch, die unterstützt dich halt fachlich gesehen gleich Null.

Ja,

die Business...

Wenn du nicht weißt, was du machst

und was du machen sollst, dann wird dir die Software dabei nicht helfen. Die wird keine Fehleingaben verhindern. Die verhindert nicht, dass du das Geburtsdatum und die Postleitzahl gleichzeitig änderst, auch wenn es dafür keinen Use-Case gibt, weil du im Endeffekt die UI ist nur deswegen da, weil die Leute kein SQL können.

Die Businesslogik muss im Kopf des Users sein, was wir nicht wollen.

Ja, ganz genau.

Und das ist halt was, wo wir ja eigentlich von weg sollten. Und da kommt halt dann so vieles zusammen. Es wird halt nicht wirklich gelehrt. Es ist halt ein eher untechnisches Denken. Du müsstest dich mal mit der Domäne auseinandersetzen und so weiter. Und wie tief das in uns verwurzelt ist. Also ich bin ja auch nicht so auf die Welt gekommen. Ich bin auch Jahre und Jahrzehnte, Jahrzehnte vielleicht nicht, aber ja doch. Anderthalb Jahrzehnte rumgelaufen, hab gedacht, also Softwareentwicklung ist ein rein technisches Ding.

Ich bin auch so groß geworden und ich habe das beigebracht bekommen. Und das ist, wo mir das immer extrem auffällt. Das ist so lustig, weil ich gestern auf der Konferenz war. Da ging es auch darum. Und ich habe mit jemandem mich über genau das unterhalten und sagte, das Standard Klischee, was auf jeder Konferenz passiert ist, wenn es jetzt nicht eine sprachspezifische Konferenz ist, eine Java Konferenz oder eine Peer, sondern so was. Keine Ahnung, eine Konferenz zur Architektur. Treffen sich zwei Leute. Hi.

Und was machst du so? Ja, ich mach Java. ⁓ ja gut, ich mach PHP. Ja, okay, war nett dich kennenzulernen. Tschüss. Ende des Gesprächs. Und das Lustige war, darüber haben wir uns unterhalten und eigentlich das total bescheuert ist, man ja mal, weil man sich vielleicht total viel zu sagen hätte, weil man vielleicht im selben fachlichen Bereich unterwegs ist. Man kommt aber gar nicht so weit, weil man sich über die Sprache identifiziert.

Ja, dann bekomme ich eine Mail, wo mir jemand schrieb. Ja, also er hat das Gespräch total inspirierend gefunden und fünf Minuten später hätte er sich mit jemand anderem unterhalten und seine erste Frage wäre gewesen und mit welcher Programmier-Sprache er arbeitet. Als er das gefragt hätte, hätte er sich gedacht, so verdammt, es ist so schwer da rauszukommen. Und deswegen hast du auch so diese Grundsatzdiskussion. Mac OS oder Linux? Was ist besser oder ist Windows cooler?

...

Internet Explorer oder Firefox oder Safari oder Chrome oder KDE oder Gnome und diese ganzen technischen Stellvertreter Diskussionen, die am Ende den Kunden null interessieren. ist ihm völlig egal, ob seine Web UI in React, in Angular, in Vue oder in sonst was geschrieben ist. Hauptsache, sie macht das Richtige. Aber uns damit zu beschäftigen, ist für uns so viel aufwendiger als diese schöne, ja, aber mein Angular ist besser als dein React.

... Diskussion

Okay, es hat so ein Identitätsding. Also ich identifiziere mich damit und das ist mein Skillset. Jetzt hast du mir im Vorgespräch von einem spannenden Projekt erzählt, wie du es schaffst, das Modellieren einfacher zu machen, in natürliche Sprache auch zu übersetzen und wo du auch damit vielleicht Code-Generierung oder auch AI mit bedienen kannst. Erzähl mal ein bisschen.

wie wir Event-Sourced Domain Modeling am besten machen.

Genau, der erste Punkt, uns da so bisschen ins Nachdenken gebracht hat, war, wenn wir in der KI einen Prompt schreiben, haben wir ja vorhin darüber gesprochen, natürlich sprachlich, dann versuchen wir oft, das halt im Code umzusetzen. Und das ist halt schon so von einem Extrem ins andere sozusagen, von dem Menschenverständlichen zur Maschinensprache. Das wären so die beiden Extreme. Und da ist halt sehr viel Strecke dazwischen, wo halt viel schiefgehen kann.

Und da hatten wir es ja vorhin auch von, dass es sehr schwierig ist, ersten Wurf oder auch im zweiten Wurf so all diese fachlichen Besonderheiten und Eigenheiten und so alles schon zu captchern. Und dass wahrscheinlich diese erste Modellierung halt nicht unbedingt stimmen wird. So, und da haben wir uns überlegt, wie wäre es, wenn man quasi eine Art Zwischensprache einführt.

Und zwar diese ganzen Domain Driven Design hat so paar Building Blocks. Wie zum Beispiel ein Command. Command ist, du als Mensch sitzt vor dem Computer, du willst irgendwas machen, du klickst einen Button an. Du klickst den Button ja nicht an, weil es so toll ist, einen Button anzuklicken, sondern du klickst den Button mit einer bestimmten Intention an. So was wie, ich möchte jetzt die Bestellung aufgeben oder ich will jetzt diese E-Mail versenden oder ich will das Dokument jetzt ausdrucken. Und

Das sind commands, weil du gibst dem System einen Auftrag, tu was. Das sind sozusagen die Eingangskanäle. Dann gibt es zum Beispiel Queries. Das sind Fragen, die du dem System stellst. So was wie, zeig mir mal alle E-Mails an, die ich in letzten vier Wochen versendet habe. Oder wie ist denn der Auftragsstatus von meiner Bestellung? Oder ist das Dokument schon gedruckt? An welcher Position in der Druckerwarteschlange steht das denn? Und im Endeffekt sind das zwei Wege, wie du mit einem...

mit der Software interagieren kannst. das, Commands und Queries, das sind zwei Bausteine sozusagen von DDD, wo DDD halt sagt, naja, wenn du eine Software planst, wenn du eine Software modellierst, dann ist es eine gute Idee, diese Commands alle mal aufzuschreiben und diese Queries alle mal aufzuschreiben. Da gibt's noch einen Haufen mehr an solchen Building Blocks. Und unsere Überlegung war jetzt, wenn man ein Format hätte oder eine Sprache hätte, die das quasi formalisiert.

also die dir erlaubt, das strukturiert aufzuschreiben, aber auf eine Art und Weise, dass es menschenlesbar bleibt. Dann hättest du eine Sprache, wo du als Mensch hingehen kannst und sagen kannst, ich modelliere mein System, ich modelliere meine Domäne so und so. In der Fachlichkeit brauche ich zum Beispiel dieses und jenes Command. Also schreibe ich das auf eine standardisierte, auf eine bestimmte Art und Weise schreibe ich das auf.

Daraus entstehen dann so nach und nach so ein bisschen wie bei Kubernetes mit den Manifest Dateien, wo du ja Pods beschreibst und deployments beschreibt und so weiter. Und so kannst du halt in unserer Sprache diese auch Yaml basiert wie bei Kubernetes kannst du halt sagen, ich beschreibe halt hier commands, ich schreibe halt hier Queries, ich beschreibe hier Aggregates, ich beschreibe hier Read Models und so weiter. Und damit kriegst du quasi eine strukturierte digitale Abbildung deiner Domäne.

Und jetzt kommt der Twist an der Sache. Das ist natürlich was, was du sehr schön zum Beispiel mit einer KI erarbeiten kannst. Wo du sagen kannst, hier ist die Sprachdefinition, wie diese Modellierungssprache aussieht. So rein syntaktisch. Ich will das und das und das modellieren. Mir geht es folgende Fachlichkeit. Ich habe mir das so und so vorgestellt, stell mir mal kritische Fragen und lass uns gemeinsam ein Modell in dieser Sprache entwickeln. Und dann...

Dann schließt sich so der Kreis zu, ich vorhin sagte, wie ich mit KI arbeite. Und dann kannst du mit der KI quasi über deine Fachlichkeit reden. Und was du aber rauskriegst, ist halt nicht fünf Kilometer Markdown, mit dem dann wiederum keiner so richtig was anfangen kann, sondern du kriegst ein strukturiertes, organisiertes Format raus, wo du dann hingehen kannst und zum Beispiel zu einer anderen KI sagen kannst, guck mal, hier ist mein digital abgebildetes fachliches Domainenmodell, setzen wir das mal ⁓ in, was weiß ich,

Java mit dem Framework OpenCQRS oder machst in TypeScript und einem Nimbus als Framework dafür oder machst in Go und zwar komplett ohne Framework. Und dadurch, dass diese Zwischensprache technologieunabhängig ist, kann die halt wiederum in alles mögliche andere nachher übersetzt werden. Und weil du da drin die Fachlichkeit beschreibst, die KI, erzeugt dir sehr viel zielgerichteter den Code und sehr viel passender den Code.

Du kriegst ein sehr viel besseres Grundgerüst für eine Anwendung, als wenn du einfach nur deinen Prompt hinschreibst und dann betest, dass die drei Kilometer Markt, an was du eingetippt hast, hoffentlich zum Richtigen führen werden. Und das gleiche Spielchen kannst du natürlich auch umdrehen. Kannst auch sagen, hier habe ich eine fertige Software. Analysier die mal und zieh da mal ein solches Modell raus, dass ich das mal reviewen kann. Und dann kann man hingehen, wenn man diese Sprache einmal hat, kann man Tools darauf aufsetzen, zum Beispiel in Linter.

der sagt, ob dein Modell in sich schlüssig ist. Oder ein Visualizer, der dir so eine Domäne mal grafisch irgendwie vernünftig aufzeichnet. Weil da gibt es in DDD auch verschiedene Workshop-Formate. Die leben immer sehr gerne davon, dass man Post-its an die Wand klebt. Und das funktioniert auch so für die Interaktion im Raum und so in der Gruppe. Da ist das auch immer toll. Ja, und wo landet das danach? Auf Fotos in irgendeinem Confluence, wo keine Sau jemals wieder reinguckt.

und die auch kein Mensch mehr lesen kann. Und da ist halt eine digitale Repräsentation, die du mit einchecken kannst, 1000 mal wertvoller. Und die hält sich mit, mit deiner Software zusammen. das ist ja genau. Genau, das ist im Endeffekt diese Zwischensprache. ist das, was wir, das ist übrigens besagt der Linter, wo ich vorhin sagte, wo ich am Wochenende dran gesessen habe. Genau, um den Linter ging's. Und das haben wir

Ja, das Modell lebt weiter. Das muss weiterentwickelt werden. Es bleibt nicht nur auf den Post-its, sondern wir müssen weiter dran arbeiten.

es dm getauft also event sourced domain modeling es muss theoretisch nicht mal zwingend mit event sourcing verknüpft werden es bietet sich halt an so von unserer denkweise her aber im grunde genommen ist es erstmal eine domänen modellierung sprache und also findet sich unter www.esdm.io ist ein kleines kommando zeilen tool mit dem man sich dann das schema dazu legen lassen kann und wo der linter mit eingebaut ist

und was man halt einfach so nutzen kann. Und ich bin sehr gespannt drauf. Also das ist nur so ein zartes Pflänzchen, aber ich bin sehr gespannt, was so da ein Ökosystem im Laufe der Zeit alles drum herum anfängt zu entstehen. Und ich habe mich jetzt mit ein paar Leuten schon unterhalten. das Ganze ist noch sehr, sehr jung. Vor zehn Tagen haben wir das veröffentlicht. Und es gibt aber schon etliches.

Feedback dazu sehr positives Feedback, gerade aus der DDD schrägstrich Event Sourcing Community und wo Leute auch schon gesagt haben, hey, sie hätten die Idee für dieses Tool drum herum oder für jenes Tool drum herum und ob das okay wäre, wenn sie was bauen würden, wo ich denke, ja, natürlich ist das okay, ist doch total cool, wenn so was wächst und so, wenn alle was dazu beitragen und so, ist doch schön, wenn so ein Ökosystem so entsteht und mal gucken. Vielleicht ist das ja

Sehr cool.

Ich will jetzt nicht so weit gehen zu sagen, das ist die neue Programmiersprache. Das wäre ein bisschen sehr hochgegriffen. Aber vielleicht verändert das ein bisschen, wir ja, wie wir Software entwickeln, wie wir Software denken können. Und vielleicht trägt es einen kleinen Teil dazu bei, dass wir halt mehr die Fachlichkeit in den Vordergrund rücken. Weil ob du das dann nachher mit einer HTTP API oder mit einer GraphQL API oder mit einer GAPC API oder sonst was ausstatten, das ist völlig zweitrangig. Und das kriegt die KI dann schon hin, wenn sie weiß, was sie inhaltlich machen soll.

Ja, genau.

Also das passt natürlich, genau das passt voll da rein, was du gesagt hast. Am Ende des Tages wird dann der Code nur noch runtergeschrieben. Das kann dann auch eine Maschine machen. Und es ist dann auch egal, ob ich jetzt in dem Bereich die Sprache benutze oder die andere. Das wird dann quasi keine Entscheidungskriterium mehr sein. Und viel wichtiger ist, wir sind ja als Abstraktionsebene unterwegs, dass wir verstehen, was wir überhaupt machen wollen. Worum geht es denn? Und wir haben ganz oft Warum gefragt.

Und das ist halt das, was du halt mal festhalten musst.

Ja.

Ja, richtig cool. Werden wir auf jeden Fall in den Show Notes verlinken, die Spec oder der Ansatz Open Source. Können Leute dort auch kontributen?

Es ist aktuell Closed Source, also das Binary Tool, wo der Lint da drin steckt, das ist Closed Source. Das Schema, eigentlich ist ein Jammel Schema, das ist allerdings, also logischerweise, damit man es auch lokal neben dran legen kann und so, das ist Open Source. Insofern, das ist öffentlich und frei verfügbar. Also der Closed-Anteil, ist sehr überschaubar, sehr klein. Das ist in wesentlicher Linie.

Ja klar, also es geht ja dann auch die

Spec, wie man die Spec weiterentwickeln kann, dass die Leute Feedback geben können. Hier braucht man ein Feld oder hier wäre eine Sache interessant. Ich werde es auf jeden Fall verlinken in den Show Notes. Danke fürs Teilen. Also hört sich sehr interessant an. Ich habe auch schon vor der Episode mal kurz drüber gescannt. ich definitiv nochmal tiefer reinschauen. Jetzt bevor wir wrappen, habe ich noch ein Thema.

Ja.

Danke schön.

Es war ziemlich emotional. habe einen deiner letzten Streams gesehen. Du hast eine lange Pause gemacht, du wieder gestreamt hast. Und hast dieses Thema Social Media, Attention Seeking Social Media versus Interest Media, also sind wir da, wie viel Wert hat das alles noch, was wir machen? Und du hast die Frage gestellt, braucht man uns überhaupt noch? Was so sehr reflektiert hat, dass du in einem

Hm?

Hmm.

Change-Modus selbst bist. Ich glaube, ihr seid es gewohnt, euch zu verändern. Also gerade als Berater, du hast mit .NET angefangen, hast Node, hast Go gemacht. Das heißt, es ist eine ständige Veränderung. Jetzt trifft die Veränderung dann doch ein bisschen stärker. Vielleicht kannst du da noch mal paar Gedanken teilen, weil ich fand's wirklich erstaunlich. Es geht ja auch dann die Frage nicht nur deiner Relevanz oder generell unserer Relevanz jetzt im neuen Zeitalter als Engineer.

Ja.

Vielen

was unsere Wert ist und wie wir uns dort ausrichten.

Ja, genau. Also ich habe vorhin mal gesagt, dass wir nicht für Kunden entwickeln, sondern mit Kunden und dass wir das immer ein gewisser Teil an Wissensvermittlung mit drin ist. Und das ist natürlich so der Punkt. Das ist auch das Ziel von unserem YouTube-Kanal. Wir wollen anderen Leuten was beibringen. Wir wollen Wissen teilen, weil wir glauben, dass die Welt, das hört sich jetzt bisschen pathetisch an, aber dass die Welt ein besserer Ort wird dadurch. Das ist zumindest die Hoffnung.

Und ich finde das mega schön, wenn du als Feedback zum Beispiel bekommst, so hey, durch eure YouTube-Videos, ich hatte letztens ein Bewerbungsgespräch und die haben mir total gut geholfen, mich vorzubereiten und ich habe den Job bekommen. Das ist so ein schönes Feedback, was du kriegen kannst, weil du da halt merkst, dass du halt nicht einfach nur so Unterhaltungs-YouTube machst, so im Sinne von so, guck mal hier, meine Room Tour, lustig, sondern dass du halt wirklich für Menschen, die du nicht kennst,

Aber dass es da draußen Menschen gibt, die aufgrund dessen, was du machst, für die das einen Unterschied in ihrem Leben macht. Das ist schon schön, wenn man was zum Positiven sozusagen beitragen kann. Und wir sind so ein bisschen in so eine Sinnkrise gestürzt, was YouTube anging, weil wir uns halt gefragt haben, naja, vieles, also wir erklären halt viele Dinge. Es soll halt gerade jetzt nicht Unterhaltungskontent sein, sondern wir versuchen eher so educational Content zu machen.

Wer braucht das denn noch, wenn du auch einfach ChatGPT fragen kannst und dir halt die technische Frage, die du hast, von der KI beantworten lassen kannst und Rückfragen stellen kannst und das halt auf dem Level dir erklären lassen kannst, wie es halt für dich passend ist und so. Da kannst du ja mit einem Video überhaupt nicht konkurrieren. Und da haben wir uns sehr schwer mitgetan. Deswegen haben wir jetzt auch fast vier Monate.

Pause gehabt, wo wir uns halt noch sehr viele Gedanken gemacht haben, wie wir mit YouTube weitermachen wollen. Und am Ende des Tages ist es aber so ein bisschen die Erkenntnis, dass die KI dir zwar die Dokumentation von irgendwas runterleiern kann oder halt die die Spec von irgendwas geben kann oder den Wikipedia-Eintrag von irgendwas reproduzieren kann. Aber was sie nicht so gut kann, ist Dinge miteinander in Beziehungen setzen und in Verhältnis setzen und Dinge einordnen.

Dinge bewerten. Und da schließt sich so dieser ganz große Kreis zum Anfang, wo ich sagte Konzept und Methoden wissen finde ich unheimlich wichtig. Und jetzt kommt irgendein neues hypothetisches Beispiel, jetzt kommt irgendein neues UI Framework und klar kann der Chat GPT zusammenfassen, was sei jetzt die Features sind und wie du das benutzt und wie die Syntax ist. Aber die spannende Frage ist ja, was steckt denn da für mich drin? Also sollte ich mich damit beschäftigen? Lohnt sich das für mich? Ist das sinnvoll?

Ist das nur ein neuer, kurzlebiger Trend, der sich in vier Wochen wieder erledigt hat? Was sind Dinge, kann der ChatGPT halt nicht beantworten? Dafür braucht es kein Wissen, dafür braucht es Erfahrung. Und das ist das, was wir an der Stelle, glaube ich, beitragen können, auf YouTube bezogen. Und was wir aber natürlich auch in Bezug auf unsere Kundinnen und Kunden in Projekten beitragen können. Dass wir halt schon ganz vieles gesehen haben, was halt funktioniert oder was auch nicht funktioniert.

Und was nicht so offensichtlich funktioniert oder nicht funktioniert, wie man vielleicht zunächst mal meinen könnte, sondern wo vielleicht manchmal die Dinge, wo man gerade denkt, ach, das ist die bescheuertste Option, wie man es lösen kann, wo genau das der richtige Ansatz war, weil das Problem halt ein bisschen komplexer ist, als man auf den ersten Blick meint oder umgekehrt. Und das ist, glaube ich, was, wo man nach wie vor einen Mehrwert stiften kann, weil letztlich geht es die Frage, welchen Wert bringst du oder welchen Mehrwert bringst du irgendwo ein?

Und da sind wir, hast ein paar Mal heute jetzt in unserem Gespräch so das Stichwort Identität oder womit identifiziert man sich, reingebracht. Und ich glaube, je mehr man sich halt darüber identifiziert, dass man jemand ist, der Code schreibt, desto schwerer wird man es haben. Weil dann konkurrierst du halt mit einer Maschine, die schreibt halt schneller Code als du. Wenn du aber halt deinen Mehrwert oder deine Identität daraus ziehst, dass du in der Lage bist, Leuten zu helfen oder Unternehmen zu helfen.

etwas Sinnvolles zu machen, sinnstiftend zu agieren. Und da spielt halt die Fachlichkeit eine ganz, ganz große Rolle. Und du in der Lage bist, in der Fachlichkeit mitzureden und das mitzugestalten. Ich glaube, dass du dann weiterhin durchaus gebraucht werden wirst. Und da auf der Metaebene braucht es natürlich auch wiederum Leute, die anderen Leuten erklären, wie man das denn macht. Und insofern haben wir eigentlich genau dieselben Patterns wie vorher.

nur sozusagen eine Ebene verlagert oder eine Abstraktionsebene halt jetzt höher angesiedelt. Und das ist halt so, der glaube ich, die Herausforderung, die man gerade hinkriegen muss, dass man sich so in dieser neuen Welt irgendwo so, dass man seinen Platz wieder findet. Also ich glaube nicht, dass es die Plätze nicht mehr gibt. Ich glaube nur, wir wissen noch nicht vollumfänglich, wie diese Plätze alle mal aussehen werden. Und die müssen wir halt, das müssen wir halt rausfinden.

Sehr spannend. Was man da merkt, dass Wissen jetzt eine nachgelagerte Relevanz bekommt. Also das heißt, ich kann ganz schnell auf Wissen zugreifen und es wird mir immer besser präsentiert, aber es ist eher so die Anwendbarkeit des Wissens und auch die zwischenmenschliche Interaktion, die nach wie vor das ist, was es einfach immer noch nach vorne bringt und

Vielen

was den Unterschied auch macht, weil man hat auch in dem Stream gemerkt, dass deine Community eine sehr willkommen Community ist und dich dafür auch schätzt, wie du es erklärst. Es kommt oft, wenn man über dich recherchiert, dass du in der Lage bist, komplexe Sachen einfach aufzubrechen und das ganz gut zu erklären. Und ich glaube, das ist einfach der Mehrwert, der dann wirklich noch vom Mensch kommt.

Ja, und das ist auch, und ich finde das so schön, weißt du, dass sich am Ende so viele so Kreise schließen und dann so viele angefangene Enden auf einmal gar keine angefangenen Enden mehr sind, sondern dass sich das irgendwie so in Wohlgefallen auflöst. Das ist nämlich, glaube ich, auch genau der Punkt, weil sich ja im Moment viele junge Menschen fragen, ob es sich noch lohnt, in die Softwareentwicklung einzusteigen. Mal abgesehen davon, dass es gerade super schwierig ist, Unternehmen zu finden, die das machen, aber

Das ist eine Frage in der jüngeren Generation, die viel diskutiert wird. Und das ist genau der Punkt. Weil das, was verglichen wird, ist immer, ja, ich weiß ja aber noch gar nichts. Und die KI weiß so viel mehr. Aber es geht gar nicht das Wissen. Es geht die Erfahrung. Und das ist das, was dich als Menschen nämlich am Ende auszeichnet, was der KI fehlt. Weil bei der KI fängst du in jeder Session immer wieder bei Null an. Und die hat keine Projekterfahrung, hat keine Domainerfahrung, die hat schon gar keine...

Real-World-Erfahrung. Und das ist das, du selbst als Junior an deinem ersten Arbeitstag anfängst zu sammeln und damit wirst du wertvoll. Und am Ende läuft es, glaube ich, halt darauf hinaus, dass die Frage nicht sein muss, die KI oder wir, also dass das so eine entweder-oder-Frage wird, sondern dass das eine sowohl als auch-Frage wird. Und das ist, glaube ich, ganz wesentlicher Punkt. Und da ist natürlich

müssen natürlich gewisse Voraussetzungen dafür da sein, damit das funktionieren kann. Und das ist halt nicht nur auf uns als Branche bezogen, das betrifft auch uns als Gesellschaft. Wie gehen wir mit Bildung ⁓ Was bringen wir der nachwachsenden Generation in der Schule, im Studium bei? Da kann man mal die Frage stellen, wie sollte Bildung, Ausbildung gestaltet werden? Vielleicht auch eine überfällige Diskussion. wenn ich mir überlege, wie viel da drin steckt alleine.

dann glaube ich nicht, dass uns die Arbeit so bald ausgehen wird. Wir haben nur noch keinen guten Weg gefunden, wie man das so insgesamt vielleicht umsetzt, das alles. Aber ich glaube, Aufgaben gibt es genug, die vor uns liegen.

Ja.

Und wie transportieren wir die Erfahrung, die nächste Generation nicht mehr diese Fehler macht, wir jetzt gemacht haben, weil wir den Code getippt haben, weil wir uns per Route eingeloggt haben und gesehen haben, weil wir Kubernetes getroubleshootet haben, sondern wenn das alles irgendwie automatisiert passiert ist, ist es vergleichbar wie wir schreiben jetzt keinen Maschinencode mehr und wir sind auf einer higher level language oder

Ja.

Wie kann ich dieses Wissen, von dem jetzt die Seniors profitieren und die dann besser orchestrieren können, besser abschätzen können, das in die richtige Richtung? Wie kriege ich das in die Junioren rein, die vielleicht diese ganzen Schritte nicht mehr durchlaufen? Hast du dazu noch einen Gedanken?

Ja,

ich glaube, dass das am Ende des Tages, ich hatte es ja gerade schon von sich schließen in Kreisen. Ich hatte ja vorhin mal gesagt, dass es am Ende Abstraktion geht in vielen Fällen. Und das, was wir heute machen, wenn wir über Softwareentwicklung sprechen, ist gar nicht so krass anders als das, was wir vor 40 Jahren gemacht haben. Wir haben nur 5000 Abstraktionsschichten dazwischen gebaut, wodurch das alles zwar in gewissem Sinne

einfacher wurde. der anderen Seite aber auch wieder komplexer. Ich frage mich immer, wenn ich jetzt heute anfangen müsste zu programmieren. Als ich angefangen habe, ich habe GW Basic unter DOS gehabt und ein Buch. Punkt. Heute, ich möchte halt 3D-Grafik und Ton und Surround Sound und Animationen und was weiß ich was. Da brauchst du ja schon 10 Millionen Technologien, überhaupt mal in Hallo Welt zustande zu bringen, was irgendwie den Hund hinter dem Ofen hervorlockt. Ich glaube, das ist sehr schwierig geworden, Programmieren.

zu lernen und das was aber jemanden der wirklich gut ist auszeichnet am ende des tages das ist gar nicht dass die person so alles mögliche weiß so im sinne von so zu jedem thema was sagen können das geht auch gar nicht dafür ist das thema immer schon zu komplex gewesen sondern das was glaube ich leute wirklich gut macht das ist wenn sie in die tiefe gehen können und ich meine als ich studiert habe vor inzwischen auch im vierteljahrhundert

Anfang der 2000er. war Java gerade hip, da kam dann gerade .NET raus, da waren Managed-Sprachen, waren das neue Ding. Und da hat jeder gedacht, ⁓ Managed-Sprachen, Garbage Collection, automatische Schweicherverwaltung, was soll ich mich denn noch mit C und mit der Memory Allocation rumschlagen? Ja, turns out, wenn deine Anwendung in irgendwelche Schweicherprobleme reinrennt, weil unter der Haube die Garbage Collection auch nicht zaubern kann,

Ja, dann ist es halt ganz gut, wenn man weiß, was ein Stack und Heap ist und was ein Value und was ein Reference Type ist und wie eine Garbage Collection funktioniert und was Generationen in einer Garbage Collection sind und warum statische Variable nicht weggeräumt werden und, und, und, und, und. Und da sind wir auf einmal nämlich wieder auf der Ebene von was macht die CPU eigentlich? Wie funktioniert eigentlich die Kommunikation zwischen CPU?

und Arbeitsspeicher. Und warum werden manche Dinge da abgelegt und an woanders? Wie ist der Speicher organisiert? Betriebssystem interner. Und auf einmal brauchst du Leute, die sich mit sowas auskennen. Und das sind dann die, die wir Senior nennen. Und das haben die aber nicht, weil die das irgendwie an Tag drei in der Ausbildung beigebracht bekommen haben, sondern weil sie über Jahre und Jahrzehnte beharrlich immer wieder versucht haben, sich da noch ein Stückchen tiefer und noch ein Stückchen tiefer und noch ein Stückchen tiefer reinzugraben.

Und immer wenn was schief gegangen ist, wieder auf die Suche gegangen sind und so lange gesucht haben, bis sie diesen scheiß Fehler gefunden haben und ihn beheben konnten, bis sie verstanden haben, was der Fehler ist und nicht das Symptom gekittet haben, sondern wirklich die Ursache gefunden haben. Und wenn man das hat, intrinsische, inhärente Neugier und diesen Entdeckungs- und Forschergeist, ich glaube, dann hast du nach wie vor hervorragende Aussichten, ein guter, erfahrener Software.

Ingenieur oder eine Software Ingenieurin zu werden. Nur das sind halt nicht so viele, die so drauf sind. Aber das waren vor 30 Jahren auch nicht so viele, die so drauf waren. Daran hat sich auch nichts geändert. Und insofern, jetzt ist halt eine Abstraktionsschicht mehr da. So what? Der Job bleibt, glaube ich, ziemlich derselbe. In gewissem Sinne. Und das, worauf es wirklich am Ende des Tages ankommt. Und ja, um die 10 Millionen der HTTP API zu schreiben, brauche ich das alles nicht.

sehr cool

Haha.

Klar, aber der Job ist ja auch nicht spannend, weil du die 10 Millionenste HTTP-API als Fleißarbeit runtertippst.

Ja, sehr spannend. Also ich glaube, das ist ein sehr gutes, finales Wort hier an der Stelle. Ich hätte auch, ich glaube, ich könnte mit dir noch stundenlang weiter sprechen, weil mir deine Ansicht sehr gut gefällt. Jetzt zum Wrapp-up. Ich habe ja eingangs schon dir eine Frage gestellt. Ich würde gerne eine Frage mitnehmen in nächsten Podcast, auch wenn du noch nicht weißt, wer der Empfänger der Frage sein wird. Was wäre deine Frage, die ich mitnehmen kann?

Ja.

werde nicht fragen wie sieht es bei dir mit fußball aus ich glaube meine frage und die schließt so ein bisschen daran an ist wer auch immer du bist wenn du das bildungssystem neu gestalten könntest wie sieht die zukunft der bildung aus

Ich bin jetzt auch schon gespannt auf die Antwort. Ich hoffe, du hörst rein in nächsten Podcast und hörst dir die Antwort rein.

Ich will selber jetzt was die Antwort ist. Insofern

auf jeden

Ich auf

Wenn Leute mehr von dir erfahren möchten, wo finden sie dich im Internet? Was sind deine Kanäle? Wo bist du unterwegs? Du hast von YouTube gesprochen. Wir haben uns über LinkedIn, glaube ich, connected. Erzähl mal, was können wir alles mit in die Show Notes aufnehmen?

Ja, also ich glaube am einfachsten, wenn man den Stil mag, wie ich Dinge erkläre, wie ich Dinge sehe und so weiter, ist, glaube ich, das Sinnvollste auf jeden Fall YouTube. Und da vielleicht auch nochmal der Hinweis, also das bin nicht nur ich alleine, sondern wir sind ein Unternehmen mit ein paar mehr Leuten. Und also von daher youtube.com slash at the native web. Aber du hast ja schon gesagt, Link kommt in die Show Notes rein. Ansonsten ja, Link in

Da bin ich vertreten. werde ansonsten auf Social Media sehr wenig vertreten. Also Insta oder so zum Beispiel gar nicht. Bin auch nicht auf Facebook, bin auch nicht auf X oder auf Blue Sky. Das artet irgendwie sonst so aus und das frisst Zeit, aber das macht es nicht unbedingt besser. Also von daher YouTube und LinkedIn sind da so die beiden Kanäle. Und ansonsten glaube ich ist so das relevanteste halt unsere Unternehmenswebsite. Also wer sich dafür interessiert, was wir als Unternehmen so machen, beziehungsweise wer vielleicht Unterstützung in den Bereichen, über die wir heute

gesprochen haben gebrauchen kann www.the native web.io und dann natürlich unsere event sourcing db die datenbank die ist aber als produktseite auf der firmenwebseite drauf und dann vielleicht als letztes noch die event source domain modeling language also esdm.io und ich denke mal das sind so die wesentlichen punkte und ansonsten habe ich ja das große glück mit einem Namen gesegnet zu sein der relativ selten ist

Also im Zweifelsfall einfach meinen Namen bei Google oder der Suchmaschine deiner Wahl eingeben und dann wirst du irgendwas über mich finden. Und mit ziemlicher Sicherheit über mich und nicht über meinen Namensverwandten, den ich nicht kenne.

Alles klar. Sehr cool.

Golo, vielen, vielen Dank für die Zeit, du genommen hast. Auch für die ausführliche Zeit. haben echt lange gesprochen. Es hat mir sehr, sehr viel Spaß gemacht. Danke, dass du da warst.

Mhm.

Danke für die Einladung, danke, dass ich da sein durfte. Mir hat es auch Spaß gemacht. ja, Dankeschön.

Und alle nutzt bitte die ja eben gehört, dass es sehr, gerne auch gesehen wird, dass wir Kommentare bekommen. Wie fand ihr die Episode? Was hat euch besonders gut gefallen? Schreibt uns gerne in den Kommentaren und liked den Podcast. Ich habe auf jeden Fall wieder eine ganze Menge gelernt. Ich hoffe, auch. Und ich freue mich schon, euch in der nächsten Episode wiederzuhören. Also bis dann. Danke. Ciao.