Engineering Excellence

Lucas: Hallo und herzlich willkommen zu einer neuen Folge des INNOQ Podcasts. Heute wollen wir über technische Exzellenz sprechen und dafür habe ich mir den Michael eingeladen. Hallo, Michael.

Michael: Hallo, Lucas.

Lucas: Magst du dich ganz kurz vorstellen, was du so bei INNOQ machst und wer du bist?

Michael: Hi, ich bin Michael. Ich bin seit knapp neun Jahren bei INNOQ und mache da primär eben Softwareentwicklung in Projekten mit, beim, für den Kunden, viel im Backend im JVM, Java Umfeld unterwegs.

Lucas: Cool. Wir beide hatten uns überlegt, heute über ein Thema zu sprechen, was so ein bisschen verschiedene Namen hat. Manche sagen auch Engineering Excellence oder Technical Excellence. Wir haben uns jetzt mal für technische Exzellenz entschieden, aber es könnte passieren, dass wir zwischendurch das Wechseln in der Folge. Magst du einmal kurz sagen, was der Begriff überhaupt für dich bedeutet. Was bedeutet das Wort oder diese Wortkombination?

Michael: Gute Frage. Darüber habe ich mir noch gar keine Gedanken gemacht, was es so direkt heißt. Ich bin auf das Thema gekommen, weil ich auf einem internen INNOQ Event einen Vortrag dazu gehalten habe. Da wurde ich darum gebeten von jemandem und da bin ich das erste Mal auf den Begriff gekommen. Und ich habe dann erst mal andere Kollegen und Kolleginnen gefragt, weil ich hatte irgendwie so ein Bild vor Augen. Das ist bestimmt etwas, eine Person, die irgendwie alles kann und besonders gut ist. Und da war halt ganz spannend, dass eine Person irgendwie geantwortet hat, dass für sie technisch oder Exzellenz immer auch mit Anmaßung und Übertreibung besetzt ist. Und das fand ich ganz nett, weil das auch so meinen ersten Reflex mit abgedeckt hat. Also, wenn ich das von mir behaupten würde, hätte ich immer dieses Gefühl, ich übertreibe auf jeden Fall.

Lucas: Ja, definitiv. Also für mich hat das Wort auch einen Beiklang von Überheblichkeit. Also es klingt nicht bescheiden, wenn man sagt, dass man exzellent ist.

Michael: Genau, aber ich meine, ich habe mich mit dem Thema ein bisschen auseinandergesetzt und erst mal geschaut, wo dieser Begriff überhaupt herkommt. Und die Quelle, die ich dann gefunden habe, ist erstaunlicherweise das agile Manifest, wo man immer denkt, das hat ja jeder mal gelesen und jeder kennt es, aber irgendwie kannte ich den Teil dann doch nicht. Und zwar, es gibt noch irgendwie die Prinzipien dahinter. Und da steht halt drin im Deutschen jetzt, dass ständiges Augenmerk auf die technische Exzellenz und gutes Design die Agilität fördert. Und spannend ist dann auch noch, dass der nächste Satz sagt: Einfachheit, die Kunst, die Menge nicht getaner Arbeit zu maximieren, essenziell ist. Und ich finde auch, die beiden Absätze, irgendwie gehören die für mich nämlich auch zusammen. Ich weiß gar nicht, ist das irgendein Designer gewesen, der gesagt hat, Perfektionismus ist, wenn man nichts mehr weglassen kann?

Lucas: Ja, ich glaube, das ist Braun, aber ich möchte mich nicht aus dem Fenster lehnen und nachher Ärger von Robert bekommen [Anmerkung: Gemeint war Dieter Rams, das Zitat ist aber von Antoine de Saint Exupéry].

Michael: Ich hätte vorher googeln können, aber habe ich jetzt auch nicht mehr gemacht. Genau, und irgendwie ist es das, glaube ich, was dann bei mir auch hängengeblieben ist. Also Exzellenz hat schon, glaube ich, sehr viel mit Wissen von jemandem zu tun oder von einer Sache, aber eben auch dann irgendwann das Wissen, was man denn weglassen kann.

Lucas: Ich finde, dass man dieses Thema auch ein bisschen unterteilen muss. Ich glaube, dass eine der wichtigsten Aufgaben in diesem Feld ist, eigentlich auch eine Umgebung zu schaffen, in der das möglich ist. Also es gibt ja diesen Begriff von diesem 10x Programmer oder so was. Das könnte man ja da reininterpretieren, sei ein 10x Programmer oder Engineer und dann ist alles super. Und ich habe selten 10x Engineers erlebt, die nicht die Produktivität des restlichen Teams gesenkt haben. Ich glaube, das sollte man auf jeden Fall erst noch mal betrachten. Geht es darum, quasi die technischen Fähigkeiten einer Einzelperson möglichst zu steigern oder die des Teams? Und das ist, glaube ich, der Kerngedanke, den man erst betrachten sollte, bevor man da reingeht, weil ich glaube, dass darauf unterschiedliche Antworten kommen, je nachdem, in welche Richtung man sich bewegen möchte. Und ich hatte jetzt letztlich auch noch mal diesen Begriff von der Engineering Culture oder auch Excellence Culture oder so was mitbekommen auf einem Konferenz Talk. Und da ging es halt eher so um diesen Bereich, wie sorgt man für diese Umgebung, in der Leute sich entfalten können und vielleicht auch ihre Arbeit besser hinbekommen, als sie es außerhalb dieser Umgebung schaffen könnten?

Michael: Ja, guter Hinweis. Jetzt, wo du es sagst, fällt mir auch ein, dass ich den Gedanken auch schon hatte. Also natürlich geht es um Individuen, weil ja jeder einzelne auch etwas schafft und etwas beiträgt. Aber genau, letztlich ist Softwareentwicklung irgendwie immer eine Teamleistung und da kommt es halt dann nicht mehr zwangsweise auf die individuelle Leistung an, sondern eben auf diese Gesamtleistung. Und du musst eben dafür sorgen, dass das Gesamte irgendwie arbeiten kann, aber auch, dass du das Potenzial eines jeden irgendwie ausschöpfst oder da Leute motivierst, sich zu verbessern, ohne mit der Peitsche hinter jemandem zu stehen. So funktioniert das, glaube ich halt nicht. Das wissen wir mittlerweile, denke ich. Genau, das ist so eine Kombination aus beidem, richtig.

Lucas: Und über welches Thema möchtest du zuerst sprechen? Erst mal über die individuellen Sachen oder über die Team Aspekte?

Michael: Die individuellen sind wahrscheinlich etwas einfacher. Vielleicht fangen wir damit an, dann haben wir hintenraus Zeit, über die Teams zu philosophieren.

Lucas: Für mich ist jetzt erst mal die Frage, welche Implikationen hat das für: Möchte ich mich breit aufstellen oder möchte ich mich spezialisieren? Weil vor dieser Frage stehen wir im Prinzip alle, weil das Feld, in dem wir arbeiten, ist so unfassbar groß, dass keiner mehr alles perfekt können kann. Das geht einfach nicht. Und da spielen halt auch so Sachen rein, wie Full Stack. Ob das jetzt bedeutet, dass man Frontend kann und Backend kann oder vielleicht bedeutet das auch noch, dass man Ops kann und Security und was weiß ich. Und dann wird einem irgendwann klar, dass man vielleicht alles grundlegend kennen kann, aber nicht alles in der Tiefe verstehen kann. Dafür reicht unsere Lebenszeit, glaube ich nicht aus. Und meiner Meinung nach und das ist das, was ich auch den Juniors, die mich danach fragen, auch immer empfehle, ist, ein grundlegendes Wissen auf der gesamten Breite anzustreben. Also natürlich nicht die gesamte Breite von embedded Systems bis was weiß ich. Aber nehmen wir jetzt mal jemand, der Webentwicklung macht, die Gesamtheit der Webentwicklung, also Frontend, Backend, auch ein bisschen was von Operations und so weiter. Alles davon, erst mal grundlegend zu kennen, aber sich dann auch zu überlegen, welches davon interessiert mich am meisten und wo möchte ich tiefer reingehen. Aber ich glaube, es ist nicht gesund, wenn man von den anderen Bereichen einfach gar nichts weiß. Und einfach sagt, darum kümmert sich ja wer anders. Also dass man grundlegend weiß, wie das alles zusammenhängt. Ich glaube, das ist für eine Exzellenz schon wichtig.

