Alles ist Culture (Sujeevan Vijayakumaran)

Wie es aber so ist, vergisst man nach einer Weile so die Schmerzen,

die man hatte und kommt man dann irgendwann auf die Idee, ja, ein zweites Buch zu

schreiben. Du kennst das Problem.

Ja, mehrfach.

Und dann, ich meine, in meinem Fall war das dann halt auch so,

ich habe dann erst den Autorenvertrag dann auch unterschrieben und so weiter,

sobald ich wusste, okay, wie sieht die Storyline grundsätzlich aus,

weil ich wollte, habe das im DevOps-Buch ja dann auch so gemacht, dass ich

von einer Beispielfirma ausgegangen bin, die halt in der alten Welt

feststeckt und jetzt aber halt in diese DevOps-Welt möchte,

und was hast du jetzt kulturell damit zu tun, als auch auf der Technikseite,

damit man immer so schöne Beispiele hat, weil ich finde Bücher ganz schlimm

Fachbücher ganz schlimm zu lesen, wo nur die Konfigurationssachen

runtergerattert werden.

Mein Gast heute ist Sujeevan Vijayakumaran.

Der Name ist für meine deutsche Zunge kompliziert, seine Eltern kommen aus Sri

Lanka und ich finde es schön selbstironisch, dass er in einem YouTube-Video

gesagt hat, bin ich auch eher, dessen Name nie genannt wird.

Seit vielen Jahren beschäftigt er sich mit technischer Infrastruktur und Tools,

angefangen mit Ubuntu und Git, später in Rollen bei GitLab und Grafana Labs.

Sujeevan ist Gründer und Geschäftsführer der Friday Deployments GmbH,

einem Beratungsunternehmen, das

Organisationen dabei unterstützt, ihre Softwareentwicklung so zu professionalisieren,

dass Friday Deployments, also entspannte Releases zum Wochenausklang, zur Routine werden.

Er hat mehrere Bücher veröffentlicht, darunter Versionsverwaltung mit Git und

Git Schnelleinstieg.

Außerdem hat er das Buch DevOps, wie IT-Projekte mit einem modernen Toolset

und der richtigen Kultur gelingen, veröffentlicht. 2024, zunächst auf Deutsch

und 2025 kam die englische Übersetzung.

Vermutlich ist er auch der Einzige, der Kacke, verdammt, erschießen und Mist

in einem Buch schreiben darf, ohne dass das Lektorat von Rheinwerk das wegkürzt.

Außerdem ist er Co-Autor des Titels IT-Management, das umfassende Handbuch.

Erschienen im Oktober 2025.

Seit November 2020 betreibt er mit Dirk Deimeke den Podcast TILpod,

TIL von »Today I Learned«, in dem es um IT, DevOps-Themen und die Kultur in Projekten geht.

Auch abseits der IT läuft es bei ihm beim Zugspitz Ultratrail,

einem Ultramarathon in Bayern, hat er den ersten Platz belegt.

Ich lasse allerdings offen, in welcher Ordnung. Ja, schön, dass wir zusammengefunden haben.

Du beschäftigst dich schon super lange mit IT-Technologien, hast studiert.

Wie bist du überhaupt zu Informatik und zu IT gekommen? Ich sage mal,

es gibt ja verschiedene Möglichkeiten, wie man sich beruflich betätigen kann.

Was hat dich dazu getrieben, was mit Computern zu machen?

In meinem Fall war das im Wesentlichen mein Bruder, glaube ich,

weil der halt irgendwie so mit Computern rumgemacht hat und dann habe ich halt

irgendwann das auch gemacht.

Und witzigerweise ist er kein Informatiker mehr, ich schon.

Was hatte dein Bruder damals für einen Computer gehabt? Weißt du es noch?

So PC oder war das noch ein Heim-Computer?

Ja, ich meine, ich bin ja noch relativ jung. Ich glaube, den ersten Familienrechner,

den wir hatten, war im Jahr 2000. Das war so ein Pentium 3 Rechner von Aldi oder sowas.

Hatte das schon so eine Umschaltetaste für Turbo, ja und nein?

Das sagt mir gar nichts.

Ja, die Rechner hatten damals so eine Turbotaste, was total lächerlich war,

weil man sich fragte, warum haben die nicht alle automatisch schnell gerechnet.

Aber damit die alten DOS-Spiele mit 4,77 Hertz noch liefen, hatten die alle

so eine Anti-Turbotaste, weil das Timing der früheren PCs war halt fest codiert.

Weil die halt damals immer diese Standardfrequenz hatten. Und deswegen gab es

so eine Turbotaste, wenn man halt die richtig schnelle Möglichkeit haben wollte.

Okay, also noch jüngerer, der PC.

Genau.

Und hast du damals schon programmiert oder was waren deine ersten Gehversuche mit dem PC?

Ja, ich habe erst mal so Webseiten-Sachen gemacht, erst mal so statische HTML-Seiten.

Also ich habe zu Zeiten angefangen, wo man sich über den Internet Explorer 6

aufgeregt hat. Diese Zeiten waren das.

Und habe halt auch immer wieder hier und da programmieren versucht zu lernen.

Hatte aber auch nur begrenzte Bildschirm-Zeit gehabt.

Ach, ihr musstet euch den Rechner teilen?

Und das und meine Mutter hat sehr stark drauf geguckt, dass ich nicht zu lange

vor dem Rechner sitze, was, glaube ich, Vor- und Nachteile hatte.

Ja, okay.

Deswegen musste ich quasi, habe ich halt irgendwelche Bücher aus der Bücherei

oder so ausgeliehen, die dann meistens auch völlig veraltet waren.

Und dann nochmal eigentlich versuchen, so, okay, ich habe jetzt eine Stunde

Zeit oder zwei Stunden Zeit, um irgendwie...

C++ zu lernen oder sowas, ohne Ahnung zu haben, ist schwierig.

Aber immerhin hast du eine gute Ausrede. Also wenn dich jemand fragt,

warum bist du denn in die DevOps-Schiene reingerutscht und warum bist du kein

Programmierer geworden, kannst du sagen, ja, ist Mutterschuld.

Also du durfte halt nicht so lange am Computer bleiben.

Und Programmieren lernen dauert halt. Meine Mutter hat mir die Zeit gegeben.

Genau, bis so 16 oder 17, glaube ich. Ich glaube, Oberschule war wieder

okay. da hatte ich dann meinen eigenen Rechner dann auch und dann war alles anders.

Hast du denn in der Oberstufe schon Informatik als nicht Pflichtfach,

wie sagt man denn, als Wahlfach haben dürfen?

Wahlpflichtfach. Ja, hatte ich und das war schlecht.

Tatsächlich hat das mich eher abgehalten, also fast abgehalten quasi,

weil ich das Gefühl habe, ich wäre zu doof dafür.

Wirklich? Warum?

Naja, du machst oder ich hatte zumindest da, wir hatten Delphi gemacht.

Was jetzt erstmal egal ist, ob jetzt Delphi oder irgendwas anderes,

würde ich mal behaupten.

Hatte ein bisschen den Vorteil zumindest, dass man zumindest eine relativ einfache

GUI hatte, die man sich da hin und her schieben konnte.

Aber trotzdem waren dann die Programmierkonzepte meistens dann halt,

okay, wie macht man verschleifelt, verschachtelte Schleifen.

Und das habe ich halt, so wie der Lehrer das erklärt hat, habe ich das halt nicht geblickt.

Ja, okay.

Und die anderen auch nicht, außer halt die Überflieger, die eh in allem eine Eins hatten.

Und das war dann halt irgendwie dann so, okay, bin ich vielleicht doch zu blöd

dafür, soll ich vielleicht doch kein Informatikstudium antreiben?

Und dann hatte ich eine Vorlesung oder zwei im Studium in Programmierung und

hatte dann alles aus drei Jahren Schule drin. Und dann so, na ja, das geht ja.

Aber das ist ja interessant. Das heißt, deine, ich sag mal, schlechte Schule,

hat dich ja nicht davon abgehalten, Informatik dann zu studieren.

Also das ist ja schon sehr selbstbewusst, zu sagen so, ich kann's doch,

ich studiere jetzt Informatik und Mathe finde ich total heiß, will ich.

Ja, also Mathe fand ich jetzt auch nicht so total heiß. Aber ich bin ja auch

kein richtiger Programmierer geworden, muss man dazu sagen.

Zum Glück nicht. Das ist ja, glaube ich, immer so das anders ausgedrückt.

Ich meine so, es ist schade, dass Leute Informatik studieren und dann nur Programmierer werden.

Ich finde das schade, weil das Informatikstudium ist ja schon eher auf der härteren

Seite und letztendlich dann Codierungsaufgaben zu machen, finde ich ein bisschen schade.

Also mit der fundierten, auch mathematisch-formalen Ausbildung,

die wir haben, ich habe ja auch Informatik studiert, finde ich das ein bisschen

traurig, wenn man dann nur irgendwie auf die Entwicklungsschiene dann geht.

Da könnte man mehr machen. Also eigentlich brauchen wir das Studium gar nicht,

um jetzt auch, glaube ich, erfolgreich programmieren zu können.

Ja, ein Satz noch quasi zu der Schulzeit. Ich glaube schon, dass eine schlechte

Lernumgebung, sagen wir das jetzt mal,

Nicht unbedingt nur auf den Lehrer gemünzt, sondern allgemein gesprochen.

Kann halt schon dazu abschreckend sein, dass Leute sich irgendwelche Sachen

nicht angucken oder weiter fortführen, weil es halt total demotivierend danach ist.

Auf jeden Fall.

Und dann ist es einfach nur so, naja, okay, mit einem gescheiten Lehrer wäre es besser gewesen.

Ja, ich fand es toll, dass in meiner Schule in Xanten habe ich Abitur gemacht,

dass ich immer Zugriff auf den Computerraum hatte.

Und es waren auch gar nicht so viele und das war eigentlich ganz schön gewesen,

dass man mir erlaubt hat, auch nach der Schule dahin zu gehen,

weil ich hatte zu Hause einen C64 und einen Amiga und keinen PC.

Aber in der Schule hatten wir PCs, so einen PC10 oder PC20 von Commodore.

Und da weiß ich noch, dass ich dann nach der Schule immer in den Informatikraum

gegangen bin. Das fand ich toll, dass mein Lehrer das ermöglicht hat.

Aber war das jetzt nur für dich oder war das für alle?

Ich vermute für alle prinzipiell, aber kein anderer wollte das oder kein anderer

hatte so ein Interesse am Programmieren.

Ja, okay.

Deswegen saß ich da, glaube ich, immer. Das war auch ganz gut so,

weil ich erinnere mich noch genau, das darf ich eigentlich keinem erzählen.

Ich habe super viele Sachen ausgedruckt und da es kein Druckpapier mehr gab,

wenn ich daran denke, muss ich wirklich selber lachen, habe ich auf Zewa-Papier gedruckt.

Was ist denn jetzt der Nicht-Markenname? Nicht Klorolle, sondern, wie heißt das?

Küchenrolle. Ich habe Küchenrollen bedruckt, genau. Weil die haben die Blätter

sanktioniert, damit die Leute nicht so viel ausdrucken. Und dann habe ich mir...

Küchenrollen gesucht und habe die bedruckt. Da das Nadeldrucker waren.

Ich will gar nicht.

Dass das geht.

Der Nadeldrucker, ja klar.

Der Nadeldrucker waren, hat das funktioniert. Ich glaube, das habe ich noch

nie irgendjemandem erzählt.

Also hier oute ich mich mal. Und ja, dann habe ich das wieder aufgerollt und

mit nach Hause genommen.

Damit ich zu Hause was zu lesen hatte. So die ganzen, weiß nicht,

Q-Basic haben wir damals gemacht. Und Pascal, die ganzen Handbücher,

die waren ja damals noch richtig gut, die Handbücher. Die habe ich dann ausgedruckt und da mitgenommen.

Genau. Spannend, ja.

Okay, dann hast du Informatik studiert in Dortmund.

Warum in der schwarz-gelben Stadt Dortmund? Was hat dich dazu gebracht?

Es ist die Nachbarstadt von Castrop-Rauxel. Von Castrop-Rauxel.

Ganz pragmatisch. Das heißt, die Qualität der Universität war völlig egal.

Hauptsache bei Mama essen.

Oder? Nee, tatsächlich ist das ein bisschen anders. Ich habe ja zwei ältere Geschwister.

Und ich habe bei denen mitbekommen, was für einen Kampf die hatten mit BAföG-Formularen,

weil die dann halt ausgezogen sind und dann hatte ich diese Formulare dann auch

immer bekommen und musste die dann auch ein bisschen weiterleiten,

einscannen, bla bla, so Mittelsmann teilweise spielen.

Und ich wusste relativ schnell, ich möchte keinen BAföG-Antrag stellen.

Und idealerweise wollte ich auch kein Studium haben, was nur theoretisch ist.

Weil ich wollte halt, wenn, dann halt richtig was arbeiten. Und deswegen hatte

ich nach dualen Studienplätzen geguckt.

Und da gab es dann halt eben in Dortmund das IT-Center Dortmund in Kooperation

mit der FH Dortmund, wo ich dann den Bachelor gemacht habe und gleichzeitig

halt gearbeitet habe in einem Unternehmen,

sodass ich ein Gehalt bekommen habe und in der Firma halt gearbeitet habe.

Also entweder habe ich studiert oder gearbeitet. Ich hatte also nicht das klassische Unileben.

Wir waren 25 Leute oder 25 oder 24 Männer im Konkreten.

Und mehr gab es halt nicht. Das war alles.

Und als du dann fertig warst mit dem Studium, du hast ja dann gewechselt auf eine andere Universität.

Ich sage mal, wenn du schon gearbeitet hast auf der einen Seite,

warum hast du dann nochmal die Universität gewechselt? Wie ist es dazu gekommen?

Ja, also ich konnte an der Hochschule, an der privaten jetzt gar keinen Master machen, damals.

Das heißt, wenn ich einen Master machen wollte, musste man damals zumindest,

ich weiß gar nicht, ob das heute so ist, ich glaube mittlerweile geht das,

muss man halt irgendwo woanders hin. Und dann bin ich halt an der normalen staatlichen

Universität halt gegangen, in Essen.

Und hab dann gemerkt, dass das irgendwie auch nichts für mich ist.

Aber du hast schon zu Ende studiert und hast einen Masterabschluss.

Ja, genau, aber man muss irgendwie, also wenn ich die,

ich würde nicht sagen unbedingt, dass ich es bereue, aber weil zu dem Zeitpunkt,

ich hatte halt überlegt, okay, entweder, ich wusste mich noch nicht so richtig,

wo ich mich beruflich vertiefen sollte, weil ich hab ja schon irgendwie dann

zu dem Zeitpunkt, irgendwie zwei Jahre Vollzeit gearbeitet,

aber dann überlegst du, okay, wo willst du jetzt tiefer gehen,

so richtig Programmierer bist du nicht und ich hatte halt damals halt viel,

was heute unter DevOps fällt, halt gemacht, so Jenkins, Pipelines geschrieben,

sich um die Testinfrastruktur gekümmert, also eigentlich alles damit,

weil wir halt damals nicht von jetzt auf gleich einen Release machen konnten,

aber ich hab halt dann die Qualität halt hochgedreht mit allen möglichen Sachen

dann halt und dann wie so, ja, wir brauchen einen Release in zwei Wochen,

