Vertrauen.

Hallo lieber Kay und ein herzliches Willkommen an alle da draußen.

Wir nehmen noch ganz schnell eine Folge auf, bevor ich morgen in den Urlaub entschwinde und haben uns da eine schöne Folge rausgesucht. Aber Kay, bist du überhaupt da? Ich bin da. Hallo. Ja, und auch hallo an die lieben Mittrinkenden hier in unserer kleinen Kaffee-Runde. Genau, wir sind... Kaffee hast du gesagt? Kaffee. Ah, okay. In unserer Web-Kaffee-Runde. Ah, genau. Okay, okay, da gehe ich mit. Ich habe nämlich heute einen Tee. Wir sind ja an einem virtuellen Tisch, schauen aus dem Fenster in das fröhliche Herbstwetter. Ja, Kaffee ist ja auch erlaubt. Ich habe gestern das erste Mal in meinem Leben, glaube ich,

vier Espressi getrunken, also einen doppelten und zwei einfache, weil ein guter Freund von mir jetzt eine Lama Soko Kaffeemaschine hat, also eine Espresso-Maschine. Ich weiß nicht, ob dir das was sagt. Nee. Gilt so, würde ich jetzt mal sagen, als der Rolls Royce unter den Espresso-Maschinen, unter den Siebträgern. Und ich weiß jetzt nicht, ob das den Espresso besser macht. Der hat natürlich auch klasse Boden da und beschäftigt sich sehr damit. Aber insgesamt war das schon ein Erlebnis, das muss ich sagen. Und du hast den puren Espresso getrunken oder mit irgendwas gestreckt? In allen Formen und Farben. Also erst ein Cappuccino, doppelter Espresso drin,

dann mit ein bisschen Zucker und dann auch als ganz puren Espresso. Und wie hat dir das geschmeckt? Ja, also ich habe hin und wieder schon sehr gute Espressi getrunken. Ja, das ist ja wie mit allen Genusssachen so. Das ist ja beim Tee genau das Gleiche. Wenn man dazu eine Geschichte erzählen kann, wenn das was Besonderes ist. Der hatte dann auch eine Bohne da, die unten aus dem Allgäu, glaube ich war es, kam. Von einer kleinen Rösterei und so. Und wenn man diese Geschichten einfach erzählen kann, wo diese Bohne auch herkommen, wie er darauf gekommen ist. Und dann die Maschine mit ihrer Wertigkeit da sieht und wie die Crema dann da rausläuft.

Also kurz um, der Espresso hat nicht geschmeckt? Er hat fantastisch geschmeckt. Okay, okay. Na gut, ich lasse dir das mal durchgehen. Kay, wir versuchen heute nochmal auf die Schnelle einen Podcast aufzunehmen und haben uns deswegen ein Thema rausgesucht, wo wir beide dachten, wir müssten nicht so viel vorbereiten. Bevor wir jetzt vielleicht über gestern reden, wollen wir noch sagen, was wir heute trinken? Ja, natürlich. Die Kurve wollte ich noch machen. Ach so, Entschuldigung. Ich bin ganz aufgeregt. Ich scharre hier schon mit den Füßen. Ey, ey, ich merke das schon. Wir sind beide total im Stress hier.

Oh, shit. Jetzt habe ich es direkt... Also ich war im Urlaub, würde ich damit sagen. Und da haben wir maßlos überteuerten Tee gekauft. Aber jetzt bin ich wieder total im Game und habe hier vor mir ein Pumpkin Spiced Tea mit Kardamom, Kürbis, Zimt, Ingwer, Pfeffer und Lakritz. Und nicht nur das, sondern ich habe auch extra einen neuen Tee-Cappuccino-Porzellankändchen

mitsamt Untersetzer geholt. Hast du neu erworben? Neu erworben, genau. Also das hat mich überzeugt mit so einem Tigermuster. Also beige, so ein beiger Sandton mit so schwarzen Punkten drauf. Alles ganz großartig. Ich habe ein Foto gemacht. Vielleicht kann ich jetzt auch mal in den Shownotes damit angeben. Ja, das packen wir auf jeden Fall rein. Dann nehme ich jetzt mal einen genüsslichen Schluck, während du erzählst, was du denn so hast. Aber Pumpkin hört sich so nach Halloween an. Das ist ja vorbei. Boah! Junge, Junge. Okay, den habe ich vielleicht ein bisschen zu lange ziehen lassen mit dem Ingwer. Der schiebt die Nasen nebenhöhlen frei, sage ich mal.

Ja, das ist doch gut. Du hast doch gesagt, du wärst ein bisschen verschnupft. Ja, das stimmt. Jetzt nicht mehr. Was hast du gesagt? Entschuldigung? Ich habe gesagt, das hört sich nach dem Halloween-Tee an mit dem Pumpkin. Also ich habe ihn zu Halloween gekauft. Zählt das vielleicht auch? Na gut, das zählt. Das lässt sich durchgehen. Ich habe einen grünen Tee dabei. Ich habe ja jetzt schon 20 Tees, 20 verschiedene Tees mitgebracht und habe so langsam meine Lieblingssorten durch. Und jetzt muss ich wirklich immer länger in die Teeschublade gucken, was es da noch so in den verstaubten hinteren Ecken gibt.

Und jetzt habe ich einen grünen Tee rausgezogen und das wird ja in China ganz viel getrunken. Ich glaube, 70 Prozent der Tees, die in China angebaut werden, sind dann grüne Tees. Wobei die Pflanze, glaube ich, sogar, gibt es verschiedene Sorten, aber es ist, glaube ich, sogar die ähnliche Pflanze, die dahinter ist, aber dann als grüner Tee hinterher verarbeitet. Dann geht es ja darum, ob man das fermentieren lässt und röstet und so weiter und so fort. Da bin ich jetzt nicht so ganz drin, aber so in der Richtung. Jedenfalls habe ich jetzt hier einen grünen Tee und habe direkt erstmal alles falsch gemacht,

weil ich ihn mit kochendem Wasser übergossen habe. Und dann im Nachgang, Lars, man darf da nur 70 Grad heißes Wasser drauf schütten. Deswegen kann ich jetzt nicht sagen, ob ich hier das volle Geschmackserlebnis habe. Und angeblich habe ich auch einen Haufen Vitamin C gekillt, das da sonst drin sein soll. Aber ich probiere ihn jetzt hier live und direkt. Ist natürlich ein Tee, den man jetzt ohne Zucker, ohne Milch trinkt. Und deswegen natürlich was ganz anderes als das, was ich sonst trinke. Aber wenn ich den so trinke, verstehe ich schon, warum Leute das gerne trinken, weil das natürlich insgesamt ein sehr, sehr stimmiges, leckeres Getränk ist.