Michael: Es wird wahrscheinlich jetzt weniger kontrovers als wir das gerne hätten. Genau, ich habe die Folien halt nebenbei auf und schaue so durch. Ich habe noch einen Kollegen zitiert, der hat gesagt, für ihn ist technische Exzellenz die Fähigkeit zu liefern. Und wenn man das jetzt auf eine Einzelperson runterbrechen würde, dann käme man eben irgendwie genau da hin. Klar, man kann nicht mehr alles kennen, selbst mit der Berufserfahrung, die wir beide jetzt haben. Also es geht halt nicht. Man lernt das, glaube ich auch über die Zeit immer mehr, dass es nicht geht. Man lässt dann halt gewisse Themen aus. Aber es macht schon Sinn, sich so rund um seinen Bereich, also wenn man einen Bereich hat, den man besonders mag oder wo man besonders gut drin ist, macht es halt, glaube ich zumindest Sinn, mal zwei, drei Schritte nach rechts und zwei, drei Schritte nach links zu gehen. Ich glaube, man muss es gar nicht immer alles so super im Detail wissen, sondern häufig geht es darum, dass, angenommen man hat jetzt drei Menschen, die irgendwie Frontend machen und alle drei fallen gleichzeitig aus, vielleicht auch nur für ein paar Tage, dann reicht es ja schon, wenn jemand, der da Backend macht, sich trotzdem zutraut, kleinere Änderungen zu machen. Die kann man ja danach immer noch korrigieren oder besser machen als er das tut, aber sich zumindest traut, das auch zu tun.

Lucas: Definitiv. Und vor allem auch versteht, was die dort tun. Also wenn man quasi da drauf schaut und dann einfach nur sagt, tja, keine Ahnung was das da ist, dann ist es halt ein Problem, weil wie du sagst, wenn die dann nicht da sind, kannst du sie auch nicht fragen.

Michael: Genau. Ich habe das auf den Folien Respekt genannt. Ich weiß nicht, ob es der richtige Begriff ist, aber einfach sich bewusst zu sein, was die Themen um mich herum tun, einfach denen mit diesem Respekt zu begegnen. Also einzusehen, die tragen auch was zur Wertschöpfung bei, auch wenn ich nicht immer alles verstehe. Wenn die Leute, die da viel Erfahrung drin haben, sagen, das machen wir so, dann wird es schon so richtig sein und nicht so dieses abfällige… Das gibt es ja in alle Richtungen. Einige Kollegys, die bei uns schon mal sagen, dass dann irgendwann im Frontend gesagt wird, jetzt mach das doch mal kurz hübsch. Also das ist nicht sehr respektvoll, aber irgendwie dieses, ja wir deployen das dann einfach irgendwo hin, ist halt genauso in die andere Richtung. Da kann sich jeder, auch ich, mich an die eigene Nase fassen.

Lucas: Ja, und ich würde das auch noch weiter fassen und auch solche Rollen wie UX Design, UI Design und so weiter reinpacken, denen oft auch nicht mit dem notwendigen Respekt begegnet wird, wo es dann heißt, ja Gott, die machen ja nur mhmhm. Und das ist halt totaler Unsinn. Die machen supertolle, wichtige Arbeit und das kann auch nicht jeder. Und wir sollten das auch respektieren und wertschätzen, was die da tun und vielleicht auch was unsere Product Owner und so weiter tun. Das ist alles wichtige Arbeit, ohne die das gesamte Ding nicht funktionieren würde und ich glaube, das ist schon ein wichtiger Punkt. Ich finde das Wort Respekt auch gut gewählt, weil das ausdrückt, worum es geht. Es geht ja nicht darum, das im Detail zu verstehen, aber es geht halt darum, zu respektieren, dass diese Leute eine Expertise haben, die ich wahrscheinlich nicht habe, die anzuerkennen und dann aber auch mit denen darüber diskutieren zu können. Ich glaube, das habe ich im Podcast auch schon mal erzählt, aber es ist schon eine Weile her, aber in meinem ersten Job, da habe ich zusammen mit einer Designerin gearbeitet. Ich war Frontend Entwickler und da habe ich super viel gelernt, weil wir haben oft zusammen dann gepaired und als ich angefangen habe, hat sie mir immer erst so Photoshop Dateien geschickt und ich habe sie einfach quasi abgemessen und dann eingetragen ins CSS. Und später haben wir dann gemerkt, irgendwie ist das nicht so klug und haben uns dann halt zusammen hingesetzt und haben zusammen das gemacht. Und wir haben beide super viel gelernt. Sie hat gelernt, an welchen Stellen sie kleine Änderungen in ihrem Design machen kann, die aber eine riesige Arbeitserleichterung in der Umsetzung ist. Und ich habe gelernt, an welchen Stellen es superwichtig ist, mich ganz genau an das zu halten, was sie tut und an welchen Stellen vielleicht man das auch ein bisschen anders betrachten kann, damit es ein bisschen leichter ist. Und diese Art von Zusammenarbeit finde ich super wichtig und ich glaube, die tut allen gut, das einfach mal zu versuchen, in diese anderen Rollen zu schlüpfen, einfach miteinander zu reden und das nicht einfach als gegeben hinzunehmen.

Michael: Genau, das ist halt auch ganz spannend, wenn man diesen Begriff Full Stack nennt, also ganz viele verbinden damit ja nur noch Frontend und Backend Entwicklung, SPA Framework und ich kann ein Backend Framework, aber selbst denen fehlen ja dann schon so technische Betriebsthemen. Und neben den Themen kommen ja dann auch noch diese ganzen weichen Themen. Also Anforderungsanalyse gehört eigentlich auch zur Softwareentwicklung und Betriebskonzept – On Call oder so. Also das ist keine direkte Arbeit, ist auch nichts Technisches, aber sind irgendwie auch Dinge, die Menschen machen müssen und Skills, die sie brauchen und die vergisst man halt auch ganz schnell.

Lucas: Ja, definitiv. Noch ein weiteres Thema, was ich sehen würde, in diesem persönlichen Bereich ist, dass man auf bestimmte Aspekte, bei denen man weiß, dass sie oft unter den Tisch fallen in dem Prozess, dass man auf die besonders Rücksicht nimmt. Und da würde mir jetzt einfallen, Security, was oft unter den Tisch fällt, da ein Auge mit drauf zu halten. Accessibility, weil das halt oft nicht in den Fokus bekommt, den es braucht und alles so in diesem ethischen Bereich wie Privacy und Tracking und so weiter, dass man dort bewusst mitgestaltet, weil man einfach die Erfahrung macht, dass die meisten Teams sich das nicht leisten für diese Themen eine explizite Person anzustellen oder zu bezahlen und dass deswegen diese Themen leider dann vergessen werden. Und ich finde, das ist auch so ein individuelles Ding, mit dem man sich gut positionieren kann und weiterentwickeln kann.

Michael: Du überrascht mich immer wieder, wie tief du das Thema durchdacht hast. Da hatte ich noch gar nicht darüber nachgedacht. Das Problem an den Stellen ist ja auch häufig, dass das eben vielleicht nicht so ein direkter Fokus häufig ist. Security und Datenschutz mittlerweile schon, aber gerade das Ethische nicht. Aber genau, so grob zusammengefasst kann man wahrscheinlich schon sagen, dass wir mitdenken müssen. Und genau den Fokus auf Dinge, die man oft vergisst, zu setzen ist, glaube ich auch eine ganz gute allgemeine Regel.

Lucas: Ja, also ich habe einfach die Erfahrung gemacht, ich war jetzt in kleinen Projekten, in großen Projekten, aber in allen Projekten ist es eigentlich so. Also Security in einem größeren Projekt hast du meistens schon jemanden, der oder die sich explizit darum kümmert. Accessibility aber zum Beispiel habe ich, glaube ich, noch kein Mal erlebt, dass das in einem Projekt tatsächlich dediziert gemacht wird und Privacy oder so was erst recht nicht. Das waren so Aspekte, die muss man dann, wenn einem das wichtig ist, mitdenken. Und ich persönlich würde sagen, wir tragen dafür eine Verantwortung. Also wenn wir weiter sind in diesem Pfad, sagen wir jetzt mal Senior, was auch immer das genau bedeutet, dann sollten wir das versuchen mitzudenken. Ich glaube nicht, dass das die Aufgabe ist von jemand, der oder die gerade erst angefangen hat. Ich glaube, da fordern wir zu viel von der Person, die müssen sich erst mal orientieren und schauen, dass sie überhaupt so ihren engen Fokus so hinbekommen. Das ist schon mehr als genug Arbeit. Aber wir reden ja über technische Exzellenz und das ist auf jeden Fall der Punkt, wo ich sagen würde, da sollten wir gut darüber nachdenken, welche Themen da vielleicht sonst unter dem Teppich gekehrt werden.