dann so, ja, von mir aus auch jetzt, wir waren so ein kleines Team und das war

dann eigentlich ganz gut gewesen,

aber das war halt dieses Zwischending halt eben, zwischen Dev und Ops,

nicht so richtig Dev, aber auch nicht so richtig Ops und da bist du dann da

und dann denkst du so, okay, irgendwo willst du dich jetzt auch weiterentwickeln,

suchst dann irgendwie andere Firmen, bist aber gerade frisch auch aus der Uni,

hast zwar Berufserfahrung.

Aber irgendwie spricht dich nichts an, wo man fachlich genau hin möchte.

Aber was hat dich dann an dem Studium, an dem weiterführenden Studium dann angesprochen,

dass du gesagt hast, naja, ich weiß nicht, wo ich beruflich hin will,

also studiere ich weiter.

Ja, so war das auch.

Okay.

Echt pragmatisch.

Was war das Besondere dann am Studium gewesen, was dich dann noch gereizt hat?

Also hast du dich noch in eine andere Richtung entwickelt im Studium?

Weil letztendlich ist es ja dann eher theoretisch und weniger praktisch.

Hattest du mal darüber nachgedacht, im Bereich der, ich will nicht sagen theoretischen

Informatik zu gehen, aber das Ganze wissenschaftlicher anzugehen?

Hat dich wissenschaftliche Arbeit gereizt?

Nee, gar nicht.

Das habe ich dann auch gemerkt, weil als ich dann im Master war und halt eben

an der Uni und man dann irgendwie,

Softwarequalitätssicherung gemacht hat und dann malt man halt irgendwelche Modelle

mit den ganzen Pfeilen, wo was wie reingeht, aber man malt es halt quasi auf und

ich bin aber halt mehr so der Praktiker und ich so, ich habe das früher schon,

zigmal so implementiert halt, die Theorie halt praktisch auch angewendet.

Und das fand ich dann halt irgendwie dann so, okay, aber das ist dann,

also das macht ja Sinn, aber ich glaube, für viele Leute ist mehr,

wir gehen ja nach der Universität eh in die Wirtschaft und nicht.

Ja.

Und das ist eigentlich für viele Leute, würde ich eher sagen,

eine Ausbildung oder eine Fachhochschule besser geeignet als eine Uni.

Ich habe so gesehen beides gesehen, also ich wollte schon sehen,

okay, wie ist es normal zu studieren, weil das duale Studieren war komplett durchgetaktet.

So, da konntest du gar nicht so viel länger brauchen, wie es bei normalen Unis

der Fall war. Du hattest auch Anwesenheitspflicht zum Teil.

Schön brav, mit Listen.

Genau. Das war bei mir halt immer lustig, weil es waren ja nur 20, 25 Leute.

Das fährt sofort auf, wenn jemand fehlt und der andere nicht für einen unterschreiben

kann. Ja, vor allem nicht.

Und dann war das dann halt auch so. So richtig viel überlegt habe ich damals,

glaube ich, auch nicht. Hauptsache am Master.

Und gut, das ist.

Ja. Was war deine Masterarbeit gewesen? Erinnerst du dich noch an den Titel?

Ja, spannendes, aktuelles, halbwegs aktuelles Thema, würde ich schon wieder

fast sagen, weil ich habe einen,

also den Titel ganz genau kriege ich jetzt nicht mehr hin, aber effektiv habe

ich diverse, ich habe Machine Learning Verfahren getestet, um E-Mails auf Spam zu klassifizieren.

Also einmal so die ganzen alten Sachen, die es dann so gab, so Basefilter und

so weiter und dann halt verglichen mit neueren Tools, die dann halt tiefer in

die Sprache rein gucken, ob das schneller, besser oder sonst was ist.

Also in die Richtung Machine Learning, AI, Thematiken. Heute wird es wahrscheinlich

wieder ganz anders aussehen.

Als du dann mit dem Studium fertig warst und dann deinen Mastertitel in der Hand

gehalten hast, wusstest du dann ab dem Moment, was du gerne machen möchtest?

Also du wusstest zumindest, was du nicht machen möchtest.

Aber war dann der Moment, wo du sagtest, okay, also ich glaube,

in dem Bereich, da fühle ich mich wohl? Oder war das immer noch so ein bisschen

neblig so? Ich weiß immer noch nicht genau, jetzt habe ich meinen Master und

jetzt stehe ich genauso wie vor dem Master, dass ich immer noch nicht genau

weiß, was ich will. Wie war das?

Ja, ich glaube, das fasst das gut zusammen. Super. Weil dann war ich halt mehr

im Ops-Bereich tätig gewesen. Also mehr den Admin-Teil gemacht.

Weil vorher war ich ja mehr auf Dev-Seite quasi.

Hab dann gemerkt, dass das dann auf Dauer auch irgendwie nix.

Das hab ich dann auch ein paar Jahre gemacht.

Ja, in dieser Zwischenzeit fällt ja auch das Git-Buch.

Wo genau ist das zeitlich verortet? Also ist es während des Studiums oder zwischen

den beiden Universitäten entstanden?

Wie kam es dazu? Du hast gesagt mal, dass das Git-Buch, was du geschrieben hast,

eigentlich auf einem Blog-Serie basierte, wo du immer die gleichen Fragen beantworten,

wolltest, weil du, glaube ich, ein bisschen genervt warst, dass die Kollegen

und Kolleginnen immer die gleichen Fragen stellen, dass du es immer aufgeschrieben hast.

In welcher Zeit ist das entstanden? Also zwischen den Studiengängen,

nach dem Master, nach dem Bachelor?

Ja, das ist eigentlich tatsächlich eine spannende Frage, das mal so zu betrachten,

weil das erzähle ich den meisten Leuten noch gar nicht, wenn sie immer fragen,

wie kam es denn dazu, dass du ein Buch geschrieben hast? Ich weiß nicht,

ist das eigentlich eine Top-Frage für dich auch? Wie kam es denn dazu, Bücher zu schreiben?

Ich glaube, die Frage, die eher so üblich ist, ist, nö, glaube ich nicht.

Okay. Bei mir ist das gefühlt ständig, vor allem halt von Nicht-Informatikern.

Oh, worüber hast du dein Buch geschrieben? und dann so über Git und über DevOps.

Und dann sieht man so einen leeren Blick.

Nee, also ich hatte halt diese Blogposts quasi geschrieben, beziehungsweise

ich war halt früher so seit 2010 rum, das war noch,

zu Schulzeiten effektiv noch, habe ich mich bei der deutschen Ubuntu-Community

mit eingebracht und kannte halt da dann halt viele Leute, von denen habe ich

auch sehr, sehr viel gelernt.

Das eine hat bei der Arbeit gelernt, dann halt viel von den Ubuntu-Users-Leuten

halt gelernt, also aus dem Team effektiv und danach in der Uni gelernt,

von der Priorität her gesehen.

Und da war es halt viel, habe ich halt eh viele Texte geschrieben und dann hatte

ich dann halt irgendwann gesagt, okay, ich will jetzt auch Git richtig verstehen

und dann A, will ich das selbst verstehen, dann schreibe ich dann halt.

Das war auch immer so ein Thema bei mir, weil dadurch habe ich mir dann halt

tiefer mit den Sachen halt auseinandergesetzt,

weil wenn ich Texte richtig runterformuliere und geschrieben habe,

und das vielleicht noch irgendwo veröffentlichen kann, wo es noch ein paar Leute

sehen, da gab es ja auch ein paar Open-Source-Magazine, die es heute nicht mehr gibt.

Also alles freiwilligen Leute, dann gibt es ja nochmal eine bessere höhere Qualität,

gleichzeitig haben welche Leute was von und ich kann es Leuten dann auch eben

in die Hand drücken quasi, einen Link zu werfen und dann so, lies dir das mal durch.

Und wenn du dann noch Fragen hast, dann können wir nochmal drüber reden und

dann wird es spannender.

Und das war so der Anfang gewesen und da hatte ich dann halt auch Kontakte zu

diversen Verlagen gehabt. Und dadurch ist das dann halt auch irgendwie entstanden,

dass ich dann halt sagen konnte, okay, ich würde das auch ausbauen von diesen

drei oder vier Blogposts.

Das war, glaube ich, so 2013, 14, also im Rahmen des Bachelor-Zeitraums.

War das dann gewesen. Und dann, um jetzt auf deine Frage zurückzukommen,

2015 habe ich dann die Zusage bekommen, das Git-Buch zu schreiben.

Da war ich gerade mit dem Bachelor fertig und habe dann mit dem Master angefangen,

habe gleichzeitig das Buch geschrieben.

Das hat gar nicht funktioniert.

Und Vollzeit gearbeitet habe ich auch noch bis Ende des Jahres.

Ja, krass.

Das hat nicht funktioniert. Also die Prüfungen haben nicht funktioniert, sagen wir so.

Okay, dann hast du ja deine Prioritäten zumindest so gesehen,

dass du nicht nur ein Git, sondern auch gleich zwei Git-Bücher geschrieben hast.

Also dann hat sich das doch Richtung Praxis dann verschoben und dein Studium

musste dann eben an zweiter Stelle stehen. Aber dein Studium hast du ja auch

abgeschlossen. Also von daher hat das ja schon irgendwie funktioniert.

Als du mit Git angefangen hast, wie verbreitet war das damals schon?

Ich kriege das gar nicht mehr so richtig auf die Reihe.

War das die Zeit, als Git quasi schon gesetzt war, dass es quasi schon so eine

Art Standard wurde als verteilte Versionsverwaltung?

Oder gab es da noch eine Zeit, wo Alternativen eigentlich auch noch aufgetaucht

waren oder dass sich noch nicht richtig klar war von der Community,

das wird sich durchsetzen? Was war das von der Zeit, als du angefangen hast?

Also ich meine, ich habe grundsätzlich mit Git 2011 angefangen,

eben mit dem bei der Arbeit auch entsprechend während des dualen Studiums.

Wenn man jetzt generell mal guckt, Git gibt es, glaube ich, seit 2005.

Und in dem Zeitraum ist ja nicht nur Git entstanden, sondern ja auch Mercurial und Bazaar.

Bazaar in dem Ubuntu-Umfeld. Mercurial weiß ich gar nicht, in welchem Umfeld

das mehr genutzt wurde. Das war Facebook und Google.

Das OpenJDK von Oracle war Mercurial für ganz lange Zeit,

bis die auf GIT umgestiegen sind auch.

Genau, das heißt, in dem Zeitraum zunächst, ab 2005, war ja viel,

war irgendwie alle drei oder vier Sachen verbreitet mit Subversion ja auch noch,

das waren ja noch Source-Forge-Zeiten, glaube ich.

GitHub gibt es, glaube ich, seit 2008 und ich würde sagen, so ab 2010-11 rum

fingen die meisten, fingen dann auch die Sachen an, dass viele Sachen auf GitHub

zumindest liegen, so Open-Source-Projekte.

Deswegen muss man ja eben, das ist unterscheiden, okay, was sind die Firmen,

waren ja eh meistens im besten hinten dran und ich war auch in dem Team der

einzigen, das einzige Team quasi, was Git genutzt hat.

Die anderen waren auch alle auf Subversion gewesen.

Und ich weiß das ehrlich gesagt gar nicht, weil ich glaube, so ein paar Jahre

später, so 13, 14, waren dann erst so, dass so tatsächlich so die meisten,

dass sich Git tatsächlich dann auch durchgesetzt hat.

Dadurch, dass GitHub verbreiteter wurde, dass GitLab dann auch kam und auch

verbreiteter wurde, in Firmen vor allem.

Und dass dann auch die Sachen von Mercurial weggegangen sind,

die es dann teilweise noch gab, in Open-Source-Projekten zumindest.

Was ich mich gerade frage, und du kannst das sicherlich beantworten,

Linus hat das ja letztendlich für sein Linux geschrieben.

Gibt es von der Community oder gab es an ihn speziell Wünsche,

Git so weiterzuentwickeln, etwas, was er für sein Linux nicht brauchte?

Aber was für realistische Projekte nötig war, dass er vielleicht zähneknirschend

gesagt hat, okay, ich brauche das jetzt nicht oder wir brauchen das für Linux-Entwicklung

nicht, aber ich sehe eine Notwendigkeit in gewissen Umgebungen und deswegen,

wollen wir Git ändern.

Also, weißt du, worauf ich hinaus will? Also, die ursprüngliche Motivation von

Git auf der einen Seite, dass Linus gesagt hat, ich baue für mich was Neues,

weil ich das so und so brauche, Punkt, so ist das jetzt und so funktioniert's

jetzt, versus wie hat sich Git in den letzten,

ja, über zehn Jahren weiterentwickelt, vielleicht in eine etwas andere Richtung,

die Linus nicht ursprünglich bedacht hat, aber die quasi nötig ist,

um gewisse praktische Aufgaben zu lösen.

Interessant für dich generell zwei Aspekte. Ein Aspekt noch,

das ist jetzt nicht die Antwort auf deine Frage.

Aber das ist mehr der Punkt so von wegen, wenn man sich das User-Interface quasi

oder die User-Experience von Git anschaut, dann war das ja vor allem sehr lange

halt sehr kompliziert. Oder ist es ja teilweise immer noch.

Also es ist ja nicht so wirklich einfach zu bedienen für Anfänger.

Teilweise im Gegensatz zu Sachen wie Mercurial oder auch Bazaar oder sowas,

weil bei Git wurde ja auch so, wurde halt dieses Datenmodell halt,

wie es intern funktioniert, halt erst gebaut und dann die Befehle drumherum gebaut.

Wenn man das Datenmodell versteht, dann versteht man auch die Befehle, warum die so heißen und,

was auch immer das Problem war, das richtig zu erklären, weil Leute dann halt

das Modell erklärt haben, aber man halt nicht weiß, wie der Linux-Kernel funktioniert,

weil da wurde halt im Wesentlichen ja nur Source-Code hinterlegt.

Ja.

Weil Git LFS, also Large File Storage, das war ja so ein Thema,

was eben nicht der Kernel braucht.

Weil der hat ja keine Binär-Dateien da drin, das ist ja wirklich nur Source-Code

only. Und das wurde dann ja auch hinterher als Add-on mehr oder weniger dran geflanscht.

Wie auch immer man das sieht. Und das merkt man dann halt schon noch,

dass das okay, das war jetzt halt die Lösung für rein Source-Code für dieses

Ding. Und dann wird angefangen, das anders zu machen.

Wo man gleichzeitig auch sagen muss, Linus Torvalds hat das ja angefangen.

Aber ich glaube, der hat das ja auch gar nicht so lange gemacht.

Ich glaube, der hat es ein Jahr oder zwei oder so gemacht. Danach hat er es ja auch abgegeben.

Wie ging das denn dann noch weiter? Committed er noch irgendwas direkt an Git?

Oder ist es jetzt völlig ausgelöst?

Ich glaube, das macht er schon lange nicht mehr. Aber das weiß ich auch gar nicht so genau.

Gibt es einen Maintainer da schon lange, der bei Google, glaube ich,

arbeitet? Und darüber läuft das dann halt.

Gut, also kann man eigentlich heute festhalten, Git hat sich als Versionsverwaltung durchgesetzt.

Ja, kann man so sagen.

Ein ganzes Ökosystem drumherum. Und das ist ja nochmal ein zweites Thema,

das wir gleich kommen, nämlich DevOps, wo Versionierung ja auch eine extrem wichtige Rolle spielt.