Gefällt mir schon auch ganz gut. Das freut mich. Felix, weißt du, was mir letztens eingefallen ist, als ich so über Halloween nachgedacht habe? Hört sich gruselig an. Die ganzen Kinder, die bei dir im Hintergrund geklingelt haben während unserer ersten Podcast-Aufnahme vor einem Jahr. Da habe ich mich tatsächlich an Halloween auch wieder daran erinnert. Hier war was los. Wir wohnen ja in so einem Neubaugebiet. Und ich glaube, ich übertreibe nicht, wenn ich sage, dass hier 30 verschiedene Kindergruppen geklingelt haben. Und genau wie du sagst, der erste Podcast, den wir aufgenommen haben, oder der erste Versuch des Podcast-Aufnehmens war nämlich genau vor einem Jahr am 31. Oktober.

Und im Hintergrund hörte man immer alle Kinder klingeln. Und wir haben uns dann am Ende nicht nur deshalb dafür entschieden, das ganze Ding nochmal aufzunehmen. Aber tatsächlich, das war der Startschuss. Das heißt, brutto haben wir jetzt Geburtstag. Netto ist natürlich der erste Podcast sehr viel später rausgekommen und dann auch nicht so regelmäßig, dass man es, glaube ich, schon ein Jahr nennen könnte. Aber zumindest mal einen Meilenstein ist erreicht. Und das ist schon ziemlich beeindruckend für das, was wir uns im Vorfeld überlegt haben. Das stimmt. Herzlichen Glückwunsch, Kay. Ja, danke. Das ist mir gerade auch wieder eingefallen.

Aber das können wir ja gerade mal hier zelebrieren. Jetzt habe ich leider gar nichts zum... Tja, hier so einen leckeren Ingwertee. Nom, nom, nom. Ich stoße auf uns an. Ja, ich freue mich. Und ich gucke tatsächlich wirklich auch mit Freude inzwischen auf unsere ZuhörerInnen-Zahlen. Nicht, dass das jetzt unsere Hauptmetrik wäre, aber irgendwie guckt man da doch mit einem Auge immer mal drauf. PolyG gibt das ja hier wieder. Und wie genau oder ungenau das ist, kann ich nicht genau sagen. Aber es sind schon so 300 Leute und mehr, die uns im Monat hier wohl hören. Und das finde ich schon beachtlich und bringt auch eine gewisse Verantwortung mit.

Ja. Hier kein Quatsch zu erzählen. Apropos Verantwortung und Quatsch. Nee, ich finde das schön. Also ich hatte da gar nicht geplant, da jetzt hier so ein Segment draus zu machen. Aber ich finde, das ist ja auch mal eine schöne Gelegenheit, das zu würdigen, auch für uns. Aber das haben wir jetzt ja hinlänglich getan. Jetzt haben wir ganz viel vorgeblänkelt, weil die Folge selbst, glaube ich, kürzer wird. Man könnte sagen, dieses Jahr Erfahrung gibt uns jetzt viel Selbstvertrauen in die Zukunft. Ja, das stimmt. Und das ist nämlich genau unser Stichpunkt. Selbstvertrauen. Oder ich habe es sogar noch ein bisschen umbenannt.

Ich weiß nicht, wie die Folge hinterher heißen wird. Aber in unserem Skript steht Vertrauen slash Selbstvertrauen. Und Kay, ich bin auf die Folge jetzt gekommen. Wir hatten das Thema ja vorher schon mal notiert, aber jetzt ganz frisch, weil ich in der letzten Woche mit einem Programmierer sehr viel Pairing gemacht habe und habe dann gemerkt, dem geht das Selbstvertrauen manchmal in seinen eigenen Code so ein bisschen ab. Also das war alles super, was der gemacht hat. Aber er hat darüber gesprochen, als wäre er sich da ganz unsicher und wäre nicht so begeistert von seinem Code und hatte Angst, dass er nicht so cool ist.

Ja, dann habe ich so ein bisschen daran gearbeitet, ihm auch zu sagen, hey, dein Code ist gut, der ist richtig geil, den können wir so veröffentlichen. Und ich muss auch nicht bei jeder Zeile dazwischen stehen oder nicht über jede Zeile drüber gucken und habe selbst das Vertrauen, das auch so in die Welt dann rauszugeben. Und das habe ich jetzt so ein bisschen nochmal zum Anstoß genommen. Ich habe ihm tatsächlich auch gesagt, wir machen noch eine Podcast-Folge darüber. Dass es jetzt so schnell geht, hätte ich nicht gedacht. Ja, das ist ein Thema, mit dem ich eigentlich tagtäglich konfrontiert bin

mit meinen Merch-Requests, die ich mit den KollegInnen mache. Und da steckt ganz viel hinter. Und das ist natürlich aber auch ein Thema, was man sehr schwer so greifen kann. Also wir können jetzt hier in unserer Position so über Selbstvertrauen reden. Aber wenn man es eben nicht hat, ist das ein großes Problem. Und mal schauen, ob wir heute herausarbeiten können, wie man da vielleicht hinkommt zu diesem Selbstvertrauen. Und ich glaube, dass zumindest so wie ich drauf schaue, ist das ein ganz natürlicher Weg, wenn man als neuer Entwickler reinkommt in so ein Programmierungsteam, sage ich mal. Dann ist natürlich am Anfang die Hierarchie relativ klar.

Nämlich man hat selber noch gar keine Ahnung. Und vielleicht, wenn man sogar Programmierahnung hat, dann vielleicht nicht, wie jetzt hier die Abläufe im Team sind und wie so Best Practices sind und Coding Styles und sowas. Und ist dann die ganze Zeit in so einer Lehrer-Schüler-Situation eigentlich. Also man macht irgendwas und hofft, dass der Lehrer einem nicht alles rot anstreicht, weil man erstmal ganz viel lernen muss, in welcher Hinsicht auch immer. Und mit mehr Erfahrung, mit mehr Sachen, die man lernt, mit mehr Zeit, die auch verstreicht, da ist so dieses Gefälle gleicht sich immer mehr an,

bis man dann vielleicht sogar irgendwann, und das ist gar kein besonderer Punkt, aber irgendwann ist man dann höher als der andere, sage ich mal, in dieser Informationshierarchie. Und weil man sich dann mehr spezialisiert hat, weil man sich mehr mit dem Code beschäftigt hat und so weiter. Und dann hat man auf einmal das Selbstvertrauen, obwohl man es selber gar nicht weiß und könnte dann damit auch auftreten. Aber diese Schwelle muss man halt erstmal merken. Wir versuchen ja bei uns nach Möglichkeit, die Leute an dedizierte Themen dran zu setzen. Also dass sich ein Mitarbeiter, eine Mitarbeiterin

mit einem speziellen Thema beschäftigt. Das kann ein Modul in der Anwendung sein, das kann eine ganze Anwendung sein, das kann ein bestimmter Kunde sein mit mehreren Projekten. Und die Idee dahinter ist natürlich, dass diejenigen dann sich eine Expertise da drin aufbauen. Und dann ist es eigentlich nur selbstverständlich, dass sie irgendwann in diesem Teilbereich auch definitiv besser sind, als du das bist, als ich das bin, die dann hinterher über die Codes zum Beispiel drüber gucken. Genau, das ist dieses Verfahren, was ich mir eigentlich wünsche, ist, dass ich am Anfang natürlich in den Code Reviews