Michael: Genau, was mir da noch eingefallen ist, aber ich weiß nicht genau, ob es hundertprozentig passt. Weil wir ja gesagt hatten, man muss eben auch mal denen aus den anderen Bereichen vertrauen, dass sie die Dinge wissen und richtig machen, soll halt nicht heißen, genau wie jetzt mit den Menschen, mit weniger Erfahrung, dass man nicht Dinge hinterfragen soll und Fragen stellen soll. Ich glaube, man darf nur, wenn man in einem Thema wenig Erfahrung hat, muss man halt irgendwann akzeptieren, wenn jemand mit mehr Erfahrung einen vielleicht trotzdem einfach mal übersteuert. Zumindest wenn es jetzt nicht offensichtliche Quatsch-Argumente sind.

Lucas: Ja, absolut.

Michael: Und sonst zu diesem Skill Profil habe ich mir jetzt auch noch Gedanken gemacht gehabt. Man sagt ja häufig T-Shaped. Also man muss ja irgendwo anfangen und man hat ja quasi von Anfang an eigentlich die Wahl, ob man erst in die Tiefe oder erst in die Breite geht. Also ich wüsste nicht, ob es da einen klaren Gewinner gibt. Man muss halt einen der beiden Wege gehen. Und wichtig ist, glaube ich, danach mindestens einmal in die andere Richtung zu gehen, dass man zumindest mal so ein T wird. Und wenn man sich so eine ganze Karriere anschaut und ich meine, bei den Rentenzeiten, die wir heute rechnen, ist man ja dann doch schon 40 Jahre und länger in der IT, wird es automatisch werden, dass man, ich habe das so Pi genannt, man hat so ein T mit noch weiteren Vertiefungspunkten. Ich weiß nicht, ob es heute noch funktioniert, nur in der Spezialisierung überhaupt durchzukommen. Ich glaube, das ist sehr schwer. Selbst Frontend, ist ja nicht eine Spezialisierung. Frontend hat ja so viele Aspekte von Design mit CSS über JavaScript, dann hast du noch 80 SPA Frameworks, die du lernen kannst. Du musst das Web verstehen. Also auch das ist mehr als nur eine Spezialisierung, da sind so Subthemen drin.

Lucas: Ich gebe dir grundsätzlich recht. Ich glaube, wir hatten ja auch mal im anderen Kontext beide gesagt, uns fällt es immer schwer, Leuten Ratschläge zu geben, wie sie es machen sollen, weil wir selber ja vieles auch nicht so Design mäßig durchgezogen haben und gesagt haben, wir machen das genauso oder das ist der richtige Weg, sondern einfach geschaut haben, wie es halt so läuft. Aber ich merke, dass es für Juniors oft auch einfach einen Stress verursacht, weil sie nicht genau wissen, in welche Richtung sie gehen sollen. Wenn sie einen Rat wollen, dann sollten wir natürlich irgendwie schauen, dass wir einen Rat geben. Und mein Rat da ist halt schon mehr Zeit, auch in bestimmte Grundlagen zu investieren. Nehmen wir jetzt bei der Webentwicklung so was, wie das HTTP Protokoll oder wie funktionieren Forms oder so was, weil das die Sachen sind, die sehr lange jetzt gleich geblieben sind und wahrscheinlich auch in Zukunft noch gleich bleiben. Und wenn man aber quasi die ersten fünf Jahre seiner Zeit oder in der IT in ein bestimmtes Framework investiert und nur das versteht und das ist dann auf einmal nicht mehr in Mode, dann ist es halt vielleicht schwieriger noch mal Fuß zu fassen. Und ich weiß auch, dass es notwendig ist, sich ein bisschen zu spezialisieren, einfach weil man sonst gar nichts schafft. Aber ich würde trotzdem immer raten, zumindest mal diesen Teil des T’s nicht ganz zu ignorieren, weil sonst steht man halt wirklich doof da, wenn dort gerade keine Jobs sind oder wenn sich da irgendwas fundamental ändert. Und das passiert ja doch häufiger als man denkt. Ich habe sehr viel Erfahrung im Backbone.js, die mir heute nicht mehr so viel bringt.

Michael: Mir ist aufgefallen, dass wir auch an der Stelle uns eigentlich wieder zu ähnlich sind und wir jetzt kontrovers diskutieren. Ich glaube, die Teilnehmer meiner Spring Trainings, die können davon ein Lied singen. Ich fange da halt auch immer mit den Grundlagen an und zeig noch, wie man das früher mal mit XML konfiguriert hat. Also häufig kommen dann am Anfang schon so Fragen: Aber ich möchte doch hier nur eine Webanwendungen mit Spring Boot oder mit Rails machen oder so. Und klar, du kannst den Leuten helfen, dann kannst du ihnen erklären, so geht’s. Aber irgendwann sind die halt irgendwie im Regen stehen gelassen, wenn es etwas spezieller wird. Und gerade wenn du da fundamental die Basis Prinzipien mal verinnerlicht hast, kannst du die halt auch super schnell auf andere Dinge adaptieren. Übertrieben gesagt, wenn man einmal ein Web Framework so richtig verstanden hat, dann versteht man eigentlich fast alle oder erkennt zumindest mal 80 % der Konzepte wieder und muss dann halt nur noch die 20 % Rest lernen – so ein bisschen Pareto-mäßig.

Lucas: Definitiv. Ich würde es ein bisschen einschränken, weil ich würde sagen, wenn man eins von diesen MVC Web Frameworks gelernt hat, dann kennt man die anderen, weil es gibt ja doch diese sehr speziellen, wo du eine Desktop Anwendung schreibst und daraus kompiliert der eine Webanwendungen, die würde ich da jetzt nicht mit einbeziehen, aber grundsätzlich würde ich dir recht geben. Ich hatte da auch so ein Erlebnis. In einem meiner ersten INNOQ Projekte habe ich halt eine Komponente gebaut und jemand anders hat eine andere Komponente gebaut. Ich habe gesagt: Könntest du bitte noch diesen Header setzen und da befüllen, weil dann weiß ich, was da los ist und der Header ist ein guter Ort, das abzulegen. Und diese Person war davon überzeugt, dass man in seinem Web Framework keine Header setzen kann. Und nachher stellte sich raus, ja, das geht, weil das geht meines Wissens nach in jedem MVC Framework oder in diese Art von Framework und ich glaube, die Person wusste einfach nur nicht, was ein HTTP Header ist. Und das ist ja auch in Ordnung, Dinge nicht zu wissen, aber da merkt man dann halt okay, wenn du gar nicht weißt, was ein HTTP Header ist, dann würdest du an der Stelle vielleicht auch eine Lösung wählen, die ganz was anderes ist. Und das ist eben etwas, was unabhängig ist davon, ob man jetzt, wie du sich viel mit Spring beschäftigt oder wie ich mit Rails beschäftigt, weil das geht bei beiden und das sind grundlegend die gleichen Dinge, auch wenn da natürlich ganz viele Sachen drin sind in den beiden Frameworks, die völlig unterschiedlich funktionieren. Es ist trotzdem gut, wenn man weiß, dass das, was sie am Ende machen, ist, HTTP raus pusten und irgendwelchen HTML und JSON und was weiß ich Kram.

Michael: Ich hatte so eine ähnliche Geschichte. Das habe ich intern bei uns beobachtet. Da hat ein Kollege ewig lange gesucht, weil er wollte gerne einen PUT über ein HTML Formular machen. Und wenn du halt weiß, dass es dieses Muster gibt, weil HTML Formulare können ja nur post und get, das du dann häufig eben ein hidden field mit rein packst und dann intern umroutest, wenn du weißt, wie das heißt und dass es das gibt, dann fand man auch sofort, wie das in seinem Framework ging. Aber da er das halt nicht kannte, hatte er halt keine Chance. Da kann er ja auch nichts für. Aber das zeigt halt schon, dass wenn man eben nicht nur die Probleme löst, sondern auch das Konzept einmal lernt, dass es einem hilft.

Lucas: Ja, definitiv.

Michael: Bei uns ist irgendwann zuletzt .NET ganz groß aufgekommen und wiederentdeckt worden innerhalb INNOQ und dann habe ich mir ein Buch zu .NET MVC – ich glaube es hieß jetzt so – durchgelesen und dadurch, dass das ein MVC Web Framework ist.. [gemeint ist ASP.NET Core]

Lucas: Core hieß es doch, oder?