Also auch, dass es sich durchgesetzt hat, muss man, glaube ich,

nochmal ein bisschen unterscheiden, mit wem man spricht. Wirklich?

Was haben wir denn für Alternativen zu Git?

Nee, es geht nicht um die Alternativen, sondern mehr um welche Firmen oder Organisationsformen.

Also, okay, ohne.

Weil ich war ja dann ab 2020, war ich für viereinhalb Jahre ungefähr,

bei GitLab gewesen. Und habe dann halt vor allem mit den deutschsprachigen Kunden

halt gearbeitet. Also Deutschland, Österreich, Schweiz.

Ja.

Und dann sieht man, da ging es dann ja nicht nur um Git, sondern vor allem halt um DevOps auch.

Und da hat man halt immer so schön gesehen, so, ja, okay, die meisten Firmen,

die haben halt mehr so deren Toolchain halt gerade gezogen.

Und modernisiert. Und dann kam der öffentliche Dienst und der sagt dann so,

ja, wir würden gerne von Subversion auf Git migrieren.

Ich habe dann immer auf meine Uhr quasi geguckt oder auf den Kalender geguckt

und dann so, welches Jahr haben wir nochmal?

Da sieht man schon einen deutlichen Unterschied.

Ich würde nochmal einen Schritt zurückgehen, weil wir jetzt den Begriff DevOps

schon benutzt haben. Wie definierst du den? Was ist DevOps für dich?

Alles und nichts. Wie würdest du das denn definieren?

Na super. Ich würde es so definieren, dass wir als Entwickler mehr Stress bekommen,

weil wir jetzt mehr können müssen als vorher.

Vorher durften wir einfach nur Software entwickeln und das irgendwie einchecken.

Und heute müssen wir uns mit Deployment beschäftigen, mit Kubernetes,

mit irgendwelchen Optionen, Speicherverwaltung in einem Docker-Container,

Wechsel von Docker nach Podman oder Alternativen.

Was kostet das Ganze? Dann sind wir in der Cloud.

Vorher durften wir so schön unsere Sachen bauen.

Die Datenbank- Admins haben ihre Datenbanken optimiert und wir hatten damit

überhaupt nichts zu tun gehabt.

Und das ist für mich DevOps. Stress für Entwickler.

Bisschen gemein, aber zumindest als ich mit DevOps angefangen habe.

Oder kam mir das so vor, dass Entwickler einfach jetzt mehr können müssen, mehr lernen müssen?

Ja, das ist auf jeden Fall was Wahres dran, aber effektiv muss man ja eh vieles können grundsätzlich.

Aber ja, ich mein, um die Frage halt, also ich frag auch über die Leute,

nämlich wenn sie fragen so, ach DevOps, das ist doch irgendwie CICD Pipeline oder sonst was.

Oder die Menschen, die sich um die Pipeline kümmern, weil das kommt ja auch

häufig dann nochmal zurück.

Deswegen, wenn man DevOps mal auseinander nimmt als Wörter, das ist ja ein sogenanntes Kofferwort,

DevOps, also Entwicklung und Operations, dann geht es ja im Wesentlichen darum,

sowohl die Entwicklung als auch das Operations, also den Betrieb der Anwendung

zusammen in ein Team zu bringen,

ohne Silos und um dann halt eben die Anwendung sowohl schnell entwickeln zu

können, als auch stabil entwickeln zu können.

Weil wenn wir uns so ein bisschen angucken und so, ja, bisher,

wenn man dann quasi die alte Welt anguckt, dann hat sie, ja,

okay, man hat halt so das Release fertig gemacht, wirft es über die hohe Mauer

zum Ops-Team, die gucken sich an, haben keine Ahnung, was das genau ist,

kennen den Source-Code gar nicht,

können vielleicht gar nicht auch in den Source-Code reingucken und müssen da

was in Betrieb nehmen und sicherstellen, dass es stabil läuft,

was dann nicht funktioniert, wenn sie die Anwendung nicht kennen.

Und dann wollen sie natürlich so, okay, wir haben uns jetzt nochmal eine Woche

Zeit für genommen, um zu gucken, wie das Ganze jetzt funktioniert,

damit auch das Thema wie Monitoring zum Beispiel auch richtig funktionieren.

Und dann wollen wir natürlich auch nicht so oft Änderungen haben,

weil wir kennen die Anwendung ja nicht.

Und das sind ja so schon andere Ziele für die jeweiligen Teams.

Die Entwickler sind dafür da, Bugs zu fixen und neue Features zu entwickeln.

Und das Betriebsteam, für die ist es ja nachteilig, wenn ständig was Neues

hin und her kommt, wovon sie aber keine Ahnung haben, wie das funktioniert.

Also im Endeffekt ist in DevOps alle Möglichkeiten, sowohl technisch als auch

organisatorischer Natur, um die Ziele so aufzubrechen, dass alle zusammenarbeiten

an gemeinsamen Zielen und eben nicht getrennt voneinander arbeiten.

Okay.

Du benutzt eins deiner Lieblingsworte und ich mache eine Strichliste.

Du hast jetzt schon zweimal Silo gesagt. Ich denke, das könnte noch mehr werden.

Du solltest im Buch vielleicht mal zählen, wie oft du dieses Wort benutzt.

Ich glaube, das ist ziemlich wichtig im Zusammenhang mit DevOps.

Was ich spannend finde in deinem Buch, dass du

die Technologie, naja, schon irgendwie beschreibst, aber ich finde es spannend,

dass du das ganz klar auf eine, sagen wir mal, als Kulturtechnik siehst,

wie wir als Gruppe Software entwickeln, das am Ende hinten was deployt und läuft,

und wie die einzelnen Teams miteinander sprechen müssen, wie die Übergänge sind,

wie man das mit Technologie aufbaut, automatisieren kann.

Deswegen, als ich dein Buch angefangen habe, habe ich gedacht,

ja, okay, jetzt geht es um Produkte und wie ich die Produkte einsetze.

Ich war aber eher positiv überrascht, dass es eben kein Produktbuch ist.

Ich glaube, da es so viele Produkte gibt, müsste man jeweils eigene Bücher zu

diesen Produkten lesen.

Dass das zwar auch irgendwie mit vorkommt, um vielleicht eine Vorstellung zu

bekommen, wie man das Produkt grundsätzlich einsetzt, aber dass es eigentlich

darum überhaupt nicht geht.

Und eins der wichtigen Prinzipien, wären die CALMS-Prinzipien,

wo es eigentlich um Culture geht.

Also diese CALMS-Prinzipien, kannst du dazu was sagen?

Was versteht man darunter? Warum sind die Prinzipien wichtig,

wie Culture, Automation und so weiter?

Genau, also die Basis ist effektiver Culture, also die Kultur,

wie wird miteinander halt gearbeitet?

Weil es bringt halt nichts, wenn zwar alle im selben Team sind,

aber man eben halt nicht irgendwie eine offene Fehlerkultur hat oder sowas.

Weil wenn ständig nur mit den Fingern aufeinander gezeigt werden,

dann bringen halt die besten Automatisierungen nichts. Und weil um die Wörter

halt nochmal auseinanderzufrieden oder das Wort halt C für Culture,

A für Automation, L für Lean,

M für Metrics oder Measurement und S für Sharing, genau. Habe ich das auch schon fast vergessen?

Und das sind so die Sachen, aber alles fußt quasi auf das Culture,

weil das bringt halt nichts, wenn man tolle Automatisierung hat,

aber die Teams halt komplett getrennt voneinander in Silos arbeiten.

Drei, danke. Jetzt ärgst du mich bestimmt und baust das extra ein,

damit ich hier mit meinem Stift die ganze Zeit Linien mache.

Und das ist dann halt auch irgendwie so das Thema. Es ist schön,

wenn du eine CICD-Pipeline hast, die zwar irgendwie technisch gut funktioniert.

Aber wenn du halt dich nicht traust, ein Deployment rauszuhauen,

aus welchen Gründen noch immer, sei es aus Ops-Sicht, weil du die Anwendung

nicht kennst, oder aus Dev-Sicht, weil du die Betriebsumgebung nicht kennst,

dann bringt halt die ganze Automatisierung halt nichts.

Dann bist du halt nur schneller in der DDR. Scheiße.

Du hast ja in der Praxis das gesehen. Was würdest du sagen, wo hakt es am meisten in Unternehmen?

Also kommen die eher darauf zu sagen, hey, diese Culture-Sache,

die finden wir richtig cool. Wir sollten alle zusammenarbeiten und uns einhaken

und dann zusammen tanzen, bis wir am Ende ein Ergebnis haben.

Oder von den fünf Punkten bei CALMS, wo siehst du, dass es daran meistens hakt?

Also ist es wirklich die Culture oder ist es eine fehlende Fehlerkultur?

Ich war sehr überrascht, nein, nicht überrascht, sondern als ich das gelesen

habe, dass man Leute nicht blamen soll, wenn sie Fehler machen.

Da war meine erste Reaktion, das ist total unrealistisch.

Ich glaube, das ist voll menschlich zu sagen, das war ich nicht, das war es du.

Funktioniert das echt, dass Leute, Menschen sich ändern können und die Schuld

nicht bei sich selber suchen, sondern sagen, okay, das war dein Fehler,

aber das ist völlig egal, wir ziehen alle nach dem Strang.

Funktioniert das?

Ja, mit Ausnahmen natürlich. Es kommt sehr, sehr stark darauf an,

wie die Firma gestrickt ist oder die Organisation, wo man drin ist.

Auch wie groß natürlich die Firma ist und wie alt vor allem dann halt auch.

Weil das ist ja schon eine andere Arbeitsweise und das merkt man dann halt auch.

Weil ich kenne halt beide, alle Welten quasi.

In Firmen, die es schon seit 25 Jahren gibt oder mehr.

Viele Firmen sind ja in den 90ern irgendwie so entstanden. Also IT-Firmen.

Und dann halt noch bei so einer Firma wie GitLab, die es seit 2011,

2012 gibt, die dann auch sehr groß gewachsen ist, wo man halt direkt mit dem

DevOps-Mindset halt gestartet ist.

Und da ist es halt einfacher, so Sachen wie Lean, also schlanke Prozesse zu

haben, weil man die halt eh neu aufbaut.

Und dann hat man halt den ganzen Altbestand ja auch gar nicht mehr.

Sowohl Altbestand im Sinne von den Leuten, die mit ihrer Inventurnummer,

Inventarnummer auf dem Nacken unterwegs sind und warten auf ihre Rente,

als auch die Leute, die halt,

als auch die Prozesse oder Tools, die da halt auch mit dranhängen.

Weil häufig ist es so, ah, das machen wir schon immer so. Das ist so mein Lieblingshasssatz,

wenn man den halt hört, so, ah, warum sollte man ein Code-Review machen?

Weil Das haben wir noch nie so gemacht.

Genau, und das wird noch nicht immer so langsamen und das wird auch nicht dazu

führen, dass wir irgendeinen Wert an den Kunden ausliefern,

was halt irgendwie dann doch sehr, und das höre ich halt heute teilweise immer

noch, und wo ich dann auch so denke,

also lieber jetzt ein paar Minuten mehr drüber nachdenken, als,

später dann halt Probleme zu haben. Vor allem, wenn die Release-Cycle in eh

sechs Monate oder noch länger sind.

Also wenn du diese fünf Dinge von CALMS nochmal vornimmst, wo würdest du sagen,

haben Unternehmen oder Teams die größten Schwierigkeiten mit?

Culture, definitiv. Weil der Weg dahin ist auch nicht so einfach.

Weil ich habe ja dieses Kapitel geschrieben, wie man die DevOps-Transformation macht.

Und effektiv ist das sehr, sehr schwierig, das auch runterzuschreiben.

Weil es halt echt stark davon abkommt, was ist das für eine Firma, was sind das für Leute.

Ist das öffentlicher Dienst, ist das halt ein Startup, ist das halt eine 30.000-Menschen-Bude.

Da sind überall Prozesse und sonst was drin, die man dann halt auch aus den Menschen

nicht rausbekommt. Ich bringe mal ein Beispiel.

Ich hatte mal im Rahmen von meiner Tätigkeit bei GitLab, ging es halt darum,

das Tool, also GitLab zu implementieren oder einzuführen.

Das fällt jetzt mehr unter dem A, also Automation. Das ist relativ einfach,

es gibt mehr oder weniger eine Wahrheit und fertig.

Bei Kultur gibt es nicht die eine Wahrheit. Das war auch die Schwierigkeit,

das Buch zu schreiben, weil es gibt halt nicht das eine richtig und falsch,

sondern sehr viel, es kommt noch drauf an.

Und das hat dann halt so die Auswirkung, wir saßen dann halt in so einer Runde

mit so 30, 40 Leuten und da meint man so, ja, okay, hier hat man jetzt ein Tool,

die DevOps-Plattform GitLab, damit werden wir grundsätzlich halt irgendwie schneller unterwegs und,

das hat aber diese Auswirkungen, weil da kommt man nochmal auf den Satz zu sprechen,

oder den Slogan, wie auch immer, People over Processes over Tools.

Weil das beste Tool am Ende bringt halt nichts, wenn die Prozesse nicht angepasst worden sind.

Weil das hatte ich denen dann halt auch gesagt, weil jedes Mal kam so,

ja, das klingt ja gut, klingt auch ein super Feature, aber da passen ja unsere Prozesse nicht.

Und dann war halt meistens der Tenor so, ja, bringt uns nichts,

weil die Prozesse so sind, statt die Prozesse zu hinterfragen.

Und wenn man dann aber die Prozesse hinterfragt, dann kommt halt wieder das

nächste, ja, das können wir aber nicht ändern, weil.

Ja, okay.

Und dann sind wir halt schnell wieder, dann sind wir schnell in der menschlichen Komponente.

Und da ist mir lustigerweise auch fast ein Fauxpas passiert,

weil ich meinte dann so, ja, das beste Tool bringt nichts,

die beste Automatisierung bringt nichts oder das beste Tool bringt nichts,

wenn die Prozesse scheiße sind und die besten Prozesse bringen nichts, wenn sie Menschen

stur sind. Genau. Und,

das ist so halt das Thema, weil eben, wenn es eben neu ist, eine neue Abteilung

aufgebaut wird oder eine neue Subfirma gegründet wird oder sowas,

da kann man das irgendwie einfacher machen, wenn man auf einer grünen Wiese ist, aber halt,

von einem bestehenden Projekt in einer großen Firma das zu machen,

das ist halt schwierig. Weil ich hatte von einem Mal gehört,

der bei der Bahn gearbeitet hat und er meinte dann halt, er findet DevOps doof.

Okay, eine Person, 60 Jahre alt, immer Kobol programmiert.

Nee, das war ein Typ, der ganz viel AI-Kram macht.

Und dann fragte ich, okay, warum? Ich frage natürlich, was ist sein Verständnis

von DevOps? Weil da hat halt auch jeder sein eigenes, anderes Verständnis.

Dann meint er so, ja, bei denen ist halt DevOps, laut seiner Erklärung,

ich hab's nie weiter verifiziert, na ja, die Devs machen deshalb auch den Betrieb.

Also so ähnlich, wie du das gesagt hast, nur noch ein bisschen härter,

würde ich sagen, weil die haben eigentlich gar nicht die Kapazitäten dazu.

Und du musst ja in einem Team ein cross-funktionales Team haben,

dann aus DevOps, aus Security, aus Business-Sicht vielleicht noch,

