#06 Hype oder Hope: Job-Titel und Beförderungen

Sind Machine Learning und Artificial Intelligence nur Hypes oder sollte ich meine Karriere dahingehend ausrichten? Und welche Hypes gibt es im Infrastruktur-Bereich? Und überhaupt: Wie steht das alles im Zusammenhang mit Job-Titels, meiner Beförderung zum Senior Engineer und meinem Gehalt?

All diese Themen klären Wolfgang und Andy in dieser wilden Folge. Weiterhin: Warum das Leben kein Ponyhof ist, was Agrar-Tech und autonom-fahrende Trecker, die Inflation und Krösus damit zu tun haben, sowie warum Software Engineers zu den Top 5% der Gesellschaft gehören.

Bonus: Warum Wolfgang kein Eiskunstlauf macht und wie er seinen Dr.-Titel bekommen hat.

Feedback an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKiosk

Erwähnte Personen

Russ Cox: https://swtch.com/~rsc/

Sprungmarken

(00:00) Intro

(01:06) Deepmind News "AlphaCode" - Ein neuer Machine Learning Hype?

(06:40) Wie kann Alpha Code in der Praxis genutzt werden?

(08:04) Coding Challenges im Recruiting-Prozess

(11:09) Hypes im Infrastruktur-Bereich

(16:45) Frischer Wind von neuen Leuten in der Firma

(19:22) Mono-Repos als Hype-Beispiel

(20:55) Industrie-Definition von Job-Titles

(26:03) Braucht man Job-Titles (Senior, etc.)?

(31:43) Festgefahrene Strukturen in Konzernen

(37:38) Geld ist bei weitem nicht alles bei einem Job

(41:50) Mach das was dir Spaß machst und Generalisten vs. Spezialisten

(45:36) 5-Jahres-Pläne

(49:56) Outro

Hosts

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

Engineering Kiosk Podcast: Anfragen an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKiosk

Transkript

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

Wolfi Gassler (00:00:02 - 00:00:54)

Willkommen zu einer neuen Episode des Engineering Kiosks. Dieses Mal haben wir eine richtig freie Diskussion wie direkt vor dem Kiosk. Und zwar über Hypes und Karrierepfade. Oder wahrscheinlich wie Andi sagen würde, Karrierepfade. Die Folge ist eigentlich aus einer Vordiskussion entstanden, in der Andi Machine Learning als Hype bezeichnet hat. Und das konnte ich natürlich einfach nicht auf mir sitzen lassen, daher habe ich auf den Record-Button gedrückt und wir haben diskutiert, ob Studenten und Ingenieure sich Hypes widmen dürfen oder vielleicht sogar sollen, ob wir Jobtitel gut finden, über Engineering-Gehälter und wie privilegiert Developer heutzutage sind und über Andis 5-Jahres-Plan, der seine täglichen Entscheidungen beeinflusst. Hast du gehört von dem Alphabet-Google-DeepMind-Programmierer, dem Artificial-Programmierer?

Andy Grunwald (00:00:55 - 00:01:04)

Nee, das letzte, was ich gehört habe, war irgendwas mit StarCraft, ein StarCraft-Bot gebaut oder ähnliches. Das war, glaube ich, die letzte Meldung. Ich glaube, die kam nach dem Go-Spiel.

Wolfi Gassler (00:01:06 - 00:01:32)

Okay, die kenne ich zum Beispiel wieder überhaupt nicht. DeepMind ist ja von Alphabet irgendwie eine Subsection unter Firmen, die vor allem im AI-Research-Bereich unterwegs ist. Und die haben jetzt bei so Code-Challenges mitgemacht mit ihrer AI und haben es geschafft, eine AI zu bauen, die gleich gut performt wie 54% aller Programmierer bei so Coding-Challenges.

Andy Grunwald (00:01:32 - 00:01:38)

Also du meinst jetzt so Sortieralgorithmen oder so Doku automatisch lösen, sowas halt?

Wolfi Gassler (00:01:38 - 00:01:50)

Genau, die Frage ist ja, werden wir dann alle ersetzt in Zukunft von diesen AI-Programmen, weil dann nur mehr ein Businessmensch irgendwie sagt, ich hätte gern diese und diese Funktion und dann gibt es da irgendeine AI, die automatisch den Code programmiert.

Andy Grunwald (00:01:51 - 00:02:06)

Glaube ich jetzt nicht, zumindest nicht in naher Zukunft. Aber ich meine, wir haben das ja schon bei GitHub Copilot gesehen. Die haben ja sowas ähnliches rausgebracht. Du schreibst, glaube ich, in Kommentaren, was du haben möchtest und der schreibt dir dann so mehr oder weniger den Code dahin, richtig?

Wolfi Gassler (00:02:06 - 00:02:15)

Genau, das geht eigentlich in eine extrem ähnliche Richtung. Das ist OpenAI von GitHub oder die Engine, die dahinter liegt, und die geht eigentlich in eine sehr ähnliche Richtung, ja.

Andy Grunwald (00:02:16 - 00:02:28)

Ich glaube die Engine, oder es basiert alles auf dem GPT-3-Modell, Generative Pre-Trained Transformer-Modell, ist im Bereich Deep Learning, aber auch im GitHub Copilot-Projekt hat man ja auch schon gesehen, da gab es so ein.

Wolfi Gassler (00:02:28 - 00:02:30)

Paar... Hast du das ausprobiert?

Andy Grunwald (00:02:31 - 00:02:45)

Ich habe es nicht ausprobiert weil ich finde es super interessant als prototype und allem darüber dran aber ich gebe zu ich bin ein bisschen skeptisch ja also immer wenn so eine so eine so eine meldung rauskommt machine learning artificial intelligence super cool was sie da gebaut haben.

Wolfi Gassler (00:02:45 - 00:02:52)

Euer Wohlstand ist ja auch noch auf auf Stahl basierend in Duisburg keine kein Wunder dass du davon von neuen Sachen nicht viel hältst.

Andy Grunwald (00:02:52 - 00:03:34)

Nein darum geht es mir gar nicht ich sage nur die. Die Applikation kann von, weiß ich nicht, auf dem Level von ganz wenig Leuten weltweit gebaut werden, ganz wenig. Und wenn man sowas sieht, dann möchte jeder sofort in den Bereich Machine Learning, Artificial Intelligence, sowas möchte ich auch und sowas müssen wir bei unserer Firma auch einführen. Doch diese menschen haben da ich glaube ihr ganzes leben lang der forschung gewidmet und und ich bin mir gar nicht sicher ob die leute wirklich verstehen was da los ist wie das funktioniert ich muss auch zugeben ich habe von dem ganzen thema relativ wenig ahnung doch ich sehe nur immer immer wieder immer wieder eine meldung kommen super viele leute wollen irgendwie auf diesen hype aufspringen und denken das ist jetzt meine karriere und da muss ich auch rein und da bin ich mir nicht sicher ob das so so richtig ist.

Wolfi Gassler (00:03:34 - 00:03:43)

Du glaubst also, es braucht in Zukunft auch noch normale Programmierer oder andere normale Jobs im IT-Bereich?

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

Was heißt normale Jobs? Ich meine, wenn ich Maschinen-Learning-Engineer bin, ist das ja ein normaler Job. Ich sage nur, nur weil eine supergute Firma so ein Tool dahingestellt hat, heißt das nicht, dass das jetzt der Hammer für jeden Nagel ist.

Wolfi Gassler (00:03:59 - 00:04:11)

Wobei man muss natürlich auch sagen, jetzt keine Ahnung, wenn ich MySQL verwende, muss ich auch nicht MySQL verstehen im Detail. Ich verwende ja auch nur andere Software, also könnte ich die Software ja genauso verwenden, die jemand anderer programmiert, die da die Intelligenz hat.

Andy Grunwald (00:04:12 - 00:04:20)

Das ist richtig, aber jetzt nehmen wir mal an, diese ganzen Programme hier von DeepMind sind selbstlernend, gehe ich mal stark von aus.

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

Hoffentlich.

Andy Grunwald (00:04:20 - 00:04:33)

Und das bedeutet natürlich auch, die können nur das lernen, was du denen gibst. Und da gibt es ja auch in der Industrie recht viele Probleme, dass wenn das Dataset mit Vorurteilen behaftet ist, dass die Logik natürlich dann auch mit Vorurteilen behaftet ist.

Wolfi Gassler (00:04:34 - 00:04:42)

Also shit in, shit out. Das heißt, du glaubst, es braucht mal gute Entwickler überhaupt, damit die Inputdaten irgendwie sinnvoll sein können.

Andy Grunwald (00:04:43 - 00:04:58)