Michael: Ja, wie auch immer. Das, was wir da meinen. Hör auf das, was wir meinen. Auf jeden Fall dadurch, dass ich halt Spring und Spring Webteil auch super kenne, war es halt schon so, dass du ganz viele Seiten so nur halb lesen musstest. Jetzt kommt ein Filter. Okay, Filter weiß ich, was das ist? Da kann man noch mal kurz schauen, meinen die wirklich dasselbe, was ich kenne? Aber man muss halt das Konzept nicht neu lernen. Und da war es dann halt wirklich so, dass fast alle Konzepte deckungsgleich sind. Und dann kannst du plötzlich auf eine andere Sprache wechseln. Also ich bin da nicht so produktiv, ich werde da langsamer sein. Ich bin da bestimmt keine gute Ergänzung in einem Expertenteam, aber zumindest macht es einem Mut, dass man in so ein Thema relativ schnell auch reinkommt.

Lucas: Ja, definitiv. Und es ist manchmal halt verwirrend, wenn man merkt so, okay, ich habe mir unter dem Namen was ganz anderes vorgestellt und nachher merke ich, dass es eigentlich genau dasselbe Konzept, wie das, was ich schon kenne. Das ist ja so ein Problem in der IT, dass alle Dinge überall ganz anders heißen müssen. Da wäre manchmal so ein Wörterbuch ganz gut, wo einfach nur drinsteht, wie heißt denn eine Middleware aus Ruby in Java? Und da ist es immer ganz praktisch, das zu übersetzen, aber man erkennt es dann doch relativ schnell wieder, wenn man dann merkt, okay, da geht irgendwie was rein, dann leitet es weiter und am Schluss kann es noch mal den Output verändern. Okay, habe ich verstanden. Damit kann ich irgendwie was tun. Und auch die Web Frameworks haben ja auch eine gewisse Ähnlichkeit. Die haben sich gegenseitig immer wieder beeinflusst und deswegen erkennt man Dinge wieder. Es gibt eben Konzepte, die gibt es in manchen Web Frameworks und die gibt es in anderen nicht. Beispielsweise Dependency Injection, wirst du in einem Ruby Framework eher nicht finden. Das kennst du dann auch vielleicht gar nicht, wenn du dann in eine andere Welt kommst, wo es das gibt. Aber Controller findest du halt in jedem von diesen Frameworks und überrascht dich dann auch überhaupt nicht, wie das funktioniert oder dass es da ist.

Michael: Ansonsten ist mir noch eingefallen, ich habe mich in dem Talk noch selber zitiert. Ich sage immer so was, wenn ich irgendein Thema habe, wie würde man dieses Thema perfekt umsetzen, also zu einer Art Perfektion und das ist dann für mich so ein Fixpunkt, den ich anstrebe, weil ich weiß, dass ich in der Realität sowieso Abstriche machen werden muss. Also die Realität lässt uns fast nie das Perfekte an der Stelle machen. Und ich habe immer Angst, wenn ich mir vorher da schon nicht den perfekten Punkt als Punkt, wo ich hin will suche, dass ich dann halt doppelt Abstriche mache. Und deswegen glaube ich schon, dass es bei ganz vielen Themen, auch wenn man technisch exzellent sein möchte, dass man dann eben wissen muss: Was wäre eigentlich das Perfekte? Und jetzt erreiche ich bewusst nicht das Perfekte, weil. Also weil zu wenig Zeit oder weil es passt doch gerade nicht, oder ich brauche hier keine Tests schreiben in dem Projekt, weil das zeige ich einmal in der Demo und danach werfen wir den Code weg. So, und das ist aber auch wieder was, was man einfach nur über Erfahrung sammelt. Ich glaube, es ist ganz schwierig, mit einem Jahr Berufserfahrung zu behaupten von sich, man wäre exzellent in einem Thema. Das geht bestimmt auch. Es gibt so Menschen und es gibt auch kleine Themen. Aber so generell, glaube ich sogar, dass eigentlich niemand von sich sagen können sollte, er ist exzellent in der Softwareentwicklung, dann kommen wir in diese Anmaßung und Übertreibung.

Lucas: Ja, definitiv. Ein Thema, was für mich so in einem Grenzgebiet zwischen Persönlich und Team ist, ist das Thema Dokumentation. Ich finde, dass man schon die Verantwortung hat, die Dinge, die man tut, zu dokumentieren, damit es anderen Leuten klar ist, was man tut. Da ist man dann sehr schnell bei dem Team, weil darauf basiert, dass die anderen dann wissen, was man da gemacht hat. Ich sehe zu oft in Projekten, dass Leute in einem Pull Request schreiben, ja, die Dokumentation davon kommt später. Es ist jetzt aber erst mal viel zu dringend und deswegen und dann bleibt für immer so ein TODO Kommentar: Bitte ergänze hier die Dokumentation. Also ich möchte damit nicht Javadoc schlechtreden, aber diese Javadoc Kommentare, wo man über jede einzelne Methode den Namen der Methode quasi noch mal als Satz drüberschreibt, sondern ich meine tatsächlich, wenn man eine Architektur Entscheidung trifft, dass man die irgendwo so nachvollziehbar dokumentiert, dass der Rest versteht, was man da getan hat, dass man selbst versteht, was man da getan hat. Und ich finde auch, gerade als Consultant hat man da noch mal eine besondere Pflicht, weil es kann ja immer sein, dass man irgendwann nicht mehr da ist und die Wahrscheinlichkeit ist bei einem Consultant höher als bei einer festangestellten Person. Das heißt, da sollte man damit rechnen, ja, vielleicht ist das Budget leer und dann bin ich dann nächste Woche schon nicht mehr da. Also sollten wir da besonders Rücksicht darauf nehmen, dass wir alles, was wir machen, nachvollziehbar gestalten. Und ja, das kann man alleine nicht schaffen, weil man muss ja seine Dokumentation in den Gesamtkontext einbetten. Aber ich finde, wir sollten dafür Verantwortung übernehmen und mitgestalten, dass die Dokumentation geschrieben wird.

Michael: Es ist leider nicht meine Stärke, muss ich gestehen. Ich bin bei dem Thema Dokumentation auch eher auf der Seite von weniger als mehr. Aber ich muss jetzt drüber nachdenken, was du gesagt hast. Da kommen wir jetzt in dem Podcast nicht mehr zu.

Lucas: Okay, alles klar. Also ich meine halt nur, ich sehe wenig Wert darin, dass jede einzelne Methode ein Kommentar bekommt.

Michael: Das ist unbestreitbar. Das ist, glaube ich eher noch so, dieses Vorurteil von Enterprise Java von vor zehn Jahren was da in deinem Kopf rumspukt.

Lucas: Ich habe auch extra betont, es geht hier nicht um Java, weil ich habe das zum Beispiel mal in einem Projekt erlebt, das war in TypeScript. Und da hat auch jemand über jede einzelne Methode einen Kommentar drübergeschrieben. Und der war völlig redundant zu dem Namen der Methode quasi. Also da stand einfach nur der Name der Methode, noch mal als kleiner Satz und dann darunter die Parameter, die dahinterstanden und deswegen, ich sage nur Javadoc Style, weil ich das so kenne als den Begriff davon, diese Kommentare darüber. In Ruby Projekten, habe ich das tatsächlich, glaube ich noch nie gesehen, dass das jemand macht. Aber es ist vielleicht auch wieder so eine Kulturfrage. Aber in TypeScript Projekten habe ich das auf jeden Fall schon gesehen, dass das dort sehr intensiv gemacht wird. Mir geht es wirklich mehr um das bigger picture, was man nicht sieht, indem man sich eine einzelne Klasse oder eine einzelne Datei anschaut.

Michael: Macht ja zum Beispiel auch einen Unterschied. Ich nehme an, wenn du in Ruby Bibliotheken hast, dann werden die Leute ja auch so eine Art Klassenbibliothek Kommentare schreiben. Da ist es auch wieder mehr gefordert als in der Anwendungsentwicklung. Das muss man unterscheiden. Das Problem bei so was wie Dokumentation auch für dieses bigger picture ist ja immer, wenn man das zu detailliert macht, dann veraltet es zu sehr, weil man vergisst das anzupassen. Und man muss natürlich immer, während man die Dinge tut, erkennen, dass man da gerade vielleicht an einem spannenden Punkt ist. Das ist auch, glaube ich etwas, was man wieder nur durch Erfahrungen lernt oder wo manche auch besser drin sind als andere wahrscheinlich so Dinge zu sehen. Aber prinzipiell stimme ich dir zu.