aus Finance-Sicht vielleicht noch, weil theoretisch spielen ja ganz viele Aspekte

mit rein und das heißt immer noch irgendwie DevOps,

weil wenn man jetzt irgendwie sagt, okay, wir haben jetzt irgendwie eine Anwendung,

die wir betreiben müssen, dann spielt ja irgendwie eine Finanzabteilung quasi

auch mit eine Rolle, wenn man

sagt, okay, hosten wir das jetzt on-premise oder gehen wir in die Cloud.

Hat finanzielle Auswirkungen, die dann auch wiederum technische Auswirkungen

haben, wie man die Anwendung designt, aufbaut, deployed, betreibt und so weiter.

Ja.

Und theoretisch musst du das ja eigentlich alles zusammenbringen,

aber das ist halt nicht so einfach, weil nicht für jede Sache brauchst du halt

noch alle, ne? Oder wie kommst du halt von A nach B?

Man kennt halt den wünschenswerten Zielzustand, alle sind Friede,

Freude, Eierkuchen und arbeiten zusammen.

Ja.

Aber wie kommt man dahin? Das ist nicht so einfach.

Ich find's interessant, weil sich das übertragen lässt, auch auf die Softwareentwicklung.

Wir hatten ja auch in der Softwareentwicklung eigentlich einen großen Shift

vor einigen Jahrzehnten Richtung agile Softwareentwicklung, ob man es jetzt agil oder nicht nennt.

Aber das war ein recht großer Wechsel gewesen. Genauso natürlich auch von eher

so traditionellen, alten Programmiersprachen, so wie Kobold oder RPG,

Richtung modernere Programmiersprachen wie C++, C Sharp und Java.

Und da ist eigentlich auch das so, so dieser Vorbehalt gegenüber dem Neuen und,

ich glaube, dass es vielleicht auch so eine Generationsfrage ist und deswegen

finde ich es schön, dass du sagst, es hängt vielleicht auch ein bisschen was

von dem Team zusammen oder hängt damit zusammen, ob die jetzt gerade anfangen,

weil ich glaube schon, dass

es wie so eine Art Wechsel ist, dass neue Teams, junge Teammitglieder gleich mit dem neuen Wissen

anfangen und ein Projekt umsetzen und realisieren, weil sie es einfach so kennenlernen

und für diese halt normal ist.

Und ich sag mal, heute ist eine objektorientierte Programmiersprache absolut selbstverständlich.

Da würde kaum jemand ernsthaft auf die Idee kommen, neue Projekte mit irgendwie

Kobol zu beginnen. Das sind eher so Altlasten.

Aber so gibt es auch einen Mindshift irgendwie so alle vielleicht 10, 20 Jahre.

Und vielleicht ist das so ein Übergangsproblem, was wir heute haben.

Vielleicht ist es wirklich so, dass in 20 Jahren oder wenn die Roboter uns beherrschen in 100 Jahren,

dass DevOps völlig selbstverständlich ist und dann macht eh nur die Maschine

Fehler oder vielleicht auch wir nur als Menschen, wer weiß.

Vielleicht ist es einfach nur so eine Kulturfrage, dass sich das alles ändert

und dass es vielleicht umso schwieriger ist, alte etablierte Prozesse zu verändern,

ja tatsächlich, weil die Leute es so gewohnt sind, so zu arbeiten.

Und ich würde auch ein zweites.

Ein zweiter Parallel sehen, zum Beispiel zu SAP-Technologien,

so als Art, in Anführungszeichen, Standardsoftware. Also ich glaube,

wenn wir alle Standardsoftware nutzen würden, mit Standardprozessen,

könnte jeder ein un-customized SAP einsetzen.

Aber, dass jeder SAP customized ist im Grunde ein Hinweis darauf,

dass keiner mit den Standards einverstanden ist, sondern, wenn man sagt,

für mich gilt eine Extrawurst, das und das ist bei uns anders.

Und ich glaube, dadurch kommen auch diese immens hohen Träge zustande,

warum SAP-Software so unglaublich teuer im Customizen ist, weil die Leute darauf

bestehen, nein, das darf nicht so gemacht werden, wie SAP das vorgibt.

Das ist ein Standard, aber wir machen das aber anders. Und deswegen müssen wir

jetzt SAP komplett umschreiben, dann zahlen wir halt 100 Millionen. Egal!

Anstatt die Prozesse vielleicht zu überdenken. Deswegen, ja,

Culture kann ich nachvollziehen.

Es gibt noch was Zweites neben Culture oder neben CALMS-Prinzipien, so die DevOps-Pipeline.

Du hattest schon ein bisschen was mit CICD gesagt.

Was versteht man hinter so einem Lifecycle? Also ich kenne das so als unendliche

Acht, unendlich Zeichen.

Kannst du mal die verschiedenen Phasen mal so durchgehen und kurz sagen,

was man darunter versteht? Also man plant natürlich und zum Schluss ist dann

irgendwie was, was geschützt werden muss und ausgeliefert wurde.

Kannst du das mal durchgehen?

Genau, also wir haben halt, genau wie du sagst, das hat diese liegende Acht,

dieses Unendlichkeitszeichen.

Heißt übrigens auch Lemniskate, glaube ich, als Fachbegriff.

Oh.

Habe ich, glaube ich, nicht im Buch verwendet, weil es, glaube ich,

mehr Leute irritiert hatte.

Aber, genau, es startet ja grundsätzlich damit, wenn du eine Änderung,

sagen wir mal, du implementierst jetzt eine Änderung, oder möchtest eine Änderung

implementieren, muss erstmal geplant werden, natürlich so, okay,

was möchten wir jetzt überhaupt machen?

Hat man auch diese Plan-Komponente, da ist quasi auch diese agile Arbeit noch

mit drin, würde ich sagen, also alles, was so Scrum, muss ja nicht nur Scrum

sein, kann ja auch Kanban oder sowas sein, mit drin, okay, dann haben wir halt

irgendwie was geplant, okay, wir möchten jetzt irgendwie einen Bug fixen.

So, und das Ziel sollte ja sein, dass ich idealerweise,

das ist jetzt mehr technischer Natur, dass ich diese Änderung,

sagen wir jetzt einen One-Line-Fix,

erstmal natürlich geplant habe, dass ich weiß, dass ein Fehler da ist,

dass ich dann anfange, das halt zu programmieren und dass es idealerweise möglichst

schnell ausgeliefert wird, damit eben.

Der Endkunde oder der Endnutzer dann eben auch weiß,

also dann sieht, dass es halt gefixt ist.

Weil für uns als Nutzer sagen wir jetzt mal, wenn wir irgendeine Software nutzen,

dann ist es irgendwie total nervig, wenn es halt ewig dauert,

bis irgendwas gefixt wird und dann baut man sich irgendwelche Workarounds.

Das heißt, wir fangen jetzt halt mit Code an und machen halt diese Änderung.

Da kommen halt so Sachen wie Code Review zum Beispiel auch noch mit zustande,

damit wir sehen, okay, da ist doch noch was nicht ganz gemacht.

Gehen wir weiter zum Bild und Test, also das Projekt gebaut wird,

aus den Sourcen gebaut werden kann, dass es dann auch ordentlich getestet wird

in der CI-CD-Pipeline, damit die Qualität dann auch eben gut ist und hoch ist.

Und das ist dann quasi schon mal dieser CI-Teil, weil erstmal haben wir ja nur

Code integriert, gebaut und getestet, sodass wir wissen, grundsätzlich funktioniert

das Ganze dann halt auch.

Und das ist ja quasi dann auch der Dev-Teil. Und dann kommen wir ja auch entsprechend

in den Ops-Teil halt rüber, weil dann ja ein Release gebaut wird,

ein Deployment gemacht wird,

Und dann haben wir noch.

Gegebenenfalls hoffentlich einen Monitoring, sodass man dann auch sehen kann,

okay, diese Änderung, die wir jetzt gemacht haben, ist dann halt eben auch paketiert

worden, ist dann auch deployed worden auf den Servern, ist auch in Betrieb

und wir können das dann irgendwie nachvollziehen und gucken und testen und auch

Monitoring vielleicht sehen.

Hat das Probleme bereitet, führt das vielleicht zu mehr Last und können dann

die Sachen, die wir daraus lernen, mit in die nächste Planung mitnehmen,

damit das wieder von vorne anfängt, effektiv. Was aber ja auch irgendwie nicht

alles ist, weil theoretisch muss man auch Security beachten und diverse Governance-Sachen,

Compliance-Sachen dann auch nochmal mit beachten.

Das klingt so ein bisschen, als ob man für die verschiedenen Teile verschiedene Tools nutzt.

Oder gibt es ein Tool, was alles kann? Wie würdest du das auf dem Markt sehen?

Gibt es da einen Trend zu zum Beispiel GitLab, die sagen, wir versuchen maximal

viel, alles aus einer Hand zu liefern?

Oder siehst du einen Trend, dass man versucht, okay, wir suchen das beste Tool für jede Stufe?

Wie würdest du das sehen?

Ja, ich meine, das musst du auch ein bisschen im historischen Kontext auch wieder

betrachten. Weil, wenn man sich das so ein bisschen historisch betrachtet,

da hat man meistens halt für jedes Ding ein Tool gehabt.

Man hat einen Jira fürs Projektmanagement, man hat,

irgendein Git-Repository fürs Source-Code-Management, man hat noch irgendwie

ein Jenkins fürs Bauen und Testen des Projektes, man hat noch irgendeine andere

spezialisierte Deployment-Pipeline effektiv,

die ist dann irgendwo hin deployed.

Man hat auch ein separates Monitoring und die sind halt alle nicht miteinander

verknüpft, historisch betrachtet. Wenn man jetzt sich die Marketing-

Aussagen von den verschiedenen Herstellern anguckt, dann sieht man schon so

einen Trend, okay, dieses Hin-

und Her-Switchen zwischen den verschiedenen Stages ist halt anstrengend.

Aus Compliance-Sicht kommt heutzutage noch mal hinzu oder auch aus Security-Sicht,

weil du dann halt, wenn du da eine Änderung gemacht hast, wie halt vorhin gesagt

hast, diese One-Line-Änderung,

idealerweise würde ich dann ja auch sehen wollen, okay, ohne zwischen zehn verschiedenen

Tools hin und her springen zu müssen, dass alles funktioniert hat.

Weil häufig ist es halt, weil dann Sonst hast du wieder, Silos, mach deinen Strich.

Danke, wir sind bei vier Strichen.

Die dann halt nicht nur personell bedingt sind, sondern auch toolbedingt.

Weil ich sehe dann halt voll häufig, dass dann halt irgendwelche Container gebaut

werden, wo dann halt Security-Scans ausgeführt werden, aber nach dem Deployment

irgendwann, die landen dann irgendwo in einem E-Mail-Postfach und werden dann irgendwie verteilt.

Da staute es sich dann und keiner guckt rein. Es ist dann zwar schön,

dass man dann irgendwelche Ausgabendaten hat, wo man theoretisch die Sachen

rausholen kann, aber wie du ja auch am Anfang gesagt hattest,

es ist ja dann doch irgendwie anstrengend,

den ganzen Stack halt zu betrachten.

Daher geht auch irgendwie die Reise halt schon eher Richtung DevOps-Plattformen hin.

Zwischenzeitlich hießen die, glaube ich, auch Value Stream Delivery Plattformen.

Je nachdem, ob man Gartner oder sonst was fragt. Aber ich glaube,

DevOps-Plattform hat sich soweit durchgesetzt und den Begriff hat im Wesentlichen GitLab geprägt.

GitHub macht das im Endeffekt halt auch.

Und das sind so die, gut, dann gibt es halt noch Azure DevOps,

aber ist auch Microsoft. Mal gucken, wie lange das noch gibt.

Und hat theoretisch halt auch noch den Atlassian-Stack, aber da passiert ja

auf Bitbucket-Seite auch nicht mehr so viel.

Das klingt eher wie eine Gefahr, weil wenn ich überlege, wir haben große Monopole,

das ist ja eigentlich nichts Gutes, dass wir uns auf einige wenige Unternehmen

konzentrieren, weil ich glaube, so viele verschiedene Lösungen haben wir am

Markt jetzt ja doch nicht.

Also für die einzelnen Teile ja durchaus, aber ist es nicht eine Riesengefahr,

dass wir an Monopole gehen und haben wir nicht in Europa auch wieder insbesondere

das Problem, dass es an amerikanische Unternehmen fällt?

Ja, genau. Das ist ein guter Punkt und da gibt es auch keine so schöne Lösung

effektiv. Weil, also klar, wenn man jetzt sagen würde, wir setzen das nur auf

Open-Source-Software, dann hat man ein Problem, man kriegt aber die ganzen Compliance-Sachen

teilweise auch nicht umgesetzt.

Wenn man sicherstellen will, dass alle Änderungen auch wirklich nachvollziehbar sind.

Also zum Beispiel, dass eben in einem Source-Code was geändert wurde,

dass auch ein Paket mit drin ist.

Und das danach ausgeführt, ausgeliefert wurde. Wenn es in ein Tool ist,

geht das dann halt. Aber wenn verschiedene Tools ist, dann ist es wieder schwieriger,

weil man die dann wieder mit Gaffa-Tape zusammenkleben muss.

Das ist in der Tat ein Problem, weil, also es ist ja im Endeffekt eine Abwägungssache.

Hat man jetzt auf der einen Hand quasi ganz viele Tools, wo die User-Experience

halt eher schlecht ist und ineffizient ist, oder geht man jetzt den Lock-in-Effekt

und setzt auf einer Plattform.

Jetzt erstmal egal, welche das ist. Einen gewissen Lock-in hat man halt eh immer.

Das ist in der Tat ein Problem. In der Zeit, als ich bei GitLab auch gearbeitet

habe, meinte auch jemand so, ja, Plattformen wie GitLab oder GitHub ist sowas

wie SAP, wenn man einmal drin ist, dann kommt man da quasi nicht mehr raus.

Fand ich irgendwie auch witzig zu einem gewissen Rahmen, weil irgendwie stimmt

das ja auch. Weil wenn du halt wirklich alle Sachen da drin hast,

das wird durch so Vibe-Coding, AI-Agents nochmal krasser, finde ich.

Weil wenn du wirklich alles in einer Plattform drin hast, dann hast du natürlich

auch mehr Kontext und so weiter.

Und dann kann der natürlich, kann der AI-Agent, wenn er jetzt da hin weit codet,

halt effizienter, effektiver sein, als wenn er in zehn Tools reingucken müsste,

wo er nicht reingucken kann.

Absolut. Also das sehe ich in der Softwareentwicklung ganz klar,

dass Technologien möglicherweise gewählt werden deswegen, weil die Sprachmodelle

einfach mit viel mehr von diesen Technologien trainiert wurden.

Ich sehe das immer bei Webprojekten. Also wenn ich ChatGPT aufmache und sage,

baue mir ein Webprojekt, dann wählt er intuitiv immer React und Tailwind als

CSS-Utility-Bibliothek.

Ganz selbstverständlich, da musst du gar nichts sagen.

Also das heißt, er wurde wahrscheinlich, oder eher es, es wurde mit viel Material

von React gefüttert, dass es damit recht vertraut ist und es natürlich findet,

klar kann man auch die ganzen Projekte

mit anderen Technologien generieren lassen, das funktioniert auch.

Aber ich finde es interessant, dass es so eine Standardwahl gibt,

dass das LLM sagt, okay, ich muss mich ja für irgendwas entscheiden.