Das hast du jetzt gesagt. Und deswegen habe ich auch gefragt, wo haben die Daten her? Weil ich meine, GitHub ist super. Ich surfe den ganzen Tag auf GitHub und ich kriege auch super viel Inspiration von GitHub. Aber da liegt halt auch echt viel Kram rum, der gegebenenfalls auf dem Basis, auf dem gegebenenfalls nicht gelernt werden sollte.

Wolfi Gassler (00:04:58 - 00:05:18)

Wobei, wenn man sich überlegt, wenn du nur besser sein kannst als der Durchschnitt, ob das nicht schon für 99 Prozent der Fälle auch ausreichend ist. Weil wie oft schaust du in irgendeine Library rein, die du verwendest, wenn du irgendeinen JavaScript-Library einbindest oder so? Dir ist doch komplett egal, wie dieser Code aussieht. Hauptsache, es funktioniert.

Andy Grunwald (00:05:18 - 00:05:25)

Da ich sehr, sehr wenig JavaScript mache und ich gehe stark davon aus, meine JavaScript-Sachen, die ich habe, haben viel zu viele Dependencies.

Wolfi Gassler (00:05:25 - 00:05:27)

Nimm deine Go-Libraries.

Andy Grunwald (00:05:27 - 00:06:25)

Ja, ich sollte, glaube ich, öfter mal in die Dependencies gucken. Du hast natürlich einen Punkt, aber auf der anderen Seite stelle ich auch die Frage, inwieweit ist das denn auch wirklich sinnvoll? Okay, du hast jetzt eine Logik, die löst jetzt diese Programmier-Challenge. Diese Programmier-Challenges sind natürlich ... Wofür gibt's die? Die gibt's zum einen zum Spaß, wenn man sich ein bisschen weiterentwickeln möchte. Dann gibt's die, glaube ich, für Recruitingzwecke. Training von sich selbst vielleicht. Weil ich mein, soviel ich weiß, diese ganze Algorithmik, Optimierung von Algorithmen, ist ja auch ein Sport. Gibt's ja auch Wettbewerbe drin. Ich meine, Russ Cox aus dem Go-Team hat so was mal kompetitiv gemacht früher. Aber ich mein, wie soll das dann jetzt später aussehen? Heißt das dann, wir schreiben, was wir genau haben wollen, einmal in Fleece-Text, und dann kommt DeepMind rum, und die bezahlen wir, dass die Applikation dahingestellt wird?

Wolfi Gassler (00:06:26 - 00:07:06)

Das ist eine gute Frage, aber ich finde es eigentlich schon irgendwie verlockend, weil wenn ich mir so überlege, meine Programmierarbeiten, 90 Prozent davon sind eigentlich langweilig. Die hat man im Kopf und die weiß man ganz genau, wie man sie programmieren sollte und man schreibt die einfach so runter und Da ist nicht viel dahinter, da denkt man nicht scharf nach, sondern es ist halt einfach nur Coding. Und wenn dieser Teil irgendwie übernommen werden könnte von einer AI, dass ich wirklich sage, okay, ich will da jetzt ein Login-Formular, aber mach mir dieses Login-Formular einfach inklusive Logik, dann finde ich das schon ziemlich verlockend für mich als Programmierer, weil dann kann ich mich mit den schwierigeren Dingen auseinandersetzen.

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

Ich meine, du hast natürlich schon einen gewissen Punkt in der Hinsicht, dass die meisten Applikationen, die geschrieben werden, bereits auf gelösten Problemen basieren. Login-Formulare. Ich lese was aus der Datenbank aus. Ich schreibe was in die Datenbank. Ich update und lösche einen Datensatz. Ja, berühmte CRUD. Create, Read, Update, Delete. Ich zeige etwas an, eine Listenview. Ich habe einen Step Wizard in einem Formular. Stimmt schon. Ich habe die Tage einen lustigen Tweet gelesen. Die Softwareentwicklungsindustrie, die IT-Industrie ist die einzige Industrie, wo das Interview härter ist als der eigentliche Job.

Wolfi Gassler (00:07:41 - 00:07:45)

Hast du das als Hiringmanager auch immer so gehandhabt?

Andy Grunwald (00:07:45 - 00:08:55)

Nein. Ich habe Basisprogrammierskills abgefragt, aber ich habe dabei immer versucht, den Kandidaten, der Kandidatin die Chance zu geben, aus ihren eigenen Programmiererfahrungen zu erzählen. Also das bedeutet, wenn ich da jetzt irgendwas über einen B3-Index von MySQL abfrage, dann kann ich das zwar vielleicht beantworten, aber vielleicht nicht der Kandidat. Dafür kann der Kandidat mir was über Hot Partitions bei DynamoDB erzählen, wovon ich relativ wenig Ahnung habe. Oder nur weil ich keine Details über Hot Partitions in DynamoDB kenne, heißt das ja nicht, dass man nicht sehen kann, ob die Person die Wahrheit sagt oder nicht. Also ob die Person weiß, wovon sie redet oder nicht. Ich denke, das bekommt man sehr gut raus. Und ein paar Basisprogrammiersachen sollte man können. Ich erwarte jetzt keinen Merge Sort aus dem Kopf. Aber weiß ich nicht. Ich glaube, wir haben da sehr oft einen kleinen Test gemacht, Man hat eine Funktion, man bekommt ein String rein und soll eine Boolean zurückgeben und die Funktion soll erkennen, ob das Argument ein Palindrom ist, also ein Wort, was von vorne und von hinten gelesen werden kann, so wie z.B. Anna.

Wolfi Gassler (00:08:56 - 00:09:12)

Aber das ist ja so ein klassisches Rätsel, worüber sich auch viele beschweren, dass man solche Fragen überhaupt stellt und dass Google zum Beispiel ja extrem als Beispiel auf diesem Zug aufgesprungen ist und recht viele von diesen klassischen Algorithmen-Fragen auch in Interviews hat.

Andy Grunwald (00:09:13 - 00:09:45)

Das ist korrekt. Und wir haben aber auch sehr viele Alternativen geboten. Und zwar, wenn du es nicht programmieren konntest, weil zum Beispiel du nicht an einer ordentlichen Tastatur gesessen hast oder die IDI nicht die war, mit der du dich auskennst oder ähnliches, dann haben wir die ganze Thematik einfach durchgesprochen. Ja, wie würdest du das machen? Und was würde passieren, wenn der String, der reinkommt, so groß ist, dass er gar nicht zweimal in den Speicher passt, in den Arbeitsspeicher und so weiter und so fort. Also sowas kann man ja durchsprechen. Das muss man ja nicht alles programmieren. Und da merkt man schon, welche Lösungsansätze da rauskommen.

Wolfi Gassler (00:09:47 - 00:10:20)

Wenn du jetzt schon sagst, AI ist so ein Hype und du als Duisburger Infrastruktur-Mensch würdest natürlich jedem Infrastruktur empfehlen, wenn sich jemand spezialisieren will oder soll. Was würdest du empfehlen? Wenn ich jetzt zurückdenke, ich war Student in meinem Studium und dann hört man überall AI und alles geht in diese Richtung und jeder will Machine Learning machen. Würdest du jetzt irgend so einem Studenten empfehlen, lass das doch sein, konzentriere dich auf Netzwerktechnik?

Andy Grunwald (00:10:21 - 00:10:24)

Moment, mein Hund zerlegt gerade einen Teppich, einen Moment.

Wolfi Gassler (00:10:24 - 00:10:29)

Du könntest schon ein bisschen investieren für dieses Podcast. So ein Teppich, es gibt Kollateralschäden.

Andy Grunwald (00:10:30 - 00:10:33)

Das war kein Teppich, das war ein Teil der Türdichtung.

Wolfi Gassler (00:10:33 - 00:10:42)

Es ist eh gut, Belüftung muss eh auch sein. Also wo waren wir? Bei dem Empfehlen für einen Studenten, soll der dann Netzwerktechnik lernen?

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

Ich sage nicht, dass Machine Learning und Artificial Intelligence ein negativer Hype ist, ganz und gar nicht. Ich denke Hypes gibt es auch im Bereich Data Science, DevOps, Reliability Engineering, also auch im Infrastrukturbereich.

Wolfi Gassler (00:10:55 - 00:11:05)

Was wäre so ein Hype im Infrastrukturbereich, wo du sagst, da springen jetzt irgendwie alle auf und eigentlich muss man schauen, ob es was wird oder ist vielleicht schon bewiesen, dass es doch nicht so toll war?

Andy Grunwald (00:11:05 - 00:11:39)

Ich denke, gerade ein Hype im Infrastrukturbereich ist auf der einen Seite DevOps, auf der anderen Seite Site Reliability Engineering. Es gibt eigentlich keine klassischen Systemadministratoren mehr. Jeder ist irgendwie DevOps, DevOps-Engineer, Site Reliability-Engineer. Aber im Endeffekt machen sie alle das Gleiche, was sie schon vorher getan haben. Und das ist für mich irgendwie Hype-Driven-Titling oder Ähnliches. Also man wechselt den Jobtitel. weil es jetzt seit Reliability Engineering von Google durchs Dorf getrieben wird oder ähnliches, obwohl das fundamental was anderes ist.

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