Lucas: Also das worüber wir hier sprechen, ist ja nicht etwas, was wir erreichen, sondern das, was wir zu erreichen versuchen anzustreben. Und ich glaube, wir müssen da drin alle immer ein bisschen besser werden. Aber gerade merkst du es oft als Konsument. Du merkst so, warum wurde das jetzt hier so gemacht? Ich hätte jetzt so gerne zwei, drei Sätze dazu, warum das so gebaut wurde. Vielleicht ist das ja auch gut so, aber vielleicht ist es auch heute nicht mehr gut so, weil es nicht mehr zu den Anforderungen passt. Und genau an solchen Stellen, da wünscht man sich das aufzuschreiben. Und ich glaube, ich versuche mich dann halt immer hineinzuversetzen in jemanden, der das halt in einem Jahr liest. Welche Frage, würde diese Person sich stellen, wenn sie das liest, was ich hier geschrieben habe. Und die fragt sich bestimmt nicht, was diese eine Zeile getan hat. Das kann sie auch selber rausfinden, sondern die fragt sich, was hat dieses Konzept hier zu suchen und warum gibt es das und warum passt das zu diesem Problem? Das ist meine Meinung dazu.

Michael: Ja, du bist da wahrscheinlich besser als ich. Ich lande zu oft bei „Ist doch offensichtlich“ als Antwort. Was natürlich auch total überheblich ist. Das erfordert ja schon, dass man sehr stark über sich selbst reflektieren kann und aus sich selber rauskommt. Ist das falsche Wort, aber sich selber von außen noch mal draufschaut und quasi in dem Moment seinen kompletten Kontext vergisst, ist nicht einer meiner Stärken, aber auch das ist okay. Ich meine, auch das gehört wahrscheinlich zu technischer Exzellenz, einfach Themen zu kennen, in denen man nicht so gut ist, wo man dann auch weiß, hier muss ich oder sollte ich einfach um Hilfe fragen. Genau, auch das gehört ja irgendwie dazu.

Lucas: Ja.

Michael: Beim Exzellenz Thema, dann denkt man immer an jemanden, der alles weiß und niemandem um Hilfe fragt. Und eigentlich gehört das eben genauso dazu, exzellent zu sein. Also seine Blind Spots zumindest ein paar davon, sag ich mal zu kennen. Und was ich als Feedback auf den internen Talk noch bekommen habe, dazu gehört auch, dass man an seinen Fehlern aktiv arbeitet. Also dass man erst mal überhaupt anerkennt, dass man vielleicht Fehler hat und Fehler macht. Und dass man sich dann überlegt, wie man denn die irgendwie in Zukunft vermeiden kann, zumindest wenn es grobe Dinge sind. Auch das gehört für mich persönlich dazu. So eine Selbstreflexion.

Lucas: Stimme ich dir zu. Und ich finde es auch wichtig, dass egal wie viel Erfahrung man hat, ist es immer so, dass eine Person wird immer mehr Fehler machen als mehr als eine Person. Also es ist nicht induktiv, 15 Personen machen auf jeden Fall weniger Fehler als 16, das glaube ich nicht. Aber eine Person macht immer am meisten Fehler, weil es gibt immer irgendwas. Du bist an dem Tag vielleicht nicht so gut drauf und hast einfach irgendwas übersehen oder das ist wirklich so ein blind spot, den du vielleicht noch nicht kennst. Und es ist immer gut, sich Feedback einzuholen für das, was man tut, damit man einfach noch mal merkt, wie sieht das denn von außen aus, was ich hier gerade gebaut habe? Also für mich geht das dann schon sehr stark in diesen Team Teil über. Aber ich persönlich sehe einen sehr hohen Wert in Reviews von allem, weil das einfach mehr Fehler findet als alle anderen Methoden, die ich kenne.

Michael: Ich lese gerade ein Buch und da ist das tatsächlich auch so, also bei Texten ist es ja ganz häufig so. Man selber schreibt den Text und man wird halt blind für das, was man da tut. Also man sieht seine Fehler gar nicht und bei Büchern gibt es dann ja zumindest mal einen, der es Korrektur liest. Und trotzdem bin ich in diesem Buch über den Begriff „String Data“ gestolpert. Es war gemeint Spring Data aber ja, irgendwie ist aus dem P ein T geworden. Ansonsten macht die Autokorrektur auch immer ganz gerne Sprint Data aus Spring Data. Da muss man schon aufpassen.

Lucas: Klar, dann sagt man so: Hä? Wie konnte mir das denn passieren? Eigentlich weiß ich doch, dass das anders heißt. Aber man sieht es dann nicht. Selbst wenn man es dreimal liest, sieht man den Fehler nicht. Und ich glaube, das sollten wir uns alle auch noch mal klar machen, dass das beim Code auch nicht anders ist. Da ist es einfach so, Mist, an der Stelle hätte ich das niemals machen sollen. Das ist totaler Quatsch. Und irgendjemand anders bemerkt es. Und ich finde, und das wäre für mich von meiner inneren Kopfliste der letzte Punkt von diesem persönlichen Bereich, den hast du eben auch schon angeschnitten, aber ich würde gerne noch mal ganz explizit sagen, es ist einfach Kritikfähigkeit, dass man fähig dazu ist, Kritik anzunehmen und auch Kritik einfordert, weil ohne Kritik können wir uns nicht weiterentwickeln. Ohne Kritik können wir nicht besser werden in dem wie wir arbeiten, aber auch, wie wir für andere Leute ihre Probleme lösen. Das geht einfach nicht und wir müssen dazu bereit sein. Und ich meine damit natürlich nicht, dass man sich jede Art von Kritik gefallen lassen muss. Manche Kritik ist einfach unverschämt und sollte nicht geäußert werden. Aber ich meine, wenn es eine vernünftig formulierte Kritik ist, dann sollten wir die annehmen. Und auch wenn das dann bedeutet, an der Stelle habe ich etwas falsch gemacht, dann sollten wir dafür eigentlich eher dankbar sein, weil dann wissen wir ja, dass wir es vielleicht in Zukunft besser machen würden. Und das ist für mich der wichtigste Punkt. So ähnlich wie in der agilen Welt für mich die Retrospektive eine der wichtigsten Punkte ist, weil das eben der Punkt ist, an dem wir uns weiterentwickeln können. Weil egal wie gut die Methodik oder wir selbst am Anfang sind, wir müssen uns an neue Anforderungen und neue Umgebungen anpassen. Und das können wir nur, indem wir halt Feedback annehmen, sonst wird das nicht funktionieren, meiner Meinung nach.

Michael: Lustig, weil ich dir zustimme, also wir reden über technische Exzellenz, aber ganz viele der Themen sind eigentlich doch sehr soft skillig. Gar nicht technisch. Vielleicht ist das auch der Grund, wieso dann manchmal dieses Engineering Exzellenz gewählt wird, weil das vielleicht anders ist.

Lucas: Guter Punkt. Für mich ist zumindest Engineering auch ein Begriff, der technisch klingt. Aber ich glaube, du hast recht, es ist vielleicht weniger stark als bei diesem technischen Teil.

Michael: Ich habe das Gefühl, bei Technical denkt man sofort nur noch an Programmiersprachen oder Kubernetes Cluster oder CSS Regeln. Und bei Engineering ist das Drumherum noch so ein bisschen mit im Begriff drin. Aber bei beidem neigt man trotzdem sehr schnell ins Technische zu kommen.

Lucas: Die Hörerinnen und Hörer, die wissen jetzt an dieser Stelle, welchen der Titel wir gewählt haben für die Folge. Wir wissen es noch nicht. Aber ich glaube, du hast recht. Ich glaube, das ist so eine Binsenweisheit, aber die trotzdem manchmal gesagt werden muss, dass das eben nur ein Teil des Jobs ist, die Programmierung oder das Operations usw., das ist nur ein Teil. Der große Teil ist der Soziale- und Interaktionsteil, der mehr Einfluss auf das Ergebnis hat als der Rest.

Michael: Eberhard sagte das mal so plakativ. Also wenn man ihm von Anfang an gesagt hätte, dass bei IT eigentlich immer nur um Menschen geht, dann hätte er was anders gemacht. Da will man nur in Ruhe im Keller sitzen und seinen Code runterschreiben, aber ständig muss man leider mit anderen Menschen interagieren.

Lucas: Das stimmt. Hast du noch was zu dem persönlichen Bereich?

Michael: Das geht sowieso ziemlich fließend über.

Lucas: Ist mir auch aufgefallen.

Michael: Wir sollten zum anderen Teil auch noch kommen, bevor die Zeit vorbei ist.

