#40 Wie wird man und Frau zum Senior Dev?

Was ist eigentlich ein Senior Engineer und wie werde ich zu einem?

In der Tech-Industrie werden Titel wie Junior-, Senior-, Staff- und Co genutzt, um Levels und Erfahrung auszudrücken. Doch was ist eigentlich ein Senior-Engineer? Was unterscheidet ein Senior von einem Junior? Wie kann sowas in der Praxis aussehen? Ist Zeit ein wirklicher Faktor für eine Beförderung (10 Jahre Berufserfahrung oder 10x 1 Jahr Berufserfahrung)? Ist "Senior" zu sein ein "Einmal-Aufwand" oder ist kontinuierliche Energie gefordert?

In dieser Episode beschreiben Andy und Wolfgang einige Attribute, die den Unterschied eines Juniors und Seniors darstellen und beschreiben, wie man den Weg zum Senior einschlagen kann.

Bonus: Warum ein Meterstab auch Zollstock genannt wird und warum Wolfgang ein T als hart bezeichnet.

Sprungmarken

(00:00:00) Intro

(00:00:58) Berufserfahrung, Breites vs. tiefes Wissen und Karriere

(00:06:23) Wie wichtig ist Karriere und Titel?

(00:08:03) Umgang mit Positions-Titeln in Firmen

(00:09:28) Heutiges Thema: Wie kann ich ein Senior Engineer werden?

(00:13:02) Erste Schritte zum Senior: Übernahme von kleinen Projekten - Die Arbeit pro-aktiv vorantreiben

(00:18:18) Impact: Was wird im Produkt wirklich gebraucht?

(00:19:34) Technische Skills: Entwicklung von Code und Testing

(00:22:34) Technische Skills: Debugging

(00:24:43) Technische Skills: Monitoring, Alerting und Skalierung

(00:26:13) Technische Skills: Security

(00:28:48) Kommunikations Skills: Feedback, positiv gestimmt, Mentoring und Knowledge Sharing

(00:35:15) Senior Engineer zu sein ist nicht einfach

(00:35:47) Technologie vs. Business-Verständnis: Wann ist eine Lösung gut genug?

(00:39:38) In die Senior-Rolle reinwachsen: Erfahrung und Zeit

(00:42:54) Unterschiedliches Verständnis von der Senior-Rolle

(00:45:07) Der eine Tipp auf dem Weg zum Senior Engineer

(00:47:32) Inflationäre Nutzung des Begriffs "Senior"

(00:48:37) Outro

Hosts