Aber ist das nicht auch eine andere Einstellung, also wie so ein Job aufgebaut ist, wie die Verantwortungsbereiche und so weiter aufgebaut sind? Also steckt da nicht ein anderes Mindset dahinter, wie so eine Stelle angelegt ist? Und zeigt das da nicht auch etwas aus, wie eine Firma arbeitet und wie die Atmosphäre dort ist und die Herangehensweisen?

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

Ja völlig völlig natürlich hat der Jobtitel Site Reliability Engineer etwas zu sagen, dann angenommen es wird ein DevOps Engineer gesucht, das ganz eng gesehen ist das eigentlich schon falsch, weil DevOps ja keine Jobstelle ist, sondern eher eine Kultur, wie man zusammenarbeitet nur also es ist ja ich sage das ist ja genau das was ich sage es ist ja fundamental was anderes und man kann nicht einfach einen existierenden job, rebranden und den da genau so weitermachen denn das ist für mich einfach so oh, müssen jetzt dem hype folgen das kriegen wir keine talente mehr oder ähnliches also nehmen wir mal, Nehmen wir mal Zeit Reliability Engineering. Zeit Reliability Engineering besagt eigentlich, die Originaldefinition ist eigentlich, man beauftragt Software Engineers mit dem operativen Betrieb von Systemen und der Grundgedanke dahinter ist, dass viel mehr Automatisierung angelegt wird und die ganze Sache nicht von einem klassischen systemadministrator mein set ich gehe jetzt mal ganz weit zurück das bedeutet ich logge mich auf die maschine ein debugger das und und führe dann drei befehle aus sondern dass man natürlich abhängig von der größe seiner infrastruktur mehr und mehr automatisiert vielleicht sogar ich nehme jetzt mal ein buzzword ins in den mund selbst heilende systeme anstrebt Kubernetes ist so ein gutes Beispiel, wenn dort ein Server wegfliegt, dann versucht ja Kubernetes auch, die Workloads auf einen anderen Server zu übertragen. Natürlich gibt es dann eine Degradation im System, aber der Grundgedanke ist eigentlich, dass das System, ich nenne es mal, selbst heilend ist.

Wolfi Gassler (00:13:42 - 00:13:55)

Aber warum darf jetzt ein Student, der das alles cool findet und in dem Bereich arbeiten will, weil das halt die neue Technologie ist oder neue Kultur, wie du auch richtig sagst, warum darf der nicht auf diesen Zug aufspringen?

Andy Grunwald (00:13:56 - 00:15:00)

Also jeder darf auf diesen zug aufspringen super und ich finde das auch ich finde das auch toll ich meine jeder kann ja machen was er möchte ich sag nur dass, dass halt ein hype ist der durch die industrie getrieben wird und dass es nicht mit dem rebrand des job titels getan ist weil in der regel gehört ja viel mehr zu ja die organisation drumherum gehört dazu, wie sich das team verhält und wie das team auch die arbeit aufbaut und angeht und und welche quartals oder jahresziele sich die betriebsabteilung denn was mal setzt oder wie die entwicklungsabteilung mit der infrastrukturabteilung zusammenarbeitet also es ist ja nicht damit getan dass jetzt jobtitle a durch jobtitle b ersetzt wird sondern sondern es ist eine kulturänderung also da muss ja da muss ja viel mehr gemacht werden. Nehmen wir mal im Infrastrukturbereich, Reliability Engineering, wie man auf Ausfälle reagiert, Blameless Postmortems, dann sich eigene SLAs, SLIs, SLOs setzt, die an die Quartalsziele gegebenenfalls geknüpft sind etc. Also da gibt es ja so viel.

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

Aber ist so ein Hype dann nicht genau gut, um so eine Kultur zu fördern und einzuführen in den Firmen?

Andy Grunwald (00:15:07 - 00:15:53)

Ich denke, er könnte ein Anschluss sein, doch nehmen wir mal das DevOps-Movement. Das ist ja jetzt nicht erst seit gestern da. Das existiert ja schon ein paar Jahre. Und zumindestens hier auf dem deutschen Markt sehe ich den Push von den ganzen Individual-Contributoren. Die wollen das, die viele, viele verstehen auch, dass DevOps kein Jobtitel ist, sondern eher eine Kultur. das management die teamleiter das mittelmanagement die die chef etage da will man das nicht verstehen oder hat vielleicht auch ganz offen gesprochen keine zeit oder interesse das zu verstehen was auch okay ist weil die beschäftigen sich jedenfalls mit anderen problemen aber ohne das ohne den rückhalt von diesen ebenen kann man keine kulturänderung in der firma vollziehen da kann da können die individuellen contributor noch so pushen.

Wolfi Gassler (00:15:53 - 00:15:57)

Okay, aber umso besser ist es, wenn Studenten darauf aufspringen und das pushen, oder?

Andy Grunwald (00:15:57 - 00:16:48)

Ich denke, dass dies ein guter Start ist. Ich denke aber auch, sofern sie keinen Erfolg in der jeweiligen Firma haben, werden die recht schnell die Firma wechseln, wo das Verständnis da ist. Und das würde bedeuten, dass über kurz oder lang, sehr viele Firmen im deutschen Bereich ein enormes Problem mit Fachkräften haben. Und das tut mir dann leid. Das tut mir auf der einen Seite leid für die Firmen, das tut mir auf der anderen Seite leid für die, nehmen wir mal dein Beispiel von Studenten, die es dann probiert haben und eine negative Erfahrung gemacht haben. Und ich hoffe, dass diese Leute dann den Mut haben, die Firma zu wechseln und das erneut zu probieren und nicht aufgeben. Weil das ist, also ich kann mir schon vorstellen, dass das sehr, sehr viel Kraft auch benötigt, nochmal einen zweiten Push zu machen, weil man weiß ja, oh, das hat bei der ersten Firma schon nicht geklappt.

Wolfi Gassler (00:16:48 - 00:18:34)

Aber ich glaube, das ist extrem wichtig, dass, ich nenne es jetzt mal einfach die jungen Leute, genau das vorantreiben und pushen. Und das war mir zum Beispiel auch immer extrem wichtig, wenn wir Newcomer hatten im Team. Ihr habt immer alle ermutigt, dass sie wirklich den frischen Wind, den sie reinbringen können, auch wirklich reinbringen in das Team und dass der auch aktiv bleibt im Team, dieser frische Wind, dass sie Sachen kritisch beurteilen, irgendwie neue Ideen reinbringen und auch wirklich dumme Fragen stellen, weil genau dieser frische Wind von außen und diese neue Sicht ist extrem wertvoll und ich glaube, dass es extrem wichtig ist, dass die Leute pushen und Die meisten Personen, teilweise auch Studenten, die wir als studentische Mitarbeiter angestellt haben, wussten gar nicht, wie viel Macht sie eigentlich haben, indem sie einfach Fragen stellen und gewisse andere Sichtweisen mit ins Team bringen, wenn sie neu sind, die extrem wertvoll für ihr Team waren. Also ich würde fast sagen, dieses ganze Hype-Driven-Development, wie du es nennst, Kann auch etwas Positives haben, weil einfach diese Hypes in die Teams getragen werden und deshalb der frische Wind ist herpuscht und du hast sowieso genug alte Leute, die auf der anderen Seite sind, die vielleicht stur auf ihren alten Technologien sitzen und auf keinen Fall eine Änderung wollen. Und ich glaube, es ist halt diese Mischung, die das einfach ausmacht, dass du dich dann irgendwo in der Mitte triffst und sinnvolle Technologien wirklich rausfilterst und dann aber auch verwendest. Und da sind diese jungen Leute extrem wichtig und ich glaube da sind die Hypes auch wichtig, weil sonst finden die Technologien oder neue Herangehensweisen gar nicht den Weg in die Firmen und in die Teams.

Andy Grunwald (00:18:34 - 00:21:16)