Lucas: Genau, das stimmt. Bevor der böse Lucas den Timer drückt. Also in diesem Teambereich, da gibt es ganz viele Sachen. Wir hatten es im Anfang schon gesagt, es ist wichtig, eine Umgebung zu schaffen, in der alle produktiver sind. Das ist wichtiger als die Produktivität des Einzelnen zu Lasten der Produktivität der anderen. Das ist einfach quasi mathematisch logisch, dass das nicht funktioniert. Aber es hilft auch bei der Motivation der anderen Leute, wenn die nicht das Gefühl haben, sie sind dabei, immer nur hinter einem aufzuräumen, weil man so super schnell alles durcharbeitet. Aber was ich da sehe in der Teamarbeit, ist immer das Verhalten vorzuleben, was man von den anderen sehen möchte. Für mich ganz klar beim Thema Pull-Request, sehe ich das sehr oft. Sagen wir jetzt mal, du hast dich in dem Team darauf geeinigt, wir machen Pull-Request und nicht Trunk-based Development. Dann ist es für mich essenziell wichtig, dass Pull-Request Reviewbar sind, sonst sind sie Quatsch. Und wann ist ein Pull-Request Reviewbar? Wenn er eine überschaubare Größe hat, können wir drüber streiten, wie viel das ist, aber überschaubar. Wenn die Intention der Änderung klar gemacht wird und wenn das Reviewen einem so einfach gemacht wird wie möglich. Sagen wir mal, wir machen eine optische Änderung, kann so ein Screenshot einem viel helfen. Da sieht man, so sah es vorher aus und so sieht es nachher aus. Okay, ist besser, cool. Hilft einem zu verstehen, worum es geht. Da gibt es ganz viele Sachen. Ich war in einem Projekt, da wurde das extrem stark von einem der Entwickler vorgelebt und da hat sich der Rest auch drangehalten. Die haben halt gemerkt, hey, das ist ja super cool, wenn ich das reviewe, dann möchte ich, dass euch das genauso einfach fällt. Und ich finde, da sollten wir immer schauen, dass wir so ein bisschen da die Vorbildfunktion einnehmen zu sagen, ich mache euch das Leben einfacher und dann hoffen, dass die anderen einem das Leben auch einfacher machen. Und in dieser Umgebung arbeitet man dann halt gerne, weil man sagt so: Hey, es macht ja Spaß hier ein Review zu machen und nicht wie ich das auch schon mal hatte, ein Review von irgendwie gefühlt 1000 Zeilen Go Code Change, wo du keine Ahnung hast, wo was reingesteckt wurde. Und du sitzt dann davor und denkst so: Ich kann jetzt nur zwei Knöpfe drücken ja oder nein und keine Ahnung, was ich davor tun soll. Und ich finde, das ist ein ganz wichtiger Teil. Und da auch gerade, wenn man unerfahrene Leute im Team hat, denen dabei zu helfen, ihre Changes verständlicher zu machen für den Rest.

Michael: Ja, das hatte ich in einem meiner letzten Projekte tatsächlich auch. Da war auch ein Kollege dabei vom Kunden, der gerade seine Ausbildung fertig hatte und der war super und hat immer unwahrscheinlich kluge Fragen gestellt. Und mit dem sind wir auch über die Zeit, also auch ich selber bin dazu gekommen, dass unsere Pull-Requests immer und immer kleiner wurden. Häufig hatten wir dann echt Features, wo wir erst noch zwei, drei Pull-Requests davor gebaut haben, wo wir das Refactoring halt wirklich in explizite Pull-Requests davorgesetzt haben. Obwohl ich der deutlich Erfahrenere von uns beiden war, führte das bei mir halt auch zu so einem Lernprozess. Und ich neige auch dazu, dass meine Pull-Requests etwas zu groß sind. Jetzt nicht so ganz riesig, aber schon noch zu groß und ich habe dann halt irgendwann angefangen die mit Git einfach wieder kleiner zu machen im Nachhinein. Das Dumme war, das kostet dann wieder doch ein bisschen Zeit, das im Nachhinein noch mal zu verändern mit der ganzen Historie. Aber dadurch war es halt für den Reviewenden einfacher. Und so hat sich das dann irgendwann im Team auch durchgesetzt, dass immer alles viel, viel kleiner wurde, immer die kleinsten Schritte, die gingen, gemacht haben und das ganze Team davon profitiert hat.

Lucas: Ja, dieses „Mache kleine Änderungen“ ist, glaube ich auch so ein wichtiges Prinzip. Und ich stimme dir zu, dass das oft mehr Arbeit ist als der Mensch, der es schreibt. Aber auch wenn man dort wieder quasi den Gesamtaufwand im Team sieht, ist es glaube ich so, dass der Gesamtaufwand kleiner ist, weil diesen Riesen-Change, der ist einfacher zu erzeugen aber viel schwerer zu reviewen. Und andersherum ist dieser einfache Change zwar etwas schwerer zu erstellen, aber viel einfacher zu reviewen und dadurch in der Summe kommt da halt eine kleinere Zahl raus, glaube ich.

Michael: Zumal sich das dann auch noch, wenn du Pech hast, akkumuliert. Weil ich habe ja schnell diesen großen Change gemacht, jetzt muss der ewig reviewen und in der Zeit kann ich den nächsten Riesen-Change bauen. Man hat so einen Pull-Request Berg vor dir ja, den du nicht mehr abgearbeitet bekommst. Dann kannst du wirklich nur noch sagen: Ich vertraue dir, ich vertraue dir nicht.

Lucas: Ja, definitiv.

Michael: Ansonsten wenn ich mich an mein halbes BWL Studium, ich habe Wirtschaftsinformatik studiert, zurückerinnere, was man Management by Example nannte, also mit gutem Vorbild voraus gehen. Genau, ist auf jeden Fall sinnvoller als all die anderen Management by. Mein Favorit ist Management by Fear, wo man immer so tut, als geht die Welt unter, damit alle Leute produktiv sind, weil sie Angst haben. Ist völlig absurd.

Lucas: Sonst die Decke einstürzt. Ich verstehe, guter Punkt. War mir so nicht bewusst, aber ja.

Michael: Ansonsten neben dieser Vorbildfunktion ist eigentlich immer Hilfsbereitschaft. Es ist halt auch individuell, aber eben auch im Team. Ich glaube, ein Team, wo man sich gegenseitig hilft, ist mit Sicherheit schneller, als wenn alle neben sich her oder noch schlimmer gegeneinander arbeiten.

Lucas: Und damit verbunden würde ich auch sagen, Fragen auch zu stellen. Also dass man sowohl selbst sagt: Hey, ich frage, anstatt es einfach danach zu googeln. Ich weiß, da muss man auch eine Balance finden, aber dass es auch allen klar ist, dass wenn ihnen etwas unklar ist, dass sie eine Frage stellen dürfen. Das ist eine Sache, die finde ich total wichtig, weil du das super oft hast, dass irgendjemand in so einem Tunnel verschwindet oder in einem Loch verschwindet. Dann kommt zwei Tage später raus und sagt: Eigentlich wusste ich gar nicht genau, was ich tun soll und habe mich dann aber nach zwei Tagen kaum noch getraut zu sagen, dass ich das gar nicht mehr weiß. Und da hätte es so viel geholfen quasi bei dem Besprechen einmal die Frage zu stellen.

Michael: Man muss sich das trauen dürfen. Das heißt halt auch man muss die passende Atmosphäre schaffen. Also sollte niemand Angst haben. Vor allen Dingen auch keine Angst, Fehler zu machen. Weil ich glaube, wenn man eine gewisse Geschwindigkeit erreichen will, dann muss man eben auch riskieren, dass ab und zu mal Fehler passieren. Es sollte nicht zweimal derselbe Fehler passieren, das wäre blöd. Aber dass Fehler passieren, ist eben voll normal. Und dann muss man die halt korrigieren. Und ja, das muss man sich eben auch trauen dürfen. Und auf der anderen Seite muss man aber auch sagen, man darf nicht übermütig werden. Vollkommen losgelöst laufen, sondern man muss diesen Mittelweg zwischen Angst und Übermut finden, wo die Leute eben irgendwie mutig vorangehen können, Fehler machen können und dafür nicht geköpft werden, aber eben an passenden Stellen dann vielleicht auch wissen, jetzt muss ich hier ein bisschen sorgfältiger sein und vielleicht mir ein bisschen mehr Zeit lassen für die Entscheidung oder das, was ich da tue.

Lucas: Ja, stimme ich zu. Absolut.