den Menschen noch allgemeine Best Practices beibringe, die wir hier so haben, oder allgemeine Konzepte vermitteln, so Entities, Namespace, alles schon mal so erwähnt. Und das sind einfach so ganz viele grundlegende Konzepte, die man allgemein auf gute Software anwenden kann. Aber in der perfekten Beziehung, oder so wie ich es mir wünsche, ist es dann irgendwann so, dass ich zwar diese Konzepte in Merch-Requests anmerke, weil ich sehe, oh, die wurden hier nicht befolgt. Aber die Menschen, die es dann geschrieben haben, sagen, ja, nee, Kay, weiß ich schon, hast du mir oft genug erzählt. Aber in diesem einen konkreten Fall

ist es wegen diesen und jenen und solchen Gründen total gut, das nicht so zu machen. Ich habe das schon berücksichtigt und sowas, aber ich mache das jetzt hier absichtlich nicht. Und das muss natürlich ein extremes Selbstvertrauen, das erfordert ein hohes Selbstvertrauen von den Leuten, damit sie jemandem, der vermeintlich dann vorgesetzt ist oder so, dann auch Widerworte geben können in dem Moment oder ihre eigene Entscheidung dann durchbringen können. Genau, und zumal das ja vor allem dann so ein Beziehungsverhältnis ist, in dem ich vorher die ganze Zeit den Leuten gesagt habe, was sie tun, sage ich mal vereinfacht formuliert.

Und jetzt auf einmal, so ohne ersichtliche Änderung, die sich in unserem Beziehungsverhältnis ergeben hat, ist diese Macht auf einmal umgekehrt. Also dann sagen die mir auf einmal, nee, Kay, was du da erzählst, ist Quatsch, weil das hier in dieser einen spezifischen Situation so und so ist. Genau, man muss sich also irgendwann davon emanzipieren, dass man nur noch den Tipps hinterherläuft, die man so bekommt und muss irgendwann anfangen, eben eigene Ideen einzubringen. Genauso sehe ich das auch. Ich kenne das aber auch genau andersrum, dass du hast jetzt gesagt, die Leute kommen rein und sagen, sie können noch nichts.

Das gibt es natürlich auch, dass Leute wirklich so sehr niedrig stapeln und man die wirklich aufbauen muss und denen helfen muss, denen sagen muss, guck mal, du kannst ja super viel in diesem und jedem Bereich schon, also geh damit offener um und hab da mehr Selbstvertrauen. Auf der anderen Seite gibt es aber auch Leute, die reinkommen und da war ich selbst einer von, als ich damals meine Ausbildung angefangen habe. Ich bin da reingegangen und hab gesagt, ich kann alles. Ich bin, ich hab früher immer so scherzhaft gesagt, ich bin der Gottkönig, der Coder und musste dann schnell feststellen, das war nicht der Fall.

Und eigentlich führt das aber zum gleichen Punkt. Also die Leute musst du genauso einfangen, wie die Leute, die sagen, sie können gar nichts, weil beides bestimmt meistens nicht. Und dann bringt man die auf so ein Level, wo man eine gute Zusammenarbeit hat, wo man denen auch Tipps geben kann, wo man viel vermitteln kann, bis zu dem Punkt, den du eben schon erwähnt hast, wo die Leute dann tatsächlich gut sind und eben selbstbewusst mit ihren eigenen Ergebnissen auch umgehen dürfen. Genau, da gibt es auch so einen spannenden psychologischen Effekt für, dessen Namen ich gerade vergessen habe. Aber je weniger man sich in einem Fachbereich auskennt,

desto überzeugter ist man von seiner eigenen Kompetenz in diesem Fachbereich. Stimmt, den Fachbereich hast du mir, den Fachbegriff hast du mir tatsächlich schon öfter sogar mal unter den Anzeiger riechen. Ich komme jetzt nicht mehr ganz, ich glaube, es ist auch was anderes als ich, naja, auf jeden Fall, wenn ich noch nicht so viel Erfahrung habe und vielleicht auch noch nicht so viel Gegenwind hatte, dann entwickle ich natürlich ein Selbstvertrauen auf den kleinen Pool, den ich kann. Und irgendwann bekomme ich dann offenbart, was es denn alle für Aspekte in diesem Fachbereich gibt, von denen ich gar keine Ahnung hatte.

Und das drückt natürlich auch massiv das Selbstvertrauen. Also Selbstvertrauen hat ja immer was mit dem Vertrauen in die eigenen Kenntnisse zu tun. Und für dieses Vertrauen muss man ja wissen, wie die eigenen Kenntnisse im Markt so wirken. Und wenn man eben nur ein relativ kleines Bild vom Markt hat, dann sind die eigenen Kenntnisse im Verhältnis sehr groß und damit wächst das Selbstvertrauen. Und wenn man dann erstmal wirklich erfahren hat, was es denn eigentlich alles für Bereiche gibt, dann ist natürlich das Selbstvertrauen auch wieder recht klein, weil man auf einmal denkt, oh, jetzt mit diesem kleinen Pool an Werkzeugen,

die ich schon kann, komme ich auf diesem breiten Markt gar nicht so weit. Ja, und da sehe ich mich auch immer wieder. Also einerseits, was du vorher gesagt hast, ich bin nämlich reingekommen in die Ausbildung und wusste nicht mal, was ein MySQL oder überhaupt ein SQL-Join ist. Und ich habe große Anwendungen gebaut mit Datenbanken und allem drum und dran und habe Abfragen ohne Ende gemacht. Ich habe nur immer alle Daten runtergeladen, die in PHP verarbeitet und dann wieder zurück an die Datenbank geschickt. oder die eben aufwendig in den Skriptenausgaben da genommen, anstatt mir die Informationen in der Datenbank direkt schon vernünftig zu aggregieren,

zusammen zu basteln, so wie sie brauchte. Und genau andersrum, wie du dann gesagt hast, habe ich das Thema bis heute, wenn ich in ein Projekt reingehe, wenn man sich so die Anforderungen anguckt, was dann da gefordert wird, von Kubernetes über Redis bis Laravel, TypeScript und so weiter und so fort. Es gibt ja nie eine Anforderung, die man komplett erfüllt. Also zumindest ist es bei mir nicht so und es sind immer Sachen dabei, die ich nicht kann. Und dann komme ich immer wieder an den Punkt, denke so, boah, kannst du das eigentlich? Aber die Erfahrung zeigt, egal in welches Projekt man uns jetzt webtechnisch reinschmeißt,

eigentlich können wir alles. Und wenn da noch zwei, drei Technologien dabei sind, die wir uns noch mal ein bisschen auffrischen müssen oder die wir sogar neu lernen müssen, dann geht das meistens super, super gut und wir sind da extrem schnell produktiv. Aber so diese erste Hürde, dass man denkt so, boah, da ist so viel, was ich nicht kenne, die ist schon immer da. Ja, wie bekommt man dieses Selbstvertrauen? Das ist ja die spannende Frage, an der ich jetzt gerade herumdokte. Und dann auch zu sagen, obwohl ich irgendein Wissen nicht habe, dass ich trotzdem sage, ja klar, schmeiß mich auf das Projekt,