Da bin ich ja auch voll bei dir und ich bin da auch einer Meinung mit dir, dass neue leute sei es sei es studenten oder von mir aus auch leute die schon 40 jahre berufserfahrung haben und von woanders kommen frischen wind mit rein bringen dass man dass man diese meines erachtens sogar superpower auch nutzen und fördern sollte ja also da bin ich da bin ich voll bei dir, doch wo ich kein fan von bin ist man hat irgendwas jetzt wieder bei bei heise gelesen und sagt genau das gleiche brauchen wir auch und nächsten tag launch man irgendeinen neuen service bei ws und schmeißt da ein gigabyte daten rein und hofft sich dass man das gleiche ergebnis hat wie die meint ja also dass man dass man nicht einfach. Irgendetwas nimmt was man drüben gesehen hat und einfach blind auf auf die eigenen firmenprobleme anwendet kommen wir mal weg von diesen maschinen learning ein anderes beispiel wäre monorepos. Monorepos versus verschiedene repository das ist alles super also google hat ein riesen monorepo und. Ein Code Change, ein API Change in einer Library kann dann komplett an allen Applikationen gemacht werden. Klasse. Und in der Theorie sieht das auch super aus. In der Praxis ist das doch alles ein bisschen komplizierter, weil man muss dafür wissen, dass Google enorm viel Arbeit und Energie da reingesteckt hat, sich das Tooling, um die Monorepos maintainen zu können, drumherum selbst gebaut hat und dies nicht veröffentlicht hat. wohingegen die klassischen Continuous-Integration-Systeme so gebaut sind, auf einem Repo zu operieren und gar nicht mit Monorepos zu arbeiten. Das bedeutet, das Tooling in der Open-Source-Szene und das, was die Firmen eigentlich gewohnt sind, ist gar nicht da. Was ich damit sagen möchte, einfach das Stichwort Monorepos in die Runde zu schmeißen und dann zu sagen, das müssen wir machen, weil da haben wir einen kleinen Vorteil, aber 35 Nachteile, und dann alle Repositorien auf ein Monorepo umzuziehen, Und dann auch die Probleme schauen wir nochmal und dann ist das Team irgendwie die nächsten drei Monate damit beschäftigt Tooling drumherum zu bauen. Das meine ich eigentlich mit Hype Driven Development, dass man, dass man sich die Thematik vielleicht, ich sag nicht bis ins kleinste Detail ansieht, das sage ich nicht. Wir hatten mal über Innovation Tokens gesprochen. Ein bisschen Risiko muss man da gegebenenfalls auch gehen. Doch ich sag immer so schön, man sollte mal einen Fall draus machen. Man sollte sich da wenigstens ein bisschen mal hinsetzen, mal ein paar Vorteile aufschreiben, ein paar Nachteile und fundamental zu sagen, okay, welches Problem möchte ich eigentlich mit dieser Änderung lösen? Und wenn wir wieder zurückkommen auf diese Jobtitles, Machine Learning, Artificial Intelligence, Data Science, DevOps, Site Reliability Engineering. Ich tu mir da halt immer ein bisschen schwer, Es gibt halt keine Industrie-Definition davon. Also nehmen wir mal Data Science. Ich bin jetzt Data Scientist und in manchen Firmen machen...

Wolfi Gassler (00:21:16 - 00:21:23)

Was war bitte die Definition von Administrator früher? Da gibt es auch keine Definition. Von einem Job Title hat es nie eine Definition gegeben.

Andy Grunwald (00:21:23 - 00:22:10)

Ja richtig da gab es aber keine 35 von da gab es ein Systemadministrator und das hieß es dann und jetzt gibt es ja Data Analyst und manche sagen der Data Scientist ist dann die nächste Stufe vom Data Analysten und da muss ich mal ganz ehrlich fragen ist das denn so weil guckt man die Stellenausschreibung aus, kann man da wirklich querlesen. Das, was ein Data-Analyst macht, macht teilweise ein Data-Scientist, teilweise ist das der Karrierefahrt, teilweise sind das einfach zwei verschiedene Rollen. Dann gibt es noch Business-Intelligence-Analyst. Ist das das Gleiche wie ein Data-Analyst oder ein Data-Scientist? Verstehst du? Inzwischen habe ich das Gefühl für eine, ich will noch niemals sagen, ähnliche Arbeit, weil es gibt ja keine Definition. Das bedeutet natürlich auch, dass jede Firma diese Jobs für sich komplett definiert. Das bedeutet aber auch, wenn ich jetzt Data-Scientist bin, dass ich nicht einfach, ich bin Data-Scientist und gehe jetzt zu Firma B und mache genau das Gleiche.

Wolfi Gassler (00:22:11 - 00:22:36)

Das stimmt natürlich und auch von der Größe, je nach Größe der Firmen unterscheiden sich die Jobs extrem. Aber ich glaube, das ist auch so ähnlich wie Senior Engineer. Wenn du bei Google ein Senior Engineer bist, keine Ahnung, die haben Levels, okay, aber oder eine andere große Firma und du bist Senior Engineer, ist wahrscheinlich ein Unterschied, als wenn du bei einer Drei-Mann-Firma irgendwie aus, aus, wie heißt die Stadt in Deutschland, die es eigentlich gar nicht gibt?

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

Bielefeld.

Wolfi Gassler (00:22:37 - 00:23:13)

Oder wenn du in einer Drei-Mann-Firma in Bielefeld bist, wo du einfach Senior Engineer bist, dann wirst du wahrscheinlich auf einem anderen Level sein, als wenn du auf dem Google Senior Engineer Level bist. Und so sehe ich das halt auch bei anderen Bereichen. Also ich glaube, du musst immer checken, wo ist diese Position angesiedelt, in welcher Firma, in welchem Environment, wie ist die angelegt. Wie schaut das Team aus? Was macht das Team? Und ich glaube, man kann das nicht ganz allgemein über eine allgemeine Definition machen, weil auch Developer, wie ist Developer definiert? Developer kann alles sein, sogar in Bielefeld.

Andy Grunwald (00:23:14 - 00:24:10)

Ich stehe dem Begriff Senior, Senior Engineer auch sehr, sehr kritisch gegenüber. Einfach nur deswegen, weil es keine industrieweite Definition gibt, beziehungsweise keine Vergleichbarkeit dazwischen, zwischen den Rollen. Nehmen wir mal Senior Engineer. Man kann sagen, man wird Senior Engineer, wenn man fünf Jahre Berufserfahrung hat. Ist das gut? Schlecht? Weiß ich nicht. Ist das zu wenig? Zu viel? Weiß ich jetzt auch nicht. Nur, was sagen denn 5 Jahre Berufserfahrung aus? 5 Jahre Berufserfahrung kann bedeuten, ich habe 5 Jahre lang den Job gemacht und mache seit 5 Jahren eigentlich genau den gleichen Job, denn ich schreibe Login-Formulare. Das wären für mich aber eher 5 mal 1 Jahr Erfahrung und nicht 5 Jahre Erfahrung. In fünf Jahren Erfahrung würde ich schon schätzen, dass die Person sich weiterentwickelt hat. Und natürlich auch nicht nur Tickets aus dem Gyroboard nimmt und bearbeitet, sondern vielleicht auch mal selbst Tickets schreibt, selbst Projekttexte schreibt, selbst Probleme aufzeigt und so weiter und so fort.

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

Aber hättest du eine Lösung dafür? Ich glaube, dass es schwierig ist, eine Definition zu finden. Und ich glaube auch nicht wirklich, dass es da eine Möglichkeit gibt, das Problem zu lösen.

Andy Grunwald (00:24:20 - 00:26:02)

Also ich denke nicht, dass wir industrieweit auf eine Definition von Senior Engineer oder ähnliches kommen werden. Was ein guter Ansatz ist, ist die ganz klare Definition von Karrierefaden. Das bedeutet, welche Kriterien muss jemand erfüllen, der vom Junior Engineer auf ein Mittel-Level-Engineer und vom Mittel-Level-Engineer auf ein Senior-Engineer aufsteigen möchte? Welche Kriterien sollen da erfüllt werden? Und das kann jede Firma ja selbst definieren und da gibt es Zum Beispiel ein paar gute Beispiele von CircleCI. CircleCI hat eine recht große Matrix, eine recht große Excel-Matrix, die sagen, okay, auf der X-Achse haben wir Junior-Engineer, Middle-Level-Engineer, Senior-Engineer und so weiter, und auf der Y-Achse haben wir Kategorien wie Project-Management, Team-Leitung, Code Reviews und so weiter. Und dann in jedem Achsenpunkt gibt es dann einen kleinen Text zur Erwartungshaltung. Und die haben sie veröffentlicht. Da kann man dann relativ objektiv sagen, okay, diese Person ist Senior oder diese Person, der fehlt im Bereich Project Management noch diese drei Punkte. So machen das ja eigentlich die großen hier Facebook, Meta, Google, Uber und wie sie alle heißen ja auch. Und deswegen gibt es ja inzwischen auch Möglichkeiten, die Levels bei den großen Funk-Companies miteinander zu vergleichen. Und deswegen ist ja auch das Wort Downleveling wirklich ein Thema. Das bedeutet, wenn jemand von Amazon nach Google wechselt und der ist bei Amazon Principal Engineer, muss das nicht unbedingt heißen, dass er bei Google Principal Engineer wird, sondern er kann da auch runtergestuft werden als, ich glaube, das Level darunter wäre Staff Engineer oder ähnliches. Also dieses Downleveling ist ja wirklich ein Ding.