Wenn du mir einfach sagst, schreibe mir ein Programm das, dann muss ich für

irgendeine Programmiersprache entscheiden.

Und dann wählt er es häufig sowas wie Python zum Beispiel, weil einfach das

Trainingsmaterial gut da ist.

Und ich glaube auch, wenn die verschiedenen Module einer alle umfassenden Software die Daten

rausgeben können, wir haben heute solche Kontextprotokolle, dass die Daten abgeholt

werden können, vielleicht über Fortschritte, Issues und sonst was,

dann ist es viel wichtiger,

dass eine Plattform alle diese Daten liefern kann, um eine vollständige Sicht zu haben, sodass

so ein AI-System automatisch – aus Fehlern oder Ausnahmen, Exceptions –

mögliche Lösungen direkt vorschlagen kann.

Je mehr umfassende Sicht man hat, desto hilfreicher ist das System.

Absolut nachvollziehbar.

Nehmen wir mal an, ich möchte jetzt meinen Shop für Lakritz möglichst schnell

online setzen und möchte dabei auf DevOps-Prinzipien setzen.

Was für ein Produkt würdest du mir empfehlen, ohne dass du für ein spezielles

Unternehmen jetzt sprechen müsstest, für das du mal gearbeitet hast?

Ja, ich meine, in dem Fall, ich bin halt biased in dem Sinne,

weil ich halt bei GitLab gearbeitet habe. Und das ist, und da kommt halt der

Punkt, das, was man als Marketing macht und was realistisch ist.

Je kleiner du bist, desto eher kannst du alle Features von GitLab verwenden.

Je größer du wirst, desto schwieriger wird das halt, weil halt einige Sachen

vor allem auf der Ops-Seite nicht so gut umgesetzt sind, Stand jetzt.

Was auch irgendwie schwierig ist, weil theoretisch hast du für jeden Stage des

DevOps, Life Cycles, gibt es theoretische Firmen mit Milliardenbewertungen.

Du hast Jira, du hast GitHub GitLab zum Beispiel für Source-Code-Management,

du hast Jenkins für CI, gut, das ist jetzt kein Milliardenunternehmen,

wobei weiß ich nicht, wie es bei CloudBees ist.

Man hat noch sowas wie JFrog und Artifactory für die Package Registry oder Container

Registry und so weiter. Du hast nochmal ganz viele Security Tools,

die du einbinden kannst, die auch nochmal alle Milliardenbewertungen haben.

Oder Monitoring Observability Tools genauso. Das ist dann halt schon schwierig,

das alles in einem Produkt dann auch richtig reinzubekommen oder auch umzusetzen,

wozu es dann den Fokus ist. Das habe ich dann ja vorhin GitLab intern gesehen.

Ich hatte halt, oder ich finde dann halt auch eben GitLab dann auch deswegen

praktisch, deswegen habe ich da auch gearbeitet, weil es halt eben Open Core ist.

Also das Basismodell ist halt immer noch Open Source, auch wenn viele Enterprise

Features halt unter einer Enterprise-Lizenz mit drin sind.

Ich meine, ich arbeite da seit einem Jahr nicht mehr, aber ich würde das halt

immer noch so machen, wenn ich jetzt vor Null anfangen würde,

würde ich das immer wählen.

Ganz grundsätzlich allerdings, habe ich den meisten Kunden halt auch so gesagt.

Also damals wie auch heute, wenn man einmal auf GitLab oder GitHub ist,

und jetzt rede ich vor allem also auf Closed-Source-Projekte,

dann hat man viel gewonnen, wenn man auf einen von den beiden ist,

weil man dadurch dann halt schon viel abdeckt.

Weil die meisten Firmen, die noch nicht auf dem modernen Stand sind,

was die Toolchain angeht, waren halt mehr so auf Bitbucket Jenkins unterwegs.

Da hast du dann halt noch so viel Aufwand, vor allem bei Jenkins,

um die Infrastruktur am Laufen zu halten. Was bei GitLab deutlich einfacher

ist. Ich habe es früher auch gemacht.

Aus deinem Buch konnte ich, glaube ich, ablesen, raushören, dass du überhaupt

kein Fan von Jenkins bist.

Und eigentlich Jenkins-Bashing betreibst. Ich war überrascht,

vor ein paar Tagen, das ist noch gar nicht so lange her, kam irgendwie so eine

Developer-Survey raus. Ich weiß gar nicht, von wem das war.

Vielleicht sogar von IntelliJ, dem Unternehmen.

Und da war Jenkins ganz oben mit dabei gewesen.

Ja, das ist noch verbreitet.

Es ist immer noch extrem verbreitet. Warum sehen die Leute die Nachteile nicht, die du siehst?

Naja, man muss ein bisschen das im zeitlichen Kontext betrachten.

Also ich habe halt viel Jenkins gemacht von 2011 bis 20,

mit Pausen dazwischen, aber im Wesentlichen irgendwie so acht,

neun Jahre oder sagen wir mit den Pausen rausgerechnet irgendwie sieben Jahre,

wo ich sehr viel Jenkins-Kram auch gemacht habe, also wirklich tief da eingestiegen bin.

Und da gibt's dann so viel, es ist halt ein relatives Moloch,

du hast ein Plugin-Dependency hell, dass alles mögliche in irgendwelchen Plugins

gelandet ist und was du ja auch gemeint hast, ja als DevOps,

da muss man so viel lernen, tun und können.

Und das Ziel von einem Entwickler sollte ja eben sein, in einem DevOps-Team,

das halt die Sachen entwickelt.

Und die anderen Sachen sollten wirklich so weit abstrahiert und nutzbar sein,

dass man eben nicht an den Tools arbeiten muss, sondern mit den Tools.

Und das sieht man bei so Sachen wie GitHub mit GitHub Actions oder GitLab mit

den CICD-Funktionen schon eher, dass die Leute halt mit dem Tool arbeiten statt an dem Tool.

Bei Jenkins wurde halt sehr, sehr viel Aufwand reingestellt,

um da Automatisierung zu bauen, statt halt an dem eigenen Projekt zu bauen.

Und das vergessen auch viele. Das sieht man halt auch in der Kubernetes-Umgebung

sehr, sehr viel. Da haben viele Leute halt mehr Spaß dran, da noch irgendwelche

Sachen noch mit hinzubauen, statt so, bringt das jetzt eigentlich dem Projekt weiter?

Was ja auch eine Art Standardisierung ja ist bei Kubernetes,

was das Deployment angeht.

Gut, wenn ich auf die Uhr gucke, sind wir schon eine Stunde dran und ich habe

noch gar nichts zu dir als Autor gefragt und ich glaube, wir sollten da nochmal kurz überleiten,

wie es dir als Autor gegangen ist.

Wie ist es grundsätzlich dazu gekommen, dass du Bücher schreiben wolltest,

also dass du geschrieben hast, hast du schon motiviert, eine Lernstrategie für

dich, außerdem willst du nicht

immer wieder gefragt werden, sondern kannst sagen, guck da, da ist gut.

Aber so ein gedrucktes Buch noch mal ernsthaft nach vorne zu bringen mit dem

Aufwand, der dahinter steckt.

Was steckt dir dahinter? Warum wolltest du gerne ein wirklich echtes Buch bei

einem echten großen Verlag wie jetzt zum Beispiel Rheinwerk schreiben?

Genau, ich habe ja den Vor- und Nachteil bei zwei Verlagen geschrieben zu haben.

Das Git-Buch war ja nicht beim Rheinwerk Verlag.

Der Hauptgrund war im Endeffekt Reputationsgewinn.

Weil ich war zu dem Zeitpunkt, als ich den ersten Autorenvertrag unterschrieben habe, 23.

Und ich wusste ja nicht, wo ich genau hinwollte. Wir erinnern uns.

Und man hatte ja eh Spaß am Schreiben, mehr oder weniger.

Und dann habe ich jetzt die Möglichkeit, dann mache ich das.

Und die Einnahmen aus so einem Buch, die sind ja bekanntlich nicht so hoch.

Außer man hat ›Java ist auch eine Insel‹ geschrieben.

Wirklich?

Und dann, aber ich habe da immer drauf geguckt, das war dann auch der Grund

für das zweite Buch, zwischen Primäreinnahmen und Sekundäreinnahmen zu unterscheiden,

weil wegen Geld macht man das ja irgendwie eh nicht, also das Buch selbst quasi,

aber was dahinter kommt, ergeben sich immer wieder neue Türen und Möglichkeiten,

die sich dadurch öffnen.

Weil man muss auch ein bisschen unterscheiden zwischen dem Git-Buch und dem

DevOps-Buch, die Motivation.

Weil bei Git war es dann, da gab es ja schon einige deutsche Bücher halt auch.

Das war halt wirklich hauptsächlich Reputation und gut, dann habe ich halt was

Eigenes. Und wenn es einen Verlag gibt, der das macht, warum nicht?

Und beim DevOps-Buch war es dann halt mehr so, naja, da kommen so Sachen wie

deine Aussage, wie, ach ja, DevOps ist ja anstrengend oder so für die Leute.

Oder wie von dem anderen, den ich meinte mit, ja DevOps, jetzt mach doch einfach Dev, mach auch Ops,

und es funktioniert nicht gut und beziehungsweise halt auch,

da war ich ja halt eben bei GitLab, dass ich den Kunden, bei den Kunden halt

immer gesehen habe, so naja, die wollen halt den Ferrari haben.

Wissen aber nicht, wie man den fährt und haben auch keine Straße dafür.

Und dann fiel denen auf, es gibt auch keinen Führerschein.

So, oder? Und dann hat man halt wieder dieses People over Processes, over Tools dann halt.

Da dachte ich, okay, wenn das, gab es natürlich auch deutsche Bücher,

äh, englische Bücher, meine ich.

Und da war für mich dann halt auch die Motivation, okay, ich möchte das jetzt

hier auch für mich, für den deutschen Markt quasi, wo das Thema noch relativ

neu ist, würde ich mal sagen.

Oder noch nicht so richtig durchdrungen ist im Vergleich zur agilen Softwareentwicklung,

die ja auch ein paar Jährchen gedauert hat,

dass man da dann halt auch sagen kann, hey, hier, hast du was und da kriegst

du einmal den Überblick sowohl die,

was DevOps allgemein ist, so kulturell betrachtet, als auch die Tools, damit man eine

bessere Einschätzung haben kann, wenn man zum Beispiel ein Entscheider ist,

okay, ich habe jetzt ein Jenkins, ich habe jetzt ein Kubernetes oder ein irgendwelche,

meine Mitarbeiter sagen, wir wollen Kubernetes einführen, aber was ist das überhaupt?

Dann hilft es halt nicht, einen Engineer zu fragen.

Man muss irgendwie das ganze Ding betrachten und das war auch so meine Motivation,

dass ich dann sage, okay, die Leute sollten halt auch verstehen können,

wofür sind diese Tools da, wofür helfen sie mir im Gesamtkonzept und nicht unbedingt ähm.

Und können sich dann ja immer noch weiter tiefer da rein vertiefen,

wenn sie möchten, ohne jetzt unbedingt alles verstehen zu müssen.

Aber so die Konzepte finde ich auch immer spannend.

Eigentlich ist es ja ein perfektes Buch, dass jemand, der, ja könnte man sagen,

Jahrzehnte in dem Umfeld gearbeitet hat, das Wissen in ein Buch presst.

Also ich sage mal, besser kann es ja gar nicht passieren. Also sonst haben wir

vielleicht Bücher, wo Leute irgendwie was abschreiben oder aus anderen Quellen zusammenfassen.

Die KI geschrieben hat. KI geschrieben. Aber die Erfahrung kommt ja tatsächlich

von dir. Also deswegen zum Beispiel das, was du über Jenkins sagst.

Und dass du sagst, ja, das sind so kleine isolierte Teile, die vielleicht nicht

richtig zusammenpassen.

Das ist ja genau die Erfahrung, die man erst dann lernt, wenn man das Produkt

praktisch einsetzt. Und nicht unbedingt nur Marketing-Quatsch oder so ein kleines

Mini-Tutorial sich irgendwie online anguckt und sagt, ja, das könnte funktionieren.

Sondern irgendwie, wie arbeiten diese Tools integriert? Macht das Schreiben

dir im Allgemeinen eher Stress, wenn du auf eine gewisse Zeit hinarbeiten musst,

auf eine Deadline anpassen musst oder hinarbeiten musst?

Wie geht es dir da als Autor? Also wahrscheinlich wirst du ein Inhaltsverzeichnis

am Anfang dir überlegen, das sind so die Themen, das passt dann rein,

jetzt schreiben wir mal los und der Verlag sagt natürlich, alles klar,

prima, so wie lange brauchst du? Dann sagst du, ja, ich denke so ein halbes Jahr.

Und dann ist das halbe Jahr um und du sagst, oh, 30 Seiten.

Wie läuft das bei dir? Also, wenn du schreibst, wie planst du dich selber ein?

Hast du Zeiten, jeden Tag 10 Minuten oder setzt du dich in eine einsame Holzhütte zurück?

Kein Internet, nur kaltes Wasser.

Duschen einmal in der Woche mit Seife und dann schreibst du den ganzen Tag nur

runter. Wie ist dein Schreibprozess?

Ja, also beim DevOps-Buch war es anders als beim Git-Buch.

Ich glaube, es lohnt sich beides anzuschauen, weil beim Git-Buch hatte ich ja,

quasi schon die Basis gehabt, mit denen ich diesen vier Blogposts, die ich da hatte.

Die habe ich quasi einmal copy-pasted und dann angefangen zu überarbeiten.

Das ging relativ gut, weil da war schon eine Storyline drin,

ein Beispielprojekt drin, was ich noch ein bisschen erweitert habe und hier

und da und dann hatte ich die Hälfte des Buches relativ zügig fertig.

Aber das war ja zu der Zeit, wo ich Vollzeit gearbeitet habe,

wo ich noch mit dem Masterstudium angefangen habe.

Also es war schon sehr stressig. Die zweite Hälfte habe ich dann halt so geschrieben.

Auch neben der Arbeit, Teilzeitarbeit dann, aber halt auch Vollzeitstudium.

War also nicht alles nicht so einfach.

Wie es aber so ist, vergisst man nach einer Weile so die Schmerzen,

die man hatte und kommt man dann irgendwann auf die Idee, ja, ein zweites

Buch zu schreiben. Du kennst das Problem.

Ja, mehrfach.

Und dann, ich meine, in meinem Fall war das dann halt auch so,

ich habe dann erst den Autorenvertrag dann auch unterschrieben und so weiter,

sobald ich wusste, okay, wie sieht die Storyline grundsätzlich aus?

Weil ich habe das im DevOps-Buch ja dann auch so gemacht, dass ich von einer

Beispielfirma ausgegangen bin, die halt in der alten Welt feststeckt und jetzt

aber halt in diese DevOps-Welt möchte.

Und was hast du jetzt kulturell damit zu tun, als auch auf der Technikseite?

Damit man immer so schöne Beispiele hat. Ich finde Bücher ganz schlimm,

Fachbücher ganz schlimm zu lesen, wo nur die Konfigurationssachen runtergerattert werden.

Wie konntest du das denn beim Git-Buch machen? Weil das ist ja erstmal ein völlig

langweiliges Thema. Man hat irgendwie ein Kommandozeilentool, man hat Optionen.

Da kann ich bei A anfangen, wie Add und bei Z aufhören, wie was weiß ich, Zeh gestoßen.