schmeiß mich da rein und ich löse das schon. Wenn man so im Arbeitsalltag unterwegs ist, um mal vielleicht einen kleinen Bogen zu spannen, zumindest bei mir ist es so, so 80 Prozent der Zeit rushe ich einfach durch mit meinen Aufgaben und werkele die ganze Zeit vor mich hin, was immer diese Aufgabe jetzt auch sein mag. Und dann 20 oder 10 Prozent der Fälle am Tag habe ich dann so eine Aufgabe, wo ich mir so richtig die Zähne dran ausbeiße. Und dann komme ich nicht weiter und muss vielleicht irgendwie nachfragen oder sowas. Und wenn ich dann am nächsten Tag zurückdenke, dann sind mir nur diese 10 Prozent im Kopf,

an denen ich gescheitert bin. Während die restliche Zeit, in der ich einfach so durchgerusht bin, die bleiben nicht besonders hängen. Und ich glaube, das ist auch der Trick dann für dieses Selbstbewusstsein, sich einfach mal gewahr zu werden, wie viel Arbeit am Tag man eigentlich schafft oder wie viel Anteil des Code-Reviews vielleicht nicht kritisiert wird, um das vielleicht mal darauf zu lenken. Und dann zu sehen, oh, ja, ich hatte zwar jetzt hier irgendwie einen Aspekt, der mir besonders schwer gefallen ist und an dem ich mich besonders lange aufgehalten habe. A, habe ich ihn vielleicht gelöst,

B, habe ich auf jeden Fall viel gelernt und C, hatte ich aber ganz, ganz viele andere Aufgaben, die ich ohne Probleme gelöst habe. Und das muss ja heißen, folglich, dass ich schon eigentlich ganz schön gut bin. Und wenn man das dann reflektiert über vielleicht das letzte Jahr und überlegt, was hat mir denn damals Schwierigkeiten bereitet, was ich heute ohne Probleme mache, dann, also so geht es bei mir zumindest, kann ich daraus das Selbstvertrauen zu schöpfen, auch in die Zukunft zu blicken und zu sagen, wie du es gerade gesagt hast, Felix, auch wenn ich mit einer Aufgabe konfrontiert werde, von der ich noch gar keine Ahnung habe,

statistisch gesehen, wird mir das meiste davon trotzdem leicht fallen. Und dann habe ich vielleicht trotzdem so 10, 20 Prozent, wo ich dann auch noch mal knobeln muss. Aber ich habe zumindest das Vertrauen, dass der Großteil davon kein Problem wird. Wir wiederholen jetzt so ein paar Sachen, glaube ich, aus der Merge-Request-Folge. Ich glaube, das ist aber auch nicht wahnsinnig schlimm. Denn genau, was du gesagt hast, ist total wichtig, dass man eben sieht, was auch alles gut gelaufen ist. Und wenn man einen super Code abgeliefert hat, kann trotzdem ein guter anderer Programmierer immer Sachen finden,

die man in der Struktur oder irgendwo noch verbessern kann. Das ist ja auch klar. Und deswegen haben wir ja in der Merge-Request-Folge auch gesagt, dass es auch unsere Aufgabe ist, die Leute auch zu loben für Sachen, die gut gemacht sind. Weil man nämlich genau sonst in diesen Effekt rein stolpert, dass man nur negative Sachen hört und denkt so, oh, ich habe einen schlechten Code geschrieben. Und oft ist es ja genau das Gegenteil, was eigentlich der Fall ist. Und deswegen werde ich nicht müde, den Leuten auch coole Lösungen wirklich, ja, die dafür zu loben. Und dann zu sagen so, boah, das ist eine Lösung,

auf die wäre ich jetzt vielleicht sogar gar nicht gekommen. Oder da hat derjenige super gut mitgedacht. Und dann muss man das auch sagen. Das ist natürlich so ein bisschen das Problem an diesen Merge-Requests. Du hast recht, wir haben schon öfter darüber gesprochen. Es werden halt häufig nur die Dinge angemerkt, die nicht so gut gelaufen sind. Oder die negativen Punkte. Und es wird selten das angemerkt, was alles gut läuft. Also es gibt dann vielleicht mal so globales Lob im Team. Aber wenn was schlecht gemacht wird, dann gibt es jede einzelne Zeile Code, wird angekrittelt, rot markiert, Backticket gestellt und so weiter und so fort.

Also die ganze Zeit ist der Fokus, so zumindest in unserem Arbeitsalltag, auf die Sachen, die eigentlich alle nicht funktionieren. Und wenn jemand seine Aufgabe problemlos abgeschlossen hat und super schnell war und alles fehlerfrei funktioniert, dann ist es am nächsten Tag mit der nächsten Aufgabe schon wieder vergessen. Und das sind ja eigentlich genau die Quellen des Selbstvertrauens, die man braucht. Das heißt, da ist diese Reflexion meiner Meinung nach total wichtig, auch die eigene Reflexion, weil von außen kommt das nicht so häufig, die eigene Reflexion auf die eigenen Sachen, die ich gut gemacht habe.

Genau. Kay, ich habe in der Zwischenzeit ChatGPT gefragt, wie der Effekt heißt, den wir eben angesprochen haben. Und ChatGPT sagt, das Phänomen, das du beschreibst, heißt der Dunning-Kruger-Effekt. Es handelt sich dabei um eine kognitive Verzerrung, bei der Menschen mit wenig Wissen oder Erfahrung in einem bestimmten Bereich ihre Fähigkeiten überschätzen. Gleichzeitig neigen Personen mit höherer Kompetenz dazu, ihre Fähigkeiten eher zu unterschätzen, weil sie wissen, wie viel es noch zu lernen gibt. Genau, da gibt es diese schöne Kurve dazu, aber ich habe letztens noch irgendwo einen Artikel gelesen,

der das auch wieder in Frage gestellt hat, ob der Dunning-Kruger-Effekt nicht selber dem Dunning-Kruger-Effekt unterliegt und da eigentlich was ganz anderes mit im Zusammenhang stand. Deswegen wollte ich mich da jetzt nicht so aus dem Fenster lehnen, aber das hast du ja jetzt gemacht. Na gut. Ja, aber vielleicht das Wort hier erwähnt zu haben, ist vielleicht gar nicht so schlecht. Ich möchte noch auf einen anderen Aspekt eingehen. Wir reden ja jetzt ganz viel über Vertrauen und Selbstvertrauen, aber was haben wir eigentlich davon, wenn die Programmierer ein gutes Selbstvertrauen auch in ihren eigenen Code haben.

Und da kann ich jetzt aus meiner eigenen Perspektive sagen, ich liebe das, wenn Leute ein gewisses Vertrauen und Selbstvertrauen in sich selbst und auch in ihren Code haben. Aber das muss gar nicht unbedingt ein Code sein. Also das kann auch bei uns in der Buchhaltung sein. Also das gibt ganz verschiedene Bereiche. Und was mich eben sehr stört, ist, wenn auch Vorgesetzte nicht ihren Mitarbeitenden vertrauen. Und ein ganz klassisches Beispiel dafür sind ja dann zum Beispiel, dass die Leute keine Merch-Rechte haben, dass die Leute keine Admin-Rechte auf ihren Rechnern haben und so weiter. Und ich habe noch nie gesehen,