Wolfi Gassler (00:26:02 - 00:26:30)

Okay, aber das zeigt dann also wirklich, dass es eigentlich nicht möglich ist, irgendwie eine industrieweite Definition zu machen. Maximal innerhalb einer Firma und sogar da ist es teilweise schwierig. Glaubst du, dass es möglich ist, komplett ohne solche Levels und Titel durchzukommen? Also Trivago war ja da auch lange Zeit oder immer noch, ich bin mir gar nicht sicher. Vor allem Rolf damals als CEO von Trivago war ein großer Befürworter, dass wir keine Titel haben. Glaubst du, dass es grundsätzlich möglich ist?

Andy Grunwald (00:26:31 - 00:26:35)

Ich denke, dass es grundsätzlich möglich ist. Bei Trivago hat es ja funktioniert, meines Erachtens nach.

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

Darüber kann man jetzt streiten. Da sind wahrscheinlich einige andere Meinung.

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

Also ich habe auch keine Lösung, ob man immer nur Titel einführen sollte oder ob man Titel weglassen sollte. Da habe ich jetzt keine Lösung. Ich glaube, es gibt ein Für und Wider für beide Bereiche. Besonders wenn die Firma sehr hierarchie-driven ist, nennen wir es mal, dann sagt natürlich auch schon mal so ein Titel was aus. Mit wem spricht man da? Wie viel Erfahrung hat die Person? Und dann wird die Person gegebenenfalls auch ganz anders wahrgenommen. Und ich denke schon, dass für gewisse.

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

Personengruppen das Bleiben wir mal bei einem Developer-Team. Glaubst du, dass so ein Developer-Team ohne Titel funktionieren kann?

Andy Grunwald (00:27:08 - 00:27:20)

Ich denke, umso weniger Entwickler es sind, umso besser funktioniert es. Ich denke, die Komplexität und Problematik kommt, umso mehr Entwickler die Abteilung bzw. Firma wirklich hat.

Wolfi Gassler (00:27:20 - 00:29:01)

Ja, das glaube ich auch. Und ich glaube auch, dass viele Personen Titel wollen, einfach um auch den Wachstum vielleicht in irgendeinem Titel zu manifestieren. Auch wenn ich jetzt persönlich überhaupt kein Freund davon bin und ich das persönlich auch nicht unbedingt als wichtig empfinde. Aber ich glaube, viele Leute wollen das. Und was dann schon auch dazu mit reinspielt, und das hast du ja auch als Beispiel schon genannt, dass die ganzen großen Firmen die funktionieren mit diesen Titeln. Und sobald du nach außen gehst, wir hatten zum Beispiel bei Trivago eben lang keine Titel oder es gibt immer noch keine Titel. Und wenn du aber mit der Welt da draußen kommunizierst, wenn du zum Beispiel mit Recruitern kommunizierst, ich hatte mal ein Gespräch mit einem Recruiter, der irgendwie gemeint hat, ja, ich soll doch von meinem Engineering Manager, Senior Engineering Manager schreiben, weil es ist so üblich in der Branche und sonst verkaufe ich mich unter Wert. Da kommt natürlich von außen sofort dieser Druck rein. Und wenn du dann nie Senior warst in deiner Firma, wie willst du dann irgendwo anders dich für ein Senior bewerben und so weiter? Also es gibt schon extremer Druck, der auch von außen reinkommt. Und ich glaube, mittlerweile habe ich eigentlich meine Meinung geändert, dass es extrem schwierig ist, glaube ich, wirklich ohne Titel auszukommen, weil es einfach so ein Druck überall ist, auf die Industrie diese Titel zu haben. Ich bin persönlich immer noch kein Freund von Titeln und ich glaube, in kleineren Firmen ist es auch nicht nötig. Aber in einer großen Firma ohne ein System auszukommen, glaube ich mittlerweile, dass es auch nicht mehr möglich ist, beziehungsweise nur wenn das sehr, sehr gut irgendwie verankert ist in der Firma, dass das ohne funktioniert und man da irgendwie eine sinnvolle Lösung findet, wo extrem viele und vor allem das Management dahinter stehen. Sonst würde es extrem schwierig, meiner Meinung nach.

Andy Grunwald (00:29:01 - 00:29:32)

Aber ich meine, da sind wir doch schon wieder bei dem Hype. Also einfach ein Senior vor deinen Software-Engineern zu knallen, bringt es ja nicht. Du hast ja kein Fundament. Was bedeutet das? Wieso darfst du Wolfgang Senior sein und ich nicht? Wenn du aber einen Fall daraus machst, wenn du eine Definition mit deinen Kollegen erarbeitest, was das denn eigentlich heißt, welche Kriterien erfüllt sein müssen, dass du Senior bist, dann ist das ja auch alles fein. Dann kannst du das ja machen. Dann ist es ja aber kein Hype mehr, sondern habt ihr alle da kontinuierlich und wirklich gut drüber nachgedacht. ob ihr das nutzt und so weiter.

Wolfi Gassler (00:29:32 - 00:30:17)

Ich vergleiche das immer recht gern mit dem Doktor zum Beispiel oder einem Master und ich habe da einfach so viele Unterschiede gesehen an der Uni, wer einen Doktor bekommt, wer einen Master bekommt, wer einen Bachelor bekommt, wer diese Titel bekommt, da gibt es einfach solche Unterschiede zwischen dem Level von Personen und die bekommen alle den gleichen Titel und vielleicht bekommen sie eine schlechtere Note für den Doktor, aber am Ende steht da ein Doktor vor dem Namen und es fragt niemand mehr, was war denn das für eine Note und hat der den Doktor wirklich verdient? Und sogar da, in diesem Bereich, wo seit Jahrhunderten diese Definitionen bestehen und verfeinert worden sind, sogar da, finde ich, ist es teilweise, ich will es jetzt nicht unfair nennen, aber manchmal fragt man sich, wie manche Leute einen Doktor bekommen, Wie.

Andy Grunwald (00:30:17 - 00:30:18)

Hast du denn einen Doktor bekommen?

Wolfi Gassler (00:30:18 - 00:30:27)

Ich habe einfach zehn Jahre gewartet und irgendwann waren dann alle so fertig und schon so aufgeweicht, dass sie mir den Doktor einfach gegeben haben.

Andy Grunwald (00:30:27 - 00:31:53)

Aber kommen wir nochmal ganz kurz zu den Jobtitles rüber. Ich meine Jobtitles sind, es ist ja auch ein Problem oder es bringt natürlich auch eine ganze Struktur mit drumherum. Beispiel. Angenommen, deine Firma hat jetzt Jobtitles. Wer bestimmt denn, wer auf das nächste Level kommen kann oder wer kommen darf? Das bedeutet also Google und die ganzen großen, die haben da so Promotion-Komitees. Und das, was man so liest, ich habe da noch nie gearbeitet, aber das, was man so liest, bedeutet, okay, du musst deine Promotion-Mappe zusammenstellen, an welchen Projekten hast du gearbeitet, welchen finanziellen und Business-Impact hattest du etc. etc. Du musst also schon deine Erfolge dann zusammentragen und dann gehst du vor dieses Komitee und die schauen sich auch deine Code-Reviews an und deine Pool-Requests und etc. und entscheiden dann, ob du den nächsten Titel bekommst oder nicht. Das bedeutet natürlich auch, oder es kann zu einem Status führen, wo du dann eigentlich nur noch für diese Promotion arbeitest. Es gibt ja auch dieses Sprichwort, you don't make friends in Silicon Valley, was darauf bezogen ist, dass es da nicht viel Kollegiales gibt. Es gibt nicht so, hey, ich hab hier ein Problem mit Docker, kannst du mir mal helfen? Sondern eher, jeder arbeitet dann eigentlich nur für seine nächste Promotion, weil diese Promotion natürlich dann gegebenenfalls an einen gewissen Gehaltsrahmen gebunden ist. Also das bedeutet ein höherer Titel, ein höherer Gehälter etc. etc. hat natürlich ganz andere Incentives. Was ich damit sagen möchte, es ist nicht einfach so, schmeiß mal Zinio davor, sondern da hängt eine ganze Menge dran.

Wolfi Gassler (00:31:53 - 00:33:01)