Michael: Mich regt das zum Beispiel ganz häufig auf, wenn Leute sagen: Ja, aber freitags deployt man ja nicht. Ich finde das ist immer so kaputt. Weil wenn man freitags nicht deployt, dann sollte man besser auch donnerstags nicht deployen. Aber es ist natürlich trotzdem eine blöde Idee, wenn der letzte, der Freitag geht, wenn man den so ein Modell hat, dann noch eben 500 Zeilen Code committed und in Produktion pusht. Also da muss man halt auch so eine feine Balance finden. Ist wieder ein plakatives Beispiel, aber irgendwas müssen wir ja hier…

Lucas: Ja, absolut. Na ja, aber diese ganz platten Weisheiten wie „Freitags wird nicht deployt“ würde ich grundsätzlich erst mal anzweifeln, weil ja, wir sollten ja eigentlich die Fähigkeit haben – gehört für mich auch wieder zu der Exzellenz des Teams zu jeder Zeit – deployen zu können und das heißt auch zu jederzeit zurückrollen zu können. Das heißt, wenn am Freitagvormittag etwas deployt wird, was doof ist, dann können wir es Freitagmittag wieder zurückrollen und alles ist wieder in Ordnung. Und ich finde es auch wichtig dabei, sich mal klar zu machen, dass es super krass auf den Kontext ankommt. Bei manchen Sachen ist es tatsächlich völlig egal, wenn du freitagabends was kaputt machst, weil am Wochenende benutzt das Ding gar keiner, was du da gebaut hast. Und deswegen ist es auch super, vielleicht freitagabends noch eine Wartungsarbeit oder sowas zu machen, weil falls es kaputt ist, kann man es in Ruhe am Montag fixen, ist gar nichts schlimmes passiert. Und in anderen Kontexten ist das Wochenende quasi die heißeste Phase, wo alles läuft. Und da muss man damit natürlich anders umgehen. Also ich finde, der Kontext, das muss man sich immer wieder klar machen. Und auch gerade wieder spreche ich hier die Consultants unter unseren Zuhörerinnen und Zuhörern an, wenn man ein Projekt wechselt, muss man sich auch noch mal kurz umschauen, ob der Kontext derselbe ist wie im vorigen Projekt, weil manche von den Annahmen, die man hat, vielleicht in diesem Kontext nicht mehr gelten. Und deswegen sollte man da besonders Rücksicht darauf nehmen. Ich finde, dieses freitags deployen ist dafür ein ganz gutes Beispiel.

Michael: Ich bin deswegen immer ganz dankbar, dass ich noch nicht den Kontext hatte, wo es in, sage ich mal, erster bis dritter Kettenglied um Leben geht. Medizinsoftware oder für Flugzeuge oder selbstfahrende Autos da ist vielleicht halt so eine Cowboy Mentalität – das ist auch wieder dieses blöde Klischee – aber wir pushen einfach mal schauen, was da passiert, ist vielleicht nicht die beste Idee, wenn es um Leben geht. Wenn es um eine Menge Geld geht, ist es vielleicht auch nicht die beste Idee, aber das ist halt irgendwie mehr virtuell und ist trotzdem keine gute Idee. Sollte man nicht tun, aber wenn es um Leben geht oder so, dann genau. Also auch das ist halt Kontext.

Lucas: Definitiv.

Michael: Ansonsten was ich immer noch feststelle ist, ich habe manchmal das Gefühl, dass unsere Industrie oder ein Teil davon auch häufig immer noch erwartet, dass sich Menschen in der Freizeit fortbilden. Finde ich mittlerweile auch ein bisschen absurd. Das gehört für mich auch in dieses Umfeld für technische Exzellenz. Also neben dem produktiven Arbeiten an dem konkreten Problem muss man glaube ich, in irgendeiner Form den Leuten Freiheit zur Weiterentwicklung während der Arbeitszeit ermöglichen.

Lucas: Und ich finde auch, das gegenseitig aufeinander ein bisschen aufpassen und bemerken, wenn vielleicht auch jemand anderes zu viel arbeitet. Also jetzt unabhängig von Freizeit noch Weiterbildung, aber man merkt so hey, die Person, die ist immer nach mir noch da und immer vor mir schon im Slack. Vielleicht frage ich mal nach, wie es da so ist. Vielleicht überarbeitet sich da ja gerade jemand. Und ich finde, das gehört auch dazu, auch wenn das überhaupt nichts mit Technik zu tun hat, aber dass man sich gegenseitig ein bisschen unterstützt.

Michael: Ja, das ist ja auch einer der Effekte mit Spezialistentum und 10x Programmer, weil wenn man jemanden hätte, der so ist, der macht ja auch für sich selber sich total viel Stress. Wahrscheinlich unbewusst, weil er weiß, wenn er nicht da ist, dann wird wahrscheinlich irgendwas untergehen. Und ich meine, alleine deswegen ist es vielleicht schon keine gute Idee, dass man gewisse Stellen hat, die nur ein Mensch bedienen kann, sondern das sollten halt immer mindestens mal zwei, idealerweise das ganze Team grob abdecken können.

Lucas: Da würde ich direkt auch zu dem nächsten Punkt überleiten. Auch darauf achten, dass weder man selbst noch jemand anderes zu so einem Kopf Monopol wird, weil man vielleicht erst mal denkt: Ach, das ist gut, weil dann ist mein Job sicher und alles ist gut. Aber der Stress, den das verursacht, die einzige Person zu sein, die das kann, bedeutet, dass du nie richtig Urlaub hast, dass du ein schlechtes Gewissen hättest, wenn du das Projekt verlässt oder so was. Und das sollte nicht so sein. Es sollte immer so sein, dass zumindest eine weitere Person auch das weiß, was du da weißt. Ja, auch hier wieder, trifft besonders auf Consultants zu, aber trifft auf jeden Fall auch auf Festangestellte zu, weil wir wollen alle Urlaub nehmen und ich finde, wir sollten auch alle Urlaub machen, ohne dass wir unseren Notebook dabei haben und einfach mal uns erholen und nichts damit zu tun haben. Und wenn was kaputt geht, dann kümmern sich die Leute drum, die gerade keinen Urlaub haben. Ich finde, das ist auch ein ganz wichtiges Ding und damit verbunden auch selber darauf zu achten, dass wenn man arbeitet und jemand anders hat Urlaub, diese Person dann auch nicht aus dem Urlaub heraus zu stören, nur weil man noch eine Kleinigkeit will. Selbst wenn es dann vielleicht mal brenzlig wird, dann zu sagen, komm, wir bekommen das auch ohne die Person hin, damit die Person sich mal richtig erholen kann und das gehört so ein bisschen zusammen, finde ich als ein Themenkomplex, ist für mich aber ein ganz wichtiger Aspekt.

Michael: Ist ja auch nicht nur Urlaub, sondern auch Krankheit. Ich weiß nicht, das ist auch ein bisschen kaputt vielleicht an unserer Kultur, dass es diese Heldengeschichten von Menschen gibt, die noch im Krankenhaus am Laptop vor der OP oder ein letztes Telefonat quasi auf dem Hinschieben machen. Und eigentlich ist es ja alles andere als heldenhaft. Eigentlich ist das dumm plakativ gesagt. Das ist das falsche Wort wieder. Tut mir leid, wenn das jemand gemacht hat, aber es ist eigentlich kein erstrebenswerter Zustand.

Lucas: Absolut. Ein Thema noch, mit dem ich mich beschäftigt habe, war dieses Thema Wertschätzung. Also für was drücke ich Wertschätzung aus? Also ich hatte es in einem Projekt, da habe ich gemerkt, dass die Leute zwar Wertschätzung empfinden, aber sie nicht ausdrücken. Das ist auch schon ein Problem. Also wir sollten auch alle gemeinsam sagen: Hey, cool, wir haben es geschafft, dieses Ding jetzt zu bauen. Und einfach mal sich auf die Schulter zu klopfen. Man muss da jetzt nicht direkt eine Party schmeißen, aber einfach mal gegenseitig sich klar zu machen, dass man es geschafft hat und dass das was Erstrebenswertes war und dass wir glücklich darüber sind. Ich glaube, das ist etwas, wenn man merkt, dass das in einem Team so gut funktioniert, dass man das unterstützt. Und wenn man schon auf diesem Level ist, dass Leute Wertschätzung ausdrücken und sagen, dass das cool ist, dann auch darüber nachzudenken, an welchen Stellen fehlt vielleicht trotzdem noch Wertschätzung. Ein Thema zum Beispiel sind so Maintenance Aufgaben. Sagen wir mal, wir haben so ein Projekt und da ist eine Person, die kümmert sich immer darum, dass die Dependency geupdated werden, ist keine glorreiche Aufgabe. Es wird auch nie einer von dem Management kommen und sagen: Super, heute wieder 21 Updates gefahren. Klasse gemacht! Aber wir alle profitieren ja davon, wenn das jemand macht. Wir müssen nämlich nicht dann irgendwann so ein Riesen-Update machen, was total schmerzhaft ist und wo alles kaputt geht und dann auch einfach das zu wertschätzen und zu sagen: Hey, vielen Dank, dass du diese Aufgabe übernommen hast. Ich weiß, ist nervig, aber cool, dass du es gemacht hast. Und das ist jetzt nur ein Beispiel. Da gibt es auch viele andere Sachen, wo die Wertschätzung oft fehlt, dass man da genau doch mal drauf achtet und sagt so: Hey, finde ich total klasse. Und dann vielleicht auch mal im Team Chat reinschreibt: Danke an X für diese Aufgabe. Einfach nur um das einfach auszudrücken, damit das nicht unter den Tisch fällt.