dass jemand Quatsch gemacht hat mit irgendwelchen Rechten, die er hatte. Und ganz im Gegenteil, ich sehe tagtäglich, dass Leute irgendwelche Rechte nicht haben. Also nicht bei uns, aber unter anderem bei unseren Kunden oder anderen Firmen. Da haben die Leute irgendwelche Rechte nicht, können Sachen nicht machen, können nicht effizient arbeiten, weil denen einfach auch von der Geschäftsleitung von den Vorgesetzten nicht vertraut wird. Und das finde ich eigentlich ziemlich traurig, weil wenn ich mit jemandem zusammenarbeite, gerade auch wenn ich mit den Leuten länger zusammenarbeite, ich muss das ja nicht direkt

am ersten Tag alle Schleusen aufmachen. Aber in dem Moment, wo ich eine gewisse Vertrauensbasis aufgebaut habe, muss ich den Leuten doch auch ihre Kompetenz zugestehen. Oh, da machst du jetzt ein sehr großes Fass aus. Ich versuche das mal so ein bisschen zu bröckeln, weil ich glaube, also zum einen haben wir natürlich eine extrem luxuriöse Position, weil wir ein kleines Team sind von Menschen, wo alle alle kennen und wo alle ein solides Grundverständnis für Technik mitbringen. Und jeder weiß, wie er sein Mac bedient und so weiter und so fort. Was du jetzt gesagt hast, das sind so Firmenregeln in gigantischen Konzernen,

wo auch jeder Hanswurst an so einen Rechner gesetzt wird. Und ich kann schon verstehen, dass die in so einem riesigen Konstrukt andere Sicherheitsbedenken haben, als wir in unserer kleinen Firma, weil die ja auch viel größere Ziele sind. Also wenn es jetzt um Adminrechte auf dem Rechner geht, dann steckt da ja im weitesten Sinne irgendwie so eine Hoffnung von Sicherheit dahinter. Und die größten Hackerangriffe, sage ich mal, passieren ja da, wo es getargetet ist. Und jetzt sind wir total uninteressant, weil wir so eine kleine Klitsche sind. Und so Riesenfirmen haben da schon mehr Gefahr. Plus, das kommt noch dazu,

wir hatten bis jetzt halt keine schlechten Erfahrungen. Also wir sind nochmal auf der grünen Wiese, weil wir weder irgendwie großartig gehackt wurden, noch irgendwie schlechte Erfahrungen mit Mitarbeitenden gemacht haben, sondern wir können hier rumsitzen und sagen, ja, ist doch alles super gut, wie wir das machen. Mal schauen, was wir sagen, wenn es das erste Mal dann nicht gut geklappt hat. Ich habe das natürlich jetzt auch sehr, sehr vereinfacht oder auch verallgemeinert. Aber vielleicht müssen wir es doch auf Programmierer einschränken, damit es ein bisschen leichter ist. Und wenn ich dann sehe,

dass die Kollegen aus Österreich zum Beispiel keine Programme installieren können auf ihren Rechnern, die sie aber zum Programmieren brauchen, das ist doch irgendwie nicht der richtige Weg, oder? Ja, ja, das ist natürlich Käse. Aber den viel spannenden Punkt, den du gerade gesagt hast, ist das mit den Merge-Requests, mit den Merge-Rechten. Und ich habe da, also ich würde dir widersprechen tatsächlich. Ich würde jetzt nicht jedem alle Merge-Rechte geben. Gar nicht so sehr, weil ich den Menschen nicht vertraue oder ich Angst habe, dass die Menschen Quatsch machen. Das ist natürlich ein total unwahrscheinliches Szenario,

dass irgendjemand von unseren Kollegen boswillig da Quatsch anstellt. Da kann ich nochmal anwerfen, das ist ja wirklich auch dieser Unterschied in Vertrauen in die Fähigkeiten einerseits und auf der anderen Seite das Vertrauen in die Absichten. Und die Absichten müssen natürlich schon nochmal positiv sein, das wäre sonst schlecht. Was halt schon passieren kann bei Merge-Requests, da geht es ja dann um Production, also Produkte, die wir dem Kunden verkaufen und die dann vielleicht auch automatisch deployed werden oder sowas. Und da sehe ich es schon so, dass ich A, die Leute schützen möchte, dass die nicht durch irgendeine

Unachtsamkeit irgendeinen Quatsch machen. Also früher, als ich noch nicht Git konnte, was meinst du, wie oft ich da irgendwelche Branches kaputt gemacht habe, weil ich irgendwo draufgeklickt habe und dann Sachen gemerged, die ich gar nicht mergen wollte. Da muss man sich natürlich auch mal fragen, wie oft war das dann auch wirklich schlimm. Aber ich lasse dich erstmal weiterreden. Ja, genau. Nur eben, insbesondere bei ganz neuen Entwicklern und Entwicklerinnen, die vielleicht auch gerade im Praktikum sind oder in der Ausbildung oder sowas, da halte ich es für essentiell, dass man denen halt so ein Sicherheitsnetz spannt,

wo man sagt, ja, ich vertraue dir zwar prinzipiell, dass du keinen Quatsch machst, aber durch irgendeine Unachtsamkeit, durch irgendein Tool, das du falsch bedienst, ist halt der Schaden, den du anrichten kannst, so massiv, dass sich diese Gefahr rausnimmt, nehmen möchte, auch zu deinem Schutz, um dir sagen zu können, hör mal, ich bestelle dir hier einen Rechner hin und da bekommst du die Codebase drauf und einen Editor und du kannst machen, was du willst, es ist völlig egal. Im Worst Case setzen wir den Rechner neu auf und alles ist zurückgesetzt. Aber der kann nicht irgendeinen Production Server

beim Kunden abschießen oder sowas. Und ich glaube, diese Sicherheit ist essentiell und dafür ist es auch wichtig, den Leuten absichtlich Rechte nicht zu geben, um denen diese Sicherheit zu geben, dass sie in einem frischen Umfeld sich einfach mal austoben können, Sachen ausprobieren, vielleicht mal Sachen anklicken in ihrem Tool, die sie sonst nicht benutzt haben oder sowas. Also ich gehe mit bei neuen Programmierern, Programmiererinnen, dass man die natürlich auch so ein bisschen schützen muss davor, dass die vielleicht aus Versehen doch irgendwie den falschen Branch ausgewählt haben oder so.

Das ist natürlich klar. Das würde ich definitiv unterschreiben. Ich hatte jetzt letzte Woche genau das Thema, dass jemand tatsächlich Merchrechte hatte, obwohl er die, glaube ich, offiziell gar nicht unbedingt haben sollte beim Kunden. Und dann hatten wir spät Nachmittags noch über einen Code gesprochen. Das war jetzt nicht besonders kompliziert und noch nicht besonders lang. Und idealerweise wäre der eben an dem Tag noch online gegangen. Und dann habe ich zu dem Kollegen gesagt, da war noch ein kleines Thema dann drin. Dann sage ich, dann macht das doch fertig. Und du hast ja Merchrechte, dann kannst du das