Wolfgang Gassler (https://twitter.com/schafele)
Andy Grunwald (https://twitter.com/andygrunwald)

Feedback (gerne auch als Voice Message)

Email: stehtisch@engineeringkiosk.dev
Twitter: https://twitter.com/EngKiosk
WhatsApp +49 15678 136776

Transkript

Das Transkript wurde automatisiert per Speech-to-Text erstellt und kann daher Fehler enthalten.

Wolfi Gassler (00:00:03 - 00:00:53)

Wie sieht das bei dir eigentlich aus? Fünf Jahre Berufserfahrung oder doch nur fünf mal ein Jahr Berufserfahrung? Und damit willkommen zu einer neuen Episode zum Engineering Kiosk, in dem wir über den Begriff Senior Entwickler sprechen. Was bedeutet der Begriff für uns? Was sind T-Shaped Skills? Wie wird man zum Senior? Und warum ist Kommunikation dabei so wichtig? Wir sprechen auch über die wichtige Pro-Aktivität, die du jetzt gerade vermutlich zeigst, sofern dich halt niemand zum Zuhören zwingt. Und nebenbei klären wir noch, warum man ein Problem hat, wenn man der Klügste im Raum ist und warum wir Tiroler ein hartes und ein weiches Tee haben. Also los geht's. Oder Moment, Moment. Noch als kleine Motivation. Am Ende verraten wir beide unserem Pro-Tipp, wie man möglichst einfach in Richtung Senior wachsen kann. Also bis zum Schluss hören. Aber jetzt wirklich rein in die Episode.

Andy Grunwald (00:00:58 - 00:01:03)

Ich bin ja fast täglich auf GitHub, Stackoverflow und LinkedIn unterwegs.

Wolfi Gassler (00:01:03 - 00:01:07)

Und copy und pasten den ganzen Tag, ist mir klar, dass du selber nichts mehr schreibst.

Andy Grunwald (00:01:07 - 00:01:44)

Ach, deswegen funktioniert mein Code nicht, weil ich immer die LinkedIn, ich habe jetzt einen Führerscheinposts in meinen Code kopiere. Ja, das stimmt schon. Nee, was ich sagen wollte, links und rechts sehe ich dann immer diese Job-Ads. Und mir ist aufgefallen, irgendwie sucht jeder Senior-Entwickler. Und da frage ich mich, was machen denn Junior-Leute oder Leute, die gerade in die Industrie wollen oder Leute, die vielleicht noch nie einen Senior-Titel haben. Und da habe ich mich auch gefragt, wie wichtig dir zum Beispiel die Karriere ist. Und dann habe ich mich weiter gefragt, denkst du, Wolfgang, dass du zehn Jahre Berufserfahrung hast oder zehnmal ein Jahr Berufserfahrung?

Wolfi Gassler (00:01:44 - 00:01:49)

War die erste Frage, ob mir Karriere wichtig ist, auch schon eine Frage an mich oder war die nur so in die Luft gestellt von dir?

Andy Grunwald (00:01:50 - 00:01:58)

Das war so in die Luft gestellt, das war, um dir meinen Gedankenkampf zu erklären. Mich interessiert eigentlich die Thematik, wie viele Berufsjahre Erfahrung du hast.

Wolfi Gassler (00:01:58 - 00:02:03)

Ja, ich mache das eigentlich immer anders. Ich sage einfach, ich bin seit 25 Jahren in der Tech-Industrie unterwegs.

Andy Grunwald (00:02:03 - 00:02:05)

Die Politiker-Antwort, oder?

Wolfi Gassler (00:02:05 - 00:02:22)

Genau, aber nachdem ich, glaube ich, in den 25 Jahren ziemlich viele unterschiedliche Sachen gemacht habe und nur wenig so richtig, glaube ich, habe ich sehr viel Erfahrung, aber wenig in der Tiefe wahrscheinlich dafür. In manchen Bereichen, aber im Großen und Ganzen ist mir persönlich das eigentlich wichtiger, eher in die Breite zu gehen.

Andy Grunwald (00:02:22 - 00:02:35)

Kann man denn mit in die Breite gehen, Karriere machen? Weil Karriere ist ja eigentlich, man wird besser in einem Thema, oder? Und besser in einem Thema zu werden, ist ja meist gleichzusetzen mit, man versteht da von der Tiefe mehr.

Wolfi Gassler (00:02:35 - 00:03:23)

Ja, es gibt ja dieses T-Shaped Model, das sagt dir wahrscheinlich auch was. Das ist so aufgebaut wie ein T, also ein hartes T. Wir können das ja mit der Aussprache nicht so klar unterscheiden zwischen D und D, Dora und Deodor. Also dieses harte T, dieses mit den zwei Strichen. Und das beschreibt ja, dass man in einem Bereich sehr in die Tiefe gehen kann und da auch sehr gut ist und oben der Querbalken, der zeigt an, dass man in die Breite geht und auch fachübergreifend und in anderen Bereichen Verständnis hat, um diese Bereiche zu verknüpfen und mit dem eigenen Tiefenwissen dann auch zusammen eben verknüpfen kann und das ist zumindest meiner Meinung nach Ziel, das man anstreben kann, weil dadurch kann man glaube ich am meisten weiterbringen, wenn man gutes Wissen in einem Bereich hat und dann halt ein gutes Verständnis von ganz vielen anderen Bereichen, die auch wichtig sind.

Andy Grunwald (00:03:24 - 00:03:28)

Und jetzt frage ich mich, wo du tief eingestiegen bist nach deinem Doktor.

Wolfi Gassler (00:03:28 - 00:03:37)

Warum nach meinem Doktor? Ich habe ja schon 15 Jahre an dieser Uni verbracht als Student und Arbeitend. Das ist wohl tief genug in dem Bereich von Datenbanken.

Andy Grunwald (00:03:37 - 00:03:54)

Aber wie siehst du das denn heute in der Tech-Industrie? Denkst du, es macht Sinn, sich ganz knallhart auf eine Nische zu spezialisieren, da tiefer und tiefer und tiefer reinzugehen? Oder sagst du, T-Shaped-Leute haben eine bessere Chance auf dem Arbeitsmarkt?

Wolfi Gassler (00:03:54 - 00:04:32)

Also ich glaube, wenn es um Chancen auf dem Arbeitsmarkt geht, ist es ziemlich egal, was du machst in der IT, weil du wirst immer eine Position finden. Ganz allgemein glaube ich, dass beide Profile gut sind. und ihre Daseinsberechtigung haben, weil du brauchst absolute Spezialisten, vor allem in größeren Firmen, aber du brauchst halt Leute, die auch die Übersicht haben und Sachen verknüpfen können. Und gerade in Startups ist es, glaube ich, noch mal wichtiger, dass du einfach breit aufgestellt bist und verschiedene Sachen machen kannst oder willst. Und umso größer die Firma, wahrscheinlich umso spezialisierter, aber auch dort braucht es Leute, die einfach den Überblick haben, mit mehreren Teams reden können und unterschiedliche Bereiche verknüpfen können.

Andy Grunwald (00:04:32 - 00:05:12)

Meine Theorie ist wie folgt. Du kannst dich auf einen Bereich spezialisieren, auch über mehrere Jahre hinweg, doch wenn du später den Job wechseln möchtest, dann ist es deutlich schwieriger, eine passende Firma zu finden. Nehmen wir mal an, ich habe mich auf die Linux-Körnel-Entwicklung spezialisiert. Natürlich kann ich dann auch C und ich verstehe komplexe Systeme. Ich habe aber das Gefühl, dass du dann als Spezialist im Linux-Körnel ganz gutes Geld verdienst und dass du dann später natürlich, ich sag mal, dich nicht verschlechtern möchtest. Und dann eine passende Firma zu finden, die wieder deine Spezialfähigkeiten in der Linux-Körnel-Entwicklung suchen, ist nicht so einfach als wenn du eher in die generellere richtung geht.

Wolfi Gassler (00:05:12 - 00:05:54)

Aber ich glaube auch dann hast du nicht unbedingt ein Problem einen Job zu finden. Du kannst natürlich nicht in jede x beliebige Firma gehen oder kannst schon, aber die Frage ist halt ob du das wirklich willst und wahrscheinlich wirst du dann in diesem Spezialbereich bleiben und ich bin immer der Meinung noch, dass du das machen solltest wo du wirklich Spaß dran hast und wenn es im tiefsten Netzwerkstack irgendwo unten ist und du dich super auskennst, dann werden sich alle großen Firmen um dich reißen und Dann wirst du von Google und allen großen Anbietern, die auf dem Bereich arbeiten, auch Angebote bekommen ohne Probleme. Und ich sehe da nicht wirklich ein Problem. Gerade heutzutage mit Remote-Arbeit bist du noch weniger eingeschränkt. Und da geht es ja nicht darum, dass du unbedingt in einem Office um die Ecke arbeiten musst in eine Eickel oder so.

Andy Grunwald (00:05:55 - 00:06:14)

Okay, du hast einen validen Punkt. Gegebenenfalls hat sich das seit Corona ein bisschen geändert, weil vorher war das ja wirklich so, dass Remote Work eher die Ausnahme war. Es war schon immer da, aber die Anzahl der Firmen, beziehungsweise die Firmen, die Vollremote angeboten haben, war ja deutlich geringer als jetzt nach Corona.

Wolfi Gassler (00:06:14 - 00:06:21)

In wann eigentlich dann einen perfekten Netzwerkjob zu finden, ist wahrscheinlich schwierig, wo du ganz unten in deinem Netzwerkstack irgendwas machen kannst.

Andy Grunwald (00:06:22 - 00:06:27)

Aber kommen wir noch mal auf die erste Frage, weil das weiß ich ja wirklich nicht. Wie wichtig ist dir eigentlich Karriere und Titel?

Wolfi Gassler (00:06:27 - 00:06:29)

Ich hab gedacht, das war nur in die Luft zurückgefragt.

Andy Grunwald (00:06:29 - 00:06:35)

Ja, das war's am Anfang auch, aber jetzt, nachdem ich mit dir gerade so drüber rede, interessiert mich das jetzt mal langsam wirklich.

Wolfi Gassler (00:06:35 - 00:07:03)

Ja, wenn mir klassische Karriere so wichtig wäre, wäre ich wahrscheinlich jetzt nicht selbstständig, sondern würde probieren, die Karriereleiter irgendwie weiter nach oben zu klettern. Mir ist halt wichtig, dass ich das mache, was ich gerne mache. Und vielleicht auch ein paar eigene Projekte. Und das ist mir aktuell zumindestens wichtiger. Und es ist weniger wichtiger, ob ich jetzt da irgendwie mit Tech-Titeln irgendwie nach oben klettere, diese Leiter. Weil dann hätte ich vor ein paar Jahren einfach den falschen Schritt gemacht, zurück in die Selbstständigkeit zu gehen.

Andy Grunwald (00:07:03 - 00:07:06)

Welche Tech-Titel hattest du denn schon mal in deiner beruflichen Laufbahn?

Wolfi Gassler (00:07:07 - 00:07:58)

Das ist ja auch nochmal ein Unterschied, was du offiziell für Titel bekommst von deiner Firma und was du eigentlich bist. Weil zum Beispiel Engineering Manager, das war kein offizieller Titel, obwohl das wahrscheinlich unsere Tätigkeit am besten beschrieben hat, bei Trivago zum Beispiel. Andere würden es vielleicht sogar Director nennen, wenn man die Teamgröße betrachtet. Es kommt immer drauf an am Ende. Wie gesagt, meiner Meinung nach muss das Spaß machen. Aber ich kann natürlich auch verstehen, dass manche unbedingt da den richtigen Titel gerne vor uns stehen haben wollen. Ich habe mal mit einem Recruiter gesprochen und dem habe ich meinen CV gesendet und dann hat er mich gebeten, kannst du bitte wenigstens das Engineering Manager in Senior Engineering Manager ausbessern, damit das besser klingt, weil sonst ist es schwieriger auf diese Position sich zu bewerben. Also scheinbar ist es sehr wohl bei manchen Firmen und es war sogar eigentlich ein Startup durchaus noch wichtiger solche Titel.

Andy Grunwald (00:07:58 - 00:08:27)

Wie Firmen mit den Titeln umgehen, ist ja auch immer so ein bisschen anders. Manche Firmen haben gar keine Titel, Trivago zum Beispiel. Da hatte man kein offizielles Leveling-System. Da war nicht der eine Senior und der andere Junior und der nächste Staff. Dann gibt es Firmen wie bis vor kurzem Netflix, die haben es jetzt geändert, aber die hatten nur Senior Engineers. Die hatten keinen Staff, kein Prinzip oder Ähnliches. Also Senior war das, höchste und die hatten da keinen weiteren.

Wolfi Gassler (00:08:27 - 00:08:54)

Aber hatten die wenigstens drunter Leute oder hatten die nur Senior-Leute? Weil die hatten ja auch immer dieses Credo oder haben es immer noch, wir haben die besten Leute und wenn jemand nicht mehr der Beste ist, dann fliegt er raus. Das ist ja auch die berühmte Geschichte von derjenigen, die das eingeführt hat, dieses Mantra sozusagen, die für People verantwortlich war, die ja dann selber rausgeflogen ist, weil irgendwann hat es geheißen, sie ist nicht mehr die Beste am Markt für diesen Job und damit ist sie gekündigt worden.

Andy Grunwald (00:08:55 - 00:09:24)

Ich meine, die hatten nur das Senior-Level. Und das war ja auch eine der Kritiken am System, dass dann Leute mit nicht so viel Erfahrung, die aber trotzdem das Interview bestanden haben, dann in die Senior-Position gesetzt wurden. Gleichzusetzen mit Leuten wie Brandon Gregg oder Ähnliches, die dann schon ungefähr so viel Erfahrung haben wie wir beide zusammen, glaub ich. Mal drei, gefühlt. Aber die sind jetzt auch auf einem klassischen Leveling-System unterwegs. Ähnlich wie die anderen Großen.

Wolfi Gassler (00:09:25 - 00:09:48)

Wir haben ja auch oft diese Anfrage bekommen von Hörerinnen und Hörern. Wie kann ich denn ein Senior werden? Oder ich komme jetzt aus meinem Studium raus, habe gerade angefangen zu arbeiten und ich möchte eigentlich Senior werden. Scheinbar ist das ja auch sehr stark in den Köpfen mittlerweile drin. Ich muss auf dieses Senior Level. Wie komme ich denn auf so ein Senior Level? Was würdest du denn den Leuten so sagen?

Andy Grunwald (00:09:48 - 00:10:11)

Erstmal würde ich sagen, ich glaube, das ist eine ganz gute Ambition, weil das heißt ja erstmal, die Leute wollen sich weiterentwickeln. Das stelle ich jetzt einfach mal voraus, dass eine Firma jemandem einen Senior-Titel gibt, sofern die Qualifikationen stimmen und nicht anhand von Betriebszubehörigkeit. Was es in der Industrie auch gibt, ist aber meines Erachtens nach der falsche Weg.

Wolfi Gassler (00:10:11 - 00:10:13)

Okay, was ist denn für dich ein Senior?

Andy Grunwald (00:10:14 - 00:11:00)

Meines Erachtens nach, und da muss ich jetzt ganz klar sagen, das ist nur meine Meinung, weil das ist ja kein definierter Titel, meines Erachtens nach übernimmt Senior weit mehr als einfach nur ein bisschen Quellcoderzeugung, Deployment und Bugfixing, sondern ab dem Senior-Level geht es halt schon sehr, sehr viel in selbstständige Arbeiten, in dem Bereich von Leadership, Mentoring und Kollaboration, Juniors helfen zum Beispiel und auch mehr und mehr weg von den rein technischen Gegebenheiten, sondern auch zum Business Track der Firma. Also womit verdient die Firma den Geld, mit welchem Produkt und man denkt auch als Senior darüber nach, ist das, woran ich gerade arbeite, wirklich das Wichtigste, was ich jetzt gerade tun kann oder gibt es etwas, was mehr Impact auf das Team und auf die Firma hat.

Wolfi Gassler (00:11:01 - 00:11:39)

Es gibt natürlich auch in vielen Firmen ein genaues Framework, wo definiert wird, was ist ein Senior, was ist ein Staff oder mehrere Levels und daran kann man sich dann natürlich orientieren, aber viele Firmen haben das auch nicht und Senior ist immer sehr, sehr schwammig, aber es ist doch irgendwie ein Titel, auf den sehr viele Leute zu steuern und wir haben zum Beispiel auch eine Frage bekommen von Anna, Wie seid ihr denn Senior-Entwickler geworden? Also Andi, wenn jetzt jemand zu dir kommt und die fragt, wie wird man denn Senior-Entwickler oder was kann ich machen, um in Richtung Senior-Entwickler zu gehen oder wie bist du Senior-Entwickler geworden? Was würdest du dir dann vorschlagen?

Andy Grunwald (00:11:40 - 00:12:04)

Ich glaube ich würde erst mal lachen und fragen ich bin doch kein senior weil die offiziell hatte ich einen solchen titel noch nie und das problem ist ja dieses imposter syndrome ich kenne ja ganz viele leute die senior sind und staff und principle und wie sie alle heißen und die sind einfach unglaublich klug in ihrem job und dann sehe ich mich daneben ab und zu mal wie so ein kleiner wie so ein kleines kind was machst du denn da. Von daher würde ich da erstmal stark grinsen.

Wolfi Gassler (00:12:04 - 00:12:12)

Darum habe ich ja absichtlich gesagt, in die Richtung des Seniors. Wenn du in die Richtung des Seniors dich bewegen solltest oder Tipps geben müsstest.

Andy Grunwald (00:12:13 - 00:12:23)

Ich sehe das immer so ein bisschen. Als Junior fängst du an, dann sitzt du da und du kriegst Aufgaben zugewiesen und erklärt und du wirst wirklich in die Hand genommen.

Wolfi Gassler (00:12:24 - 00:12:26)

Als Mitlevel packst du, pickst du dir.

Andy Grunwald (00:12:26 - 00:13:01)

Schon vielleicht selbst die ein oder andere Aufgabe und als Senior und höher bist du eigentlich unter anderem auch dafür verantwortlich, Probleme aufzuzeigen und auch daraus Arbeitspakete selbst zu formen. Natürlich passend mit der Priorisierung, ob das wirklich ein Problem ist, das wir lösen sollten. Weil oftmals finden wir Engineers ja auch sehr viele Probleme, die es Vielleicht zu lösen gilt aber vielleicht lohnt es sich einfach oft nicht diese zu lösen also wenn man in diesem mentalen model darüber nachdenkt dann könnte das schon in richtung senior und drüber gehen.

Wolfi Gassler (00:13:01 - 00:13:28)

Aber steigen wir mal ein in das zum Beispiel, was du erwähnt hast mit Impact-Projekte übernehmen und so weiter. Wie mache ich denn das konkret? Also ich arbeite jetzt in irgendeiner Firma und will mich Richtung Senior entwickeln. Ich kann nicht einfach sagen, ich bin jetzt verantwortlich für dieses große Projekt und das übernehme ich jetzt und ich bin diese leitende Funktion und that's it und damit bin ich jetzt Senior oder gehe in die Senior-Richtung, weil ich brauche das, ich brauche jetzt ein Projekt. Wie würdest du das anlegen überhaupt?

Andy Grunwald (00:13:28 - 00:14:22)

In die Übernahme von Projekten sollte man natürlich erstmal reinwachsen und erstmal mit was ganz kleinem anfangen. Ich glaube, das beste Beispiel ist, man möchte ein Feature umsetzen, was von einem Produktmanager konzeptioniert wurde auf Basis einer Anfrage vom Sales Team. Jetzt kann ich mich als Ingenieur da hinsetzen, kann das implementieren, bis ich zur ersten Frage komme, wo ich keine Antwort habe. Jetzt kann ich natürlich mich zurücklehnen und warten bis der produktmanager auf mich zukommen sagt wie weit sind wir denn ja ich bin geblockt ja ich brauche diese info oder der softwareingenieur kann auch direkt zum stakeholder gehen und zum produktmanager sagen hey ich habe diesen ich habe diesen blocker den müssen wir mal auflösen können wir da was machen also proaktiv sein Oder, achso, und sich dann natürlich wieder zurücklehnen und warten, bis das Sales-Team wieder auf einen Zug kommt und eine Antwort hat. Oder man wird halt mehr und mehr selbstständig und sagt, pass mal auf, ich habe jetzt diesen Blocker hier, was hältst du von diesem Lösungsvorschlag?

Wolfi Gassler (00:14:23 - 00:14:38)

Also weniger, dass man ein Projekt wirklich übernimmt, aber dass man halt einfach probiert, Tasks zum Beispiel aktiv zu treiben und die nötigen Infos holt und das probiert wirklich zu pushen, als wie wenn es mein Task eben wäre oder mein kleines Projekt.

Andy Grunwald (00:14:39 - 00:15:55)

Wir machen das ja auch alles im privaten Leben. Meines Erachtens nach ist Projekte übernehmen im Job nichts anderes wie im privaten Leben. Möchte man eine Wohnung mieten, muss man sehr wahrscheinlich irgendwie eine Auskunft von der Bank haben oder ähnliches. Oder vielleicht irgendwie, je nachdem wie groß die Wohnung ist, eine Bürgschaft. oder was weiß ich nicht. Und wenn die Anfrage kommt vom Vermieter auf dieses Dokument, dann nehm ich mich ja auch nicht zurück, sondern dann geh ich los und besorge mir irgendwie dieses Dokument. Und eigentlich ist das ja nichts anderes im Job. Und man wächst da mit seinen Aufgaben. Erst ein kleines Projekt, dann vielleicht ein bisschen was Größeres und so weiter und so fort. Man darf jetzt natürlich nicht erwarten, dass man sofort den kompletten Rewrite für ein Fünf-Micro-Services kriegt, der dann auch noch businesskritisch ist. da muss man sich selbst mal ein bisschen an die nase fassen das funktioniert ja im normalen leben auch nicht du sagst ja auch nicht komm grad frisch aus der uni und bau mir deswegen eine stadt villa in düsseldorf city, also das funktioniert halt einfach auch nicht und genauso ist dann halt beim job man muss langsam da rein wachsen man muss gucken dass man die probleme aus dem weg räumt, Und besonders wenn man Probleme gerade kriegt, die man vielleicht übersehen hat, muss man sich auch Fehler eingestehen und die nach oben kommunizieren. Aber das Beste ist natürlich dann immer, wenn man eine Alternative zur Hand hat. Also schon ein bisschen Organisation an den Tag legen, Selbstorganisation an den Tag legen.

Wolfi Gassler (00:15:56 - 00:17:08)

Ich glaube, das, was du auch proaktiv genannt hast, es ist sehr wichtig, dass man einfach von sich aus Sachen vorschlägt, dass man auf Leute zugeht, dass man auch aktiv vielleicht sich meldet. Also, wer kennt das nicht, wenn man dann irgendwie so fragt, wer könnte das übernehmen? Und dann starren irgendwie alle im Boden. Wenn man halt in solche Situationen dann einfach, vielleicht auch, wenn es nicht der coolste Task ist, aber mal einfach irgendwas übernimmt, weiterbringt, abschließt und dann einfach die Challenge in der Organisation auch sieht, wenn es jetzt vielleicht nicht der coolste Task von technischer Sicht ist, also dass man irgendeine coole neue Technologie einsetzt, sondern halt, dass man einfach was Projektmanagement technisch umsetzen kann und abschließen kann, dass man sich da halt auch meldet und auf solche Opportunities, wie heißt das auf Deutsch? Möglichkeiten. Möglichkeiten ist keine Opportunity. Natürlich. Chancen. Ich würde es Chancen nennen. Also wenn sich so Chancen irgendwo auftun, dass man da drauf springt und die dann wirklich mitnimmt und halt auch diese Proaktivität zeigt. Und dann kommt man nochmal viel schneller auch zum Zug für coolere Projekte, dass man die übernimmt und vielleicht auch mal größere Projekte. Und dann muss man sich halt einfach beweisen und dementsprechend auf die Projekte selber draufspringen und die auch vorantreiben.

Andy Grunwald (00:17:09 - 00:17:24)

Ich meine, die ganze Sache muss ja noch nicht mal so ein richtiges Projekt sein. Man kann ja auch wirklich klein starten. Man kann vielleicht einfach ein größeres Epic nehmen und das in kleinere Storys umwandeln, sodass drei, vier Leute parallel an diesem Epic arbeiten können. Das ist ja auch schon eine Art von Organisation und Selbstorganisation zu übernehmen.

Wolfi Gassler (00:17:25 - 00:17:53)

Und man braucht da eigentlich gar keine Angst haben, dass man da jetzt vielleicht irgendwem die Arbeit wegnimmt oder so. Also wenn man sich einfach mal Gedanken macht zu einem Epic, was könnte ich da machen und dann gut vorbereitet ist und in einem Grooming oder in einer Session, wo man die Tasks schätzt, dass man da einfach gut vorbereitet reingeht und dann dementsprechend auch den Lead übernehmen kann, nur indem man gut vorbereitet ist, da kann man halt auch schon zeigen, dass man sich darum kümmert und das ist eigentlich schon Leadership, die man da zeigt.

Andy Grunwald (00:17:54 - 00:18:09)

Das klingt jetzt immer ganz so einfach auch einfach mal eine große anforderung runter brechen aber brech die mal bitte so runter, dass die tickets alle ordentlich definiert sind und dass man wirklich parallel daran arbeiten kann das ist gar nicht so einfach und besonders es gibt ja nicht.

Wolfi Gassler (00:18:09 - 00:18:13)

Umsonst immer product owner oder sonstige leute die die das projekt management übernehmen.

Andy Grunwald (00:18:14 - 00:18:57)

Aber da hast du einen guten Punkt erwähnt. Meines Erachtens nach zählt auch so ein bisschen dazu, zu verstehen, was denn eigentlich wirklich im Produkt gebraucht wird. Ich sag jetzt nicht, du musst den Job eines Product Owners, Product Managers voll und ganz übernehmen mit Discovery und User Research und was da nicht noch alles zugehört, aber wir Techniker sehen halt auch oft Dinge, die es gegebenenfalls die gegebenenfalls funktionieren aber ich nenne es mal nicht so schön aussehen und dann gehen wir da dieses rabbit hole runter und versuchen das zu fixen und nach zwei tagen sagen wir da ach vielleicht bleibt das doch einfach so und das ist dann gegebenenfalls auch etwas vielleicht vorher mal darüber nachdenken ist das jetzt so wichtig das jetzt zu beheben also bringt es das produkt weiter oder nicht.

Wolfi Gassler (00:18:57 - 00:19:02)

Bevor wir in eine andere technische Kategorie springen, kurze Frage, Andi, weißt du, was ein Meterstab ist?

Andy Grunwald (00:19:03 - 00:19:05)

Das ist ein Zollstock. Das ist ein Zollstock.

Wolfi Gassler (00:19:05 - 00:19:09)

Fehl dich aus. Warum heißt es Zollstock, wenn ihr nicht mal in Zoll misst?

Andy Grunwald (00:19:09 - 00:19:14)

Ich guck grad mal, ob hier ein Zoll drauf ist. Ist hier ein Inch drauf? Nee, ist es nicht.

Wolfi Gassler (00:19:14 - 00:19:24)

Auf jeden Fall, wer in den letzten Minuten komische Geräusche im Hintergrund gehört hat, das war dieser Meterstab, mit dem Andi herumgespielt hat und der sehr viel Lärm macht. Also Andi, leg das mal auf die Seite.

Andy Grunwald (00:19:25 - 00:19:31)

Aber ich habe gemerkt, der Miethausstab hat Gradzahlen drauf. Das wusste ich noch gar nicht.

Wolfi Gassler (00:19:31 - 00:19:52)

Manche zumindest. Aber kommen wir zurück zum Senior und zu den technischen Skills. Jetzt waren wir schon bei nicht-technischen und bei der Organisation Leadership. Gibt es denn technische Dinge, die dir wichtig wären, was ein Senior haben sollte? Oder eine Senior? Kann man das eigentlich gendern? Senior, Seniorin, Seniorin? Klingt eigenartig.

Andy Grunwald (00:19:53 - 00:19:56)

Seniorin sind doch eigentlich ältere Damen, aber.

Wolfi Gassler (00:19:56 - 00:20:05)

Wohl ... Eben, eine Senior-Developerin. Klingt noch besser. Also, welche Eigenschaften erwartest du dir da in Bezug auf Tech-Skills?

Andy Grunwald (00:20:05 - 00:21:01)

Also, ich glaub, im Bereich Tech-Skills gibt's eine ganze Menge zu empfehlen. Von dem Schreiben von Code über Testing, Debugging, Monitoring, aber auch die Architektur und Security. Fangen wir doch einfach mal zur Entwicklung von Code an. Wo der Junior einfach, okay, der Junior schreibt den Code und behebt den Fehler. Da sorgt der Mid-Level-Engineer schon eher dafür, dass der Code dann auch wirklich testbar ist und dass ein paar Edge-Cases und der Happy Pass getestet ist, wo dann natürlich der Senior von dem wird erwartet, dass jeder Code 100% testbar ist, dass alle Edge-Cases abgefangen werden und dass man natürlich genau weiß, wann Kommentare für welchen Kontext angebracht sind und nicht, hier assigne ich die Zahl 5 der Variable i. kein sinnvolles Kommentar, was ich von einem Senior erwarten würde, sondern eher, warum man jetzt hier komplexes String-Processing machen muss und warum das hier notwendig ist und nicht da drüben.

Wolfi Gassler (00:21:01 - 00:21:26)

Also das Testing würde ja challengen, weil ich würde ja sagen eher, dass jemand, der unerfahren ist und vielleicht jetzt direkt aus der Uni kommt, der probiert alles zu testen und alle Edge Cases zu testen und der Senior testet diese Sachen, die einfach wichtig sind und dass die Developerin in optimierter Zeit, also in möglichst kurzer Zeit, möglichst viele Sachen abtestet und sinnvolle Sachen abtestet. Und ich glaube, das ist eigentlich meiner Meinung nach viel besser, als wenn man sagt, man testet jeden Edge Case ab.

Andy Grunwald (00:21:27 - 00:21:47)

Ja, das ist richtig. Und von Testing habe ich ja gar nicht erwähnt, dass es automatisierte Unit-Tests sind oder vielleicht nicht manuelles Geteste. Also ich würde halt eher darauf gehen und sagen, umso erfahrener man wird, umso besser testbaren Code schreibt man, umso bessere Tests, Unit-Integration, End-to-End-Tests und was man nicht noch alles hat, schreibt man.

Wolfi Gassler (00:21:48 - 00:22:35)

Und ich glaube natürlich, es ist auch abhängig von der Industrie, in welcher Industrie du bist. Wenn du jetzt Flugzeugsoftware-Klassiker schreibst, dann wirst du ja andere Anforderungen haben, als wenn du jetzt irgendeine Web-App baust und in der Agentur arbeitest. Aber auch im ganz Allgemeinen würde ich sagen, Senior-Developerinnen können einfach möglichst optimiert arbeiten und machen genau das, was wichtig ist, um den Task möglichst sinnvoll umzusetzen, dass der abgeschlossen ist. aber halt auch den Kriterien entspricht, die man so in der Firma hat und auch halt dementsprechend mit in die Zukunft denkt, wenn es um Langlebigkeit geht oder eben auch nicht, dass man es vielleicht nur quick and dirty hackt, wenn das sowieso nur eine Woche lebt, also dass man einfach diese Einschätzung hat, was ist wichtig, was ist unwichtig und wie setze ich das technisch am besten um.

Andy Grunwald (00:22:36 - 00:22:50)

Du hast sehr schön von Hacks geredet und da kommt mir mal ein Thema in den Kopf und zwar Debugging. Richtig zu debuggen ist ja auch eine Kunst meines Erachtens nach, wo man gegebenenfalls als Junior anfängt ein paar Print- und Log-Statements in den Code zu bauen.

Wolfi Gassler (00:22:50 - 00:22:54)

Bist du jetzt sagen mein Print-based Debugging ist nicht Stand der Technik?

Andy Grunwald (00:22:54 - 00:23:01)

Vielleicht ist ein Console-Log im JavaScript noch Stand der Technik, das weiß ich nicht, aber obwohl es natürlich da auch schon Step-in-Debugger gibt.

Wolfi Gassler (00:23:01 - 00:23:19)

Wobei das viel schwieriger wird, wenn man jetzt so in der Cloud zum Beispiel arbeitet oder viel mit Services, weil man da einfach weniger Zugriff hat. Also Debugging mit Services und Cloud ist immer noch eine große Herausforderung und da wird in der Tat Console-Log oder irgendwelchen Prints ist wieder ein starkes Tool teilweise, das man verwenden kann.

Andy Grunwald (00:23:20 - 00:23:24)

Na ja, also Remote-Debugger gibt's ja auch noch, ne? Und je nachdem ... Ja, aber die.

Wolfi Gassler (00:23:24 - 00:23:25)

Müssen erst in der Cloud funktionieren.

Andy Grunwald (00:23:26 - 00:24:42)

Ja, aber wenn du einen Docker-Container deployst, dann funktioniert's ja in der Regel, je nachdem, welcher Port frei ist. Na ja, wie dem auch sei. Wo ein Junior-Entwickler oder eine Junior-Entwicklerin eher so mit Console-Log und Print und Echo und was es da nicht noch alles gibt, ein System versucht zu debuggen, geht's mit steigender Erfahrung natürlich mehr und mehr ans systematische Debuggen, um Fehler zu finden. oder sogar systematisches Debuggen, um Fehler zwischen Services oder in generellen größeren Architekturen zu finden, anstatt nur in einem Service. Und mit systematischem Debuggen meine ich wirklich ordentliches Log-Processing, vielleicht komplexere Fehler nachstellen, die irgendwie nur in bestimmten Konstellationen zu finden sind, Race-Conditions, Und natürlich aber auch so was wie ordentliche Step-in-Debugger, vielleicht helfen dir irgendwie Tracing-IDs mit und so weiter und so fort. Also da, wo es schon ein bisschen komplexer wird, um wirklich den Fehler zu finden, wo vielleicht sogar externe Systeme eine große Rolle spielen, mit mehr Erfahrung findet man solche Fehler schneller. Und man ist halt wirklich systematisch dran, die meisten Komponenten auszuschließen. Also wirklich nach dem Ausschlussverfahren, anstatt zu sagen, oh, ich hab eine Vermutung, das ist es.

Wolfi Gassler (00:24:42 - 00:25:14)

Also mehr systematisches Debugging und nicht chaotisches. Da braucht man natürlich auch die richtigen Tools dazu. Haben wir übrigens gerade vor zwei Episoden, Episode 38, erwähnt, wie man richtiges Monitoring macht, Metricking, auch das Tracing, wie man diese Daten bekommt. Das hilft da natürlich alles. Und wenn man das richtig aufsetzt, erleichtert man sich natürlich das Leben auch dementsprechend, wenn es ums Debugging geht. und das ist halt ein teil den senior developer und developerinnen richtig abschätzen sollten.

Andy Grunwald (00:25:14 - 00:25:46)

Nicht nur abschätzen meines erachtens nach junioren würde ich sagen die haben mit monitoring noch relativ wenig zu tun mit level leute die kennen so ungefähr das monitoring und metriken system und von seniors erwarte ich halt schon dass, diese Personen die Alertings ein bisschen tunen, sich die Metriken öfters mal anschauen, aber halt auch zum Beispiel mit der DevOps SAE Systemadministrator Abteilung sich hinsetzen, sich die ganzen Datenpunkte ansehen und dann mit Verbesserungsvorschlägen für das System kommen.

Wolfi Gassler (00:25:46 - 00:25:57)

Und da ist halt auch wieder die Selbstorganisation, die Proaktivität gefordert, dass man von sich aus diese Sachen macht. Man schaut mal in die Metriken rein und kommt dann eben proaktiv mit Vorschlägen um die Ecke.

Andy Grunwald (00:25:57 - 00:26:19)

Also ein bestes Beispiel ist, bald ist wieder, glaube ich, Black Friday. Und jeder, der einen E-Commerce-Shop betreibt oder irgendwas, was auf Black Friday halt eine höhere Zugriffszahl bekommt, dem würde ich relativ schnell als Herz legen, mal auf die Metrik zu gucken und gegebenenfalls sich mal mit der Operativabteilung hinzusetzen, wie können wir unser System denn gegen einen Absturz beim Black Friday sichern.

Wolfi Gassler (00:26:19 - 00:26:25)

Wir sehen ja eine Rezession, Andi. Black Friday ist sowieso uninteressant. Das wird alles ein Reihenfall dieses Jahr.

Andy Grunwald (00:26:25 - 00:26:37)

Ja gut, dann wenn wir alle keine Kaufkraft mehr haben, dann würde ich sagen, ist uns alle langweilig und dann sitzen wir zu Hause und versuchen Systeme zu hacken, um zum Beispiel umsonst eine Pizza zu bestellen und da sind wir schon beim nächsten Thema Security.

Wolfi Gassler (00:26:37 - 00:26:56)

Was ein ganz großes Thema ist und da stellt sich für mich auch die Frage, Muss ein Senior sich im Security-Bereich auskennen oder gibt es einfach einen Security-Beauftragten, den man fragen sollte? Wie siehst du das? Wie weit geht die Verantwortung der Security in den Bereich eines Developers und vor allem Senior-Developers rein?

Andy Grunwald (00:26:56 - 00:27:39)

Das kommt auf der einen Seite darauf an, wie groß die Firma ist, ob es da wirklich einen Security-Beauftragten oder Security-Team gibt. Auf der anderen Seite denke ich, dass ein Senior-Entwickler halt schon einen gewissen Grad von Verständnis von Security haben sollte. Speziell in der Applikation Security, nennen wir mal eine Web-App als Beispiel, dann erwarte ich halt schon, dass die OWASP 10 bekannt sind, was eine SQL-Injection ist, was Cross-Site-Scripting ist, was der Unterschied zwischen normalem Cross-Site-Scripting ist und persistentem Cross-Site-Scripting. Was eine sichere Passwortverschlüsselung ist, dass man keine Klartextpasswörter in der Datenbank hält und so weiter und so fort. Also das sind schon meines Erachtens nach Security-Basis-Bereiche, die ich von einem Senior erwarte.

Wolfi Gassler (00:27:40 - 00:28:26)

Ich würde dir jetzt gerne fragen nach deinem Bullshit-Bingo, was die ganzen Unterschiede sind und so weiter, aber so viel Zeit haben wir leider nicht. Also ich kann jetzt leider nicht prüfen, ob du wirklich ein Senior bist. Aber ich gehe mal davon aus, dass du es weißt. Es sind viele Begriffe, die man auch googeln kann und die man zumindest verstehen sollte und im Hinterkopf behalten sollte, wenn man irgendwas entwickelt und dann dementsprechend auch sich die Hilfe holen kann von einem Profi, wenn es wenn es wäre, beziehungsweise wenn man halt irgendwo am Ende ist, dass man selber sich dann zu wenig auskennt. Aber Security ist einfach so ein Riesenbereich geworden. Man kann natürlich nicht alles überblicken, aber auch da sind wir wieder bei dem T-Shaped Skills, dass man halt einen gewissen Einblick hat und ein Verständnis, auch weiß wen fragen und die richtigen Punkte verknüpfen kann, um dann in seinem eigenen Spezialbereich das jeweils anwenden zu können.

Andy Grunwald (00:28:26 - 00:28:36)

Aber du hast gerade einen sehr guten Punkt erwähnt. Auch ein bisschen Selbstreflexion in den Tag legen. Wann sollte ich wen Externes dazu holen und wann komme ich an meine Grenzen?

Wolfi Gassler (00:28:36 - 00:28:39)

Moment, Grenzen? Welche Grenzen? Ihr habt keine Grenzen.

Andy Grunwald (00:28:39 - 00:28:46)

So, somit ist meine Frage beantwortet. Hast du zehn Jahre Berufserfahrung oder hast du zehnmal ein Jahr Berufserfahrung?

Wolfi Gassler (00:28:47 - 00:28:53)

Eben, habe meine Grenzen noch nicht gefunden. Drum mache ich ja diesen Podcast mit dir, um meine Grenzen endlich zu finden und auszulocken.

Andy Grunwald (00:28:53 - 00:30:00)

Sehr schön. Aber auch wenn man als Senior in solche Streitgespräche kommt oder auch im Slack, im Pull-Request oder wo auch immer, erfährt man das als Senior immer mal wieder. Der Bereich Kommunikation ist auch unglaublich wichtig und meines Erachtens nach einer der wichtigsten Komponenten innerhalb eines Teams, weil innerhalb eines Teams kommt es maßgeblich zu Konflikten, früher oder später. und mit mehr erfahrung wird auch erwartet dass man kontinuierlich objektiv bleibt lösungen oder alternativen zu dem streit thema findet nicht die meinung und die stimmung von dem ganzen team runter drückt also jetzt nicht sagen hey das ist richtig kacke sondern, Mit mehr Erfahrung wird halt erwartet, wenn jemand in die falsche Richtung geht, dass man das Feedback ordentlich verpackt, dass man der Person natürlich die Möglichkeit gibt, daraus zu lernen, dieser Person aber auch wirklich dabei hilft, die bessere Lösung zu implementieren, weil nur so wachsen alle und man hat einen positiven Outcome für die Firma und für das Produkt, anstatt einen Scherbenhaufen im Team-Gefühl.

Wolfi Gassler (00:30:01 - 00:30:52)

Und man kann natürlich auch schlichtens reinspringen, wenn man so eine Situation sieht im Team, im Slack, in der Kommunikation, dass man einfach als Mediator reinspringt und probiert, das in irgendeiner Form zu beruhigen. Und das ist, glaube ich, auch eine wichtige Qualität, die ein Senior Developer haben sollte, dass man da eben auch wieder proaktiv probiert, einfach die Wogen zu glätten. Und das hilft ganz oft, wenn da einfach eine dritte Person kurz reinspringt. und das irgendwie beruhigt mit einer Message oder einfach mal nachfragt, was ist denn das Problem? Könnt ihr mir das kurz erklären? Dann hilft man da schon, ganz viele Konflikte vorzubeugen. Und das ist natürlich in einem Team wirklich wichtig. Und man unterschätzt auch oft, wie viel Einfluss man da haben kann. Mit einer einfachen Message kann man da wirklich Riesenstreits vermeiden. Und das ganze Team ist dann produktiver am Ende und vergeudet nicht irgendwelche Zeit mit irgendwelchen Konflikten oder Streitgesprächen.

Andy Grunwald (00:30:52 - 00:31:28)

Meines Erachtens nach ist dieser Bereich einer der schwierigsten im Senior Engineering. Meines Erachtens nach ist es deutlich einfacher, testbaren Code zu schreiben, denn bei der Kommunikation geht es halt darum, auch wenn wir einen schlechten Tag hatten, auch wenn wir müde sind, auch wenn es uns nicht ganz so gut geht, wird von einem Senior Entwickler oder einer Entwicklerin eigentlich immer Objektivität und positives Denken erwartet und nicht dass man als Person mit da reinspringt und über den Kollegen herzieht. Das kann man vielleicht bei der Deutschen Bild-Zeitung machen, aber nicht als Senior-Entwickler in der Firma.

Wolfi Gassler (00:31:29 - 00:32:10)

Und ich glaube, man kann sogar noch einen Schritt weiter gehen. Man kann auch Feedback aktiv einfordern. Also nicht nur Feedback geben, wie es der Andi jetzt auch zuerst beschrieben hat, sondern dass man aktiv fragt und nicht nur den eigenen Lead, sondern vielleicht auch die Kollegen, Kolleginnen im Team. Was haltet ihr denn davon, auch 101 vielleicht macht? Da haben wir auch eine schöne Episode, by the way, wo 101 auch mit Kolleginnen im Team, dass man einfach mal nachfragt, was haltest du denn von unserer Arbeit, von unserer Zusammenarbeit in den letzten Monaten? Gibt es da irgendwelche Punkte, die schwierig sind? Kann ich mir irgendwo verbessern? Sollte irgendwo mehr helfen? Dass man da einfach Fragen stellt und aktiv Feedback einfordert. Ich glaub, das ist auch ein Skill und eine Gewohnheit, die man sich einfach angewöhnen sollte.

Andy Grunwald (00:32:10 - 00:33:08)

Und wenn wir schon über das Thema sprechen, dann ist das Thema Mentoring nicht weit. Meines Erachtens nach ist man als Senior nicht ein 10x-Developer, der den meisten Code schreibt, sondern jemand, der über seine Karriere hinweg eigentlich weniger Code schreibt und versucht, wirklich ein sogenannter Enabler zu sein, neuen Leuten mit weniger Erfahrung, ich sag mal, hochzuhelfen und das Wissen weiterzuvermitteln, wie man sich als Senior verhält, worauf es ankommt, warum jetzt eine hundertprozentige Testcoverage bei den Unit-Tests gegebenenfalls nicht hilfreich ist und so weiter und so fort. Und das heißt nicht nur, dass man Leute innerhalb der Firma connecten muss, sondern gegebenenfalls auch außerhalb. Weil mit mehr Erfahrung, umso größer wird das Netzwerk, desto mehr kann man Leute mit gleichen Interessen auch connecten Und vielleicht hat ja sogar irgendwer mal Lust, außerhalb der Firma einen Juniorentwickler oder eine Juniorentwicklerin innerhalb eurer Firma zu mentoren. Dann hat man natürlich eine Win-Win-Situation.

Wolfi Gassler (00:33:08 - 00:34:04)

Also auch meine Arbeit als Lead war eigentlich ganz oft nur die richtigen Leute zu connecten. Es kommt irgendwer, stellt eine Frage, ich persönlich kenne sie auch nicht die richtige Antwort, aber ich kenne jemanden in der Firma, in einem anderen Team, in einem anderen Bereich und sage einfach, frag mal diese Person und dann ist es teilweise einfach nur ein kurzes Gespräch oder drei Slack-Messages und man hat die Antwort. Aber dieses Wissen einfach, wer hat welches Spezialwissen in der Firma, wen kann man wie verknüpfen, das ist glaube ich sehr wichtig als Lead natürlich, aber auch als Senior-Entwicklerin, dass man sich ein gewisses Netzwerk aufbaut und sich auch merkt und Interesse daran hat, was andere Leute machen in der Firma, weil das kann man halt dann dementsprechend auch nutzen, um die Connections dann herzustellen und wie der andi so schön sagt als ennebler zu arbeiten jetzt haben sie so viele beschwert wir wir verwenden so viele englische begriffe andi was ist der deutsche begriff für ennebler andi googelt jetzt natürlich ihr habt mich auch gerade gefragt was ist das deutsche begriff dafür und mir ist nichts gutes eingefallen.

Andy Grunwald (00:34:05 - 00:34:13)

Ich habe nicht gegoogelt ich habe einfach mal den deep l übersetzer angeschmissen und der deutsche begriff ist der befähiger oder der ermöglicher.

Wolfi Gassler (00:34:14 - 00:34:17)

Okay, es klingt aber nicht sehr gut.

Andy Grunwald (00:34:17 - 00:34:23)

Deep L schmeißt mir aber als dritte Alternative Enabler raus, also es scheint schon eingedeutscht zu sein.

Wolfi Gassler (00:34:24 - 00:35:20)

Ja, ich finde leider auch nichts Gutes. Also bleiben wir bei Enabler. Wie man noch Leute enablen kann, ist Knowledge Sharing. Wir haben da auch eine eigene Folge darüber gemacht und zwar ist es die Folge 35 Knowledge Sharing, wo wir einiges besprechen, aber ganz allgemein, dass man auch proaktiv sein Knowledge Shared, sei es jetzt mit einem Junior, sei es im Team, sei es über Teamgrenzen hinweg. oder man auch mal zu einer Konferenz geht oder einer internen Konferenz in der Firma oder vielleicht einfach so einen Talk mal haltet für interessierte Leute über das eigene Team, was man so macht. Also da gibt es, glaube ich, ganz viele Möglichkeiten. Erwähnen wir eben auch in dieser Episode noch einige andere Möglichkeiten. Aber dass man auch das proaktiv vorantreibt und damit auch wieder das Team und andere Leute enabled oder vielleicht schneller macht, oder ihr leben erleichtert und das was man eben die letzten jahre gelernt hat dass man das auch dementsprechend weiter gibt und ich glaube auch da sind die senior rollen mehr gefordert in diesem bereich aktiv tätig zu sein.

Andy Grunwald (00:35:21 - 00:35:40)

Und die senior position auszuleben ist bei weitem nicht einfach das ist kontinuierlich anstrengend, Aber wie der Wolfgang bereits am Anfang des Podcasts schon sagte, in der Regel verdient man dann auch etwas mehr als klassische Junioren oder ähnliches. Und mit mehr Gehalt kommt mehr Verantwortung.

Wolfi Gassler (00:35:40 - 00:37:22)

Wobei mir persönlich dieser finanzielle Aspekt eigentlich nicht so wichtig war. Und ich finde es auch ein bisschen eigenartig, nur weil man dann ein bisschen mehr Verantwortung hat, plötzlich viel mehr Geld zu verlangen. Aber gut, das ist eine andere Geschichte und eine Herangehensweise. Aber wenn wir schon bei Geld sind, die wirtschaftliche Sicht auf die Dinge ist schon auch etwas, was man als Senior eigentlich beherrschen sollte zumindest. Weil ganz oft als technische Person hat man ja so die Technik im Kopf und will die beste Technologie, die beste Lösung, die sauberste, die schönste Lösung. Aber wenn man halt ganz wirtschaftlich denkt und Firmen müssen in der Regel schon noch wirtschaftlich denken, ist halt oft die zweitbeste Option immer noch gut genug. löst das Problem und ist aber vielleicht um 50 Prozent einfacher zu lösen, umzusetzen oder das Team braucht 50 Prozent weniger Zeit dafür und dann muss man schon abwiegen, okay, was macht man. Und da setze ich persönlich nochmal als Lead zum Beispiel auch auf Senior-Leute, dass die das Verständnis haben, den Einblick, ist es wirklich wert, Technologie XY einzusetzen, die coole neue Hipster-Technologie, was für Probleme haben wir damit, setzen wir eine alte Technologie ein, Was ist denn die beste Lösung für dieses Problem, auch von wirtschaftlicher Seite und Sicht, damit die Firma eben auch nach vorne gebracht wird. Und ich glaube, da vergisst man ganz oft als Techniker, dass das halt ein wichtiger Bereich ist, auf den man schon achten sollte. Und es schmerzt am Beginn immer als Techniker. muss ich dazu sagen, wenn man halt nicht die schönste Lösung hat und wenn man irgendwas dreckig macht. Aber oft kann man halt einfach einen viel größeren Impact am Ende haben durch so eine einfache Lösung, anstatt die perfekte Lösung zu haben und wie es vielleicht im Lehrbuch stehen würde.

Andy Grunwald (00:37:22 - 00:38:05)

Ich kriege ja oft sehr viele negative Kommentare, wenn ich wirklich sage, okay, lass uns einfach mal einen gepflegten Hack hier reinbauen und das hält dann wieder ein paar Jährchen. Und ich bin auch kein Advocate für technische Schulden, ganz und gar nicht. Und ich möchte auch große Architekturen nicht unsauber hinterlassen und es alle langsamer machen. Doch ich sehe halt auch sehr oft, dass sehr viel Engineering-Porn in Bereichen angewandt wird, wo es einfach nicht notwendig ist, wo ein kleines Bash, ein kleines Python-Skript oder was weiß ich nicht einfach gut genug wäre. um die ganze firma nach vorne zu bringen und ich denke auch ich bin stark davon überzeugt dass millionen firmen von ein paar kleinen wichtigen skripten zusammengehalten werden.

Wolfi Gassler (00:38:05 - 00:38:12)

Sehr schöne formulierung du denkst du bist überzeugt also ich glaub nur dass du überzeugt bist von dieser meinung.

Andy Grunwald (00:38:12 - 00:38:31)

Ja, keiner möchte zugeben, dass eine Millionenfirma von 150 Zeilen Pythons zusammengehalten wird. Das will ja keiner zugeben. Deswegen ist das meine Theorie. Also, falls ihr irgendwie mal einen Whistleblower spielen wollt, schickt mir doch einfach mal anonym irgendeine E-Mail und bestätigt meine Theorie.

Wolfi Gassler (00:38:31 - 00:40:09)

Wobei auch da muss man aufpassen, dass man halt da nicht in der Vergangenheit hängen bleibt und nie irgendwie auf neue Technologien setzt oder auf den nächsten Schritt macht, nur weil er gerade jetzt zu kompliziert ist. Aber auch da sind Seniors gefordert, dass die halt den Weitblick haben und sich überlegen können, okay, was bedeutet das, wenn wir jetzt eine neue Technologie einsetzen? Welche Probleme schaffen wir uns selber damit? Was wird vereinfacht? Wie schaut es in Zukunft aus mit der Wartbarkeit? Ist es so eine neue Hipster-Technologie, wo es nicht mal sinnvolle Dokumentation gibt? Ist da eine große Community dahinter, ja oder nein? Was bringt es am Ende? Und ist es dann das ganze wert, sich das überhaupt anzuschauen und das zu implementieren oder einzusetzen? Und da hilft halt auch die Erfahrung, die man einfach gesammelt hat. Und wenn man Spezialist in einem gewissen Bereich ist, weiß man halt einfach, wie Keine Ahnung, wie schnelllebig zum Beispiel JavaScript-Frameworks sind und dann kann man vielleicht auch besser einschätzen, wobei das sicher die schwierigste Kategorie ist, irgendwas einzuschätzen, wie ob jetzt ein JavaScript-Framework stirbt oder nicht oder erfolgreich wird oder nicht und wann man darauf aufsetzt. Aber wenn man da halt die eigene Erfahrung verwenden kann, um das besser abschätzen zu können, hilft das natürlich auch. Ganz klassische Erfahrung. Zeit, muss man schon auch sagen, hilft schon auch, um einfach mehr in so eine Seniorrolle reinzuwachsen. Also man kann nicht sagen, nur weil man jetzt diese Punkte auch abhandeln kann oder versteht, dass man sofort nach einem halben Jahr Berufserfahrung in eine Seniorrolle springen kann. Also auch da muss man sagen, es braucht wahrscheinlich eine gewisse Zeit, um einfach auch die Erfahrung zu bekommen in gewissen Bereichen und man dann eben diese Erfahrung auch dementsprechend anwenden kann. Es ist nicht nur Zeit, aber Zeit ist definitiv ein Faktor meiner Meinung nach.

Andy Grunwald (00:40:10 - 00:41:50)

Zeit ist ein Faktor, aber nur weil man fünf Jahre den gleichen Job macht, ohne seinen Bereich zu erweitern, ist man halt auch kein Senior. Und das ist genau dieser Spruch von, hat man fünf Jahre Berufserfahrung oder hat man fünfmal ein Jahr Berufserfahrung. Und wenn ihr jetzt sagt, hey, ich bin in meiner Firma, ich bin in meinem Team, irgendwie hab ich gar nicht die Möglichkeiten, hier mich so weiterzuentwickeln, bin ich jetzt kein Fan davon, unbedingt sofort irgendwie den Job zu wechseln, sondern ich bin immer erst ein Fan davon, mit seiner Managerin und mit seinem Manager darüber zu sprechen und einfach mal über deine eigenen Ziele zu sprechen. Also wohin möchtest du gehen? Was möchtest du mal erreichen? Und wenn dann das Gesprächsergebnis wirklich ist, okay, die aktuelle Firma kann dir das zurzeit nicht bieten, dann hast du auf jeden Fall der Firma eine Chance gegeben. Und wenn du in dieser aktuellen Umgebung deine Ziele nicht erreichen kannst, Dann heißt es vielleicht einfach weiterziehen in einer anderen Umgebung, frisch auch mal ein bisschen den Kopf auf, weil man gegebenenfalls mit neuen Leuten arbeitet, mit neuen Problemen konfrontiert ist und vielleicht dann nicht immer der Klügste im Raum ist, weil in der Regel wollt ihr das nie sein. Ihr wollt nie der Klügste im Raum sein, sondern ihr wollt immer Leute um euch haben, von denen ihr konstant etwas lernen könnt. Ich sag aber auch, nur weil ihr mit Juniors arbeitet, heißt das nicht, dass ihr nichts mehr lernen könnt. Meines Erachtens nach kann man auch als Senior von Juniors sehr, sehr viel lernen, weil die einfach fundamentale Fragen stellen wie, warum ist das denn einfach so? Und dann setzt ihr euch hin, ja, das ist eine sehr gute Frage. Warum ist das denn eigentlich so? Ich mache den Job hier schon seit zehn Jahren und habe immer gedacht, das ist einfach so.

Wolfi Gassler (00:41:50 - 00:43:18)

Und wenn die Antwort ist, weil wir es immer schon so gemacht haben, dann sollte man sich was überlegen. Wir verlinken auf jeden Fall auch noch einige Blog-Artikel bzw. Webseiten über solche Growth-Frameworks wie Career Growth. Wie nennt sich das auf Deutsch? Karriere... Karriereleitern. Karriereleitern, ja. Da gibt's Matrizen, so eine Matrix, wo man dann sieht, in was für einem Bereich man sich fortbilden muss. Zum Beispiel CircleCI ist da sehr früh rausgekommen mit so einer Matrix. Aber da gibt's auch andere Ressourcen noch, die jeweils das erklären, wie das in den Firmen abläuft. Da kann man sich also auch viel abschauen. Wir verlinken auch noch einen Blogartikel von einem ehemaligen Kollegen, von Tom Bartel, der einen super Blogartikel geschrieben hat über Leadership als Individual Contributor, weil es ja auch immer heißt, wie kann ich denn wirklich Leadership zeigen, wenn ich gar keine Rolle habe, wo ich diese zeigen sollte. Also auch als Individual Contributor kann man viel weiterbringen und der hat da super Beispiele auch drinnen und Praxisbeispiele, wie sowas funktionieren kann. Also genug zum Lesen und natürlich würde es uns auch interessieren, was ihr so haltet von der ganzen Seniorrolle. Haben wir im Großen und Ganzen abgedeckt, was eine Seniorrolle ausmacht? Haben wir irgendwas vergessen? Bitte sendet uns da Tweets oder auch E-Mails. Wir freuen uns natürlich auf jedes Feedback und auf Twitter entsteht ja auch immer ganz gerne Diskussionen über solche Themen, also gerne einen ein tweet zu dem ganzen senior thema sind gespannt auf euer feedback.

Andy Grunwald (00:43:18 - 00:43:54)

Wir verstehen dass das thema nicht einfach ist und wir verstehen auch dass ohne eine industrieweite definition jeder ein anderes verständnis von junior mitlevel und senior engineer hat und das finde ich auch toll wenn ihr jetzt noch kein senior engineer seid. Schaut doch mal in eurer Firma nach, ob es eine definierte Karriereleiter gibt und wenn nicht, fragt doch mal nach, was ihr dafür tun sollt oder könnt. Lasst euch nicht mit Wischiwaschi-Attributen abspeisen, sondern versucht wirklich ganz konkrete Tipps zu bekommen, wie ihr euch weiterentwickeln könnt. Vielleicht sogar in die Richtung von messbaren Attributen.

Wolfi Gassler (00:43:55 - 00:43:59)

So wie dein Gewicht zum Beispiel, oder Andi? Oder was willst du da messen?

Andy Grunwald (00:43:59 - 00:44:09)

Wenn die Zahl auf der Waage höher geht, dann ist meine Work-Life-Balance sehr wahrscheinlich nicht so richtig. Oder sie ist genau richtig, ich weiß es nicht.

Wolfi Gassler (00:44:09 - 00:44:13)

Aber hast du eine Metrik? Was wäre eine gute Metrik deiner Meinung nach?

Andy Grunwald (00:44:13 - 00:44:36)

Ja, es kommt halt ganz drauf an, in welchem Bereich man sich weiterentwickeln möchte oder in welchem Bereich man sich weiterentwickeln sollte. Beispiel, sollte man die Kommunikation und das Mentoring steigern, warum nicht einfach mal ein oder zwei Junioren mentoren über die Zeit von einem halben Jahr und dann schauen, ob vielleicht nicht ein Junior eine Beförderung kriegt zum Mitlevel, was ja dann schon ein Erfolg wäre im Mentoring-Bereich.

Wolfi Gassler (00:44:36 - 00:44:38)

Also es ist nicht wirklich eine Metrik, oder?

Andy Grunwald (00:44:38 - 00:44:38)

Och, wieso?

Wolfi Gassler (00:44:39 - 00:44:42)

Du meinst die Anzahl an Juniors, die du mentorst?

Andy Grunwald (00:44:42 - 00:44:50)

Erfolgreich. Es zählt ja nicht, dass ich dich mentor, es zählt ja dann der Outcome und ein positiver Outcome vom Mentoring, dass zum Beispiel ein Junior eine Promotion kriegt.

Wolfi Gassler (00:44:51 - 00:45:28)

Also man darf das nicht als klassische Metrik sehen, wo man täglich irgendwie einen Value sieht und eine Zahl ablesen kann, sondern das Ziel zum Beispiel, ein oder zwei Leute einen Schritt weiter bringen zum Beispiel. Aber es ist messbar. Es ist keine klassische Metrik wie eine Servermetrik, aber es ist etwas, was man messen kann, genau. Jetzt ganz abschließend, Andi, wenn du einen Tipp hättest für jemanden, der jetzt als nächstes mehr in die Senior-Richtung gehen wollen würde, was würdest du sagen, kann man immer machen, egal wie das Framework jetzt ausschaut, wo man dann viel mitnimmt und wo man auf jeden Fall mal in die richtige Richtung geht, aber ganz konkret ein Beispiel.

Andy Grunwald (00:45:28 - 00:45:34)

Ich würde mir jemand dazu holen und einfach mal eine Selbstreflexion starten.

Wolfi Gassler (00:45:34 - 00:45:35)

Wen würdest du denn nehmen?

Andy Grunwald (00:45:35 - 00:45:44)

Sehr wahrscheinlich keinem aus meinem Team, entweder meinen Manager oder einen Senior Entwickler aus der Firma oder aus einer anderen Firma.

Wolfi Gassler (00:45:44 - 00:45:47)

Und dann ganz konkret fragen, was sollte ich tun?

Andy Grunwald (00:45:47 - 00:46:37)

Ich würde erst eine Selbstreflexion machen für mich alleine und dann würde ich diese Selbstreflexion mit einer externen Person machen, um zu schauen, wie off ich eigentlich bin oder ob alles passt. Und dann würde ich mich tief damit auseinandersetzen, was die Firma, in der ich aktuell bin, wirklich valued, was die Firma sozusagen als Senior-Entwickler definiert. Weil dann weiß ich, wo ich stehe und wo ich hingehe. Und dann, wenn ich diese zwei Punkte habe, dann würde ich einen Plan machen mit meinem Tech-Lead, mit meinem Engineering-Manager, mit meinem Abteilungsleiter. Dann würde ich sagen, hey, ich würde gern dieses Ziel erreichen. Wie können wir daran zusammenarbeiten? Kommen jetzt bald irgendwelche Projekte, an denen ich vielleicht eine größere Rolle übernehmen kann oder Ähnliches? Und dann von da aus weiter. Welchen Tipp würdest du der Hörerschaft geben?

Wolfi Gassler (00:46:37 - 00:47:32)

Also mein ganz konkreter Tipp wäre wirklich einen Vortrag zu machen. Man sucht sich irgendeine interne Konferenz oder irgendwie ein Format externe Konferenz und probiert einen Vortrag zu machen über das eigene Team oder über irgendein technisches Thema. Weil damit musst du ganz viel kommunizieren mit anderen Leuten. Du musst dein eigenes Problem besser verstehen aus mehreren Winkeln. Vielleicht auch mit von Product Seite, warum man das überhaupt macht. Man lernt, wie man einen Vortrag macht, wie man sowas aufbaut. Man bekommt dann Feedback von anderen. Und ich glaube, dieser ganze Prozess bringt einen auf ganz vielen Ebenen weiter, obwohl es eigentlich nur ein simpler Vortrag ist, eine Präsentation. Aber dabei lernt man einfach auf ganz vielen Ebenen was und das geht dann in die richtige Richtung. Ein ganz konkreter Tipp und ich würde sicher nicht alles lösen um ein Senior zu werden, aber wenn man mal irgendwo ganz konkret starten will, würde ich damit starten mit einer Präsentation.

Andy Grunwald (00:47:32 - 00:47:39)

Auch nicht schlecht in der Tat. Wir haben natürlich den Begriff Senior jetzt ein bisschen inflationär benutzt, das bedeutet mit Senior meinen wir.

Wolfi Gassler (00:47:39 - 00:47:42)

Inflation ist aktuell ein hippes Thema, das ist schon okay.

Andy Grunwald (00:47:43 - 00:48:04)

Mit Senior meinen wir natürlich auch Staff, Senior, Staff und Principal. Da geht es natürlich in diesen Attributen noch viel, viel weiter. Und ein fundamentaler Unterschied zu diesen Positionen, also den Positionen nach dem Senior-Level, ist, dass man all diese Attribute nicht nur auf Team-Level ausarbeitet, sondern eigentlich auf Abteilungs- und sogar Firmen-Level.

Wolfi Gassler (00:48:04 - 00:48:37)

Wobei man natürlich auch sagen muss, dass es in jeder Firma anders sein kann und es gibt ja keine genaue Definition, was sowas ist. Und wenn man sich das so anschaut, jetzt im Data Science Bereich zum Beispiel entsteht ja gerade das Gleiche. Da hat es bis vor kurzem eigentlich nur Senior Data Scientist gegeben und jetzt kommen halt diese anderen Stufen langsam dazu, weil man einfach merkt, okay, die Leute sind jetzt Seniors, aber es gibt noch was dazwischen, das geht ja noch weiter. Und man macht jetzt immer die nächsten Stufen Staff und da geht's halt dann immer mehr darum, dass man das halt noch globaler und in noch größerem Scale auf Firmenebene zum Beispiel macht.

Andy Grunwald (00:48:37 - 00:48:58)

Da sind wir auch schon wieder am Ende unserer Episode. Uns interessiert natürlich euer Feedback zu diesem Thema. Seht ihr das genauso wie wir? Welche wichtigen Attribute haben wir als Senior Engineer vergessen? Wo erwarten wir vielleicht sogar auch zu viel? Und wie sieht die ganze Sache bei euch aus? Und ab wann seid ihr eigentlich Senior geworden oder ab wann deklariert ihr euch eigentlich selbst als Senior?

Wolfi Gassler (00:48:58 - 00:49:05)

Also die Herausforderung wird sein, zu beschreiben, was ist ein Senior in 140 Zeichen auf Twitter? Oder wie viele Zeichen hat aktuell Twitter?

Andy Grunwald (00:49:05 - 00:49:05)

240?

Wolfi Gassler (00:49:05 - 00:49:13)

Ich weiß gar nicht, wie viele es aktuell sind. Auf jeden Fall in wenigen Worten erklären, was ein Senior ist. Wir sind wirklich gespannt auf eure Definitionen.

Andy Grunwald (00:49:13 - 00:49:35)

Der Tweet geht natürlich an atengkiosk und falls ihr ein bisschen mehr Zeichen nutzen wollt, schreibt uns einfach eine E-Mail an stehtisch at engineeringkiosk.dev oder falls ihr auch mit dem Hund geht und die einfach nicht tippen wollt, wir haben auch eine Handynummer, steht in unseren Shownotes. Einfach mal das Handy nehmen und eine WhatsApp-Voice-Nachricht drüber schicken, würde uns sehr freuen.

Wolfi Gassler (00:49:35 - 00:49:38)

Bis dahin, bis bald. Bis nächste Woche, ciao.