Wie macht man das spannend, sowas wie so ein Git-Buch?

Also ich habe das jetzt beim Git-Buch was einfach, fand ich,

weil ich habe halt ein Projekt gemacht, was eine Index-HTML-Seite ist und dann hat man noch,

damals habe ich das Bootstrap CSS,

JavaScript Framework genutzt und das ist halt eingebunden, sodass du dich quasi

an dem Code arbeiten kannst und der Code war halt einfach ein paar HTML-Dateien,

weil dann hast du halt die Start-Seite gehabt und hast auch noch eine About-Seite

gehabt, über dich selbst, also eine Webseite über dich selbst. Wie ist deine Webseite?

Und dann hast du ja auch sowas, was zum Ansehen. Du hast es nicht nur rein theoretisch,

sondern halt, du kannst halt sehen, okay, ich habe jetzt diesen Branch gewechselt,

also sehe ich jetzt den Inhalt nicht mehr, den ich auf der anderen Branch gemacht

habe, sondern sehe den jetzt, und das kann ich zusammenführen, also sehe ich das auch.

Man kann das mal hingehen und das angucken. Das finde ich dann immer recht praktisch,

weil dann sieht man dann auch tatsächlich.

Weil ich habe schon häufig gesehen, wie dann Leute, ah, meine Änderung ist dann

alles weg. Ja, du hast den Branch gewechselt. Vielen Dank.

Und bei DevOps habe ich dann halt eben das Beispiel, was ich auch eben genannt

hatte und da war das aber schwieriger, weil bei Git hast man ja eine Wahrheit,

und bei DevOps eben nicht, hatten wir auch schon vorhin angerissen.

Das macht das Schreiben unfassbar viel schwieriger.

Und da hat die auch gewaltige Probleme, das zu schreiben.

In meinem Fall habe ich verschiedene Phasen halt gehabt, bei so Sachen,

wo ich wusste, was ich schreiben will. Da gab es ein paar Stages effektiv,

der DevOps-Lifecycle, kenne ich mich halt besser aus als bei anderen.

Und da habe ich halt viele Stichpunkte erst gemacht, habe mir häufig auch einen

Timer gesetzt, von wegen so, okay, ich mache jetzt 25 Minuten Pomodoro-Technik,

mache mir dann einen Timer und versuche jetzt konzentriert daran zu arbeiten, weil sonst,

ah, das Handy hat gewimmelt oder sonst was.

Und dann hat man den Gedanken schnell verloren und habe dann teilweise dann

die Unterscheidung halt gemacht, okay, schreibe ich jetzt mehr den Inhalt runter

im Sinne von Stichpunkten.

Weil da muss ich ein bisschen mehr drüber nachdenken oder habe ich jetzt quasi

die Anführungsstrichen dumme Phase, wo ich die Wörter ausformuliere,

die Sätze ausformuliere, weil

das kann man auch machen, wenn man nicht mehr ganz so auf der Höhe ist.

Und wenn man aber halt einen Vollzeitjob hat oder mehr als einen Vollzeitjob

hat, dann ist es halt ganz schön schwierig, das zu machen, effektiv.

Und ich hatte halt Phasen, wo ich dann teilweise ein, zwei Monate gar nichts

geschrieben habe, aber halt viel mit Leuten geredet habe, vor allem aus dem

Arbeitsumfeld und sagen so, ja, ich schreibe gerade das und das,

hab denen so erzählt, wo ich gerade drin bin, nur einfach um nochmal so ein

paar Eindrücke zu hören,

was ich vielleicht noch bedenken sollte oder sonst was.

Gar nicht so sehr mit einer Frage, sondern mehr ein, lass uns mal drüber unterhalten,

ich brauche mal jemanden zu reden, weil ansonsten sitzt man ja doch im Kämmerlein und schreibt es.

Was für mich aber anstrengend war, war dann halt auch, ähm.

Ich weiß nicht, wie es für dich ist, aber würde mich gleich auch interessieren,

wenn sich die Deadlines immer verschieben.

Ja, zum Glück habe ich das nie. Also jetzt bei den Java-Büchern sind wir ja

bei einer deutlich konservativen Zeitleiste angelangt, irgendwie Update alle

zwei Jahre, weil erst dann gibt es Java LTS-Releases.

Vorher hatten wir tatsächlich immer so einen Jahresrhythmus gehabt,

aber wenn man dem folgt, was in der Industrie gemacht wird, dass nämlich meistens

LTS-Releases eingesetzt werden, weil man denkt, die anderen sind irgendwie unwürdig und kaputt.

Was nicht stimmt, jedes Java-Release ist vollständig und völlig in Ordnung und

nutzbar. Also das ist jetzt nicht irgendwas auf dem halben Weg.

Das, obwohl es Java ist? Auch deswegen, ja.

Aber es wird halt irgendwie nicht so richtig wahrgenommen, dass auch die kleinen

Java-Releases, also jetzt quasi Java 8, Java 11, 17, 21, jetzt 25,

das sind die großen Releases, wo die Unternehmen Support anbieten.

Anbieten, dass du quasi das einkaufen kannst.

Aber was jetzt nach 25 kommt, Java 26, wäre genauso nutzbar.

Aber letztendlich folgen wir da dem Markt und machen alle zwei Jahre ein Update.

Und bei mir ist es so, dass in dem Moment, wo neue Java-Features sich ankündigen,

dass ich dann schon das Buch direkt aktualisiere. Also quasi wenn ich von der

letzten Version, ich bin jetzt bei der Überarbeitung, hab ich gerade abgeschlossen, das stimmt.

Am Wochenende waren zwei sehr schmerzhafte Tage, wo ich 1200 Seiten PDF durchblättern

musste. Das finde ich immer das Scheußlichste in meinem Buch.

Wenn das jetzt abgeschlossen wird, ist, dann wird mir daraus ja wieder so ein

Word-Dokument generiert.

Und da kann es gut sein, dass ich schon in zwei, drei Wochen selbst wieder die

ersten Änderungen mache, weil ich irgendwas so aufschnappe oder irgendwas vielleicht

neu entwickelt wurde oder vielleicht neue Funktionalitäten reinkommt.

Dann aktualisiere ich das Buch immer sofort.

Also ich habe jetzt nicht so einen Punkt, wo ich sage, jetzt habe ich mal ein

halbes Jahr nichts gemacht und dann setze ich mich hin und mache eine Woche

lang hintereinander was. Nee, also ich aktualisiere das Buch kontinuierlich.

Ah ja.

So permanent. Und dadurch gibt es jetzt für mich nicht so eine Deadline,

dass ich sage, oh, jetzt muss ich aber fertig werden. Sondern wenn der Verlag

sagt, Christian, mach mal ein neues Release, wie viel Zeitvorlauf brauchst du,

sage ich, ja, gar nichts. Fertig.

Also so ist es eher in meinem Fall.

Also du machst Continuous Integration.

Definitiv.

Mit Word-Dokumenten.

Das Wasserfallmodell.

Ja, das ist spannend. Also ich mache das irgendwie gar nicht.

Also bei den Git-Büchern, da gab es ja, nachdem die erste Auflage steht,

danach ist es ja eh nicht mehr so viel Aufwand.

Also bei den Git-Büchern, da hatte ich jetzt drei Plus-Eins-Auflagen.

Plus-Eins war ein Schnelleinstieg, was quasi

die gestrippte Version von der dritten Auflage ist. Ich glaube,

da saß ich ein Wochenende dran, wo ich einfach nur die Kapitel so ein bisschen

auseinandergerupft habe und ein paar rausgeworfen habe.

Bei den anderen, bei Git passiert ja nicht so viel. Klar, ein bisschen Feedback

mit reingesammelt, aber die mache ich dann, wenn ich an dem Buch erst arbeite

und ich notiere die mir manchmal dann so, okay,

ich habe eine Liste teilweise, ich habe auch noch von so einem anderen her eine

ganz lange Liste von Sachen bekommen über DevOps.

Also von dir, die habe ich mir halt notiert und dann gucke ich,

wenn ich daran arbeite, weil ich muss mich halt in diesen Text reinarbeiten,

vor allem bei DevOps und da ist die mentale Hürde halt so hoch,

das kontinuierlich zu machen, was eben bei DevOps halt der Fall ist.

Deswegen ist das da so ein bisschen anders, wenn man ein neues Buch schreibt oder was vorhanden ist.

Ich mache mir kontinuierlich schon irgendwie Gedanken, nicht aktiv, aber mehr so passiv,

weil was ich bei einem DevOps-Buch bei einer möglichen zweiten Auflage,

machen würde, ist noch mehr über die DevOps-Transformation zu schreiben,

weil das irgendwie auch das ist, wo ich denke, da kann man noch sehr,

sehr viel mehr zu Interessantes zu machen, wo man halt zu Firmen hingehen kann

und sagen kann, okay, wie habt ihr denn das gemacht?

Weil einige machen das Konferenzen und dann würde ich halt hingehen und einige

kenne ich dann halt auch schon und dann frage ich sie, hey, hast du Lust hier für

ein paar Seiten mitzumachen, wenn die Firmen das dann überhaupt erlauben,

aber wenn die das auch für Konferenzen machen, dann warum nicht auch für ein Buch?

Das fände ich dann halt auch irgendwie spannend. Können größere sein,

können kleinere sein, irgendwie sowas. Das fände ich zum Beispiel spannend.

Also echte Storys zu haben und nicht nur aus verschiedenen Storys,

die man so aus dem Alltag halt so kennt, ne?

Das fände ich dann halt gut, aber es ist halt schon und das habe ich dann,

deswegen hatte ich die vorhin ja auch gefragt, wie das bei dir mit den Deadlines ist,

bei mir wie lange hat das gedauert, ich glaube ein halbes Jahr hat sich quasi die Deadline immer um,

einen Monat oder zwei verschoben und das war voll frustrierend weil ich glaube,

ich habe ja zwei Jahre für gebraucht, jetzt muss ich nochmal überlegen und am

Anfang habe ich dann am Anfang des Jahres, es war auch Ende Januar glaube ich,

habe ich den Vertrag unterschrieben.

Und hab dann gesagt, okay, ich guck mal, wie weit ich bis zum Ende des Jahres komme.

Idealerweise hab ich da schon mal so ein halbwegs brauchbares Manuskript.

Ich wusste aber schon so, okay, das ist wahrscheinlich nicht so der Fall,

dass ich das bis dahin fertig hab, aber ich guck mal, wie weit ich komme.

Weil wenn ich gar keine Deadline hab, dann funktioniert nichts.

Aber als ich dann so ein bisschen angefangen hab zu schreiben,

dann kommt dann, ach, da haben wir auch darüber muss ich noch überlegen,

darüber muss ich noch überlegen und das ist bei mir dann halt so die Sachen,

wo ich dann beim Joggen nachdenke oder halt wenn ich mit irgendwelchen Leuten rede, dann sag ja,

darüber sollten wir mal reden, wie machst du das denn?

Und dann, damit ich so ein bisschen mehr Inputs für das Buch habe.

Und zum Schluss hin war dann halt ständig mit meinem Lektor dann halt auch so,

hm, es hat sich jetzt gerade wieder verschoben,

weil erst habe ich dann die Deadlines gerissen und dann war ich irgendwie fertig

und dann so, ja, jetzt habe ich leider keine Zeit und dann kommt nochmal so

eine ganze Lawinen, Änderungen, die ich noch machen soll und muss,

und ich will es einfach nur fertig haben.

Eigentlich ist es immer am einfachsten als Autor, glaube ich,

wenn du irgendwas fertig schreibst, dann gibt es den Verlag und sagst du, hier ist es.

Ja.

Und dann können sie sich das überlegen. Und mit einer Zeit habe ich es auch nicht so.

Also ich weiß, als ich das Spring Boot Buch angefangen habe,

das mich natürlich auch Rheinwerk gefragt hat, ja, wie lange brauchst du denn

dafür? Ich so, ja, keine Ahnung.

Wie ist denn der Umfang? Ja, weiß ich auch nicht.

Also es ist eher so, ich schreibe, was mir in den Sinn kommt und das ist irgendwie

einfacher, aber man will ja auch erstmal, naja gut, ich sag mal,

als Autor gibt es so zwei Richtungen.

Tatsächlich Weg Nummer eins, man schreibt was, ist quasi fertig,

bis auf Lektorat und hübsche Bilder, geht dann zu verschiedenen Verlagen und

sagt, habt ihr Bock, habt ihr Bock, habt ihr Bock und irgendjemand sagt, jup.

Oder eben, man wird vielleicht vom Verlag angesprochen, die haben einen Vorschlag,

das fehlt noch bei unserem Portfolio, könntest dir das vorstellen?

Und dann sagt man ja, da ist aber noch nichts da.

Ich glaube, das ist echt hart, wenn du dich darauf einlässt.

Ja, das habe ich ja gemacht.

Ja, also Respekt. Mein Java-Buch war ja mehr oder weniger schon fertig gewesen.

Der Rheinwerk Verlag hatte das als PDF online gefunden und gesagt,

oh, können wir das verlegen? Ja, können wir. Okay.

Das war ja ziemlich einfach gewesen. Und ja, anders würde ich selber auch gar nicht vorgehen.

Das finde ich schon hart. Hättest du denn für neue Autorinnen und Autoren irgendwelche

Tipps und Tricks, wenn jemand sagt,

das klingt gut, ich möchte auch mal ein Buch schreiben, ich möchte auch berühmt

werden und reich und mit Gold zu werden?

Was empfiehlst du neuen Autoren? Wie würdest du rangehen, was würdest du empfehlen?

Also die erste Empfehlung ist erstmal eine Frage an dich.

Magst du das Schreiben als Prozess?

Ja, na klar.

Was magst du daran?

Ich weiß nicht.

Ich verstehe. Also wer natürlich nicht wirklich schreiben mag,

die Person sollte nicht anfangen, ein Buch zu schreiben. Also vorausgesetzt,

diese Person mag schreiben.

Ja, genau. Also die Frage war tatsächlich auch an dich gestellt.

Magst du den Schreibprozess selbst?

Ja, mag ich. Mhm.

Weil bei mir ist das so eine Hassliebe, würde ich sagen. Weil ich mag es, was mag man?

Muss man ein bisschen unterschreiben, was ist es denn genau?

Weil wenn ich jetzt gucke, ich mag halt die Konzepte zu erstellen und überlegen,

wie ich was erklären kann.

Also die Story drumherum bauen, die Fakten oder sonst was. Das Runterschreiben

ist relativ der langweilige Part, würde ich sagen.

Und der ist aber teilweise auch der ätzende Part, größtenteils.

Ja.

Und wenn man sich halt überlegt, und ich hatte jetzt voll oft,

schreiben mich Leute an, die ich kenne, mal mehr oder mal weniger,

vor allem als ich bei GitLab war, weil es halt diverse Verlage gibt,

die mehr nach Masse statt Klasse gucken.

Die schreiben dann random Leute an und fragen so, hey, willst du nicht ein Buch

schreiben? Und da denken Leute, weil sie das irgendwie auf der Bucketlist haben,

ich weiß nicht, wie es für dich war. hattest du das Buchschreiben auf deiner

Lebens-Bucketlist gehabt?

Nein, überhaupt nicht. Null.

Ich auch nicht.

Also bei der Java-Insel war das ja relativ simpel. Ich brauchte für meine Schulungen

damals Unterrichtsmaterial. Ja.