direkt auf den Main dann auch merchen, wenn du soweit fertig bist. Weil ich demjenigen dann vertraut habe, dass bei einer Änderung in der Größenordnung, weil wir zusammen drauf geguckt haben und ich kann natürlich auch einschätzen, wie derjenige dann drauf ist, dass ich gesagt habe, also das ist mir das Risiko definitiv wert, dass da doch irgendwie, natürlich kann immer irgendwas drin sein, aber das ist mir das Risiko wert, dass er das dann merchen kann. Und dann sagt er, um Gottes Willen, ich kann doch nicht einfach merchen auf den Master oder auf den Main, heißt der heute. Das habe ich noch nie gemacht.

So in der Richtung. Und am Ende hat es glaube ich dazu geführt, er hat es tatsächlich gemercht. Ich bin nämlich 100% sicher, aber ich glaube schon. Und es ist dann nichts passiert. Gut, jetzt sagst du natürlich, uns ist noch nie was Schlechtes widerfahren. Das ist natürlich eine schöne Position. Aber das finde ich schon cool, wenn man so den Leuten auch vertrauen kann, wenn es so funktioniert. Und ja, ich finde, das ist auch ein Stück weit, also das ist ja für die Leute auch ein cooles Gefühl, glaube ich, wenn die merken so, ah, der vertraut mir so weit, dass ich abends auf den Main noch was merchen kann

und der glaubt, das funktioniert schon, was ich da mache. Und der glaubt, dass das die Qualität hat, die wir erwarten. Das zahlt natürlich ungemein auf das Selbstvertrauen ein. Und wenn du den Leuten das Vertrauen aussprichst, dass sie das schon schaffen, dann zahlt das sicherlich auch auf das Selbstvertrauen ein, das dann auch mal zu versuchen. Jetzt muss man natürlich immer schauen, was ist denn der Worst Case, der passieren kann. Und da gibt es ja unterschiedliche Projekt-Setups. Bei manchen ist dann der Merch auf den Master, stößt gleich eine komplette Pipeline an, die ungesehen irgendein Production-Deployment macht,

live auf den Server des Kunden. Und bei anderen ist dann noch zwei, drei Schritte dazwischen mit manuellen Prozessen, wo vielleicht erst mal was auf den Test-Server deployed wird oder sowas. Stimmt, das war natürlich jeder Fall. Also wäre schon mal eine Testrunde dazwischen gewesen. Genau, also davon hängt es natürlich ganz dramatisch ab, wie weit denn dann diese Einflüsse sind. Aber was ich eigentlich konzeptionell eher noch finde, ist auch, ich habe ja in meiner Position letzten Endes die Verantwortung über das Projekt. Und das heißt dann gar nicht zwangsläufig, dass ich den Entwicklerinnen oder Entwicklern nicht vertraue,

dass die irgendwelche Sachen machen oder dass die irgendwelchen Quatsch machen und dann einfach Sachen auf den Main merchen, die da gar nicht rein sollen. Das machen unsere Menschen natürlich nicht. Aber letzten Endes habe ich die Verantwortung für den Main Branch. Und das bedeutet auch, wenn irgendwas schief geht oder wenn irgendwas nicht so funktioniert, wie es soll, dann bin ich in der Verantwortung, A, dafür gerade zu stehen und B, das zu reparieren und wieder gerade zu biegen. Und dafür muss ich, oder so verstehe ich das zumindest, auch die Kontrolle darüber haben, über die Sachen, für die ich die Verantwortung habe.

Ja, das weiß ich nicht. Wir reden jetzt nicht darüber, dass jemand absichtlich irgendeinen Quatsch macht. Es kann ja auch sein, dass jemand, weil jeder Mensch Fehler macht, so wie wir das auch machen, durch eine Unachtsamkeit, durch irgendwas, einen Bug einschleust, der in so einem Merge Request vielleicht aufgefallen wäre, aber den mercht er direkt. Und ich finde es für mich schon wichtig zu sagen, okay, ich möchte diese, diese Sicherheitsinstanz sein, die zwischen mir und, also die, die zwischen den Kunden und unseren Kolleginnen steht. Einerseits, dass ich Sachen abfange, die, also die, ich sage es immer,

wenn jemand einen Fehler macht, war es meine Schuld, wenn jemand was gut macht, war er es. So verstehe ich das. Und das muss aber auch heißen, dass wenn er einen Fehler macht, dann muss ich das auch abfangen können und damit nicht der Kunde direkt den Entwickler anruft und sagt, der hat Scheiße gebaut, sondern das soll bitte über mich gehen. Der Entwickler soll davon nichts mitbekommen. Auch wieder Thema Sicherheit und sowas. Aber dann muss ich andererseits auch die Kontrolle darüber haben, über alles, was da passiert. So verstehe ich das. Aber Felix? Ja, ich sehe das eben ein bisschen anders.

Ich habe ja letztlich die gleiche Situation, vielleicht sogar auch dir gegenüber. Alles, was du zum Beispiel in den PRs durchwinkst und alles, was wir beim Kunden so veröffentlichen, letztlich habe ich da die Verantwortung drüber. Und genauso wie du sprichst, will ich das haben. Ich will, dass du denkst, du hast die Verantwortung darüber und dass du das nicht nur denkst, sondern dass du das auch hast. Und wir haben ja zum Teil Kunden, die dich anrufen, wenn ein Problem da ist. Und genau das will ich auch. Ich will nicht, dass die unbedingt bei mir anrufen. Natürlich können die mich anrufen. Ich will mich auch nicht

aus der Verantwortung ziehen. Aber letztlich kann ich denen sagen, jo, ich frage Herr Domrose. Und dann können sie letztlich auch dich direkt fragen. Und ich will ja gerade bei den Leuten eine Eigenverantwortung aufbauen. Und das ist natürlich bei dir jetzt im Speziellen, aber eigentlich auch bei jedem anderen Programmierer. Also wir haben zum Beispiel eine Mitarbeiterin, die ein Kundenprojekt komplett selbst behandelt. Und ich glaube, der Kunde würde nie darauf kommen, mich oder dich anzurufen, sondern der würde immer die Kollegin anrufen, weil die da auch die meiste Kompetenz hat und ja, da federführend

auch für verantwortlich ist. Und so versuche ich eigentlich auf allen Ebenen, natürlich in verschiedenen Intensitäten, sage ich mal, die Leute in die Verantwortung für ihr Modul, für ihr Projekt, für ihren Kunden zu bringen und auch Sachen selbst entscheiden zu können. Und natürlich kann jederzeit auf mich zurückgegriffen werden und ich muss auch immer wieder Sachen abfangen und mich für Sachen hinstellen. Und das fand ich genial, dass du das gesagt hast. Wenn irgendwas schief geht, bin ich es. Wenn irgendwas gut gelaufen ist, ist es derjenige, der es gemacht hat. Das ist absolut oberes Credo,