Ich habe auch noch ein anderes Negativbeispiel, ganz ganz konkretes Beispiel. Größere Firma, quasi Konzern, die aber nicht nur IT-Leute haben, die haben Levels und die Levels sind verknüpft natürlich mit Gehalt-Ranges und das Problem was sie jetzt haben, damit sie die IT-Gehälter mit dem Markt matchen können, müssen sie jetzt die Levels von den Mitarbeiter von den Mitarbeitern und Mitarbeiterinnen erhöhen, damit die irgendwie auf diese Levels kommen, damit die irgendwie ein ähnliches Gehalt bekommen, wie am Markt üblich ist. Das heißt, die werden jetzt zum Beispiel auf einen Senior gehoben, obwohl sie eigentlich gar kein Senior sind, aber sie müssen auf Senior Level sein, um überhaupt so ein Gehalt zu bekommen, das marktüblich ist. Das heißt, in dem Fall ist das Connected mit dem Gehalt, was glaube ich meiner Meinung nach sowieso ein großer Fehler ist, aber eigentlich bei allen natürlich in irgendeiner Form verbunden ist. Dann gibt es natürlich solche Probleme wie jetzt, wo der Markt teilweise um 10%, 20% angezogen hat. Da musst du einfach dann diese Leiter nach oben, um überhaupt sinnvolle Gehälter zu bekommen. Und das macht natürlich dann auch keinen Sinn, weil du willst ja eigentlich nicht deine Leute auf den Senior heben, obwohl sie kein Senior sind.

Andy Grunwald (00:33:01 - 00:33:05)

Warum bist du dagegen, die Jobtitles an einen Gehaltsrahmen zu binden?

Wolfi Gassler (00:33:06 - 00:33:40)

Genau aus diesen Gründen, weil du dann die Flexibilität verlierst, dass du vielleicht irgendwie Gehaltsanpassungen machst. Also es wäre in dem Fall möglich, wenn du das auf Positionen machst, also dass zum Beispiel jetzt Developer, Data Scientists bekommen allgemein ein höheres Gehalt. Das wäre natürlich möglich, dass du das dann irgendwie entkoppelst von diesen Levels. Aber wenn die Levels natürlich auch für jemanden aus der Buchhaltung gelten, aus dem Marketing, dann hast du da natürlich sofort Probleme mit dem Gehaltsschema da in einer großen Firma, wo du halt tausende Mitarbeiter hast.

Andy Grunwald (00:33:40 - 00:33:56)

Aber ein Jobtitle sagt ja beziehungsweise auch etwas über die Verantwortung aus. Also ein Senior Engineer, der sollte meines Erachtens nach auch mehr Verantwortung haben als ein Junior Engineer und diese Verantwortung muss natürlich in irgendeiner Art und Weise auch vergütet werden.

Wolfi Gassler (00:33:56 - 00:34:24)

Aber das meine ich ja eben, genau. Wenn du jetzt einen Junior hast zum Beispiel, der bekommt aber zu wenig Geld. Und damit du die Juniors halten kannst, musst du die erhöhen in ihrem Gehaltsschema, damit die dir nicht zu anderen Firmen wechseln, weil die einfach extrem niedrig eingestuft sind. Jetzt musst du die auf ein höheres Level heben, damit du denen überhaupt mehr zahlen darfst, Company intern. Weil sonst darfst du denen gar nicht das Gehalt zahlen, das am Markt üblich ist.

Andy Grunwald (00:34:25 - 00:34:32)

Ja, Moment, aber du redest jetzt von der Anhebung der Title. Wieso werden die Gehaltsranges nicht geändert?

Wolfi Gassler (00:34:33 - 00:34:37)

Weil die starr sind, weil es ein Riesenkonzern ist.

Andy Grunwald (00:34:37 - 00:35:13)

Ja gut, aber das ist ja nicht das Problem von Levels, sondern das ist ja das Problem von der Inflexibilität von Gehaltsstrukturen. Ich meine, unabhängig von dem Entwicklermarkt, von dem IT-Markt, wir haben eine Inflation und die Inflation ist gerade gar nicht mal so wenig. 4, irgendwas Prozent, 5 Prozent pro Monat, irgendwie sowas haben wir gerade. Er meint ja pro Jahr, Entschuldigung. Aber auf jeden Fall, da ändern sich natürlich auch die Gehälter von Leuten aus dem Marketing, aus der Personalabteilung, von der Rezeption etc. Also diese müssen ja auch angepasst werden der Inflation nach.

Wolfi Gassler (00:35:14 - 00:35:53)

Ja, aber du hast zum Beispiel jetzt eben SREs, wenn du Site Reliability Engineers suchst, dann hast du sicher einen stärkeren Anstieg als die 5% Inflation zum Beispiel. Da hast du am Markt vielleicht jetzt 20% gegenüber dem vorherigen Jahr, damit du Leute bekommst. Und dann hast du nur dieses Problem, dass einer in der Buchhaltung nicht so eine starke Anpassung hat, wie ein Site-Reliability-Engineer. Und damit bist du schon wieder weniger flexibel. Ich sage nicht, dass das nicht lösbar ist, aber nur zum Erklären, dass das bei größeren Firmen und vor allem sobald du in so ein System reinkommst, wo du das verknüpfst, dass das durchaus zu einem Problem führen kann.

Andy Grunwald (00:35:54 - 00:36:11)

Ja, das kann ich mir schon vorstellen. Ich muss dann zugeben, dass aber auch eine große Firma lernen muss, sich den neuen Gegebenheiten anzupassen. Ist ja auf dem Wettbewerbermarkt eigentlich nicht anders. Es gibt ja auch kleine Firmen, die Großkonzerne angreifen und dann müssen die großen Konzerne auch agieren.

Wolfi Gassler (00:36:12 - 00:37:00)

Klar, aber das hilft dir halt weniger, wenn du bei dieser Firma arbeitest oder in einem Team zum Beispiel arbeitest. Aber du musst halt dann woanders hingehen und die Firma muss es vielleicht lernen. Aber es ist halt gerade in großen Firmen ein Problem, die keine IT-Firmen sind oder Tech-Unternehmen. in denen die IT-Abteilung halt ein kleinerer Bereich ist und wenn du halt nur, keine Ahnung, im Tech-Bereich 5% Mitarbeiter hast und davon haben dann 2,5% so ein Problem, dann sagt die Personalabteilung natürlich auch sollen wir jetzt unser ganzes Modell umwerfen für das 1% von der Company oder so. Da ist halt wenig Verständnis da. Leider, muss man auch dazu sagen. Aber das ist halt ein konkretes Beispiel, das ich persönlich kenne. Und ich weiß halt, dass das große Schmerzen bereitet den Leuten in dieser Firma.

Andy Grunwald (00:37:01 - 00:37:20)

Du redest natürlich jetzt von einer Firma, die, wenn du sagst 1% der Firma, bedeutet das natürlich, dass recht wenige Software-Engineers da sind oder ITler. Das sind natürlich ganz andere, ganz andere Gegebenheiten der Firma und diese Firma muss natürlich sich jetzt auch nicht mit den Gehältern von Google rumschlagen, weil sie mit Google zum Beispiel ja nicht im Wettbewerb steht.

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

Die stehen sehr wohl mit Google im Wettbewerb. Das ist einfach eine große Firma, ein großer Konzern mit mehreren zehntausenden Mitarbeitern oder noch mehr. Und die IT-Abteilung von denen steht natürlich sehr wohl in Konkurrenz mit Google. Und die verlieren auch Leute an Google.

Andy Grunwald (00:37:38 - 00:39:17)

Ja gut, dann muss ich einfach zugeben, da muss der Konzern meines Erachtens nach, da bin ich dann so hart und direkt und hohepottisch, ja, müssen damit klarkommen und sich anpassen. Also das Leben ist kein Ponyhof. Also man muss auf der anderen Seite sagen, als Mitarbeiter, Geld ist ja auch nicht alles. Also ich meine, ein Job bietet ja auch deutlich mehr als nur Geld und ich bin auch der Meinung, dass man immer jemanden findet, der mehr Geld zahlt. Also das bedeutet auch, wenn du als Software-Ingenieur 400.000 Euro im Jahr kriegst, gehe ich Startschaften aus, du findest irgendjemand, der 410 zahlt. Die Frage ist nur, was musst du dafür tun? Und hast du dann noch 40 Stunden? Und was kommt damit? Also ein höheres Pricetag bedeutet auch höhere Anforderungen. Und deswegen bin ich auch ein ganz großer Fan davon, nicht immer nur aufs Geld zu schauen, sondern was bietet der Job dir denn auch? Flexibilität, Lernmöglichkeiten, Kultur, Liebe zum Produkt. Gegebenenfalls arbeitest du für eine Firma, die stellt einen autonomen Trecker her, der autonom ein Feld umflügen kann. Wenn du passioniert für das Feld Agrartech bist, dann ist das eine sehr hohe Produktliebe. Ich gehe aber mal stark davon aus, dass die Firma Heckler & Koch dir mehr Gehalt zahlen würde, weil die dann automatische Waffen damit bauen würden. Und jetzt ist die Frage, was ist deine Priorität? Ist das Geld deine Priorität? Oder legst du auch ein bisschen Wert darauf, für was du da arbeitest? Ich will nicht nur sagen, okay, Jobtitel, und da bin ich dann jetzt ... Ich wechsle jetzt die Firma, weil ich da drüben Senior bin, und dann kriege ich 2.000 Euro mehr. Ich empfehle nicht immer weiterzuspringen, nur weil jemand anderes zahlt.