Und genauso wie du, durch das Schreiben lerne ich und frage mich die schwierigen

Fragen. Und denke auch, wenn du es nicht erklären kannst, dann hast du es nicht

verstanden. Also hilft es mir auch, mich selbst zu reflektieren.

Ja.

Und auf der anderen Seite brauchte ich eben Schulungsmaterial.

Und das war halt zu der Zeit vor, keine Ahnung, Java ist jetzt 30 Jahre alt,

ist 25 Jahre her, da war der Markt noch nicht so gesättigt.

Wahrscheinlich gab es noch gar nichts ans Deutsche, ich weiß es nicht mehr genau, schon so lange her.

Also habe ich das Tutorial im Grunde geschrieben und immer wieder ausformuliert

oder weiter geschrieben, bis es dann mal zufälligerweise ein Buch wurde.

Also das war nie geplant. Und bei den anderen Büchern, bei dem Java-Aufgabenbuch,

die Aufgaben hatte ich schon.

Also die jetzt in Buchform zu bringen, war kein Problem.

Bei dem Spring-Buch war das auch relativ einfach. Ich mache Spring-Seminare,

Spring-Boot-Seminare seit super vielen Jahren.

Die Schulungsunterlagen waren fertig. Ich habe die Schulungen schon dutzende Male gemacht.

Also hatte ich einen guten didaktischen Ablauf. Daraus ein Buch zu machen, war auch relativ easy.

Also das das war dann nie so wirklich

problematisch gewesen also weil der Content eigentlich schon da war.

Aber bei mir war es genau andersrum, bei dem Git-Buch vor allem. Ich habe dann aus

dem Buch dann Workshops erstellt, ja, Schulungen erstellt.

Aber dann hattest du ja eigentlich auch so eine Feedback-Schleife,

dass du testen konntest, ob das, was du in einem Buch erstmal theoretisch dir

überlegt hast, ob es in der Praxis überhaupt so funktioniert.

Oder ob die Leute nicht immer den gleichen Punkten hängen.

Ja, beziehungsweise ich hätte ja auch davor die Blogposts gehabt.

Da gab es ja auch nochmal eine Feedback-Schleife. Dann kam das Buch und dann

habe ich, ich habe aber nicht viele Schulungen gemacht. Das war nur,

wenn mich tatsächlich jemand aktiv angeschrieben hatte, was nicht oft vorkam,

bei mir zumindest. Ich habe es aber auch nicht aktiv beworben.

Aber ja, die Frage halt so, mag man das Schreiben selbst, muss man sich halt klären.

Und weil ich habe vorher schon viel geschrieben, du auch, das macht das Ganze

viel, viel, viel einfacher, weil ich weiß noch,

als ich damals nämlich in der Ubuntu-Community angefangen hatte, dann,

hatte ich einfach nur das Gefühl gehabt, ah, ich will hierbei irgendwas mitmachen

und ich will was Neues lernen und das Einzige, was ich konnte,

war nichts Technisches, sondern nur, ah, schreiben kann ich,

ich kann bestimmt Sachen irgendwie zusammenfassen. Das war dann so ein Wochenrückblick über Ubuntu.

Da habe ich dann halt irgendwie ein paar Newsartikel zusammengeguckt und dann

halt Zusammenfassung geschrieben. Heute habe ich eine LLM dazu.

Damals habe ich das bei Hand gemacht und ich habe dann halt durch Zusammenfassen

halt viel schreiben gelernt. Okay, da sind jetzt, das ist irgendwie ein heise-Artikel oder sonst was.

Und ich bringe das jetzt auf zwei Sätze runter und dann habe ich da was.

Aber das willst du ja auch prägnant und kurz haben und nicht richtig lang.

Dadurch habe ich halt viel über die Jahre halt Schreiben gelernt effektiv und

dann halt auch längere Artikel geschrieben und so weiter.

Deswegen ist das Schreiben selbst jetzt, sobald man einmal anfängt oder richtig

im Flow ist, nicht das Problem.

Aber wenn du gar nicht geübt bist zu schreiben, dann würde ich auch nicht unbedingt

empfehlen, ein ganzes Buch zu schreiben.

Das stimmt, richtig. Und es kann gut sein, dass vielleicht für eine neue Generation

von IT-Lern es vielleicht sogar eher noch schwieriger wird zu schreiben,

weil möglicherweise spielt Schreiben gar nicht mehr so eine große Rolle wie früher.

Also wer weiß, wie sich Schreiben als solches verändert im Laufe der Zeit.

Also vieles ändert sich. Also Konzentration ändert sich massiv.

Und wann schreiben Menschen nochmal so?

Also kann gut sein, dass es alles flöten geht. Also dass wir Kurzformen uns

daran gewöhnen, SMS oder vielleicht sogar Sprachnachrichten zu schreiben.

Also wann schreibt man nochmal im Alltag, zumindest außerhalb der Schule,

mal durchgehend längere Texte?

Und ich sage mal, wenn die Schüler auch in der Schule jetzt auch keinen Bock

mehr haben zu schreiben, sondern sich alles durch LLMs schreiben lassen,

dann praktizierst du jetzt ja noch weniger.

Also kann gut sein, dass wir in, weiß ich nicht, 100 Jahren der Generation sind,

wo kaum jemand mehr selber wirklich etwas schreibt oder vielleicht schreiben

lässt, aber dann ist es ja auch nicht mehr die eigenen Worte.

Ja, und dann nutzt man auch eine LLM auf der anderen Seite, um das Geschriebene zu kürzen.

Genau, richtig, genau.

Genau.

Und LLM für die fachliche Korrektur. Genau, Lektorat fällt dann auch weg.

Wie hat die Zusammenarbeit mit dem Lektorat funktioniert?

Hatte das Lektorat viel zu meckern gehabt bei dir oder hat es mehr oder weniger

durchgewunken? Wie lief das?

Dadurch, dass ich zwei verschiedene Lektorate... Du hattest auch mehrere Lektoren, oder? Über die Zeit?

Verschiedene, die Korrektur lesen. Also fachliche Lektorat habe ich nicht.

Sondern nur so quasi schön schreiben.

Da habe ich verschiedene. Jetzt habe ich jemand anderen, die,

ich will nicht sagen, das Buch umschreibt, aber irgendwie die Wörter anders schreibt.

Also nicht die Wörter anders schreibt, sondern irgendwas anders,

was die Autorin da vorher geändert hat. Ich habe jetzt kein Beispiel dafür,

ich weiß es jetzt nicht mehr, aber irgendwie an ganz, ganz vielen Stellen,

wo ich sage, ey, das hat doch das Lektorat, wo eine Auflage hat das doch so geschrieben.

Also irgendwie, ich weiß nicht, irgendwas, Sätze mit einem Punkt abschließen

oder in Tabellen irgendwie die Zellen mit Großbuchstaben beginnen,

da immer so eine Kleinigkeit war da.

Aber quasi von einer Auflage zur anderen, nicht alles umgeschrieben,

also nicht umgeschrieben, aber so eine Kleinigkeit, wie gesagt,

irgendwie Zellen anfangen oder

Aufzählungspunkte setzen oder die nicht vollständigen Sätze mit Punkt abschließen

oder nicht Punkt abschließen, was ich irgendwie amüsant finde,

dass man sich nicht unbedingt so einig ist, aber sei es drum.

Ja, ich meine, bei MITP war es dann so, dass die Lektorin jetzt nicht sonderlich technisch war.

Das heißt, ich habe eigentlich meinen Text geschrieben, da ging es dann vor

allem um sprachliche Aspekte.

Also da gab es wenig inhaltliches Feedback.

Aber habe ich dann auch gemerkt, einfach nur, weil es wohl auch so gut war,

dass man da gar nicht so viel machen musste.

Ich hatte halt selbst Freunde, Bekannte gefragt, oder Arbeitskollegen gefragt,

kannst du hier nochmal drüber gucken?

Entweder über einzelne Sachen oder über ganze Sachen. Da habe ich bei beiden

Büchern aber gemacht, um vorher noch Feedback zu bekommen, ist das fachlich

in Ordnung, weil wir haben ja an dem und dem Projekt gearbeitet,

daran muss ich denken, also kriegst du das jetzt gelesen. Das haben viele auch gerne gemacht.

Und deswegen war da beim Git-Buch gar nicht so viel geändert worden.

Außer jetzt so sprachliche Sachen halt. Aber das ist ja quasi normal.

Beim DevOps-Buch wurde schon deutlich mehr gemacht, was ich auch gut fand,

weil dann so, oh, stimmt, das habe ich sogar falsch erklärt.

Und die Lektoren sind ja nicht unbedingt technische Leute. Auch wenn sie die ganzen Bücher lesen.

Das dürfen wir gerade nicht. Genau, ich glaube, das ist super schwierig,

nicht quasi das Buch zu lesen, sondern zu sagen, mich interessiert der Inhalt

überhaupt nicht. Ich achte nur auf Grammatik.

Das stelle ich mir ultraschwierig vor, weil ich mir vorstelle,

dass man irgendwie doch anfängt zu lesen, dann liest man so drüber und irgendwie

nach einer Seite denkt man, Mist, jetzt habe ich den Inhalt gelesen.

Das wollte ich gar nicht.

Aber jetzt verwechselst du gerade doch ein bisschen Lektorat und Korrektorat, oder nicht?

Nö.

Für mich ist es Fachlektorat, die fachlich gucken. Und Lektorat ist Grammatik

und schöne Wörter finden.

Korrektorat ist für mich Lektorat.

Ja, okay. Weil ich unterscheide das anders. Ich weiß nicht, was die richtige Definition ist.

Aber in meinem Fall beim DevOps-Buch war es schon so, da wurden halt Satze umgeschrieben

und dann besser erläutert, wo dann auch fachlich teilweise noch ein paar Sachen mit reinkamen.

Hab ich null. Gar nicht.

Hatte ich aber auch, wie gesagt, nur bei dem DevOps-Buch, wo dann halt auch

seine Erfahrungen aus seinen anderen Büchern da mit reingeflossen sind,

was dann auch ganz gut war.

Manchmal bin ich natürlich enttäuscht, wenn ich so Sachen wie Business-Kasper

schreibe und dann wurde es ersetzt durch Business-Analyst.

Passt ja auch.

Wobei man auch sagen muss, dass …

mir kam der Begriff Business-Analyst nicht in den Kopf, aber ich wollte sagen,

irgendein Business-Mensch halt.

Oder du hast es vergessen, dass sie da drin stand.

Und dann habe ich halt irgendwo Business-Kasper halt reingeschrieben.

Dachte so, ich werde das schon, ich oder der Lektor wird das schon richtig machen.

Und irgendwann sah ich dann nur so, als ich durch die Diffs geschaut habe,

dass das halt ersetzt wurde. Also mein Lektor, der schreibt dann halt auch im

Git-Repo mit rum. Ich habe es dann in Markdown erst mal geschrieben.

Und dann sage ich ja, hier. Und dann gucke ich mir halt das Diff an.

Und dann sage ich ja, gut.

Sehr cool.

Das ist natürlich dann schöner. Ich finde auch die Bilder erzeugen aber anstrengend.

Bilder mag ich überhaupt nicht. Also manchmal, jetzt mal so unter uns gesagt, hört ja keiner,

mache ich einen Screenshot von irgendeinem Bild, was ich irgendwie so online

finde und sage, male das nach, so will ich das auch haben.

Ja, das habe ich da auch gemacht ein paar Mal. Ja, weil die Schöpfungshöhe ist

ja häufig ja dann noch irgendwie, gibt es zehn verschiedene Sachen vom selben

Ding. Also das ist keine hohe Schöpfungshöhe.

Ja, genau. Also ich sag mal, wenn du so ein Array hast oder so ein Pointer oder

sowas, das sind so Standardbeispiele, wo du sagst, da hast du halt irgendwie

so ein Array, so ein Feld mit so Zellen drin oder so ein Pfeil drauf und so,

das male ich da nicht nach, sondern da gibt's Millionen Abbildungen,

die alle gleich aussehen und dann kann ich schon sagen, so möchte ich das auch

haben, so find ich das gut.

Ja, ich mein, bei mir auch die DevOps 8.

Ja, sowas genau.

Oder halt irgendwie Blue-Green-Deployments, gibt's auch ganz viele Sachen,

ob ich da jetzt was selbst hinbaue oder was nachgebaut wird.

Ja.

Aber mir ist eher das Problem, dass ich dann nicht weiß, wie ich etwas,

bei den Sachen, wo es nichts so gibt, fehlt mir meistens die Kreativität und

wie stelle ich was dar, um das aufzulockern, weil ich bin eher so der Typ,

der zu viel Text schreibt, statt noch ein paar Ideen für Grafiken zu haben.

Ich weiß nicht, ob das jetzt einfacher ist, weil als ich das DevOps-Buch geschrieben

hab, mittendrin quasi kam halt ChatGPT raus.

Und dann habe ich zumindest manchmal versucht, ein paar Textschnipsel hinzuwerfen

und sagen, gib mir ein paar Beispiele für Bilder, die ich dazu machen könnte.

Einfach nur als Text, weil damals konnte es auch keine Bilder.

War jetzt nicht so hilfreich, aber gefühlt war die erste Version von ChatGPT

eh noch nicht so gut, wie sie heute ist.

Wäre vielleicht auch spannend, einfach nur um Ideen zu kriegen,

so okay, das ist der Text, ich will jetzt irgendwas Sinnvolles haben.

Ich schreibe ja zum Spaß gerade an einem C-Buch. Ob ich das jetzt wirklich bis

zu Ende treibe, weiß ich nicht. 400 Seiten sind jetzt fertig.

Und vielleicht habe ich nach 500, 600 Seiten keine Lust mehr. Mal gucken.

Und ich mag ganz gerne solche kleinen Comics. Und da frage ich ChatGPT mal zu

manchen Themen so, was für einen Comic könntest du dir hier vorstellen?

Aber dann kommen total komplizierte Folgen. Also normalerweise möchte ich so

ein Panel haben mit einem Bild. Und dieses Bild soll irgendwas aussagen.

Und ChatGPT sagt dann, ja, die Figur macht erst das, und dann macht sie das,

und dann macht sie das, und dann macht sie das.

Und ich sage, ey, das ist ja schon eine Seite, so ein Comic.

Ich will nicht eine große Handlung. Ich will ein einziges Bild haben.

Machen wir den Vorschlag von einem einzigen Bild, das das irgendwie captured.

Aber nee, da kommt nichts Gescheites raus. Also das funktioniert nicht,

also in meinen Erfahrungen.

Also wenn ich selber was hingehe und sage, wie wäre es denn da und damit?

So, so, ja, ja, ja, das ist schön, ja, super Idee, dann kann er auch eine Skizze

oder irgendwas visualisieren, aber so diesen Vorschlag für ein einziges Bild,

das irgendwas festhält, habe ich bis jetzt noch nicht so gut erfahren.

Ja, ich glaube, es ist besser geworden, aber, weil das habe ich da nicht mal

hinbekommen, aber damals zumindest, also ist das ja schon zwei Jahre her oder so.

Aber ja, ich meine, das ist so die Schwierigkeit unserer Bilder zur Auflockerung,

finde ich, weil reine Textwüsten zu lesen, ist halt auch anstrengend.

Also ich merke das ja selbst, wenn ich meine eigenen Texte lese und das finde

ich auch immer super anstrengend und langweilig, die eigenen Texte zum 20. Mal zu lesen.