würde ich sofort mitgehen. Aber ich versuche eben so viel Verantwortung wie möglich in die einzelnen Positionen reinzuschieben, weil ich finde, da gehört es einfach hin. Aber das sind ja dann Verantwortungen, die du oder die wir bewusst jemandem geben und nicht die per Default gewährt wird. Ja, genau. Und das ist aber ja, glaube ich, genau das, worüber wir hier heute sprechen. So, wo ist die Grenze? Also gebe ich jemandem, der schon ein halbes Jahr jetzt in einem Projekt arbeitet und gute Arbeit bisher abgeliefert hat, gebe ich dem Merch-Rechte, nicht weil er die unbedingt braucht, sondern weil das Vertrauen da ist

und ich weiß, wenn ich mal im Urlaub bin, wenn ich mal nicht verfügbar bin, wenn mal was schnell gefixt werden muss und derjenige ohnehin die Verantwortung hat, vielleicht auch gegenüber dem Kunden direkt, ist es dann nicht total sinnvoll, ihm da entsprechend dann auch die Rechte zu geben, ihn mit den Kompetenzen auszustatten. Und wo zieht man die Grenze und wann zieht man die Grenze? Das ist, glaube ich, so genau diese Gratwanderung, die man haben muss. Und ich glaube, man kann schon raushören, ich bin ja jemand, der da eher locker, eher offen mit ist, während mir das oft ganz komisch vorkommt,

wenn eben gerade in großen Konzernen, wie du das gesagt hast, diese Grenzen sehr, sehr, sehr eng gesteckt werden und dann Leute total überladen sind mit Arbeiten, wo sie eigentlich immer nur das Gleiche machen, nämlich immer nur auf OK klicken. Ja, also da fehlt mir jetzt einfach das Verständnis für so große Konzerne. Die machen das sicher nicht aus Spaß. Die haben natürlich für... Die machen das, um Leute zu beschäftigen. Ja, vielleicht. Da kann ich jetzt halt nicht für sprechen, aber ich stimme dir total zu, wenn jemand die Verantwortung hat, dann, also vielleicht zusammenfassend, die Macht kommt immer mit einer Verantwortung.

Und du kannst nicht eins von beiden haben. Du kannst nicht Verantwortung ohne Macht haben und du kannst keine Macht ohne Verantwortung haben. Und eine Merge-Requist, also Merge-Rechte ist ja genau das, Du hast die Macht, etwas zu ändern an einem Production-Build, dann bedeutet das gleichzeitig auch, du bekommst die Verantwortung. Und wenn wir aber jemandem die Verantwortung nicht geben wollen, aus welchem Grund auch immer, dann bekommt er auch die Macht, die damit zusammenhängt, nicht. Also die Frage ist einfach, wie viel Verantwortung hat eine Person und ist sie jetzt entscheidend für dieses Projekt

und macht da selbstständig Deployments und Kommunikation mit dem Kunden und alles, dann bekommt sie selbstverständlich auch die Macht, die Sachen zu tun, wie sie machen muss. Ja, vielleicht müssen wir uns sogar umdrehen und gar nicht sagen, soll man das per se erlauben, dass alle alles können, sondern man muss vielleicht andersrum gucken, wem muss man es aktiv erstmal verbieten, so mies wie sich das anhört. Aber genau wie du sagst, dass man dann sagt, dass man neueren Leuten zum Beispiel vielleicht erstmal eine gewisse Kompetenz, ein gewisses Recht nicht gibt und sich vielleicht so der Sache nähert.

Was mich aber jetzt noch interessiert ist, wie machen wir es denn eigentlich aktuell? Ich überlege das gerade so parallel. Wir haben Projekte, kleinere Projekte, wo jeder mehr oder weniger, der die Zugangsdaten hat, erstmal auch alles machen kann, weil das auch wichtig ist in diesen kleinen Projekten, wenn da ein Thema ist, dass man sagen kann, guck mal, hier sind die Zugangsdaten, los geht's. Und in den größeren Sachen, die wir haben, gibt es aber ja schon oft auch Einschränkungen. Hast du da genauere Insights, wie das bei uns, der Moment aktuell überhaupt läuft? Wild läuft das aktuell. Wäre auch mein Gefühl?

Nicht so sonderlich konsequent. Das liegt aber auch daran, dass es nur wenige KollegInnen gibt, die wirklich in mehreren Projekten rumtouren. Und viele haben dann ein Projekt, in dem sie aktiv sind oder vielleicht zwei und haben dann maßgeschneiderte Rechte dafür. die irgendwie keinem besonderen Schema entsprechen, sondern organisch irgendwie gewachsen sind. Grundsätzlich hätte ich erstmal gesagt, alle haben Leserechte und dann nur ausgewählte Personen haben Schreibrechte, einfach um das auch kontrollieren zu können, was da passiert. Wie gesagt, wieder nicht wegen bösartiger Unterstellung, sondern einfach für Produktionscode.

Vielleicht nochmal einen Bogen zurück. Das ist ja eigentlich ein ganz normaler Prozess, der mit jedem Menschen passiert, mit dem man in Kontakt tritt. Alleine wenn du jemanden kennenlernst, erzählst du ihm nicht direkt deine Handy-Pin, sondern man tauscht erstmal so das allernötigste, allernötigsten Smalltalk aus und dann über die Jahre, wenn sich Vertrauen bessert, dann darf der mehr und mehr und dann wird es vielleicht die Partnerin und dann darf sie noch mehr. Also das ist ja ein ganz normaler Prozess und so machen wir das ja in der Firma auch. Wenn jemand Neues reinkommt, unabhängig davon,

was die Kompetenzen sind oder so, dann ist der Vertrauensgrad erstmal relativ niedrig. Dann bekommt der vielleicht noch nicht den ganzen Passwort-Manager-Zugang, sondern erstmal nur für so einen kleinen Bereich, den ihn interessiert. Und er bekommt vielleicht nicht Merge-Request-Rechte für alle unsere GitLab-Projekte, sondern erstmal nur für eins. Und je länger man vertraut mit dem Menschen ist, desto offener wird man. Also es ist ja ein ganz normaler Prozess. Ja, vielleicht können wir das tatsächlich auch so stehen lassen und als Take-away damit rausnehmen. Ich kann das immer nur aus meiner Perspektive sagen

und das mache ich jetzt hier nochmal. Ich bin ein großer Fan davon, die Leute nicht einzuschränken dadurch, dass sie, wenn wir jetzt ganz konkret über Merge-Rechte zum Beispiel sprechen, dass sie nicht eingeschränkt dadurch sind, dass es irgendwelche Rechte nicht gibt. Und ich bin ein großer Fan davon, in dem Moment, wo die Leute aktiv bei einem Projekt mitarbeiten, sich bewährt haben, dass man dann auch sagt, okay, du hast die Rechte erarbeitet, verdient, wie auch immer. Da sind sie dann auch. Und dann kann derjenige damit auch arbeiten. Während ich in anderen Strukturen, anderen Firmen das oft erlebe,