Wolfi Gassler (00:39:18 - 00:39:50)

Ja, ich glaube, wir sind da in einer sehr privilegierten Situation, weil ich glaube, dass die meisten Engineers und Data Scientists, die in dem Bereich arbeiten, wahrscheinlich zu den Top 5 Prozent der Gesellschaft gehören und dementsprechend auch verdienen. Und da hast du natürlich vollkommen recht. Ich glaube, da kann man durchaus auch mal Vor allem, wenn man schon mehr Erfahrung hat, dann werden, glaube ich, andere Dinge einfach wichtiger. Wenn man dann fünf Stunden weniger arbeiten muss in der Woche, nimmt man das auch gerne in Kauf, wenn man dann ein bisschen weniger verdient.

Andy Grunwald (00:39:51 - 00:40:12)

Ich habe Kollegen, die haben einen 40-Stunden-Vertrag, die sind freiwillig runter auf 35 und irgendwann auf 30, weil sie mit dem Gehalt klargekommen sind und ihre freizeit höher bewertet haben als mehr geld und das finde ich persönlich eine super geschichte sofern natürlich alle grundbedürfnisse gedeckt sind ja genau.

Wolfi Gassler (00:40:12 - 00:40:28)

Man muss natürlich auch dazu sagen dass engineering jobs so gut bezahlt sind dass du dir das auch leisten kannst auf 30 stunden runterzukommen und trotzdem noch leben kannst wie wie wie sagt man denn wie cesar wie größer ist der größte.

Andy Grunwald (00:40:29 - 00:40:31)

Er sagt mir unser Leben wie Krösus.

Wolfi Gassler (00:40:31 - 00:40:35)

Wer ist Krösus? Okay, irgendwer in Duisburg. Mit Trauben und Bediensteten.

Andy Grunwald (00:40:36 - 00:41:20)

Also prinzipiell bin ich ja ein ganz großer Fan davon, dass man das machen soll, was einem Spaß macht. Und ich hab Freunde, die, was ich auch voll okay finde, die haben einfach keinen Bock auf Arbeit, die sagen, okay, ich arbeite, weil die Miete gezahlt werden muss, und die machen keinen weiteren Handschlag in ihrem Job, als sie wirklich machen müssen. Und das find ich auch okay, das kann man so machen. So einer bin ich nicht, gegebenenfalls werd ich auch ab und zu als Workaholic bezeichnet, Ich mache halt das, was mir wirklich Spaß macht. Das kann natürlich dann auch mal dazu führen, dass man ein bisschen länger arbeitet, aber ich denke, dass über kurz oder lang du mehr Motivation und Passion da reinsteckst und dann auch irgendwann der Erfolg von ganz alleine kommt, was dann Erfolg für dich auch immer ist.

Wolfi Gassler (00:41:21 - 00:41:24)

Das heißt, du springst auf die Hypes auf, weil das dir Spaß macht?

Andy Grunwald (00:41:24 - 00:41:48)

Nein, ich springe nicht auf die Hypes auf. Ich nehm mal den Beispiel Machine Learning und Artificial Intelligence. Ich find das superinteressant, was da GitHub Copilot und DeepMind mit Go und StarCraft macht, find ich superinteressant. Ich persönlich hab irgendwie gar kein Interesse daran, das zu lernen, weil es ist, glaub ich, einfach viel zu kompliziert für mich, oder ich hab keinen eigenen Anwendungsfall. Ich glaub, da kannst du sehr gut Geld verdienen.

Wolfi Gassler (00:41:51 - 00:42:04)

Ja, aber das wäre jetzt das gleiche, wenn ich sage, ich springe nicht auf diesen Hype von Eiskunstlauf auf, weil klar, das mache ich nicht, damit habe ich wenig zu tun. Aber du springst jetzt auf alle Hypes im Bereich Infrastruktur zum Beispiel gerne auf.

Andy Grunwald (00:42:04 - 00:42:56)

Ich bin aber auch schon etliche Jahre im Infrastrukturbereich. Ich bin noch nie auf einen Hype aufgesprungen. Ich war leider irgendwie mitten drin. Was ich damit sagen möchte ist, mach das, was dir Spaß macht. Vielleicht auch, schau mal nach, dass du vielleicht nicht alle zwölf Monate die Industrie oder die Richtung wechselst. Ich meine, es gibt auf GitHub immer Repositories. Das musst du lernen, um Frontend-Engineer zu sein. Das musst du lernen, um DevOps-Engineer zu sein. Das musst du lernen, um XY zu sein. Und dann schaut man sich diese Mindmaps an, und diese sind unglaublich kompliziert. Da steht dann Nginx und Apache 2, und da steht da AWS Cloud, und da steht da Azure Active Directory, und dann steht da Prometheus, da stehen so viele technologien ich habe von mehr als 50 prozent keine ahnung also also jagt nicht immer dem neuesten hype hinterher sondern schau einfach okay was macht dir spaß und dann gibt sich die ganze sache meines erachtens darüber kürzere.

Wolfi Gassler (00:42:56 - 00:44:19)

Wobei, da muss ich natürlich diese Leute verteidigen, die auch in die Breite gehen, weil ich selber auch definitiv eine Person bin, die gerne in die Breite geht und viel ausprobiert. Und ich bin auch der Meinung, dass es diese Generalisten auch braucht. Es braucht diese Leute, die wirklich fokussiert auf einem Bereich arbeiten oder in einem Bereich arbeiten und dort sich weiterbilden. die absoluten Profis in dem Bereich werden. Ich glaube, solche Leute braucht es, aber du brauchst auch Generalisten, die einfach links und rechts vom Teller auch mal geblickt haben, andere Bereiche kennengelernt haben. Vor allem, wenn es darum geht, ein bisschen mehr einen Überblick zu geben, wenn es um irgendwelche Technologien geht, wo könnte man hingehen, was gibt es sonst noch, was sollte man vielleicht nicht machen. Wenn man da eine gewisse Erfahrung hat in die Breite, klar kann man dann kein Spezialist sein und so eine AI entwickeln, die Google entwickelt hat oder DeepMind, das geht dann wahrscheinlich nicht. Aber wenn man Grundverständnis hat, zum Beispiel in dem Bereich, kann das sehr hilfreich sein. Und mir persönlich hat es zum Beispiel immer viel gebracht, auch als Engineering Manager zum Beispiel, dass ich halt in vielen Bereichen mich einigermaßen ausgekannt habe und halt eine gewisse Grundlage gehabt habe, um auch mit den Leuten zu sprechen und zu diskutieren über diverse Bereiche. Also ich glaube, es gibt schon beide Herangehensweisen und ich glaube nicht, dass die eine besser als die andere ist.

Andy Grunwald (00:44:20 - 00:44:33)

Ich widerspreche dir auch gar nicht und ich bin mir auch gar nicht sicher, ob wir jetzt hier über Generalisten versus Spezialisten sprechen. Ich bin eher in der... Ich meine, ich bin da ähnlich wie du. Ich schaue mir auch sehr, sehr viel an und ich schaue mir auch Frontend-Frameworks.

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

An, Was hast du dir als letztes angeschaut als Frontend Framework?

Andy Grunwald (00:44:37 - 00:46:07)

Ich habe mir Vue.js angeguckt und habe auch echt lange gebraucht, bis ich das alles mal verstanden habe. Was ich aber damit meine, ist vielleicht nicht jedes Jahr den Job nach links und rechts zu wechseln. Also man kann sich ja sehr, sehr viel anschauen. Das ist ja auch super, weil ich denke, dass super viele Ideen aus anderen Bereichen genommen werden sollten und in deinem Bereich implementiert werden sollen. Nehmen wir mal ein Beispiel, ich habe einen alten Bekannten, der hat seine Doktorarbeit auch geschrieben und da ging es um Netzwerktechnik, da ging es um Switch-Konfigurationen. Und was er damals gemacht hat, er hat die Methode des Continuous Integrations und Continuous Deployment aus dem Web-Bereich genommen und das für Switch-Konfigurationen umgebaut. Das bedeutet, Switch-Konfigurationen wurden automatisch immer deployed. Das war vor ein paar Jahren gefühlt Rocket Science, aber Ganz unten drunter hat er einfach einen vorhandenen Jenkins genommen, der im Web ja sowieso schon da ist, da womit Webprojekte deployed werden, und hat da einfach einen Switch bespielt. Und das meine ich damit. Schau dir links und rechts was an. Das heißt ja nicht, dass du deinen kompletten Karrierepfad ändern musst und mach das, was dir Spaß macht, dann kommt der Erfolg ganz von alleine. Ich würde aber auch bitten, mal ganz kurz über deine Definition von Erfolg nachzudenken. Ist Erfolg für dich, ganz viel zu viel Geld zu verdienen? Ist Erfolg für dich, Spaß zu haben oder kotzt du jeden morgen, wenn du aufstehst und sagst, boah jetzt muss ich schon wieder diesen Job machen, dann sollte man das vielleicht ein bisschen überdenken. Oder ist deine Einstellung, ich mache den Job, dass die Miete zahlt und lebe mein Leben, was auch völlig okay ist, ja super. Ich sage auch nicht, dass jeder einen 5-Jahres-Plan haben muss.

