Deep Dive 198 –

Manager und Coding mit Mirko Seifert

06.01.2026

// Podcast
// Deep Dive 198

Shownotes

Wann kommt der Moment, an dem man als Entwickler:in weniger Code schreibt – und ist das überhaupt ein Ziel, das man anstreben sollte? In diesem Deep Dive sprechen wir mit Mirko Seifert, selbsternannter Devfluencer, CEO und Entwickler aus Überzeugung, über genau diese Frage und über den oft schleichenden Übergang von der reinen Entwicklung hin zu Rollen mit mehr Verantwortung.

Mirko beschreibt sehr offen, wie stark sein eigener Coding-Anteil über die Jahre geschwankt hat und warum es ihn unzufrieden macht, wenn er zu lange keinen Code mehr anfasst. Dennis reflektiert seinen Weg vom iOS-Entwickler über Product Ownership bis zum Head of Development und erklärt, warum er heute bewusst Abstand zur Codebasis hält, obwohl ihn das Entwickeln immer noch reizt. Jan ergänzt diese Perspektiven um seine Erfahrungen aus Tech Leadership, Developer Relations und Community-Arbeit.

Gemeinsam diskutieren die drei, ob technisches Up-to-date-Sein in Führungsrollen Pflicht ist oder ob es reicht, die grundlegenden Probleme der Softwareentwicklung einmal wirklich verstanden zu haben. Es geht um Vertrauen und Credibility in Teams, um Machtgefälle bei Code-Reviews, um das Risiko von Micromanagement und um die Frage, wie viel Nähe zum Code hilfreich ist und ab wann sie eher schadet. Auch Recruiting, große technologische Shifts und der Einfluss von AI auf aktuelle Entwicklungsarbeit spielen dabei eine Rolle.

Ein wiederkehrendes Motiv ist die Versuchung, sich in das zu flüchten, was leicht fällt und Spaß macht – und warum genau das für Menschen mit Verantwortung gefährlich werden kann. Am Ende steht keine einfache Antwort, sondern eine ehrliche Bestandsaufnahme: Wie viel Code gut tut, hängt stark von Rolle, Umfeld und Teamdynamik ab.

Dieser Deep Dive richtet sich an alle, die zwischen Coding, Verantwortung und Selbstverständnis stehen, egal, ob frisch befördert, schon lange in einer Lead-Rolle oder gerade mitten in der Frage, wie die eigene Zukunft in der Softwareentwicklung eigentlich aussehen soll.

Download

/transkript/programmierbar/deep-dive-198-manager-und-coding-mit-mirko-seifert