dass die Rechte dauerhaft auch zurückgehalten werden und immer bei den Vorgesetzten in irgendeiner Form bleiben. Obwohl das meiner Meinung nach nicht so wahnsinnig passend ist. Und du hast auch schon gesagt, bei uns ist es so ein bisschen Kraut und Rüben. Das kommt ein bisschen auf die Projektgröße an. Das kommt ein bisschen auf die Struktur beim Kunden an. Das kommt auch ein bisschen darauf an, wie vielen Projekten diejenigen unterwegs sind. Aber wir versuchen schon, oder ich würde mal so von außen behaupten, von außen ist gut, eigentlich bin ich ja innen drin, dass ich keinen bei uns habe, der dauerhaft eingeschränkt ist

durch irgendwelche Rechte, die er nicht hat. Also wenn jemand zu mir kommt und sagt, Felix, ich muss das hier veröffentlichen, kannst du das machen? Dann denke ich mal, warum kannst du das nicht selbst? Gib ihm die Rechte und fertig ist die Kiste. Und das ist vielleicht auch das, was ich so als Empfehlung rausgeben würde. Wenn ihr eure Leute kennengelernt habt, vertraut denen auch, weil das die Einzelbasis ist, glaube ich, auf der man vernünftig zusammenarbeiten kann. Und wenn wir aus der Programmiererperspektive gucken, dann kann ich einfach nur nochmal, ich glaube, das haben wir oft genug getan,

alle Leute ermutigen, die programmieren, dass sie wirklich versuchen, alles zu geben in ihrem Code, 100% abzuliefern und dann ihren Code auch wirklich verteidigen und dann sagen, guck mal, das habe ich so gemacht, weil ich mir da dies beigedacht habe und das habe ich so gemacht, weil ich mir das beigedacht habe. Und wenn es guten Input gibt, nimmt man den gerne an, aber davon ist nicht alles schlecht. Und das ist so, dieses Selbstvertrauen, dieses Selbstverständnis beim Programmieren, da wollen wir eigentlich alle von unseren Programmierern, von unseren Programmierern hinbekommen und das würde ich mir

für ganz viele da draußen auch wünschen. Das ist natürlich ein gutes Vorbild, wenn wir vorangehen und den Leuten durch Merchrechte und weiß ich nicht was das Vertrauen aussprechen, dass zumindest wir an ihre Kompetenzen glauben. Das muss für die Menschen selber dann natürlich nicht automatisch auch gelten, dass sie das von sich selber glauben. Aber zumindest von außen dieser Impuls ist ja wichtig und auch von außen dieser Impuls, den wir immer versuchen zu machen, zu loben, aufzuzeigen, auch wie sich die Menschen verbessert haben. Ich drehe da jetzt wieder eine Schleife, aber ich glaube, das ist ja dieser spannende Takeaway,

wie dieses Selbstvertrauen zustande kommt. Wir machen extra Jahresgespräche, um so ein Delta aufzuzeigen und zu schauen, schau mal, vor einem Jahr hattest du hiermit Probleme und jetzt klappt es auf einmal voll gut. Und ich denke, das ist auch mein entscheidender Takeaway, wenn man selber mehr Selbstvertrauen entwickeln möchte, in die Reflexion zu gehen und zu schauen, was ist denn letzte Woche gut gelaufen? Was hat mir alles keine Schwierigkeit bereitet? Was hat mir vor einem Jahr noch Probleme bereitet und hat jetzt total gut geklappt? Und nur durch diese regelmäßige Reflexion, so war das zumindest bei mir,

hat sich dann eben dieses Selbstvertrauen entwickelt, auch in die Zukunft zu blicken und zu sagen, ja, ich werde das schon alles schaffen, weil in der Vergangenheit, statistisch gesehen, hat es auch schon alles gut geklappt. Definitiv. Jetzt habe ich noch eine Sache, die du mir nochmal erklären musst. Du hast nämlich schon öfter vom Imposter-Syndrom gesprochen. Da musst du mir noch einmal einen Refresher geben, was das ist und ob das ins Thema passt. Ja, genau. Also das passt sehr gut ins Thema, weil Imposter-Syndrom ist ja die langläufige Beschreibung und ich glaube ein psychologisches Konzept

für genau das, dass man selber das Gefühl hat, man ist die ganze Zeit eigentlich nur ein Imposter, also ein Scharlatan, ein Gaukler, jemand, der vorspielt, etwas zu können, was er gar nicht kann. Und das hängt eben auch damit zusammen, das ist häufig im beruflichen Kontext oder in anderen Fachgebieten, wo man gefordert ist. Und üblicherweise ist es ja so, dass man weiß, was es alles gibt und man weiß selber davon nur einen kleinen Teil. Also bei der Programmierung weiß ich, was ich kann und das ist aber eine kleine Schnittmenge von einem gigantischen Komplex an Sachen, die ich wissen könnte, aber nicht weiß.

Ich weiß, dass es sie gibt, aber ich weiß nicht, ich weiß, dass es DevOps gibt, aber noch nie gemacht oder solche Späße. Und da kommt her, dass man eigentlich die ganze Zeit an seiner eigenen Kompetenz scheitert, weil man eben weiß, was man alles nicht kann, statt zu wissen, was man alles schon kann. Und daraus stellt sich dann bei manchen Leuten so ein Gefühl ein von, ach, ich bin ja eigentlich total fehl am Platz. Ich schummel mich doch hier nur so durch die Gegend und irgendwann wird es schon auffallen und dann werde ich dafür bestraft oder sowas. Also nochmal so eine stärkere Ausprägung von eigentlich mangelndem

Selbstvertrauen in die Sachen, die man schon kann. Ja, spannend. Kay, dann bleibt mir nur noch zu sagen, das Mikrofon ist angekommen, was ich bestellt hatte. Ich habe mir nämlich so ein, ich sage mal in Anführungsstrichen, Travel-Mikrofon geholt. So ein Shure MV7 Plus. Das ist die aktualisierte Version von dem, was du hast, Kay. Und das, was das Ding auszeichnet ist, dass es direkt bei USB-C auch an den Rechner angeschlossen werden kann. Und in meiner Vorstellung habe ich damit die Möglichkeit, auch im Urlaub mal einen Podcast aufzunehmen. Ich werde das Ding mitnehmen. Ob wir tatsächlich podcasten,

werdet ihr dann sehen. In meiner Vorstellung sitzt du dann künftig am Strand bei Wellenrauschen und Podcast so in den Tag hinein. Ja, das ist, das ist auch mein Gedanke dazu. Mal gucken, ob das klappt. Vielleicht ist das jetzt die Gelegenheit, auf Podcast mit Video und Hermalungen zu wechseln. Hm. Nicht, dass wir Leute zu neidisch machen. Oh Gott. Jetzt fragt ihr euch bestimmt alle, wo es hingeht. Ich fliege nach Mauritius, ohne damit jetzt angeben zu wollen, aber ich finde das auch immer blöd, damit so hinter Berg zu halten. Obwohl mich da auch eine gewisse Flugscham plagt. Aber so ist es und ich freue mich sehr drauf

und morgen geht's los. Viel Spaß. Danke dir, Kay. Und wir hören uns entweder im Urlaub oder danach. Tschüss. Bis dahin.