Wolfi Gassler (00:46:07 - 00:46:11)

Hast du einen 5-Jahres-Plan oder gehabt damals nach der Ausbildung oder in der Ausbildung?

Andy Grunwald (00:46:11 - 00:47:28)

Ich habe jetzt keinen strikten Fünf-Jahres-Plan, aber ich habe immer ein, zwei große Ziele, auf die ich über kurz oder lang hinarbeite. Und dann schaue ich, was dafür notwendig ist. Und wenn dafür, für mein großes Ziel, Beispiel, mehr Freizeit notwendig ist, dann schaue ich nach, was kann ich entweder optimieren oder wo kann ich zurücktreten, damit ich mehr Freizeit habe. Oder wenn ich irgendwie ein haus kaufen möchte und sage ich brauche mehr kapital dann und das ist wirklich also dann bin ich mir aber auch sicher dass das mein mein mein großes ziel ist dann überlege ich mir auch einen job zu wechseln wo ich einfach mehr geld zu verdiene wo ich mehr geld verdiene um an mein ziel zu kommen. Aber ich habe jetzt nicht den fünf jahres plan ich bin jetzt engineering manager und in zehn oder in fünf jahren möchte ich mindestens 140 leute leiden das ist mir völlig egal ob ich zwei oder zwanzig leite ja es gibt mir nicht mehr power sondern es macht den job einfach nur komplizierter denke ich. Aber ich möchte einfach nur cooles Zeug mit coolen Leuten machen. Und mit dem 5-Jahres-Plan denke ich dir halt, überleg dir mal, was du mal so wirklich erreichen möchtest und schau dann, was dafür notwendig ist und wie sehr du es wirklich möchtest. Hast du einen 5-Jahres-Plan oder hast du dich immer so treiben lassen?

Wolfi Gassler (00:47:29 - 00:48:33)

Also viele Leute beschweren sich bei mir immer, dass ich nicht einmal einen Wochenplan habe, geschweige denn einen Jahresplan. Ich glaube, ich habe schon so, ich würde es fast Visionen nennen, es klingt sehr hochtrabend, Visionen, aber so Ziele, wie du es vielleicht nennst, so im weitesten Sinne, wo man mal hingehen möchte, aber das ist alles sehr, sehr weit entfernt, meistens damals im Studium zum Beispiel. Ich habe mir schon überlegt, okay, es wäre mal cool, mit einem Team zu arbeiten oder solche Sachen, aber das sind sehr rudimentäre Ideen, Ziele und ich habe dann eigentlich am Weg einfach immer das genommen, was cool geklungen hat, im Sinne von Spaß gemacht hat und interessant war, eine Challenge. Vielleicht auch mal einen Hype mitgenommen, aber ich habe ja auch lange an der Uni gearbeitet, da ist man ja quasi die Vorstufe zum Hype, da erzeugt man im Idealfall die Hypes und muss ja an sowas forschen. Aber so wirklich konkrete Pläne habe ich eigentlich nie gemacht und probiere mir da auch nicht zu sehr festzulegen diesbezüglich.

Andy Grunwald (00:48:33 - 00:48:42)

Ja und jetzt machen wir hier ein Podcast über Software Engineering, Engineering Kultur, Technologie, Open Source und Menschen und schau mal wo du gelandet bist.

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

In einem Gespräch mit dir ist doch sehr positiv.

Andy Grunwald (00:48:45 - 00:49:40)

Ich sage ja auch, man muss nicht immer einen Fünfjahresplan haben. Und das hört sich jetzt auch alles total schulkuriert an, was ich da gerade gesagt habe. Ich mache auch viel Blödsinn nebenher. Ich lasse mich auch total ablenken und lasse mich auch abzutreiben. Also von daher, man muss nicht alles immer ganz so ernst nehmen. Aber hier und da sollte man schon seinen eigenen Weg finden und nicht immer links und rechts gucken, um zu sagen, was hat die Person denn, das möchte ich auch erreichen, sondern einfach mal seinen eigenen Weg gehen. Ich denke, dass Hypes helfen können, aber man sollte sie ein bisschen mit Bedacht einsetzen und nicht jedem Hype sofort hinterherlaufen. Ich vergleiche das immer mit Hacker-News-Driven-Development. Man sollte nicht jede Datenbank, die auf Hacker-News heute Abend auftaucht, einsetzen, sondern vielleicht auch erst mal ein bisschen mit rumspielen oder erst mal warten, bis ganz viele Leute ganz schwierige Erfahrungen damit gemacht haben.

Wolfi Gassler (00:49:41 - 00:50:30)

Also ich glaube auch, dass das ein ganz guter Tipp ist. Man sollte sich mit neuen Technologien beschäftigen, man sollte sich glaube ich mit Hypes beschäftigen, meiner Meinung nach. Man sollte sich das anschauen, zumindest wenn man Interesse hat, das auszuprobieren. Da eignen sich übrigens Side Projects auch sehr gut, wenn man welche hat, um einfach neue Technologien mal auszuprobieren, weil da bekommt man dann sehr schnell raus, ob die Technologie wirklich was kann oder drauf hat, bevor man sie wirklich produktiv irgendwo einsetzt. Da könnte man mal Folge 1 und 2 von uns hören, da haben wir viel über Side-Projects gesprochen. Und sonst bin ich aber eigentlich auch eher auf deiner Seite, Andi, dass man eher klassische Software, gut getestete Software für wichtige Produkte und Projekte einsetzen sollte. Ganz klar. Und man glaubt gar nicht, wie spannend teilweise alte Technologie sein kann.

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

Okay, das nehmen wir mal als Abschlusswort. Wir haben ein bisschen über die Karrierefahrt, über Hypes in Machine Learning, Artificial Intelligence, Jobtitles, Fünf-Jahres-Pläne und weiteres gesprochen.

Wolfi Gassler (00:50:43 - 00:51:03)

Es war eigentlich eine ziemlich freie Episode, mal was anderes im Gegensatz zu den etwas mehr strukturierten, die wir in letzter Zeit gemacht haben. Lasst uns auch mal wissen, was ihr von so einem Format haltet, ob das interessant ist zuzuhören, ob ihr mehr davon wollt oder eher durchstrukturierte Episoden mit einem ganz klaren Fokus.

Andy Grunwald (00:51:04 - 00:51:06)

Und legt bitte nicht jeden Satz auf die Goldwaage.

Wolfi Gassler (00:51:09 - 00:51:14)

Andis Sätze könnt ihr schon auf die Goldwaage legen. Also man sollte Andis schon genau sagen, was er falsch gemacht hat.

Andy Grunwald (00:51:15 - 00:51:37)

Betrachtet es immer im Kontext. Und was wir noch nachreichen werden, sind die ganzen Links, wie zum Beispiel die Engineering Growth Passes von CircleCI oder die Matrix, was ein Senior Engineer und was ein Staff Engineer machen soll. Da gibt es ein paar Webseiten, die verlinken wir alle in die Shownotes. Und auch wer Croesus war, das werden wir noch recherchieren. Ansonsten vielen Dank, dass ihr wieder dabei wart und bis zum nächsten Mal.

Wolfi Gassler (00:51:38 - 00:52:07)

Und lasst uns vielleicht auch wissen, ob ihr Levels in eurem Unternehmen habt oder Titles oder ob ihr ohne Titles auskommt. Am besten auf Twitter, damit es auch andere lesen können, was es denn so in anderen Firmen gibt oder welche Modelle es in anderen Firmen gibt. Und sonst, wenn ihr natürlich Feedback oder Ideen habt, wie immer bitte gerne an stetisch at engineeringkiosk.dev. Und dann freuen wir uns schon, dass wir uns nächste Woche dann pünktlich ab Dienstag wieder hören.

Andy Grunwald (00:52:07 - 00:52:07)

Bis bald!

Wolfi Gassler (00:52:08 - 00:52:11)

Ciao!

Andy Grunwald (00:52:11 - 00:52:13)

War eine sehr, sehr opinionated Folge, glaube ich.