Michael: Genauso ein bisschen die Kombination Lob ist das Gegenteil zu dieser Kritikfähigkeit. Und das andere ist eben da auch auf Menschen zu achten, die vielleicht sonst nicht so wahrgenommen werden, weil sie vielleicht nicht die Selbstdarsteller oder die Menschen sind, die aus sich herauskommen. Ganz lustig, ich habe mir Gedanken gemacht zur Wichtigkeit von Personen innerhalb von Organisationen. Und das, was du beschrieben hast, ist glaube ich bei mir als Stereotyp der interne Räumer gewesen oder interne Räumerin, die halt einfach diese Aufgaben übernimmt, die gemacht werden müssen, die irgendwie eigentlich auch wichtig sind, aber die halt keiner nach außen sieht, weil die eben keinen großen Ruhm hervorbringen. Ganz lustig.

Lucas: Ja, definitiv. Guter Punkt. Räumer ist ein guter Begriff.

Michael: Weiß ich nicht, aber das war es was mir nachts im Hotelzimmer eingefallen ist als ich darüber nachgedacht habe.

Lucas: Hast du noch Punkte auf deiner Liste?

Michael: Die Teamliste mit der hast du mich ehrlich gesagt vollkommen überrascht. Die hatte ich so explizit gar nicht so auf dem Schirm.

Lucas: Okay.

Michael: Aber die passt perfekt dazu und ich habe die immer implizit mitgedacht, weil für mich, in Software gibt es halt eigentlich kein Individuum, was im luftleeren Raum existiert. Ich finde, generell haben wir sehr locker über alles gesprochen, zumindest was ich so im Kopf hatte.

Lucas: Ich habe noch einen Punkt stehen, der mir noch wichtig ist. Also ich hatte eben schon gesagt, Fragen zu stellen ist wichtig, aber ich finde es auch wichtig, gute Fragen zu stellen. Jetzt kommt wieder dieser blöde Spruch: Es gibt keine doofen Fragen. Aber das hatten wir eben auch schon an einer anderen Stelle. Es gibt immer die Frage, wo schiebe ich die Arbeit hin? Und als Fragensteller kannst du dich auch entscheiden: Stelle ich die Frage so, dass sie für mich wenig Arbeit ist oder für die Person, die sie beantwortet, wenig Arbeit ist. Und wenn wir unvorsichtig sind, dann können wir einfach alle Fragen so stellen, dass sie für uns ganz wenig Arbeit sind, aber für die, die sie beantworten, super viel Arbeit sind. Beispiel: Ich stelle so eine super allgemeine Frage, worauf dann erst mal 15 weitere Fragen zurückkommen müssen, was genau ich meine, anstatt direkt die Frage so zu stellen, dass mein Kontext mit inbegriffen ist, damit man die Frage einfach beantworten kann. Oder ich sage XY ist kaputt und schicke dann so einen Code Snippet von 400 Zeilen und unten drunter irgendwie so einen Log von 3000 Zeilen und sage: Es ist kaputt. Anstatt, es gibt ja diese Idee von diesem minimal Case, dass man halt so den minimalsten Fall raus extrahiert, um zu sagen, das ist kaputt. Kann mir jemand erklären warum? Weil das kann jemand dir erklären, das aus diesem Riesen Wust rauszuziehen ist halt die Arbeit, die du eigentlich schon hättest machen können. Und das finde ich, ist auch eine ganz wichtige Eigenschaft, weil das auch wieder ein bisschen auf diese Respekt Frage zurückkommt. Ich respektiere deine Zeit im Projekt genauso oder mehr als meine eigene. Das heißt also, wenn ich mich entscheiden kann, gebe ich dir diesen Kram oder übernehme ich mehr von dieser Zeit, versuche ich mehr Zeit bei mir abzulegen, weil deine Zeit wertvoll ist. Und ich finde, das sollten wir auch in einem Team etablieren. Zu überlegen, wie bekommen wir es hin, dass Fragen zu beantworten oder Fehler zu beschreiben oder Fehler zu verstehen möglichst wenig Arbeit ist für die Leute, denen wir das zumuten.

Michael: Genau eigentlich dasselbe wie mit den Pull-Requests. Vom Prinzip her ist es auch da, wenn du den so klein wie möglich und so gut für Reviews machst, dann hast du halt mehr Arbeit. Also ich lese immer noch mal komplett meine Pull-Requests durch, bevor ich die jemand anderen gebe, weil ich eben versuche, die Zeit des anderen möglichst zu schonen. Ansonsten fallen mir dazu nur noch mehr Horror Stories ein. Also ich kenne die selbe Geschichte wie du, aber nur mit Log ohne Code, auch besonders gut. Oder wenn man zu trivial Fragen stellt, wo man denkt, die müsste man nach zwei Minuten googlen gefunden haben. Das ist auch ein bisschen fies. Es ist heutzutage mit der ganzen Vernetzung so einfach, Fragen zu stellen, dass es eben häufig einfacher ist, als die Dinge noch mal zu suchen oder nachzulesen. Ich weiß nicht, kann auch niemandem persönlich einen Vorwurf machen, muss man halt auch balancieren.

Lucas: Genau, da finde ich die Balance wirklich schwierig. Ich glaube, das ist auch wirklich ein Unterschied, wenn man früher so im Büro gearbeitet hat und man hatte eine Frage, dann ist man halt zu der Person rübergegangen. Aber dafür musste man erst mal aufstehen und hinlaufen. Und jetzt machst du halt Tab und bist in deinem Slack und dann gibst du es einfach ein und Enter. Ich glaube, die Frage sollte nicht so spontan rausschießen. Da sollte wenigstens mal kurz noch mal drüber nachgedacht werden. Was ist, wenn ich das in meine Suchmaschine eingebe? Ist die Antwort vielleicht der erste Treffer, dann ist das auch gut. Dann brauche ich die nicht in Slack zu stellen. Aber gleichzeitig finde ich, müssen wir da halt so eine Balance finden, dass das nicht bedeutet, dass die Leute dann keine Fragen mehr stellen und stattdessen lieber vor sich hin leiden. Und das finde ich eine sehr schwierige Balance.

Michael: Wie alles bei den Menschen, die miteinander interagieren. Die Balance ist sehr schwierig, weil ja jeder so anders ist, so andere Erfahrungen gemacht hat, in dem Moment vielleicht in einem anderen Kontext ist.

Lucas: Ja, definitiv.

Michael: Wir kommen immer wieder zurück auf diese Menschen und Softskills. Vielleicht sollten wir die Folge so nennen.

Lucas: Menschliche Exzellenz.

Michael: Das ist auch nicht schlecht.

Lucas: Okay, gut. Wir zwei überlegen jetzt im Anschluss noch mal, wie wir die Folge nennen.

Michael: Die ging viel zu lange.

Lucas: Nein, Quatsch.

Michael: Ich find’s gut. Mir hat das Gespräch auf jeden Fall sehr viel Spaß gemacht.

Lucas: Mir auch. Und ich hoffe euch da draußen auch. Gibt uns gerne Feedback, wenn ihr Sachen habt, die fehlen oder wenn ihr sagt, da war viel zu wenig Widerspruch deswegen muss ich jetzt einfach mal widersprechen. Könnt ihr auch gerne tun.

Michael: Auf jeden Fall machen. Dadurch lernen wir ja auch wieder.

Lucas: Sehr gut. Hat der Michael direkt alles umgesetzt, was wir gerade besprochen haben. Und dann danke ich dir für deine Zeit, Michael. Und den Hörerinnen und Hörern sage ich bis zum nächsten Mal. Tschüss!