Irgendwann hängt einem das nur noch aus der Nase raus, aus den Ohren raus.

Aber bist du denn mit dem, was du dann liest, zufrieden und sagst, mhm, mhm, mhm, mhm?

Oder sagst du bei jedem zweiten Satz, ach, ich weiß nicht, ich glaub,

da muss ich noch mal drangehen.

Oder bist du dann mit dir im Reinen und sagst, ja, find ich gut,

ja, das liest sich locker und flüssig durch, passt schon so.

Also ich glaub, wenn ich durch einen Text drübergehen würde,

könnte ich immer wieder was Neues anders schreiben.

Also Perfektionist sein ist ein Problem. Bin ich zum Glück jetzt nicht so,

aber man muss das halt schnell ablegen. Aber ansonsten wird man nie fertig.

Was bei mir halt auch immer so ein Ding war, wenn ich nicht wusste,

ich muss was am Buch schreiben und ich habe gerade auch die Zeit dafür,

aber ich weiß es gerade, irgendwie hat man halt diese Blockade,

dass man nicht so richtig anfängt, da wo man es eigentlich machen sollte.

Dann habe ich einmal angefangen Korrektur zu lesen.

Und existierende Sachen nochmal umgeschrieben, anstatt Neues zu schaffen.

Genau. Ist besser gemacht. Deswegen ist so das erste Kapitel ziemlich gut geworden, würde ich sagen.

Weil ich da so oft von vorne halt angefangen habe.

Und dann so, ah ja, da kann man noch eine schöne Story, ich mag halt Storys

da mit reinzubauen. Weil als ich mit DevOps angefangen habe.

da hatte ich natürlich irgendwie geguckt, was habe ich für eine Story drin, am Anfang zumindest.

Und Storys waren jetzt kleine Sachen, nicht die über das ganze Buch gehen.

Und da habe ich ja zwei Sachen mit reingebaut, die zu dem Zeitpunkt aktuell waren, nämlich,

die, und da wollte ich sagen, die nicht technisch sind, weil wenn du da irgendwie

sagst, A-B-Testing sind toll für Conversion-Rates bei Online-Shops,

das ist irgendwie dann doch sehr nischig gefühlt und ich will das ja auch ein

Beispiel haben für Leute, die mich auf der Straße fragen, was ist ein DevOps?

Wirst du auf der Straße gefragt? Wow!

Und gut, dass ich dieses Beispiel nicht am Anfang gemacht habe,

aber die Einführung des 9-Euro-Tickets ging ja doch recht zügig vom Beschluss,

dass das kommen soll, bis ist es jetzt verfügbar, waren irgendwie drei oder vier Wochen oder sowas.

Genau so steht im Buch. Das hat ich extra nachgeschaut. Das heißt,

in diesen drei Wochen musste halt alle Systeme umgestellt werden,

dass es dann halt auch richtig geht.

Und gefühlte man ja sonst immer so, das geht nicht, weil das dauert zu lange

und das dauert zu lange und dies geht nicht.

Vor allem, was so behördlichen Kram angeht oder was vom Start kommt.

Und dann hast du immer drei Jahre Vorlaufzeit und alles Mögliche.

Das hattest du beim 9-Euro-Ticket nicht und das hat funktioniert.

Einfach mal gesagt, okay, wir machen jetzt eine langweilige Lösung quasi.

Jeder kann sich überall irgendwie diese 9-Euro-Ticket ziehen und gut ist.

Und kostet 9 Euro. Genauso wie die Mehrwertsteuersenkung zwischenzeitlich für 6 Monate.

Muss man halt auch alles testen und machen, weil wenn du da irgendwo das fest

verdrahtet hast, dann hast du ein Problem gehabt, beziehungsweise musst du es halt immer umschalten.

Und das sind halt so Beispiele, so okay, das muss halt schnell gehen,

muss auch komplett getestet sein. Je mehr du an DevOps-Prinzipien bist,

ist einfach ging das. Solche Storys mag ich halt,

drüber nachzudenken und reinzupacken, die jeder quasi verstehen kann.

Ich glaube, das ist auch wichtig, weil erstmal man hält die Aufmerksamkeit der

Leser, weil ich glaube, Menschen mögen Geschichten und sowas verpackt sich einfach

viel besser in Informationen über einen Helden, der irgendwas schafft,

der eine Umstellung schafft, eine Migration schafft oder irgendein Problem löst,

oder vielleicht auch scheitert.

Also ich glaube, das ist deutlich spannender, das in kleine Geschichten zu verpacken,

anstatt einfach nur nüchtern runterzuzählen. So, wir brauchen das und das,

weil das und das ist toll. Super.

Aber viel schöner ist, Willi arbeitet an einer Software.

Willi hat aber immer wieder häufig Probleme und die Software crasht.

Und wenn er etwas hochlädt, funktioniert das nicht. Und seine Kunden sind ganz enttäuscht.

Ich glaube, wenn man das in Geschichten verpackt, ist das einfach,

ja, unsere Fantasie wird dadurch mehr angeregt.

Also, ich glaube, du hast ein, sagen wir mal, ein dankbares Umfeld mit DevOps,

weil das ist, glaube ich, reich an Geschichten ist. Deswegen kann man ein schönes Buch damit machen.

Ja, ich meine, ein Beispiel, was ich mal wieder aufgegriffen habe,

war ja auch das Thema mit nachts geweckt werden, weil irgendwelche Systeme down sind.

Weil ich hatte, als ich in einem reinen Ops-Team saß, als Externer,

hatte ich keine Bereitschaft gehabt, aber die anderen im Team.

Und die haben dann am nächsten Morgen gesagt, ja, da ging wieder irgendwie ein

Service, ein Monitoring-Ding hat halt gebimmelt, weil die Festplatte vollgelaufen ist.

Warum? Das Log-File war zu groß. Also ist man hingegangen, hat entweder das

Log-File gelöscht und oder die Partition oder das Logical Volume vergrößert oder sowas.

Dann hast du aber am nächsten Tag das gleiche Problem gehabt,

statt zu gucken, was ist denn das für eine Anwendung.

Und wie, warum schreibt du zu viel da rein?

Weil das offensichtlich ein Problem ist. Man hat dann immer gesehen so,

ah, den einen Tag war es um 2 Uhr morgens, nächsten Tag war es um 3 Uhr morgens,

nächsten Tag war es um 4 Uhr morgens.

Und später hat dann eine der Personen gekündigt, weil die keinen Bock mehr hatte.

Genau, richtig.

Und irgendwann habe ich die Person dann auch wieder gesehen auf einer Konferenz

und meinte so, ah, ich habe dich übrigens in meinem Buch erwähnt,

zwar nicht namentlich, aber halt deine Story.

Und das ist dann halt wieder so, okay, das ist halt Silos.

Ja, Nummer fünf.

Wenn die Leute in den Silos arbeiten,

dann passieren halt solche Sachen und die werden halt nicht an dem eigentlichen

Problem gefixt. Und solche Storys sind dann halt auch echt.

Und das ist dann halt auch immer, das finde ich auch irgendwie das Spannende.

Ich gucke auch bei Vorträgen oder so weiter immer, dass ich irgendwelche Storys

reinbaue, damit das irgendwie spannend ist. Weil manchmal sehe ich irgendwelche

Vorträge oder auch irgendwelche andere Bücher.

Jetzt wird dann schon wieder die nächste Konfigurationsoption genannt,

wofür man das nutzen kann, aber halt immer nur so für sich und nicht so im Gesamtkontext.

Manche muss ja auch nochmal den historischen Kontext mit drin haben.

Warum ist jetzt Jenkins gerade so beliebt geworden?

Das ist auch wichtig, damit man einschätzen kann, warum war das für damals gut

und wichtig, aber heute willst du es nicht mehr haben.

Das finde ich auch irgendwie immer das Spannende. Das ist das,

was ich beim Bücherschreiben quasi mag, aber das kann ja auch ein Buch schreiben

sein, das kann auch ein Vortrag sein, so im Sinne von, welche Storys zu überlegen,

so wie bringt man das, ein bisschen das Thema in der Fülle.

Ist denn ein Update des Buches geplant? Also du hast neue Beispiele,

du könntest das Buch ausbauen, erweitern, du hast schon gerade Beispiele genannt.

Ist was geplant oder ist ein ganz neues Buch geplant?

Neue Auflage ist erstmal nicht geplant, also zumindest habe ich bisher noch

nicht drüber diskutiert und ich hoffe, da kommt auch erstmal nichts.

Aber ich glaube, ich habe auch erstmal gesagt, zwei bis drei Jahre bei DevOps

passiert ja jetzt nicht so viel und ich gehe in die ganzen Tools ja nicht so tief rein.

Das Einzige, was ich jetzt vielleicht noch bei dem DevOps-Buch ergänzen würde

oder anders machen würde, neben den Unternehmens-Stories, weil das wäre,

glaube ich, ein schöner Task, den man da mit anderen Leuten nochmal machen kann,

wäre noch irgendwie Compliance-Sachen vielleicht noch ein bisschen stärker fokussieren,

also komplett durchdachtes Compliance dann halt auch oder mit einer guten User-Experience

vor allem und das andere wäre AI-Themen halt da nochmal, weil das macht ja

dann doch nochmal einen Unterschied.

Die hatte ich nur so ein bisschen angekratzt, aber da passiert eh alle drei Tage, aber da war es...

Bestimmt zwischen Aufnahme dieses Podcasts und der veröffentlicht und nicht

wahrscheinlich auch wieder ganz viel anderes.

7, 8, 9, 10.

Und neues Buch habe ich nicht geplant. Ich habe immer wieder irgendwelche Ideen.

Wo ich jetzt gerade denke, könnte man eigentlich schon was runterschreiben,

weil das Problem, was ich habe, ist,

oder mittlerweile bin ich ja selbstständig und da habe ich eher so,

dass ich muss halt diverse Sachen machen und wenn ich es runterschreibe,

dann habe ich es halt in einer Form schon mal da,

um es dann halt irgendwie in Vorträge, in Schulungen oder sonst was halt zu machen.

Daher ist es mir eher, das in irgendeiner Form halt runterzuschreiben.

Deswegen wäre es eigentlich gut, über diverse Themen dann halt tatsächlich einfach

mal hinzugehen und sagen, ich schreibe jetzt was runter, statt gar nichts zu machen.

Das Problem wäre jetzt nur, dann hätte ich wieder, ich will keine Deadline haben,

weil das stresst mich dann halt zu sehr.

Aber das heißt, wenn ich noch ein drittes Buch schreiben wollen würde,

also ein drittes eigenes zumindest,

dann wäre mein Idealzustand, ich schreibe es wirklich nur für mich erstmal,

und dann, wenn es halbwegs fertig ist, dann gehe ich zum Verlag und sage,

hier, ich habe das Thema, hier habe ich schon mal die Hälfte fertig und jetzt

brauche ich noch mal ein halbes Jahr oder so oder vielleicht noch ein Jahr,

um das noch hübsch zu machen. Wie sieht es aus?

Weil dann kann, da kommt dann, weil ich würde das unterscheiden,

so die, welchen Teil ich gut und schlecht finde, die Ideen machen und sonst

was im ersten Teil quasi, bis so das Buch so halbwegs steht,

so von der Story her, vom Inhalt her.

Und dann der ganze Feinschliff mit dem ganzen aus der Box denken, schreiben.

Und halt natürlich Fehlerkorrekturen und sowas.

Ja, gewisse Sachen ergeben sich auch erst mal im Laufe des Schreibens.

Also bei den Beispielen zum Beispiel, wenn ich jetzt meine Bücher denke,

dass ich irgendwie so weitergehe und irgendwann denke so, Moment mal,

das Beispiel, das würde ja vorne auch schon passen.

Aber da könntest du damit schon anfangen und das und das vorbereiten und das

da und da so und so weitermachen. Ah ja, okay, dann schreibe ich vorne was um.

Dann schreibe ich weiter, entwickle irgendwas und dann fällt mir wieder ein,

Moment mal, aber am Anfang hättest du das ja auch schon in diese Richtung umschreiben

können, dass das schon gleich so aufgebaut wird.

Und so entwickelt sich das so dynamisch. Also ich springe auch immer mal wieder

zurück, ergänze da was, springe wieder zurück, schreibe da irgendwas um,

bis am Ende da irgendwie so ein roter Faden rauskommt. Also ich finde es auch

wichtig, dass die Beispiele irgendwie so ein gemeinsames Thema haben.

Also das finde ich irgendwie gut. Bei Programmierbüchern ist,

finde ich, die Schwierigkeit, machst du ein Aufbau und das riesengroßes Beispiel.

Das ist an sich natürlich gut, hängt aber Menschen und Leser ab, die

nicht alles durchgelesen haben, die dann quasi von so einem komplexen Beispiel,

was am Ende steht, völlig überfordert sind, weil dann kannst du nicht einfach

am Ende einsteigen, wenn du sagst, mich interessiert nur das letzte Teil,

ein Stückchen, weil dann hast du total viel davor entwickelt.

Auf der anderen Seite kannst du Bücher aber machen, dass du viele kleine Spezialbeispiele

hast, die genau dieses Feature perfekt zeigen, aber dann komplett losgelöst sind von allem anderen.

Das hat den Vorteil, dass man eben dieses eine Feature darstellen kann,

aber du siehst das halt nie in der Gesamtsituation, also warum sich das irgendwie so einfügt.

Also egal, welchen Weg man geht, man kann nicht gewinnen. Weil beide Varianten

haben Vor- oder Nachteile.

Aber das gefällt mir in deinem Buch gut, weil du hast auf der einen Seite viele

kleine Beispiele gewählt und dann hast du natürlich auch dieses umspannende,

große Beispiel mit dem Unternehmen, mit deinem Kleidungsunternehmen.

Also im Grunde hast du dadurch ja beide Vorteile auch schon irgendwie vereint.

Ja, manchmal muss man ja auch andere Sachen machen, weil ich habe halt dieses

Kleidungsunternehmen mit einem Online-Shop, das ist irgendwie das klassische

Beispiel für DevOps, weil DevOps Handbook, was ja quasi die DevOps-Bibel ist,

die hatte ja auch irgendwie Autoteile, waren das glaube ich.

Und in dem Sinne war es halt irgendwie gleich, man will ja auch keine anderen

Bücher kopieren, das kommt ja auch nochmal hinzu, ne?

Aber irgendwie, man bringt das halt an, dann hat ja nämlich vielleicht ein anderes

Beispiel oder sonst was, das wird dann wieder zu konstruiert,

nur damit nicht der Eindruck erweckt wird, dass man irgendwas kopiert hätte.

Meine Struktur ist schon ganz anders, aber das Beispiel ist halt doch ähnlich,

aber nicht jeder hat einen Online-Shop, das kommt ja nochmal hinzu und die willst du ja auch abholen.

Und jeder hat ein Start-up, nicht jeder startet auf einer grünen Wiese,

Deswegen auch ein Brownfield-Projekt effektiv dann halt.

Und nicht da, hey, wir starten jetzt von vorne, weil das ist immer sehr einfach.

Womit sich der Kreis wieder zum Anfang schließt. Wenn wir sagen, es ist Culture.

Alles ist Culture. Ja, das war ein schönes Gespräch und jetzt ist unsere Aufnahme

doch noch deutlich länger geworden.

Ich danke dir für deine Zeit und wünsche für deine Projekte noch viel Erfolg. Mach's gut.

Danke, dir auch.