Jan: Hallo und herzlich willkommen zu einem neuen Deep Dive in der programmier.bar. Ich bin wie immer, immer noch, wie auch immer Jan Gregor im Getriebe und mit mir im virtuellen Studio in der oberen Ecke heute des Bildschirms sitzt
Dennis: Dennis Becker, vermute ich. Ich sehe mich ja auf deinem Bildschirm nicht, aber ich denke mal, dass Du mich meinst als Ersten.
Jan: Du sitzt immer in der oberen Ecke bei mir, das hast Du
Dennis: so Nein, aber Du, irgend eine mittlere Ecke war ich sonst, nicht in der oberen Ecke.
Jan: Ja, wenn wir wenn wir 4 Leute sind, hast Du die mittlere Ecke. Okay. Aber heute sind wir nur zu dritt. Gut. Wir wollen heute sprechen über die Frage, ob und wenn ja, wann oder wie und weshalb man irgendwann aufhören sollte mit diesem Coachschreiben in seine Karriere, insbesondere dann, wenn es vielleicht dazu kommt, dass man noch irgendwelche andere Verantwortung mit aufgetragen bekommt, die über das eigentliche Produkt vielleicht hinausgehen. Und damit wir dazu nicht nur in unserer eigenen Suppe hier vor uns hin schwimmen und aus unserer eigenen Erfahrungen erzählen können, haben wir uns noch einen Gast eingeladen. Wir haben eingeladen bei uns Mirko Seifert. Hallo Mirko, schön, dass Du da bist.
Mirko: Hi, schön, dass ich da sein darf.
Jan: Mirko, Du bist laut deinem LinkedIn Profil Devfluencer. Und jeder, der dich vielleicht schon mal auf LinkedIn gesehen hat, würd dich vielleicht aus deinen Videos kennen, die ich persönlich ziemlich hart abfeier, muss ich schon sagen. Ich hatte sone Best of Playlist wahrscheinlich, vielleicht kann ich die nachher im Pick of the day noch verwenden.
Mirko: Ja, schön. Ja.
Jan: Aber vielleicht willst Du einmal ganz kurz erzählen, warum Du eigentlich diese Video machst, was Du da mit Devfluencenzen willst und was Du eigentlich machst, wenn Du die Videos sonst nicht machst.
Mirko: Okay, das sind jetzt 3 Fragen. Ich hoffe, ich krieg die alle noch zusammen. Also wie ist es dazugekommen, dass diese Videos entstanden sind? Also wir haben vor 13 Jahren mal mit paar Kollegen zusammen eine Firma gegründet, eine Softwarefirma natürlich. Und es hat relativ lange gedauert, bis wir begriffen haben, wie wichtig es eigentlich ist, nach außen sichtbar zu sein, ne? Wir dachten immer, die wichtigste Sache an soner Firma ist, gute Arbeit zu machen, aber das ist nur 'n Teil davon. Und irgendwann nach, ich sag mal so, 9, 10 Jahren haben wir begriffen, wie wichtig es ist, sichtbar zu sein nach außen. Und diese Idee mit den Videos ist war einfach so, ich sag mal, eine Schnapsidee. 1 von uns dachte, okay, das können wir ja mal ausprobieren. Und dann war's eben so, dass Leute wie Du, Jan und viele andere das eben, genau wie Du sagst, hart gefeiert haben und sehr viel positives Feedback dazu gegeben haben. Und deswegen haben wir das dann weitergemacht und einfach, weil's 'n positives Bild nach außen strahlt, einfach lustig ist. Es macht uns Spaß, es macht den Leuten Spaß und und das ist eine gute Sache. Was mach ich sonst, wenn ich keine Videos mache? Wir haben grad noch eine zweite Firma gegründet, die Prio 0 GmbH. Da bin ich Geschäftsführer. Das heißt, ich kümmere mich dort, wie das so ist in 'ner kleinen Firma eigentlich alles. Sales, Marketing, Entwicklung, Produktenscheidungen, ne. Alles querbeet. Das sind so meine Aufgaben den ganzen Tag.
Jan: Das ist natürlich insbesondere dann lustig zu sehen, wenn man die Videos kennt und weiß, dass Du in den Videos ja all diese Rollen auch selber spielst. Einfach mit nur so leicht angepastem Outfit und viel Szene Schnitten, ja? Aber dann entspricht das quasi eigentlich auch deiner Lebensrealität, dass Du alles in Personalunion bist.
Mirko: Ich glaube, deswegen funktioniert es. Deswegen ist es so witzig für die Leute oder deswegen können wir diese Situation so gut natürlich maßlos übertreiben, ne. Aber im Kern sind's alles Dinge, die die Leute kennen, die passieren, die wir beobachtet haben bei anderen Firmen, die bei uns so passieren, ne. Und das ist, glaube ich, ja, das, was die Sache so authentisch macht und so witzig.
Jan: Auf deinem LinkedIn Profil steht auch der Satz, eigentlich bin ich Entwickler mit Leidenschaft für guten Code. So, jetzt ist da ja die Relativierung im Prinzip schon eingebaut. Ja. Und das ist, glaub ich, auch so genau das Thema, über das wir heute sprechen wollen, nämlich die Frage so, also wir haben alle irgendwann mal irgendwie als Entwickler angefangen und die Frage ist, kann man, muss man, sollte man sich das erhalten über die Zeit? Oder ist man irgendwann an 'nem Punkt angekommen, wie bei dir, Merkel, ne, wo man halt eben noch 25 andere Hüte gleichzeitig aufhat und sich irgendwann son bisschen von diesem Developer Alltag verabschieden muss oder eben auch nicht. So, ja? Das das ist, glaub ich, der Punkt. Und ich glaube, diese Diskussion einzuordnen, wär's vielleicht ganz hilfreich, wenn wir alle mal so ganz kurz beschreiben, was wir eigentlich so wirklich den ganzen Tag über machen, wie wir da so hingekommen sind, wo wir jetzt grade sind, den Hörerinnen son bisschen mehr Eindruck zu geben, wie so unser Alltag überhaupt aussieht, unabhängig davon, ob wir dadrin noch entwickeln oder nicht. Und weil Dennis noch nicht so viel geredet hat, darf Dennis anfangen.
Dennis: Ja, danke sehr. Vielleicht, ich da hatte mal ganz kurz mit der Anekdote, die ich auch habe zu mit Zukunft auf Mirko, weil ich glaub, es gab nicht nicht viele, die mit Tech Content da draußen einigermaßen viral oder erfolgreich sind, was
Jan: Außer uns.
Dennis: Was lustige Videos angeht. Nee, auch wir sind nicht mit lustige Videos erfolgreich.
Mirko: Nee, nee, nee.
Jan: Aber
Dennis: ich bin ja,
Mirko: wie wie
Dennis: ist das richtige Adverb dafür? Ich bin so weder leidenschaftlich noch geschundener, ich weiß es nicht, ich bin TikTok User auf jeden Fall und hab darüber die die Videos gesehen und hab dann Mirko in Real Life auf der in Dresden aus der Ferne gesehen. Und das war son bisschen, das war 'n lustiger Moment, weil ich dann, also das vorher nicht wusste oder erwartet hab und dann son bisschen dieser Realitätscheck, die hast Du doch mal diesen TikTok Videos gesehen, dass Du irgendwie, das ist strange und wo kommt ihr her? Und dann mal kurz gegoogelt hab und dann die Verbindung hatte so, ah, okay, da ist er einzuordnen. Das das war dann 'n schöner Moment und cool, dich dann auch persönlich kennengelernt zu haben, Zu deiner eigentlichen Frage zurück. Ja, Kurz Abriss ist, ich hab irgendwann mal Medieninformatik studiert und mich dann sehr stark auf mobile Entwicklung, vor allen Dingen, iOS konzentriert. Glaub für mich son bisschen auf die Schulter, dass auch das 1 der Gründe war, warum Lotum heute Mobile Games macht, weil wir, also Kommilitonen Benny und ich, Mobile son bisschen zu Lotum gebracht haben, nachdem wir einmal Webseiten gebaut haben.
Jan: Wart mal, Benny hat mit dir studiert? Ja. Und der Benny Benny?
Dennis: Ja. Ach, ist ja lustig. Die Geschichte kennst Du noch gar nicht?
Jan: Nee, das muss ich mir auch bei Gelegenheit mal einziehen lassen.
Dennis: Vom Pissoir bis zur gemeinsamen Masterarbeit, es mit einem Satz
Jan: Ich bin morgen Abend mit Andy verabredet und ich werde mir das im Detail erklären lassen.
Dennis: Sehr gut, die die Geschichte. Und die hat 16 Jahre auch gemeinsam in der in der gleichen Firma angestellt. Ja, und irgendwann hab ich so gemerkt, okay, mich interessiert aber auch son bisschen, warum die ganzen Sachen machen und zugegebenermaßen waren wir auch noch 'n bisschen unprofessioneller natürlich unterwegs. Das heißt, wir hatten eigentlich so den kompletten Prozess von vorher alles designt und dann fertig und gedacht und dann Development und keine Ahnung was. Sondern auch so was, wir skribbeln mal aufm Blatt Papier irgendwie eine, ne, wie sone Appseite aussehen kann und und bauen den irgendwie oder so. Das war immer son bisschen näher auch an an dem, was wir täglich gemacht haben. Und trotzdem hatt ich diesen Drang, bisschen mehr zu verstehen, okay, was sind denn die Gründe und warum machen wir das? Und bin deswegen, was damals bei uns ich noch schlicht nannte, ja, weil wir noch nach Scrum entwickelt haben, Product Owner geworden für 1 dieser Teams und eben mich darum 'n bisschen das Produktmanagement gekümmert. Und dann, das ist auch eine relativ Natürlich entstanden, ich war irgendwie nie mein Ziel oder irgendwie 'n Karrierefall, den ich unbedingt einschlagen wollte. Aber ich hab einfach festgestellt in der Konstellation, wie wir waren, wir waren damals noch kleiner bei Lotum, vielleicht so, weiß nicht, 30 Leute, 35 Leute oder so. Ich war in meinem Team dann der 1, das einzige Team, wo nicht noch 'n Gründer mit irgendwie drin war, so. Und das heißt, so Themen der Personalverantwortung, die eigentlich immer dort aufgehängt waren, hab ich dann irgendwie recht natürlich in diesem Team son bisschen mit übernommen, weil's da noch dies diese Strukturen für gab. Und dann haben wir uns damals dann bei Lotum entschieden, okay, wenn wir jetzt noch 'n bisschen weiter wachsen, heute heute sind wir 50 Leute, dann macht wahrscheinlich sone Ebene noch irgendwie Sinn, die sich mehr die Leute dann da kümmert. Und das heißt, da bin ich dann vom Produktmanagement sozusagen weg, wo ich auch, sagen wir mal, die erste Zeit und relativ viel, also auch noch entwickelt hab. Ich hab das so fuffzig fuffzig erst mal gemacht. Irgendwann hab ich dann auch 100 Prozent dieses gemacht für, weiß nicht, 2, 3 Jahre. Und dann eben gewechselt in die Rolle, die ich jetzt habe, Head of Development, wo eben mein mein Ziel ist, einen Raum für unsere Entwickler*innen zu schaffen, indem sie halt mit möglichst viel Spaß möglichst professionell Dinge umsetzen können. Ja, vielleicht erst mal so weit, bevor ich jetzt noch sage Oder möchtest Du jetzt schon die Einschätzung hören, wie viel ich heute noch code?
Jan: Nee, nee, nee, das sehen wir uns auf. Wir brauchen noch 'n kleinen Schifffänger für 'n Ballungsbogen. Mirko, wie sieht das bei dir aus?
Mirko: Also na ja, ähnlich, aber irgendwie auch anders. Wenn ich dem Dennis so zuhöre, hab ich das Gefühl, dass quasi der Anteil der Zeit, die er wirklich noch programmiert, über die Zeit so kontinuierlich kleiner geworden ist. So so wirkte es jetzt auf mich, ne. Bei mir hat es sehr geschwankt über die Jahre so, ne. Es gab so Zeiten, da hab ich wirklich, ich sag mal, 90, 95 Prozent mit Coden verbracht, auch nachdem wir die auch nachdem wir Dev Booster gegründet hatten, weil's einfach das die Hauptarbeit war und viel zu tun gab. Es gab wieder andere Zeiten, da hab ich das komplett irgendwie delegiert und bloß noch, na ja, so product orhnomäßig, ich sag mal, Anforderungen aufgeschrieben, mit Kunden geredet, ne. Am Ende musste war's so, man musste immer dort hingehen, wo jemand gefehlt hat, ne. Wenn jemand da wär, der zum Kunde fährt und mit dem spricht, was der haben will, dann muss das jemand machen. Und das gab's dann halt Leute, die das lieber gemacht haben als andere. Und das ist eigentlich bis heute so, es schwankt sehr. Also selbst bei Brionol gibt's gab's Wochentage, wo ich häufig unheimlich viel programmiert hab, nur fast nur. Jetzt im Moment ist es wieder sehr wenig. Jetzt ist es Sales und Marketing und ich sag mal, mit Kunden, Kunden anzuboten, zu sehen, dass es funktioniert. Das schwankt sehr, ne. Und ich muss auch ganz ehrlich zugeben, wenn dieser Prozentsatz bei mir unter eine gewisse Grenze fällt, dann werde ich unzufrieden. So, ich sag das mal so vorsichtig, ne. Ich brauch das, ne. Also wenn ich irgendwie 3, 4 Wochen lang keine Zeile Code anfassen kann, dann vermisse ich diese Sache einfach, weil's einfach was ist, was mir Spaß macht, wo ich in den Flur reinkomme. Und ich sag auch immer, ich kann 8 Stunden hintereinander programmieren, da gehe ich ausm Büro raus, da ist es so alt wie Urlaub, ne? Wenn ich aber 8 Stunden Marketing gemacht hab, da gehe ich ausm Büro raus und bin Brauch Urlaub so ungefähr, ne? Also es ist einfach Wir sind ja alles, ich sag mal, in gewisser Weise zieht es uns zu dieser Tätigkeit, ne. Und manche mehr, manche weniger. Und mir, ich kann das nicht komplett abgeben und es fällt mir auch schwer, mir vorzustellen, mal son Fahrrad zu gehen, wo ich quasi gar nichts mehr programmiere. Also sone reine Engineering Manager Position vielleicht, ne, wie die es in großen Firmen gibt, innezuhaben. Also das ist für mich schwer vorstellbar, ja. Beantwortet es die Frage Jan. Ich denke, schau.
Jan: Das beantwortet, glaube ich, die Frage ganz gut. Dann mach ich die Runde hier noch komplett. Ich hab ähnlich wie Dennis das Glück gehabt, sehr früh in 'n cooles Start-up zu kommen und bin da im Prinzip mit reingewachsen. Und war dann am Ende da für unser Development- und Projektteam verantwortlich. Und dann, wie Mirko grade schon so angeteasert hat, sobald man nur noch Personalverantwortung hat, das hat relativ wenig mit Arbeit am Code irgendwie zu tun. Wir waren so in meinem Team ungefähr 50 Leute und da kann man sich ja mal durchrechnen, ne? Wenn man mit jedem auch nur ab und zu son One on One hat und dann noch son bisschen Budgetplanung hat und hier eine Review und da noch was, hier Boardpräsentation und so, dann bleibt halt super, superwenig Zeit. Und das war voll ärgerlich, weil ich hab mich eigentlich immer gerne mit so diesen Architekturfragen beschäftigt. Also das war E-Commerce-Space und mich hat irgendwie immer interessiert, wie kann man, weiß nicht, ne, den Weg von der Order bis hin zum Bahnwirtschaftssystem irgendwie supercool gestalten. Was kann man da so mitnehmen? Ich hab anders als Dennis, glaube ich, nicht viel Spaß an Produktarbeit. So, so dieses letzte bisschen so, wie kann man das für den Kunden, für den Endverbraucher noch cooler machen? War bei mir nie so ganz vorne, sondern für mich war immer mehr so, wie kann man's halt irgendwie technisch noch besser aufstellen? So, wie kann man das, ne, was kann man heute irgendwie daran drehen, dass es uns morgen nicht auf die Füße fällt? Das war immer mehr so mein Ding. Was dann wahrscheinlich auch irgendwie in sonem wachsenden Start-up vor allem halt mit in die Wiege gelegt wird irgendwie. Und da ich dann da immer weniger mit Code zu tun hatte, bin ich da gewechselt und hab bei Shopify Developer Relations gemacht und hab da gemerkt, dass eigentlich, ja, Architektur ist ganz cool. Was mich irgendwie immer hintendran mehr gereizt hat, war so eigentlich, wissen wollen, wie Sachen verstehen und Sachen auszuprobieren können. Und da ist natürlich Architektur 'n cooler Vorwand für. Weil da, oh, Sachen irgendwie ordentlich aufzubauen, muss man sie irgendwie verstehen und mal 'n bisschen was rumprobiert haben und hier 'n Proof of Concept bauen und da mal was irgendwie anschauen und so. Und da könnte man sich dann natürlich in noch viel mehr austoben. Ja, und jetzt bin ich ja wieder bei der programmier.bar gelandet und hab ja hier nur noch mit Wissen zu tun. So, also im Prinzip alles, was ich mach, ist mir ja jeden Tag, jede Woche in irgend 'ner Podcastfolge irgend 'n Thema anhören, diskutieren, einarbeiten, was ich halt irgendwie selber megainteressant finde. Unabhängig davon, wie viel Coding das jetzt irgendwie am Ende des Tages ist. Also natürlich bauen wir interne Tools, wir bauen die programmier.bare Plattform noch, da gibt's schon auch irgendwie immer was zu tun. Aber das ist nicht immer so dieser, den ich eigentlich scratchen wollen würde. Und da geht's mir ähnlich, wie Mirko schon gesagt hat so, wenn man das dann son paar Wochen nicht macht, dann wird man irgendwann hibbelig. So, ich weiß noch, als wir letztes Jahr mit ihrem Camper son paar Wochen mit dem Camper son paar Wochen durch Europa gefahren sind, hab ich auch so mein halbes Büro eingepackt, weil ich gesagt habe, so okay, ich kann mir nicht vorstellen, dass ich da wochenlang in der Pampa sitze und nichts mach. Ich werd irgendwann mit 'nem Buch oder mit 'nem Video oder mit 'nem kleinen Codeprojekt oder irgendwann mal dasitzen und irgendwie so was was tun. So funktioniert das, glaub ich, bei mir. Ja. Und das vielleicht einmal einmal dazu. Und jetzt können wir vielleicht son bisschen auflösen, Mirko hat das ja schon son bisschen gesagt, wie er das zur Handhabt. Dennis war es noch der Cliffhanger. Dennis, wie viel machst Du denn jetzt noch so am Ende des Tages?
Dennis: Sehr wenig. Also ich hab das auch oder vielleicht eine eine kleine Korrektur von dem, was Du gesagt hast. Tatsächlich also hatte ich zwar das Interesse damals zu gucken, warum wir was machen, hab aber schon auch gemerkt, als ich, und das wurde mir erst richtig klar, als ich dann die Head of Development Rolle eingenommen hab, dass mir Product dann doch nicht so viel Spaß macht. Also weißt Du, das war also das war dann Das Caterprinzip.
Jan: Das war dann so lange fördert, bis man da landet, wo man gar keinen Fall
Dennis: Ja, das war irgendwie so das, also das Management und so, das hat mir schon, also ne, die so die Managementaufgaben davon haben wir, glaub ich, ganz gut gelegen. Aber was ich halt nicht, wo ich nicht besonders gut drin war, war irgendwie Discovery und ne, Mechaniken und sich da so tief reinfuchsen, warum und so. Also diese diese Parts davon, wo ich auch dann sehr abhängig war von Kolleg*innen, die die ne, da irgendwie jeden Fut gegeben haben. Und das hab ich erst gemerkt tatsächlich, als ich dann mich darum nicht mehr kümmern musste, dass ich so dachte, oh, das ist irgendwie ganz angenehm, dass dieser Part nicht mehr ist. Ich hab immer noch son bisschen dieses Management und kann mich jetzt noch mehr Leute kümmern, so. Das das das war eigentlich sehr befriedigend. Und ja, bei uns ist es tatsächlich so und das ist, glaub ich, auch irgendwie, ich weiß gar nicht, ob das da draußen so der Unterschied zwischen Head of Development und CTO ist oder ob wir das einfach nur so leben. Gefühlt sind CTOs noch mal deutlich oft technischer dran und treffen irgendwie technische Entscheidungen und müssen deswegen, ne, Sachen ausprobieren und irgendwo Prototyp bauen und vielleicht immer die Architektur bauen, auch schon mal je nach Größe. Wir haben so das Credo, dass wir halt die gesamte Verantwortung über die technische Hoheit in die Teams reingeben. Das heißt, da hab ich eigentlich nix mitzureden so, ne. Was einfach auch dazu führt, dass ich im Alltag halt nicht dazu komme, irgendwo an unseren Projekten tatsächlich was dran zu machen. Auf der anderen Seite steht natürlich, dass ich trotzdem versuche, irgendwie aktuell zu sein, unterstützen zu können, ne, Gedanken dazu zu haben. Gerade natürlich irgendwie AI ist was, wo man dann natürlich irgendwie schon einsteigt selbst und Sachen, ne, ausprobiert und und also ich hab deutlich mehr Code wieder produziert, seitdem seitdem es AI Tools gibt, einfach natürlich, ja, da auf fundierte Entscheidungen treffen zu können und das einordnen zu können so.
Jan: Ich würd da ganz kurz einhaken wollen, weil Du gesagt hast, so die Hoheit liegt ja in den Teams und dementsprechend wenig gibt es da wirklich, wo Du dich austoben kannst. Aber ist es dann nicht am Ende trotzdem so, dass Du ja dafür verantwortlich bist, dass sie die richtigen Entscheidungen treffen können? Also ja, Du Du musst dich vielleicht jetzt nicht irgendwie technisch in die eine oder andere Richtung bringen, aber Du musst ja zumindest trotzdem dafür sorgen, dass die Maßstäbe, die sie anlegen, halt irgendwie allein sind und dass sie die richtigen Sachen kennen und erkennen können und so. Das ist ja trotzdem wichtig.
Dennis: Ja, aber da habe ich auch das Gefühl, also ich glaube, es wäre schwer, meine Rolle genauso zu machen, wenn man vorher nie Entwickler war, so, ne. Also das ist ja dann noch mal 'n Unterschied. Aber dadurch, dass Du irgendwie die Herausforderungen und die Probleme und so was irgendwie schon mal mitgemacht hast, da empfinde ich es dann als zweitrangig son bisschen, welche Programmiersprache das jetzt zum Beispiel ist, ne, weil das dann irgendwie doch irgendwie sehr ähnlich die gleichen Problematiken wieder hervorbringt. So, also ich glaube schon, dieses die Erfahrung darin zu haben, das ist schon wichtig. Und dadurch fällt es mir auch relativ einfach, würd ich sagen, halt up to date zu bleiben und ne, also ich würde sagen, ich verstehe noch ganz gut, was wir machen und wenn ich mir das angucken würde so. Und ja. Und trotzdem, also das, was Mirko hat, dieses unter, es gibt schon auch die Momente, wo ich ganz gerne, also wenn ich's einfach so per Klick meine Aufgaben abgeben könnte, würd ich auch gerne noch mal für 'n paar Monate in ein Team gehen und einfach nur entwickeln so. Also das ist schon was, was mich schon 'n bisschen juckt, grade tatsächlich auch in den heutigen Zeit, noch mal einfach zu erleben, wie ist es jetzt grade? Weil ich das halt einfach nur an Seitenprojekten hier 'n bisschen und so was testen kann und nicht wirklich eben, so fühlt es sich heutzutage in einem Entwicklungsteam an. Ja.
Jan: Mirko, wie wichtig ist für dich dieser Aspekt, den Dennis grade genannt hat, mit ja auch, son bisschen aktuell zu bleiben?
Mirko: Na ja, also der Dennis hat vorher noch 'n eine andere Sache gesagt, die, glaub ich, noch sehr viel wichtiger ist, nämlich er hat diese Erfahrungen gemacht, ne. Er kennt die Probleme, die immer wieder auftauchen, ne. Das find ich superwichtig, ne. Das also da son typisches sone typische Sache, dass es 'nem Entwickler schwerfällt oder 'ner Entwicklerin zu sagen, wie lange was dauert, ne. Ne. Das sagen wir ja ganz oft, ne.
Jan: An der Stelle verlinken wir euer Video zu Schätzungen, wie lang dauert es, einen Button einzubauen?
Mirko: Ach so, stimmt, ja. Genau, gibt's 'n Video dazu. Aber das ist sone Sache, die find ich, die ist zum für Außenstehende in Anführungszeichen oder Leute, die noch nie in dieser Situation waren, total schwer zu verstehen, ne. Also sich, warum ist jemand nicht in der Lage, zu sonem einfachen Feature zu sorgen, wie lange es dauert, ne. Aber als Programmierer, wenn man da mal drinsteckt und diese Unberechenbarkeit, die's da manchmal so gibt, schon mal erlebt hat, dann kann man ganz anders mit dieser Situation umgehen. Und deswegen find ich das superwichtig, was der Dennis gesagt hat, dass ihm diese Erfahrung dabei hilft, mit den Teams zu interagieren, die Teams zu steuern, ne. Und ich glaube, das ist was, was was man in soner Managerposition, nennen wir's jetzt mal so, unbedingt braucht, ne. Dieses es, also ich kenn auch Leute, die die sind so empathisch, die können das ohne es jemals selbst erlebt zu haben, aber die sind sehr selten, ne. Es ist halt einfacher, wenn man die Situation schon mal erlebt hat, ne. Und dieser Punkt, den Du Ich kann
Jan: ja ganz ketzerisch sagen, das ist ja vielleicht sogar das Allerwichtigste, ja? Und das ist ja ein ein Wissen, ein Erfahrungsschatz, der ja relativ zeitlos ist. Also, ne, die die was Du grade sagst hast, wenn man das einmal verstanden hat, dann ist ja im Prinzip auch egal, ob die Leute das grade mit mit Swift, mit mit Ruby, mit keine Ahnung was machen, weil die grundsätzlichen Probleme, die sind die gleichen und die werden aller Voraussicht nach auch die nächsten 20 Jahre noch dieselben sein so, ja? Und dann könnte ich jetzt ganz ketzerisch fragen so, muss ich dann überhaupt irgendwie technisch am Ball bleiben? Oder reicht das nicht, wenn ich quasi einmal das zugrunde liegende Problemset verstanden habe und kann ich damit nicht, in Anführungszeichen, unendlich lange Tech Leadership machen?
Mirko: Also aus meiner Sicht ja und nein. Du kommst relativ weit mit dem Erfahrungsschatz, ne. Und Du musst jetzt zum Beispiel dieses Up to date bleiben, ne. Es ist, glaub ich, relativ wurst in soner Position, ob Du jetzt die neuen Sprachfeatures von, keine Ahnung, Java 35 kennst, wenn's dann irgendwann rauskommt, ne. Das ist egal. Aber dieses Up to date bleiben hat ja auch noch eine, aus meiner Sicht, eine zweite Funktion, nämlich wenn Du mit den Leuten sprichst und die merken, dass Du up to date bist, ne, dass Du dich damit beschäftigst, dann baust Du oder dann hast Du 'n anderes Level von Credibility, ne ne. Und Entwickler sind immer so mindestens die Männlichen, die ich kenne, ne. Die die die orientieren sich da dran. Die die merken ganz schnell, ob jemand in 'nem gewissen Gebiet, wie viel der Ahnung hat, ne. Und die und respektieren das dann oder eben auch nicht, wenn wenn's einem fehlt, ne. Das heißt, diese zweite Funktion von up to date bleiben, mitreden zu können, dass die Leute merken, okay, der Typ oder die Typen, die kann mitreden, ne. Das ist ganz wichtig, diesen, ich sag mal, diesen Respekt auch von den Teams zu kriegen, damit die dann, wenn man irgendwie vielleicht eine unbeliebte Entscheidung trifft und jetzt sagt, okay, ihr wollt Programmiersprache x y, aber aus irgendwelchen Gründen müsst ihr jetzt was anderes machen. Wenn man sone Entscheidung, ich sag mal, durchbringen will, dann hilft dieser Respekt unheimlich viel. Deswegen, also so ganz ohne Abdo Date bleiben, glaube ich, es ist einfach schwerer dann, die Leute zu überzeugen.
Jan: Jetzt hast Du auch schon erzählt, Mirko, dass es bei dir auch mal Phasen gibt, wo Du richtig viel machst. Ja. Ne? Wie schaffst Du das so zu balancieren? Weil ich könnte mir vorstellen, grade wenn man natürlich auch Spaß daran hat, ne, und Du hast ja selber gesagt, das ist dann son bisschen wie wie Urlaub machen. Ja. Dann kann man ja schon vielleicht auch in die Falle tappen zu sagen so, na ja, ich ich hab ja hier alle Hüte selbst auf. Ich kann mir meine Zeit selbst einteilen und das ist ja auch son Phänomen, was mit sonem gewissen Level immer einhergeht. Da wird einem mehr Vertrauen entgegengebracht. Da kann man selber gucken, was man mit seiner Zeit so macht. Dann ist ja wahrscheinlich auch die Gefahr sehr groß, da reinzutreten, sagen so, ja, jetzt jetzt mach ich halt nur noch so also dieses dieses komische Personal und diese one on ones, die können ja warten, ja, ja. Die können auch nächste Woche noch mit mir reden, aber ich muss jetzt hier grade sonen echt coolen Bug irgendwie fixen oder 'n kleines Feature bauen, was ich schon immer mal haben wollte. Ja. Wie wie wie schafft man das da auch, sich's wieder son bisschen rauszureißen vielleicht auch?
Mirko: Also absolut, diese Gefahr ist total da, ne. Da lieber was zu machen, was einem Spaß macht, ne. Das hab ich auch schon bei Leuten gesehen. Ganz extrem, ich hab mal bei 'ner Firma gesehen, da war 1, der CTO, der hat halt gerne entwickelt, ne. Und der hat sich dann eingesperrt und hat 5 Jahre lang irgendwie eine Software für die Firma gebaut und sich nichts anderes gekümmert, ne. Also diese dieses Rapidhole existiert. Für mich ist es immer so, ich hab über die letzten Jahre gelernt, wenn dass es schlecht ist, wenn ich zu lange Dinge mach, die mir Spaß machen. Weil das heißt, eigentlich Klingt
Jan: erst mal paradox.
Mirko: Das klingt total paradox, aber der der Punkt ist, das machen, also diese Tendenz haben natürlich alle. Das heißt, also dieses Verlassen der Komfortzone fällt allen schwer, ne. Und und ich sag mir dann immer, ich muss da raus. Ich muss jetzt Dinge machen, auf die ich erst mal keinen Bock hab, die schwierig sind, die ich vielleicht nicht kann, ne. Weil die wichtiger sind als die Dinge, die die mir leicht fallen, ne. Und dann zwinge ich mich halt und sag, ich weiß, ich programmier lieber, aber das ist grade völlig egal für unser Produkt. Wir müssen Marketing machen, dann wird Marketing gemacht, ist egal. Ne, also man muss sich da so bisschen selbst kasteien, sag ich mal. Und sich und sich das, ich sag mal, logisch herleiten damit, dass das halt wichtiger ist, ne, ja. Und das kann ich mittlerweile ganz gut. Also da gibt's dann, keine Ahnung, mal 'n halben Tag in der Woche eine Belohnung, wo man mein Feature bauen darf oder am Wochenende. Und dann ist das ganz gut.
Jan: Wenn Du also, bei Dennis hab ich gehört, wenn er so was macht, dann ist das eher so nebenbei, ja. Bei dir klang das jetzt eher so, als ob's tatsächlich Arbeit am Produkt wäre.
Mirko: Ja. Ne.
Jan: Ja. Da würde mich mal interessieren, weil auch da hab ich schon verschiedenste Ausprägungen gesehen über die Zeit, inwieweit da sone gewisse Powerdynamik halt auch reinkommen kann. Weil natürlich, ne, wenn jetzt Code Review zum Beispiel ansteht, ja, und das ist das Feature von deinem Chef. Und Du musst da jetzt halt eben drauf gucken, ob das auch alles in Ordnung ist. Wie bringt man da die Leute dazu halt, ne, trotzdem offen und ehrlich zu sein? Und auch wenn die Idee von oben kommt, kann sie trotzdem genauso schlecht sein wie von jedem anderen auch. Und auch ein Feature, was der Chef mal vor 3 Jahren gebaut hat, darf heute angepackt und rausgeschmissen und und keine Ahnung was werden. Habt ihr so was schon erlebt?
Mirko: Also ich denke, dass es das auf jeden Fall gibt. Bei uns ist es so, also das Team, was bei uns an dem Produkt arbeitet bei Prionol, die Leute kenn ich so lange. Die haben keinerlei Respekt mehr vor meinem Code. Wenn die was doof finden, dann sagen die mir das also so dermaßen deutlich ins Gesicht. Aber das ist völlig okay, weil wir uns einfach so lange kennen. Wir wir wissen, dass wir's miteinander machen können, ne. Und von daher ist das okay. Und das dieses Problem mit den Code Reviews gibt's bei uns nicht, weil wir keine Code Reviews machen. Ist auch eine Methode, das Problem zu lösen, ne. Wir sagen einfach, jeder ist verantwortlich und muss das hinkriegen, was auch nur funktioniert, weil weil wir uns so lange kennen und die Leute so gut sind, dass man die das machen lassen kann, ne. Aber ich glaub, in 'nem normalen Team hättest Du diese Sachen und ich hab das auch schon beobachtet, dass da CTOs in Firmen, ich sag mal, ja, Code eingecheckt haben oder Entscheidungen getroffen haben, die das Team teilweise geschlossen abgelehnt hat, ne. Also nicht Das waren keine Diskussionen, wo die Hälfte dafür war und die Hälfte dagegen, sondern der CDU hat gesagt, wir machen jetzt das. Alle haben gesagt, das ist völliger Blödsinn. Es wurde trotzdem gemacht, ne. Also klar, wenn Du diese Machtgefälle hast, dann passieren diese Dinge. Und das ist Mist am Ende, ne.
Jan: Jetzt hast Du gerade schon das Team son bisschen angesprochen. Das hat mich auf 'n ganz anderes Thema gebracht, nämlich so Recruiting, ja? Und auch da kann es ja hilfreich sein, son bisschen aktuell zu bleiben. Ich weiß nicht, Mirko, wie viel Recruiting bei euch läuft, aber ich weiß, dass der Dennis noch bei unserem Recruiting mit rumturnt. Und vielleicht, Dennis, kannst Du ganz kurz erzählen, wie hilfreich oder nicht hilfreich es ist, dass Du nebenbei noch 'n Code hast oder ob's überhaupt gar keine Rolle spielt. Mhm.
Dennis: Interessante Frage. Muss ich grade selbst mal kurz drüber nachdenken.
Jan: Das schon mal 'n gutes Zeichen, dann war die Frage gut.
Dennis: Ja, ich würde fast sagen, eher nicht. Und das liegt aber jetzt aber auch wieder an ein an, ich weiß nicht, ob er besonders Speziell ist, aber an unserem Bewerbungsprozess mit den Merkmalen, dass wir nicht für eine spezielle Rolle suchen oder eine bestellte Stelle, die ausgeschrieben ist, sondern dass wir seit Jahren konstant immer nur nach guten Entwickler*innen suchen. Und von daher es relativ technologieagnostisch ist, was dort passiert. Also ne, in unseren Vorstellungsgesprächen vor Ort, wenn Leute da coden müssen, dann ist uns beispielsweise die Programmiersprache egal, so. Und da geht's halt eher die Logik, die Sprache, das miteinander darüber reden. Und da ist jetzt, glaube ich, nicht so viel, was ich jetzt durch Seitenprojekte, die ich noch mache oder so was, haben. Da ist dann vielleicht eher der der der der Fall, den Mirko tatsächlich auch nannte. Also da dann mitreden zu können, dass Du halt irgendwie weißt, ne, was Future ist oder keine Ahnung, also irgendwelche, ist jetzt auch keine besonders neue Technologie, aber fällt mir was Neues ein, Bann oder was auch immer, ne, dass Du's halt einordnen kannst und und weißt, womit Du's vergleichen kannst und was auch so die Dinge. Das schon, aber jetzt ums zu evaluieren, würde ich sagen eher weniger.
Jan: Ich hab das mal zu meinem Gründer damals gesagt, als als CTO brauchst Du eigentlich nur son Bullshit Radar. Du musst über alles mitreden können und Du musst eigentlich nur erkennen, wenn jemand anfängt halt wirklich über was zu reden, wo er keine Ahnung von hat und das halt irgendwie so merken. Das ist, glaube ich, so die Ebene, die man da braucht. Alles andere ist, wie Du schon sagst, ne? Okay, man muss so bannen kennen und so wissen, was sind die Vorteile davon und warum ist es interessant? Du musst jetzt nicht wissen, wie es irgendwie intern funktioniert und wie man das irgendwie aufsetzen, keine Ahnung was. Ja. Ich hab's
Mirko: aber manchmal die Erfahrung gemacht, also was hilft in sonem Bewerbungsprozess als jemand, der dabei ist? Ich sag mal, wenn jemand zum Beispiel eine Technologie oder eine Sprache benutzt, die Du selbst nicht kennst, ne, dann kannst Du ganz authentisch und einfach dumme Fragen stellen, ne. Du kannst sagen, erklär mir mal, was macht 'n das Ding? Wozu braucht man jetzt das? Und da lernst Ja. Du ganz viel darüber, wie der oder diejenige antwortet und dir das erklärt, ne. Und Ja. Und das ist 'n ist ja 'n super Skill, ne, wenn jemand dir was Neues erklären kann und Du verstehst es danach wunderbar, ne. Also bin ich voll bei Dennis.
Jan: Ja, und ja eigentlich auch 'n cooler 'n cooler Indikator so, ne. Also ob halt jemand seine eigene Arbeit so im laufenden Betrieb sozusagen erklären kann Oder ob er dann dabei irgendwie ins ins Stolpern kommt, hat ja auch schon mal sone Situation. Aber trotzdem, dann ist ich würd das noch mal hinterfragen, weil Du meinst, man man muss jetzt nicht irgendwie so viel von der Technik verstehen. Es gibt ja doch alle paar Jahre, Jahrzehnte so so große Shifts vielleicht irgendwie, ne. Jetzt machen wir in der Softwareentwicklung grade sehr viel, was für Ei Arbeit angeht, so reaktiv. Egal, ob das jetzt mit oder oder oder oder so was ist so, was es ja vor 15 Jahren so noch nicht gab oder vor 10 Jahren oder so. Und sind das nicht doch irgendwie Shifts, die man noch so mitnehmen, probieren und verstehen muss? Weil das ja dann schon auch Sachen sind, wo Du manchmal so das Mindset von jemandem doch irgendwie abfragen musst, ne? Hat der son Konzept irgendwie verstanden? Weiß nicht, also ne, Mirko, ich weiß auch nicht, wie bei euch so die Architektur aussieht, aber wenn ich jetzt 'n Projekt hätte, was super event driven zum Beispiel funktioniert, ne, unabhängig von der von der Sprache und so dem Framework, was da benutzt wird. Aber das ist ja schon eine andere Art, Software zu entwickeln oder Funktionen zu verkapseln, als jetzt vielleicht, weiß ich nicht, einfach nur klassisch irgend 'n MVC Framework dahin zu setzen oder so was, ne. Und das sind doch schon so Sachen, wo ich mein, das muss man eigentlich schon verstehen und mitkriegen, wenn so was aufkommt, oder?
Dennis: Ja, ja. Aber das ist vielleicht auch das, also das wird dann vielleicht auch wieder individuell, wie jeder dort dann lernt, ne. Also ob das ob es reicht praktisch, dass Du dazu was gelesen hast und mit Leuten drüber gesprochen hast und dann so die Konzepte verstehst Oder ob Du's halt lieber mal ausprobiert hast und es selbst mal runterprogrammiert hast, weil Du dann besser das Verständnis dafür hast, ist wahrscheinlich ja noch mal individuell. Aber natürlich musst Du irgendwo 'n bisschen mit der Zeit gehen. Und ich, also ich mein, jetzt grade befinden wir uns wahrscheinlich so in einem der größten Shifts, die man sich so vorstellen kann. Und da finde ich, ist zum Beispiel essenziell, dass ich das auch ausprobiere und nicht nur auf Artikel basiert, so was ist da theoretisch möglich, sondern es einfach auch irgendwo ausprobiere. Jan hat 'n leichtes Grinsen aufm Gesicht, weil ich zu viel positiv Vibe code und denke, es muss ja alles einfach so funktionieren.
Jan: Na ja, ich find das gut, dass es auch Leute in der Firma gibt, die ihre AI Tools öfter wechseln als ihre Unterwäsche oder so. Wir lernen ja alle mit davon. Also Aber sonst müsst ihr's ja selber probieren.
Dennis: Aber nee, der des definitiv ist es trotzdem auch so und da da seh ich, da da merke ich im Moment ein Gap so, wenn ich im Moment die komplette Freiheit hätte, würde ich tatsächlich gerne mal als Entwickler für 'n paar Monate wieder im Entwicklungsteam sein, einfach zu spüren, wie ist das jetzt auf 'ner Legacy Code Base wirklich produktiv, mit diesen Tools zu arbeiten? Weil das natürlich immer 'n Riesenunterschied ist zu, ich mach hier gleich mal, ne, einen Side Project oder mach eine kleine Funktion, die ich irgendwo mach hab oder so was, einfach, weil das ist, glaub ich, schon jetzt gerade jetzt ein ein Shift, wo es fiel natürlich auch die Prozesse, die Absprachen, ne, wie werden wir, wie ist es gemacht und so weiter, also viel irgendwie mit dabei ist, was sich grade ändert. Und da können wir jetzt leider nicht so sehr auf unsere Expertise der letzten Jahre irgendwie bauen, weil es einfach schon so unterschiedlich ist. Und da entweder wirklich durch sich selbst machen oder einfach durch sehr nah dran sein, viel mit den Leuten reden, ist es, glaube ich, trotzdem, also ja, es ist es ist jetzt wichtig, das mitzubekommen und zu spüren. Da hättest
Jan: Du die die ketzerische Frage, also warum machst Du's denn nicht?
Dennis: Es ist nicht ausgeschlossen. Ich hab es, ich ich hab, vermute ich, ein bisschen zu viele Verantwortlichkeiten. Also wenn das jetzt einfach aufm Papier, also wenn Du die, wenn man eine Rolle definieren würde und würde irgendwie sagen, so, was ist vernünftig, welche welche Verantwortlichkeiten man eine Rolle zutut, würde ich behaupten, hab ich im Moment ein paar zu viele Hüte auf, alles alles ordentlich und ganz so zu machen, wie man also perfekt zu machen, wie man's machen könnte, so. Und dadurch ist einfach eine gewisse Abhängigkeit da und also jetzt der konkrete Fall ist, ich will das Team ja auch nicht, Ich will das Team nicht stören und da nicht irgendwie eine eine eine Sonderlok oder so was sein. Das heißt, wenn, hätte ich schon den Anspruch, so als als Entwickler dabei zu sein und dann Das geht auch nur, wenn Du eine gewisse Zeit da dann dich committen kannst, dabei zu sein, so.
Jan: Na ja, aber also ich mein, Du warst ja auch schon in Elternzeit und da ist die Firma ja auch nicht zusammengebrochen. Also es es scheint ja zu
Dennis: gehen knapp davor.
Jan: Nein, nein, nein, ist Wenn Du zumindest 'n paar von diesen Hüten irgendwie pausierst, ja oder wenn man zumindest so was sagt wie, 3 Tage die Woche, dann bist Du halt das Äquivalent von 'nem Teilzeitentwickler oder so was. Also.
Dennis: Ja, ja, weil ich es ist auch, es ist für mich auch nicht ausgeschlossen. Also es ist tatsächlich was, wo ich wo ich stark drüber nachdenke und mit, also auch eine Frage, so wann ist genau der richtige Zeitpunkt, ne? Also es gibt vielleicht dann noch mal Nie. Wahrscheinlich.
Jan: Spoiler, also der richtige Zeitpunkt ist nie, egal wie die Frage lautet.
Dennis: In ein ein paar Monaten noch mal, ja, vielleicht der Epec noch größer oder so was auf auf auf das tägliche Ding. Aber nee, ich hab's nicht ausgeschlossen. Also es ist, ist halt nicht was, was man einfach so macht. Es muss 'n bisschen vorbereitet oder geplant werden, aber Lust darauf hätt ich schon, sagen wir mal so.
Mirko: Mhm.
Jan: War von euch schon mal jemand in der Situation, wir hatten das bei Mirko vorher nur ganz kurz, ich hab son bisschen spielerisch gefragt so, dieses Loch, in das man reinfällt und dann irgendwie auch wieder rauskommen muss, dass man zu viel codet. Wart ihr schon mal in der Situation, wo ihr sagt, oh, das war jetzt aber doch zu viel und ich hätte da irgendwie 'n bisschen weniger Zeit reinstecken sollen oder Also ne, eben diese diese ungesunde Form von diesem Management, so von diesem Zeitmanagement zu finden. Und meistens bemerkt man's ja irgendwie erst danach, dass es nicht so supergut gelaufen ist. Ja, natürlich.
Mirko: Alles andere wär eine Lüge, ne. Wenn jetzt jeder sagt, er hat das perfekt im Griff.
Jan: War das getrieben aus mehr so dem, was wir vorhin gesagt haben mit, ne, man hat halt zu viel Spaß daran und und bleibt dann einfach son bisschen darauf hängen? Oder es kann ja manchmal auch von der anderen Seite kommen. Es war halt irgendwie gefühlt grade sehr notwendig oder man hat das so wahrgenommen, als das besonders notwendig wär. Und dann ist man halt irgendwie darauf hängen geblieben, weil auch das ist ja son Risiko, dass man sich quasi mit einkauft, wenn man son bisschen technisch up to date bleibt. Und dass man ja natürlich auch immer, ne, Mirko das sagt, wenn Du ab und zu 'n kleines Feature baust, dann kennst Du ja eure Code Base noch. Und wenn jetzt mal Not am Mann ist, dann ist es ja naheliegend zu sagen, so, boah, jetzt muss der Mirko halt vielleicht doch mal 'n paar Wochen da mit rein und im Prinzip, denn ist da ein Traumleben, mal wieder so das das Developerleben voll auszukosten, ja? Oder wenn eine Downtime, ne, irgendwie incident und man muss hier 'n bisschen Feuer löschen und so, dann ne, ist ja auch immer so, je je besser man sich noch mit allem auskennt und je näher man noch mit dran ist, desto mehr fühlt man sich ja dann auch in der Verantwortung, da mitzumachen und im Zweifelsfall, ob man dann wirklich nett positiv ist an der Stelle, weil man was beiträgt oder ob man nicht die anderen 'n bisschen mehr ausbremst, weil man auf einmal mitmischt, das ist ja auch sone Frage, ne?
Mirko: Ja. Na ja, klar. Also das ist ja so ein Grund, warum man in sone Spirale reingerät. Einfach weil mit jeder Zeile, die Du hinzufügst, steigt ja dein Investment, ne. Du liebst Du liebst ja den Code, den Du geschrieben hast, ne. Das heißt, jede Zeile, die Du hinzufügst, macht diese Liebe 'n bissel größer und umso schwerer ist es dann wieder, das Ganze loszulassen, ne. Ich denke, es fällt einfacher, wenn man Leute sich rum hat, die das genauso behandeln wie wie man selbst. Also die auch sone Zeile einem, also sone Zeile übernehmen, ne, und Du hast das Gefühl, die machen das so weiter mit zumindest mit derselben Liebe, wie Du es selbst machen würdest. Dann fällt es leichter, so was abzugeben. Und und ich hab solche Leute mich rum, deswegen finde ich das gut, ne. Aber ich war auch schon in Situationen, wie Du das beschreibst. Du hast hast da an 'nem Feature gearbeitet. Du bist derjenige, der's versteht bis ins letzte Detail. Jetzt kommen Bugs rein. Du weißt genau, wo Du hingreifen musst. Du fühlst dich verantwortlich, ne. Ist ja auch nur son Ding, ne. Diese Liebe ist ja das eine, aber man hat ja auch so Verantwortungsgefühl dafür. Wenn was nicht funktioniert, sagt man, okay, ich muss da irgendwie helfen, ne. Aber am Ende sind's die Leute außen rum, die entscheiden, wenn Du 'n gutes Gefühl hast, das jemand anderen zu geben und den den Bug fixen zu lassen, dann fällt's erleichtert zu sagen, ich muss jetzt mal was anderes machen. Ich hab noch Face to Face Meetings, die mal gemacht werden müssen oder ich muss mal 'n Plan aufstellen, keine Ahnung, was es dann ist, ne. Also so dieses Weggehen von jeder hat seine Insel irgendwo im Kot hin zu, es gehört allen und die Leute mögen auch die ganzen anderen Stellen natürlich nie so wie den eigenen Kot, ist klar, ne. Ja, das ist immer, bloß 95 Prozent, aber es reicht vielleicht.
Dennis: Kannst Du 'n bisschen skizzieren, für was für Szenarien oder Aufstellung von Teams Du denkst, dass das funktionieren kann? Aber ich glaub ja schon, also Du sagst, ich mein, das sind jetzt Leute, denen Du vertraust und die dir vertrauen. Ist das so, dass dass es da irgendwie 'n stetiges Entwicklungsteam gibt und Du dann praktisch mal dazu kommst? Oder es gibt's dann auch die Phasen, wo praktisch wenig entwickelt wird, weil es gar nicht so sehr die anderen Ressourcen gibt? Weil zumindest stell ich mir schon als eine relativ große Herausforderung vor, ich mir schon als eine relativ große Herausforderung vor, wenn in 'nem Team, was irgendwie konstant an etwas arbeitet, da immer mal wir oder jemand reinkommt und son bisschen was dazugießt. Wo, also was sind so die Rahmenbedingungen, damit das funktionieren kann?
Mirko: So, das ist so, wie Du das beschreibst, denn das ist son Team, was kontinuierlich dran arbeitet, ne. Und wo dann ich hin und wieder mal reinkomme, wenn's wenn ich was beisteuern will oder muss, ne. Aber aber man muss sich das vielleicht so vorstellen, das sind jetzt nicht irgendwie 3 Monate, dass ich weg bin und irgendwie was anderes mach. Und dann komm ich wieder und mach 2 Wochen Chaos und dann bin ich wieder weg. Sondern Mhm. Also das ist wirklich
Jan: Also
Mirko: die Abstände sind sehr viel kleiner, ne? Da schmeiß ich mal die eine Woche was dazu und dann ist mal eine Woche Pause, aber ich bin immer relativ nah dran, denke ich, ne? Dann Ja. Das ist, denke ich, eine Rahmenbedingungen, die wichtig dafür ist, ne. Und ich glaube, es gibt da sehr wenige Teams, die ich sag mal so von der von von dem Level, wie gut sie sich kennen, so nah bei oder so hoch sind, ne. Also das ist einfach unnormal. Ich hab hab Leute bei uns im Team, die kenn ich seit 10 Jahren und mit denen hab ich auch seit 10 Jahren gearbeitet, ne. Wo in welchen Teams hast 'n das, ne? Ich mein, die Leute wechseln Firmen normalerweise viel öfter oder oder oder arbeiten noch gar nicht so lange, ne und so. Also normalerweise hast Du viel größere Varianz in den Teams drin. Und dann passieren ganz andere Effekte, die man anders ausgleichen muss, ne. Oder wo man ein anderes Set-up schaffen muss, dass das funktioniert.
Dennis: Im gewissen Stolz dürfen wir ja sagen, dass das bei uns auch relativ oft so ist, dass wir schon mit mit vielen sehr lange zu Art zusammenarbeiten.
Mirko: Das macht's einfacher. 6 von 15, die
Dennis: seit über 10 Jahren dabei sind. Mhm.
Mirko: Das ist auch schon 6 von 15. Viel, ja.
Jan: Das macht's an vielen Stellen, glaub ich, einfach. Es macht's auch an anderen Stellen dafür schwer, weil natürlich die paar Leute, die doch ab und zu dazukommen, natürlich auf 'n sehr anderes Environment treffen, ne. Weil sich hier gerade gesagt, schon seit dem Studium irgendwie zusammenhängen. Das ist natürlich 'n Set-up, wo's erst mal schwerfallen kann, irgendwie sich zugehörig zu fühlen, ja, oder so, ja? Grade wenn da halt schon so viele Dynamiken am Start sind. Aber weil Dennis grade meinte, unsere Leute sind auch schon alle so lange irgendwie dabei. Dennis, ist es so, ich weiß es nicht von allen, dass unsere Teamlead, also unsere Game Leads, ja, unsere unsere Product Leute immer aus den Teams rauskommen? Ich hab das jetzt nur mal so bei bei Dave natürlich gesehen, aber wie wie ist das so historisch?
Dennis: Von unseren 5 aktuellen Gameleads war es bei 4 so, dass sie aus 'ner Dev Rolle kamen. Ja.
Jan: Und da stell ich nämlich auch wieder die Frage, ne, also weil da dieser Punkt, den den Mirko nannte natürlich auch wieder reinspielt, Du hast son gewisses Standing, Du hast Vertrauen, die Leute wissen, dass Du selber was kannst in Anführungszeichen. Du hast an der Code Base irgendwie mitgearbeitet. Und gleichzeitig ist ja dieses Risiko, was wir eben angesprochen haben, mit dieser Spirale so rückfällig zu werden, nenn ich's mal, ja, natürlich besonders groß, weil Du hast ja alles schon gemacht. Also wenn jetzt halt mal jemand krank wird in deinem Team, dann dann springst Du halt mal irgendwie ein oder so was, ja. Ohne jetzt Namen zu nennen, aber kennst Du da Fälle, wo das bei uns 'n bisschen schwierig war? Nee, ich
Dennis: hab eigentlich nur Fälle, wo es, also können wir auch den Namen nennen, wo es positiv war. Also keine Ahnung, Fabi, der ja auch häufig im Podcast ist
Jan: Ja, über Fabi können wir reden, da hab ich überhaupt viel Werbung.
Dennis: Ne, der jetzt, als wir auf Unit umgestiegen sind, der letzten Monate ja viel gemacht hat, so. Aber auch genauso auch schon Phasen hatte, wo er gar nichts an Code gemacht hat, ne. Also ich glaub, der der hat 'n auch 'n ganz guten Umgang damit, dass dass, wenn es möglich ist, damit einzusteigen und zu, aber eher unterstützend das zu machen und nicht eben reinzugehen und zu sagen, hey, jetzt hab ich hier was gebaut und damit müsst ihr jetzt irgendwie umgehen und so macht man's irgendwie richtig, sondern tatsächlich dann, ja, unterstützend halt da damit mitgeholfen hat, weil das so die Prio war und zu dem Zeitpunkt vielleicht die anderen die andere Rolle nicht so nicht so viel Zeit brauchte und dafür irgendwie dann die Möglichkeit da war.
Jan: Warum ich noch mal so auf die Game Leads abgestellt hab, ist, weil ich glaube, dieses sich mal 'n bisschen zurücknehmen oder aus dem Tagesgeschäft rausnehmen, zu coden, hängt natürlich auch sehr stark an dem einzelnen Profil. Ich glaub, wir alle 3 haben sone Situation, wo wenn wir, ne, wenn Dennis, wenn Du jetzt deinen Job, deinen regulären Job morgen aufhören würdest für eine Woche, würde es sehr lange dauern, bis es auffällt. Nicht, weil Du sonst weil Du nix arbeitest, sondern weil die Arbeit, die Du machst, halt sehr indirekt ist.
Mirko: Mhm.
Jan: Und bis sich quasi auswirkt, dass sie nicht mehr stattfindet, dauert es einfach sehr lange. Und deshalb ist es natürlich da einfacher, wenn auch nicht ungefährlich, das zu tun. Wohingegen es, glaube ich, bei 'nem Teamlead, Gamelead, Product, Mensch, wie auch immer es in unterschiedlichen Firmen heißt, ja 'n 'n viel akuterer Effekt ist, wenn weniger Zeit angewandt wird, den nächsten Monat direkt fortzuplanen, zu gucken, was sind die nächsten Features, die wir uns anschauen wollen, mit den Designern zu sprechen et cetera et cetera. Da ist ja da die die Wirkung viel direkter.
Dennis: Das stimmt, aber deswegen ist es, glaube ich, auch bei uns so gewesen, dass seltener die Versuchung war. Also weil einfach die die Rolle des Gamies dann so ausfüllend war, dass da dass da gar nicht die Kapazitäten war, noch darüber nachzudenken, selbst irgendwas umzusetzen davon. Wo es natürlich mega hilft und da haben wir ja auch am Anfang schon drüber gesprochen, son bisschen diese Erfahrung zu haben. Also ich glaube, das ist einfach, ich mein, wir sind in Summe ein sehr technisches Unternehmen. Das heißt, auch all die Bereiche, die jetzt gar nicht mit der tatsächlichen irgendwie Spieleentwicklung zu tun haben, sind trotzdem irgendwie sehr nah, also sehr technikaffin so. Und ich glaube, das hilft in dieser Rolle genauso. Einmal natürlich das das Team einzuschätzen, das Team zu unterstützen, vielleicht auch mal für eine Auswertung oder was auch immer, halt selbst das machen zu können, so und nicht immer abhängig zu sein von, ne, irgendwie anderen Sachen, mal was im Code einfach nachgucken zu können, wie ist es denn implementiert? Also da gibt's schon sehr viele Synergien, die man nutzen kann. Aber ja, in dem konkreten Fall bei uns, glaube ich, ist es halt, lässt lässt die Arbeit das, also lässt der die Arbeit, die man hat, ist gar nicht zu, da noch groß rückfällig zu werden und und und wieder zu entwickeln.
Jan: Das cool, aber ich hab selber schon Teams erlebt, wo das tatsächlich son Problem war, ja, wo dann Teamleads zu mir gekommen sind und hab ich mir mal, hey, Mitarbeiter x y ist grade krank, aber ich hab jetzt einfach seine Tickets hier noch mal so mitgemacht. Ich sag, nein, da darf dafür bist Du halt nicht da. So ist schön, dass Du das machen willst, aber Du hast ganz andere Aufgaben, die halt mindestens genauso wichtig sind. Und die kann keiner übernehmen, wenn Du wegfällst, ne. Wenn im Team 'n Entwickler krank ist, gibt's im Idealfall noch andere Entwicklerinnen, die einspringen können. Aber es gibt den den Teamlead halt irgendwie nur einmal, so. Und das ist, glaub ich, auch was, was viele erst mal lernen müssen und was ja auch immer akuter wird, je weiter hoch in Anführungszeichen man man sich so arbeitet, weil das ja auch son angenehmer und unangenehmer Nebeneffekt. Je weiter oben Du bist, desto weniger Leute hast Du, die dir auf die Finger schauen und die son bisschen eine Peergroup für dich sein können und vielleicht auch mal son bisschen eine korrigierende Wirkung haben können. Und wenn man da, glaube ich, son paar Sachen nicht früh genug lernt, dann tut man sich sehr schwer später. Aber ist ja schön, dass offensichtlich die Leute bei uns das schon schon verstanden haben.
Mirko: Ja, nee, ich hab noch eine ganz schräge Motivation dafür, rauszukommen aus dieser Versuchung, was zu programmieren oder sich da Jetzt mal manchmal zu lassen. Ich hab einfach es oft erlebt, dass wir uns als Teams bei Kunden oder egal irgendwo oder die Teams bei Kunden, sich so tief in irgendwelche technischen Geschichten reingebuddelt haben und Dinge gebaut haben, die niemand gebraucht hat, dass ich dass ich 'n Frust aufgebaut hab dagegen. Also wenn Du wenn Du so das drei-, viermal erlebt hast, dass Leute wirklich substanziell Zeit in irgendwas investiert haben Und mit substanziell meine ich jetzt irgendwie mal paar Monate, ne. So Team 5, 10 Leute, bauen 'n paar Monate was. Und danach kommt's komplett in die Tonne, ne. Dann sagst Du beim ersten Mal so, okay, dumm gelaufen, ne, passiert. Beim zweiten Mal denkst Du so, ah, wieder dumm gelaufen. Aber ich hab das über die 13 Jahre, mittlerweile hab ich das eben öfter als zwei- oder dreimal erlebt, ne. Und dann denkst Du so, okay, bevor wir hier wieder irgendwas bauen, was niemand braucht und das in die Tonne klopfen, dann wird es, da kommt so viel Frust her. Lasst uns lieber erst mal überlegen, lasst uns Discovery machen, lasst uns mit Kunden reden, ne. Lass uns vorher überlegen, wie können wir das erst mal mini mit minimalem technischen Aufwand machen, bevor wir irgendwie 'n Monster wieder erschaffen, ne. Und also deswegen, sag ich, das ist 'n schräger Grund sozusagen. Die Angst vor dieser Frustration, dass so was wieder passiert, die nehm ich dann manchmal her als Motivation, Produktarbeit zum Beispiel zu machen und mit Kunden zu reden oder Dinge kleiner zu denken, ah, wenn's technisch vielleicht noch viel geiler und besser und schneller und größer geht, ne. Aber das ist sone persönliche Erfahrung, die ich gemacht hab über die Jahre, die mir wirklich wehgetan hat. Und ich beobachte das auch bei anderen. Da kannst Du genau angucken, wie oft die diese Situation erlebt haben, wie die da drauf reagieren, wenn die sagen, na ja, wart aufgelaufen. Dann weißt Du genau, okay, da hat das weniger als dreimal erlebt bis jetzt,
Jan: ne. Was, ist, glaube ich, auch sone sone allgemeingültige Weisheit, dass bei son bei son gewissen Reifegrad muss man einfach auch 'n paar Mal auf die Fresse gefallen sein. So, weil wenn man halt immer nur erfolgsverwöhnt war, egal ob durch eigene Arbeit oder einfach nur durch gute Umstände einen herum, kann man, glaub ich, son paar Sachen überhaupt gar nicht gelernt haben.
Mirko: Es geht schneller auf jeden Fall, wenn man mal hinfliegt.
Jan: Es brennt sich besser ein. Ja. Ja. Okay, ich hab zum Abschluss, oh, Dennis hat noch was anderes. Dennis darf zuerst.
Dennis: Ja, ich hatte kurz Entschuldigung, diese philosophische Frage ein, aber ich eingehe, weil gefühlt ich zu selten in meinem Leben auf die auf die Chance gefallen bin, dass ich irgendwie immer Echt? Mit mit relativ wenig also Aufwand immer durchgekommen bin. Also beispielsweise in der Schule so, ne. Ich hab ich hab das Minimum gemacht. Die Schule war superangenehm für mich, aber irgendwie, ich erinnere mich in eine, fast nicht wirklich klasse, das war, wenn man eine Lehrerin extra statt 'ner 1 minus einfach eine 2 Plus gegeben, weil sie gesagt hat so, ne, Du Du könntest dich 'n bisschen anstrengen so und dann dann hättest Du das so. Das war einfach nur son Demonstrationszweck und und trotzdem gab's nie so richtig den Moment, wo ja, ich da mal wirklich Schaden genommen hab, zu sagen, okay, ich muss daran was ändern. Und manchmal denke ich, aber ich wollte eigentlich gar nicht auf die Philosophie so, ich wollt da gar nicht drauf eingehen. Ich wollte eigentlich
Mirko: Jetzt hat er angefangen, jetzt
Dennis: Ja, ja. Und und manchmal denk ich so, es wär schon irgendwo, also wie ihr auch schafft so, wär schon auch nicht schlecht, das manchmal zu auch einfach irgendwie da noch mehr das Learning raus. Weil sonst fühlt man sich auch manchmal son bisschen halt in 'nem Luft, also weißt Du, als ob da praktischer kein Feedback ist. So, das läuft irgendwie und das geht irgendwie weiter. Und ja, irgendwie alle, ne, ist auch zufrieden, so, alles gut. Aber son Moment so dann zu realisieren, okay, das war richtig, das hat gar nicht funktioniert, das schadet schon nicht und gibt einem schon wahrscheinlich irgendwas. Und hab ich noch nicht so oft gehabt.
Jan: Ja, also ich mein, es es ist ja natürlich fraglich, ob man, also wie sehr man mit der Nase wirklich den Boden berühren muss, ja? Oder ob nicht einfach nur reicht, schon so zu sehen, oh, das hätte auch irgendwie ganz anders laufen können. Ist jetzt noch mal gut gegangen, aber das war ehrlicherweise nicht nur so mein Verdienst, sondern auch 'n bisschen glücklicher Umstand und man kann ja trotzdem was rausnehmen, ja? Und ich glaube, solang man irgendwie noch reflektiert genug ist, das zu erkennen und nicht einfach immer nur zu denken so, boah, mir ist noch nie was passiert, ich bin der absolute Überflieger, ja, dann kannst Du auch noch was mitnehmen.
Dennis: Ich wollte Mirke noch mal kurz fragen, was was deine Meinung ist, weil in eurem Setting, das vielleicht ja auch 'n bisschen, wenn Du so Teams außerhalb von von euch sieht, besonders ist in 'ner gewissen Weise und wo Du sagst so, dass da funktioniert es, dass Du auch phasenweise mehr und weniger machen kannst. Hast Du eine generelle Einschätzung, wenn Du draußen Teams siehst und wie Headoffs oder CTOs irgendwie damit umgehen, dass Du eher sagen würdest, Du hättest eher die Empfehlung, dass sie weiter weg von der Codebasis bleiben oder dass es gut ist, dass sie damit rumfuhrwerkeln?
Mirko: Das ist eine gute Frage, muss ich erst mal drüber nachdenken. Dadran merkt man, dass es eine gute Frage ist. Ich glaube, das kommt ganz drauf an, auf diese Dynamik zwischen den Menschen, ne. Also ich glaub, das kann beides funktionieren, wenn die sich irgendwie verstehen und je nach Historie, ne. Also mir fällt's schwer da zu sagen, okay, das eine Modell ist besser als das andere, ne. Ich überleg jetzt grade, es fallen einem natürlich immer als Erstes die Set ups ein, wo's schlecht funktioniert hat, weil die sich irgendwie mehr einbrennen.
Jan: Wie ich das immer so mach? Ich beantworte gerne Fragen, die ich nicht selbst gefragt wurde.
Mirko: Danke. Ja.
Jan: Und würde mal sagen, also ich würde, glaube ich, tendenziell eher davon abraten. Zum einen ist es, glaube ich, so, wie Mirko gesagt hat, mir fallen auch mehr die negativen Beispiele ein Und zum anderen ist es zumindest in den Fällen, die ich so gesehen hab, so, dass wenn es schiefgeht, der Schaden halt exorbitant hoch sein kann und selbst wenn es gut läuft, der Netbenefit nicht herausragend gut ist. Also Mhm. Wenn Du als als CTO noch irgendwie so richtig Hands on sein kannst, Du kannst bestimmt was bewegen, aber am Ende des Tages, grade je größer die Firma wird, halt auch nicht mehr so superviel, ja? Wohingegen Du richtig viel kaputtmachen kannst. Und dann würde ich mich einfach würde ich mir einfach überlegen, okay, was ist sone Risiko- und Nutzen Abwägung? Und dann, wie gesagt, je größer die Firma, desto eher würde ich dann die die Finger davon lassen und dann halt eher überlegen, ob ich nicht 'n Outlet finde, wo ich mich halt austoben kann, was jetzt nicht unbedingt am am am Produkt irgendwie ist oder so, ja.
Dennis: Ja. Ja, wobei also, wenn ich so reflektiere viele unserer auch CTO Wäschels, die wir beispielsweise hatten in der programmier.bar, da bei vielen immer schon in den schon überrascht war, wie wie sehr, wie nah sie noch dran sind so an den Produkten, an den technischen Entscheidungen, an der Codebase sozusagen.
Jan: Ja, aber nah an der Codebase zu sein und am Code mitzuarbeiten, sind ja auch 2 unterschiedliche Dinge, ne?
Dennis: Ja, ist richtig, ja.
Jan: Also es gibt ja auch Leute und ich glaube, das ist 'n 'n 'n Skill, den man unbedingt lernen muss, ist, durch passives Konsumieren halt auch irgendwie informiert zu bleiben. Also das ist was, wo ich ehrlicherweise nicht sonderlich gut drin bin, irgendwie einfach nur alle Pull requests oder so was halt durchzulesen und mir und mein mein Mental Model so irgendwie aktuell zu halten. Ich muss halt in die Code Base reinhüpfen und mich da durchklicken und gucken und tun. Ich kann nicht mit diesen Inkrements sozusagen mein mein Mental Model aktuell halten, ja? Aber wenn Du halt jemand bist, der das kann und einfach immer mal wieder so stichprobenartig reinliest, okay, was passiert hier? In welche Richtung treiben die so die Code Base und bla bla bla, dann ist das, glaub ich, superwertvoll. Und dann kann man auch damit noch irgendwie 'n Impact haben am Ende des Tages, ohne halt selber Hand anzulegen.
Mirko: Wobei das natürlich sehr, also das ist die Tür zum Rebell, ne. Wenn Du die Commits kriegst per E-Mail oder so und dann Dinge siehst.
Jan: Also ich kann dir sagen, dass ich schon oh, ich weiß nicht, darf ich das sagen? Ich ich sag das einfach mal. Als ich noch bei Shopify gearbeitet hab, hab ich an einem, von dem ich dachte, nicht großen Feature gearbeitet an 'nem sehr basic Ruby Library. Also nicht basic im Sinne von klein, sondern basic im Sinne von viel anderes. Baut darauf auf. Und dann hab ich eine eine Slack Nachricht von dem dem CEO, also von Tobi Lütge bekommen. Hat so, hey, ich hab gesehen, Du baust da gerade an diesem Feature rum. Was hast 'n Du da so vor? Und ich hab nur so, okay, also dann dann gehen bei dir halt so alle Alarmglocken irgendwie an, ne? Wenn da irgendwie, Du weißt nicht, bei Shopify sind da so 15000 Leute und Tobi hat grade nichts anderes zu tun, als dich zu fragen, was Du mit dieser Codezeile vorhast, die er vor, weiß ich nicht, wie vielen Jahren selber geschrieben hat. Das, so meinte ich das nicht. Weil weil das, dann stürzt Du halt ganz schnell nicht nur in so dein eigenes Rabbithaul, sondern dann bist Du ja auch so, ohne da jetzt Tobi was vorwerfen zu wollen, aber das kann ja auch in Micromanagement enden. So, ja? Und da, also nicht nur verschwendest Du deine Zeit damit, sondern Du verprähst ja auch die Leute irgendwie, die Du da versuchst, Micro zu managen. Aber ja, auch so was hab ich schon erlebt. Das war eine ganz interessante Erfahrung.
Mirko: Hab ich selber so gemacht, ganz am Anfang. Hab ich dann, wenn die Commits kamen, durchgelesen. Da gibt's eine ganz legendäre Geschichte. Ich weiß nicht, ob ihr ihr ja Bauer von Entwicklerheld kennt.
Jan: Ja. Ja, der war ja auch schon bei uns im Podcast und auf der Konferenz und aufm Meetup. Der war quasi schon überall bei uns.
Mirko: Genau und der war mal Werkstudent bei uns. Und wenn dem seine Commits kamen oder alle Commits hab ich damals gelesen, war ganz am Anfang, 12 Jahre her, Dann hab ich durchs Büro gerufen, ja. Und dann wusste er, musste an meinen Schreibtisch, weil ich irgendwas gewonnen hatte, was mir nicht gefällt. Und das war bei Entwicklerheld, hab ich 10 Jahre später erfahren, jahrelang Running Gag, dass die Leute ihn durchs Büro so gerufen haben und mich nachgeahmt haben, mich diese schlechte Eigenschaft von mir kopiert haben, sich darüber lustig zu machen. War mir damals nicht so bewusst, wie doof das war, ne. Aber so genau dieser Move, ne. Und hab ich hab ich mir abgewöhnt dann. Glücklicherweise hat's mir irgendwann jemand gesagt, dass es doof ist, die Leute Also
Jan: dann ist Challenge, morgen einfach random neben irgendwelchen Leuten am Schreibtisch auftauchen, 'n bisschen skeptisch über die Schulter blicken und sie einfach hart ausm Konzept werfen. Sehr gut.
Mirko: Ja. Also war wirklich eine dumme Idee, aber muss man lernen irgendwie am Anfang.
Jan: Ja, aber also aber das ist ja das, was ich meine. Also Du hast es ja auch nicht irgendwie aus aus böse Absicht gemacht in dem Moment so einfach, weil Du halt auch versuchen willst, so am Ball zu bleiben und zu gucken, was halt irgendwie alles passiert. Und ich glaube, da muss man halt sein seinen Weg finden. Manche lesen halt gerne irgendwie Pullrequests mit, anderen reicht es irgendwie, weiß nicht, auf Ticketebene irgendwie dabei zu sein oder wo auch immer. Und das muss, glaub ich, ja, jeder muss da so sein Tooling irgendwie für haben, sich nicht abhängen zu lassen. Okay, Dennis, noch eine letzte Frage.
Dennis: Ob ich noch eine hab?
Jan: Ja. Nee.
Mirko: Okay. Dann hab ich
Jan: eine vorletzte Frage. Meine vorletzte Frage ist dir, die sonst meine letzte Frage ist. Mirko, welche Frage haben wir dich nicht gefragt? Worüber wolltest Du unbedingt noch reden? Was wolltest Du unbedingt erzählen? Und wir haben's einfach ignoriert.
Mirko: Das ist wieder eine schwierige Frage. Also ich ich find ja das Herrliche an den Podcasts, also dass ich hier reinkomm und Du uns hier einfach durchleitest oder ihr, und dass es einfach son herrliches Gespräch ist, ne? Und so also so interessant und witzig und einfach so unterhaltsam. Also es ist eine meiner Lieblingsbeschäftigungen mittlerweile, in Podcasts zu kommen und mitzureden, obwohl ich beim ersten Mal fast hier 'n Herzinfarkt hatte vor Aufregung, aber mittlerweile finde ich das so herrlich. Also die Frage, die Du hättest stellen können, ist, was machst Du am liebsten? Dann wäre meine Antwort gewesen, in Podcasts kommen und mit den Leuten reden, weil das ist einfach eine geile Beschäftigung. Könnt ich den ganzen Tag auch machen. Also wenn wenn
Jan: Ja, ja, ja, ja.
Mirko: Wenn das Marketing the tree ist, dann mach ich nur noch Marketing.
Jan: Du musst einfach auch bei der programmier.bar arbeiten, da kannst Du das den halben Tag machen.
Mirko: Ist zurecht. Okay. Ich hab 'n geilen Job.
Jan: Ja, würd ich auch sagen. Dann komm ich zu meiner letzten Frage und die hab ich für euch beide dabei. Wir haben jetzt lange darüber gesprochen, wie viel man so eigentlich am Code bleiben sollte, wie viel man eigentlich am Code bleiben will. Wenn ihr euch nach dem Gespräch noch mal so eure aktuelle Position vor Augen führt und wie ihr das so managt, wäre eure Einschätzung so, das läuft grade ganz gut oder würdet ihr das lieber in die ein oder andere Richtung ändern? Dennis darf anfangen.
Dennis: Ich bin für den Alltag eigentlich zufrieden damit und und ist, glaub ich, eher positiv, dass ich mich aus dem Tagesgeschäft sozusagen da raushalte und das in der, also dadurch eben die Verantwortung, die fachliche Verantwortung komplett an die Entwickler*innen abgebe. Der eine Randaspekt, der vielleicht noch 'n bisschen deutlicher geworden ist und ich noch mehr noch mal mitnehmen möchte, da mal auszubrechen und explizit mal das Entwickeln heute in einem unserer Teams zu erleben, das seh ich dann 'n bisschen, weißt Du? Also das ist ist ja 'n bisschen getrennt. Da würde ich ja praktisch meine Rolle für pausieren, das dann zu machen, dann vielleicht wieder 'n Benefit in meiner Rolle danach dann zu haben. Aber da dadurch würd ich so den Alltag nicht umstellen. Aber hat mich noch mal 'n bisschen mehr motiviert, den den Gedankengang noch mal weiterzudenken.
Jan: Mirko, wie sieht's bei dir aus?
Mirko: So ich persönlich bin superhappy, grade mit der Prozentzahl meiner Zeit, die ich mit Programmieren verbringe. Aber das Gespräch hat mich auf eine Idee gebracht oder eine Frage aufgeworfen. Ich glaube, ich muss die anderen mal fragen, wie die das finden, ne.
Jan: Weil Du Fair, ja.
Mirko: Weil Du hast so Du hast so diese Situation und dann kommt hier der rein und der schmeißt hier son Feature rein und so. Und und die anderen müssen sich drum kümmern. Das ist schon was, was ich gerne mache, ne. Und ich glaube, ich muss mal gucken, wie das so ankommt. Ich weiß noch nicht, wie ich das rausfinde. Muss ich irgendwie heimlich geschickt fragen irgendwie oder
Dennis: Soll ich den Podcast empfehlen?
Mirko: Aber das ist son Gedanke, der mir gekommen ist, dass dass das eigentlich wichtiger ist als wie gut's mir geht damit, die Features reinzuschmeißen. Ist eher die Frage, wie gut geht's den anderen, die die hier abkriegen und sich drum kümmern müssen, ne? Das wär schon mal irgendwie, ne, mir eine Strategie überlegen, wie ich das rausfinde, eine ehrliche Antwort darauf zu kriegen.
Jan: Das ist das ist 'n sehr schöner Punkt und das bringt mich auf eine allerletzte Frage. Wenn jetzt jemand grade erst in diesem Findungsprozess ist, weil er vielleicht von der klassischen Entwicklerrolle hin zu 'nem Teamlead oder irgendwo mit mehr Verantwortung hinbefördert wurde, was wär so der eine Tipp, der eine Hinweis, den ihr da mitgeben würdet? Weil Mirko grade dran war, darf er weitermachen.
Mirko: Na ja, diese Rolle oder diese Rollen, wo die Leute dann reinwachsen oder hinbefördert werden, je nachdem. Ich glaub, der maßgebliche Unterschied oder ein großer Unterschied ist, Du musst dich viel mehr mit den Menschen auseinandersetzen, ne. Als Programmierer kann ich unter Umständen, es ist nicht ideal, aber ich kann relativ viel Zeit alleine hinter 3 Monitoren verbringen, ne. Und ich kann gute Arbeit machen, ich kann Tickets abarbeiten, auch wenn ich vielleicht sozial wenig Kontakte pflege oder so was. Es ist, es wäre besser, wenn ich's täte, aber ich kann einen guten Job machen. In den Positionen oben drüber ist es schwierig, 'n guten Job zu machen, wenn Du, ich sag mal, 'n Problem hast, mit Menschen umzugehen oder oder es dir schwerfällt ist, in eine andere hineinzuversetzen, eine Perspektive zu wechseln oder zu überlegen, warum fällt die Person sich so, ne. Und ich denke, das ist was, was den Leuten bewusst sein muss, die dahin befördert werden. Es muss auch den Leuten bewusst sein, die die Leute dahin befördern. Es passiert nämlich oft genug, dass, ich sag mal, der ist supertaggy, der alles weiß, in sone Position kommt und dann komplett überfordert ist, weil's auf einmal nur noch drum geht, Menschen zu motivieren oder zu steuern oder sich überhaupt mit ihnen auseinanderzusetzen, ne. Und ich glaube, das muss allen bewusst sein, dass das, wenn es nach oben geht, viel mit Empathie zu tun hat, viel mit Perspektivwechsel, viel mit sich miteinander reden, ne. Ist ja son Ding, ne, was vielleicht manche Leute ungern machen. Und das ist das ist der Tipp, das einfach zu machen, aber da kann man, also da kann man ja superviel draus schöpfen, ne. Also wenn man das aufbaut, diese Fähigkeiten mit Menschen umzugehen, zusätzlich zu dem ganzen Technologiewissen, ne. Und das dann kombinieren kann. Also das ist einfach, das multipliziert sich, sag ich mal. Das addiert sich nicht, diese Fähigkeiten, ne.
Jan: Wunderbar. Dennis, dein Tipp.
Dennis: Zum einen wär's mir, glaub ich, an der Stelle wichtig zu sagen, dass aus aus meiner Sicht es eigentlich nicht nicht richtig ist, das Wort Förderung zu nutzen oder nach oben, weil für mich ist es tatsächlich eigentlich eine eine parallele Entwicklung und das ist leider eine Sache, die die oft falsch interpretiert wird. Das heißt, wenn ich irgendwie Karriere machen möchte, dass ich dann diese Dinge mit übernehmen muss. Und ich glaub, man sollte sich einfach darüber bewusst sein so, also ich fände das Mindset schön so, Du kannst genauso Karriere machen und wenn wir jetzt, keine Ahnung, viele verknüpfen halt beispielsweise das Gehalt mit Karriere so, ne. Das sollte genauso möglich sein in der Expertenrolle 1 Entwicklers, 1 als Entwicklerin, wie es auch ist von von jemandem, der dann anfängt, das Management zu machen, dass das nicht dadurch getrieben ist. Also ne, dass deine Motivation nicht ist, oh, ich will die Karriere machen, okay, dann nehme ich das noch mit, sondern Du musst eine intrinsische Motivation haben. Ja. Und das, was Mirko gesagt hat, dich mit Leuten auseinanderzusetzen und mit den diesen diesen Themen auseinanderzusetzen. Und ja, damit eigentlich, also wenn Du da genug Spaß dran hast, dann bist Du auch bereit, irgendwie das Kunden, ne, beiseite oder zu, zum Teil beiseitezulegen. Dann ist es nicht mehr so der große Konflikt, wie ich, wie's vielleicht ist, wenn das praktisch son bisschen aufgezogen wird. Also ich glaube wirklich, dass das ist essenziell, dass Du diesen anderen Aufgabenbereich, der es ist, nicht einfach so, okay, ja, es ist irgendwo der der weitere Fahrt und das muss ich halt jetzt dann zumachen, sondern dass Du darauf Lust hast. Und dann fällt es dir auch einfacher, diesen Weg zu gehen.
Jan: Das ist doch ein schönes Schlusswort, wenn es denn unser Schluss schon wäre, aber wir haben immer noch, Dennis, was kommt noch?
Dennis: The.
Jan: Und weil ich es schamlos ausnutze, dass Dennis seine Hausaufgaben gemacht hat, darf er anfangen. Oder er hat sie nicht gemacht, Plottwist. Ich weiß nicht, was jetzt passiert.
Dennis: Na ja, Hausaufgaben. Sagen wir mal so, während der Folge kam mir kam mir die Idee. Nein, ich hatte am Anfang der Folge haben wir gut, hast Du kurz abgefragt, der hatte ich 'n anderen im Sinn. Ich hab parallel noch mal gesucht auf unserer programmier.bar Webseite, ob's den schon gab und ich hab vorher erschrecken festgestellt, dass es noch kein Pick war. Deswegen wähle ich Notebook l m von Google.
Mirko: Das hat noch niemand gepickt?
Dennis: Das hat mich auch gewundert, dass wir's Also wir haben uns mit Sicherheit mal gesprochen hier und da, aber es ist eben noch kein Pick gewesen und deswegen mach ich das einfach mal. Wer Notebook l m nicht kennt, das ist ein Recherchetool, nenn ich's jetzt mal von Google, wo man mit einem LLM als Hilfe eigene Quellen da reinwerfen kann und dann eben nur auf diesen Quellen und nicht noch zusätzlichen Wissen und Dingen, die sich das LDL dazurahmt, sondern rein auf diesen Quellen basiert chatten kann, aber eben auch mittlerweile durch Nano Banana Pro und andere Tools, ganz viel andere so sofort Actions bekommen. Ich kann mir 'n Podcast generieren lassen, ich kann mir 'n Slidesk generieren lassen, ich kann mir 'n Infovideo generieren lassen, also alle möglichen Interaktionen, was halt superangenehm ist, sich neue Themenfelder zu arbeiten. Ich hab's jetzt erstmalig, ich weiß auch, warum gar nicht, warum erstmalig genutzt für eine Vorbereitung im im Podcast, wo ich's einfach dann ein Thema genommen hab. Du kannst so im ersten Schritt 'n Deep Research machen, wo dann alle möglichen Internetquellen dazu genommen werden. Die werden da reingepackt und dann darauf basierend, die erklären. Also das ist son Ding, wenn ich da an das Studium zurückdenke, das ist ja also unfassbar, was das so ermöglicht hätte im im im Studienkontext. Aber eben auch heute, wenn man sich mal 'n bisschen tiefer mit einem Thema beschäftigen möchte. Vielleicht 'n andere anderes Praxisbeispiel noch. Wir haben bei Lotum sogenannte Cliffon strengt, das son, wie nennt man das, Charaktertest, wie auch immer oder Stärken, also wo man die unterschiedliche Stärken rausfinden kann durch son Assessment. Und da hab ich dann auch einfach alle möglichen Ressourcen reingepackt und in, wo wir jetzt über diese Stärken sprechen, mir jeweils vorher einfach generieren lassen, hey, sag mal, was die Person auszeichnet, wo die Kombinationen aus Stärken sind, einfach sonen Überblick zu bekommen. Ja, was was superhilfreich ist, das einfach so als weitere Quelle dann dort zu haben, was sehr individuell individuell auf dem basiert, was dort einfach vorgegeben ist.
Jan: Lifehack hab ich bei 'nem Bekannten gesehen, der hat die gesamte Dokumentation und alle Anleitungen von den Einzelgeräten von seinem Smarthome in Notebook l m geschmissen, dann quasi jederzeit sagen zu können, so hey hier, wenn ich die Heizung automatisieren will, dass sie dieses und jenes macht, wie muss ich in Home Assistant welche Geräte ansprechen und bla und und mach mal so. Ja. Na, entzetzt gut. Cool. Einmal Notebook l m, hätt ich auch nicht gedacht, dass das noch nie da war. Verrückt. Dann würd ich sagen, schließ ich mich einfach mal kurz hier rein, weil ich hab auch was von Google dabei, ohne dass Dennis und ich uns abgesprochen haben. Aber ich hab Stitch mitgebracht von Google, was, glaub ich, die wenigsten da draußen kennen, weil das son bisschen irgendwie untergegangen ist, ähnlich wie Notebook l m am Anfang. Und Stitch ist son Tool, schöne EUIs mithilfe von AI bauen zu können, weil unser 1 codelt ja gerne ab und zu mal, aber ich bin ultraschlecht in Designer. Ich hab wirklich 3 linke Hände, was irgendwie Pixelschubsen angeht. Und deswegen, als wir jetzt neulich das neue Analytics Dashboard für die programmier.bar gebaut haben, bin ich auch zu Stitch gegangen, hab gesagt, hey, ich brauch hier son schönes Dashboard. Das sind die Art von Charts, die ich irgendwie darstellen will. Und Du kannst ihm dann so mäßig quasi vorher was zusammenbauen und sagen so, das ist unsere aktuelle Webseite, damit Du das CI 'n bisschen verstehst. Das ist 'n bisschen, wo ich hinwill, das sind Beispiele, bla. Und dann baut er dir quasi son son drauf daraus zusammen und Du kannst dann daran mit ihm son bisschen interieren, kannst ähnlich wie 'n Figma Kommentare dranhängen, irgendwie Bereiche heihlighten und markieren, Kommentare dazu hinterlassen und dann quasi noch mal versuchen lassen und so. Kriegst das Ergebnis dann einmal als Bild und einmal als HTML. Ich hab dann das beides im Prinzip genommen und zur Cloud hingeschmissen und gesagt, hey, machen wir mal 'n UI Komponentensystem irgendwie da draus, das verwenden kann. Und das war irgendwie ganz cool. Also stitch with Google dot com. Kann man benutzen, ist auch kostenfrei, nutzt auch Gemini und Nanobanana hintendran. Ja, mega mega cool. Und zweiter Pick des Tages heute, weil ich's heut schon mal gesagt hab, muss ich's natürlich auch machen, das Video zu wie lange dauert es, einen roten Button in unsere Anwendung einzubauen von Mirko. Das sei hier auch noch mal empfohlen. Wir verlinken das auch noch mal. Das ist mein mein Lieblingsvideo Mirko aus der Gesamtpreis. Also ich mein, ich weiß nicht, ob ich die alle gesehen hab. Ich bin ja auch erst seit 'n paar Jahren mit dabei. Ich weiß nicht, wie lange's die Videos schon gibt. Aber das ist mein Highlight und ich muss sagen, ich feier den Sales Guy immer am meisten.
Mirko: Das ist sehr schön. Sehr schön. Ich kann dir ja mal eine 'n Tipp machen mit allen, dass Du nichts verpasst, Jan.
Jan: Wunderbar. Dann Mirko, was ist dein Pick of the day?
Mirko: Ja, ich hab was ganz anderes mitgebracht. Ihr habt ja hier Tools und so, ne. Ich hab hier ganz altmodisch 'n Buch mitgebracht. Alles erlaubt. Streng genommen nicht der Pick of the day, sondern der Pick of the yesterday oder der day bevor yesterday. Bei uns kriegt nämlich jeder 'n Buch zum Geburtstag geschenkt in der Firma, los den Tag, das Buch zu lesen, ne.
Jan: Mhm.
Mirko: Und das Buch, was ich dieses Jahr bekommen hab, heißt Alchemie oder Ayseie auf Deutsch von Rory Soverland. Und das ist son Typ, den habt ihr vielleicht schon mal gesehen. Dennis auf Youtube, auf TikTok hast den sicher schon mal gesehen, der macht auch Videos da. Und der hat so die Idee oder darum geht's in dem Buch sozusagen, ich sag mal, Psychologie zu benutzen, Probleme zu lösen. Ganz einfaches Beispiel, irgendwo ging's drum, irgend eine Zuglinie. Wie kriegen wir die schneller, damit die Leute schneller von a nach b kommen, ne? Und das hätte irgendwie, keine Ahnung, 'n paar Millionen gekostet, neue Gleise zu legen und so, ne? Und er sagt eben, den gleichen Effekt kannst Du haben, indem Du einfach, ich sag mal, Fernseher in die Züge einbaust, dass die Leute Unterhaltung haben, während sie fahren. Und dann kommt ihnen die Zeit kürzer vor, die sie unterwegs sind, ne? Und entscheidend für die Experience, die Du hast, ist, wie wie's dir vorkommt. Es ist nicht entscheidend, ob's 2 Stunden dauert oder 3 Stunden. Es ist entscheidend, wie dir diese 2 oder 3 Stunden vorkommen, ne? Und in dem Buch geht's ganz viel darum, wie das ganz viele Geschichten, wo das in der Vergangenheit angewendet wurde, irgendwie 'n ganz großes Thema ist, zum Beispiel Fischnamen. Fischer haben irgendwie immer ganz hässliche Namen, so Namen, wo die niemand essen will, ne. Und die Fischindustrie ist dafür bekannt, die umzubenennen und sich irgendwelche Fantasienamen auszudenken, ne. Seelachs ganz bekannt, ne, damit sich diese Fische verkaufen. Ach, son Tritt, ne, der löst das Problem, ich krieg die Fische nicht los oder so. Und und ich find das insofern ganz interessant, weil es es ist komplementär zu dem, was wir Techies immer machen. Wir versuchen nämlich, Probleme überhaupt nicht mit Psychologie zu lösen, sondern wir versuchen sie mit Technik zu lösen, ne. Und wenn jemand kommt und sagt, der hat ein Problem, dann ist ne. Aber das zu hinterfragen, ob der überhaupt eine Software braucht, derjenige oder wie die aussehen muss oder ob vielleicht Excel völlig ausreicht für dafür, ne. Ne. Diese Frage stellen wir uns irgendwie vom Natur aus viel zu wenig, ne. Und deswegen find ich das Buch supercool, weil da ganz viele Beispiele drin sind, wo halt son anderes Denken, son, ich sag mal, son anderer Blick auf das Problem auch die Lösung komplett verändert und viel einfacher macht und viel billiger, einfacher und so. Oder oder überhaupt möglich, ne. Und das ist mein Pick of the day, kann ich bloß empfehlen, das Buch. Oder oder den Autor Hurry Suffarent, der gibt auch Ted Talks und so was. Superunterhaltsam, super leicht zu lesen und man lernt was, was einem hilft von dieser Perspektive. Ich die Software, die von mir jetzt gebaut wird, löst das Problem, bissel wegzukommen.
Jan: Also ich ich muss sagen, für mich ist grade sone Welt zusammengebrochen, weil ich wusste nicht, dass Seelachs nur son Kunstname ist. Und ich hab das grade parallel gegoogelt und das ist ja erschreckend. Also nicht nur, dass der Seelachs nicht Seelachs heißt, sondern er ist nicht mal Lachs. Ja. Das ist ja quasi Betrug in jeglicher Dimension. Ja.
Mirko: Und wenn Du das Buch liest, wirst Du sehen, dass es noch an 1000 anderen Stellen auch noch gemacht wurde und funktioniert hat.
Jan: Ja, ich weiß nicht, ob ich das Buch lesen will. Ja, also ich weiß nicht, ob Du mir das grade besser oder schlechter verkauft hast, ja. Ist ja abgefahren. Ja. Okay. Also Cliffhanger, alle müssen das Buch lesen und rausfinden, was noch überhaupt alles gar nicht stimmt so. Cool. Dann danke dir Mirko für diesen Tipp. Ich bin schon sehr gespannt. Ich glaub, ich werd mir das auch mal geben. Mindestens auf TikTok. Oh,
Mirko: ich gerne.
Jan: Wenn nicht vielleicht sogar das Buch. Ich danke euch für die Zeit und das Gespräch hier. Wenn ihr da draußen noch Fragen, Anregungen, Kritik, was auch immer habt, dann immer gerne an Podcast at Programmier ier Punkt bar oder ihr kommt zu uns auf den Discord Server. Oder ihr hinterlasst uns Kommentare auf einem der, weiß ich nicht, unzähligen Social Media Kanäle, wo wir mittlerweile schon aktiv sind. Und dann lesen wir das auch alles gerne fleißig mit. Mehr bleibt mir nicht zu sagen, außer 1000 Tag euch beiden. Tschüs und bis zum nächsten Mal. Tschau, tschau.
Dennis: Danke dir Mirko.
Mirko: Tschau, vielen Dank.
Dennis: Macht's gut.

Manager und Coding mit Mirko Seifert

Shownotes

Picks of the Day

NotebookLM

Stitch

„Alchemy“ von Rory Sutherland

Speaker Info

Mirko Seifert