Was wir als Juniors gerne gewusst hätten

Hier könnte Ihre Werbung stehen und damit herzlich willkommen zu Entwicklerleben. Heute mal die Intro von mir, aber trotzdem auch dabei der Raphael. Moin Moin! So, wir haben uns für heute mal wieder eine kleine Plauderrunde überlegt. Wir wollen mal darüber sprechen, was wir denn alles so gerne gewusst hätten, als wir noch ganz grün in den Ohren waren und als Junior irgendwann mal angefangen haben zu arbeiten. Da gibt es eine ganze Menge, tatsächlich. Willst du mal loslegen?

Ja, als allererstes würde ich glaube ich irgendwie sagen, Jobtitel sind einfach nur Bullshit. Also erstmal die erste steile These zum Anfang hier in den Raum rein. Also, ob ich jetzt irgendwie Junior bin oder Senior, also zumindest auf der Visitenkarte, ist eigentlich vollkommen egal. Das macht es jetzt irgendwie nicht besser oder schlechter, weil es ist auch sehr, sehr individuell pro Company.

Bei dem einen bist du irgendwie gefühlt nach einem Jahr schon Senior-Entwickler, bei dem anderen bist du erst nach fünf Jahren. Dort gibt es einfach keine feste Zeitleiste, wann du was bist.

Und deshalb dachten wir, reden wir jetzt mal ein bisschen darüber, wie man tatsächlich unabhängig von Jobtitel tatsächlich in Richtung Senior kommt. Genau, also ich sehe das auch so. Ich finde das auch sehr schwierig, weil jedes Unternehmen hat so seinen eigenen Maßstab. Wie du schon gesagt hast, beim einen bist du nach einem Jahr alt automatisch einfach in der nächsten Titelstufe. Die anderen haben einfach sechs Stufen, bis du das höchste Tier bist, was noch entwickelt oder so.

Und da lässt sich gar nicht so viel draus schließen, zumal die Anforderungen für den Aufstieg teilweise halt auch sehr wild sind. Ich habe das schon erlebt, da war es notwendig, um vom Junior-Software-Ingenieur zum Senior-Software-Ingenieur zu werden, sollte man mindestens... Eine Sache an einen Kunden verkauft haben. Was ja gar nichts damit zu tun hat. Genau, das hat nichts damit zu tun, aber es ist natürlich für die Firma schön. Also die freuen sich natürlich, wenn du was verkauft hast.

Aber das zeigt halt, wie Schall und Rauch das halt eigentlich sind. Ich meine, klar, zum Einordnen, in welcher Gehaltsstufe man sich irgendwo befindet, ist das vielleicht ganz nett. Aber an sich kann da eine ganze Menge Schund mitgetrieben werden. Ich kenne auch Leute, die schon seit Jahren entwickeln und dann einfach von irgendeinem gesagt bekommen haben, ja, du kennst erst zwei Programmiersprachen, mein Freund, du bist ein Junior.

Und ich mir denke, ja gut, aber wenn du die halt masterst, dann bist du kein Junior offensichtlich. Ja, das ist ein sehr, sehr guter Einstieg. Viele denken halt immer oder geben damit an, ey, ich kann so und so viele Programmiersprachen. Das sehe ich, wenn ich jetzt meine Stellenausschreibung hier reinsetze, bekomme ich Bewerbungen, ja, ich kann PHP, Python, C-Sharp, Java, Swift, was auch immer.

Das sagt überhaupt gar nichts über die Qualität aus. Da denke ich mir so, okay, cool, du hast vorüber mal reingeschaut. Das habe ich früher in meiner Ausbildung auch gemacht, durch die Berufsschule bedingt, mal in mehrere Programmiersprachen geschaut. Aber eigentlich hatte ich den beruflichen Fokus immer auf Python.

Und das ist, ja, natürlich hat jede Sprache Vor- und Nachteile, aber im Endeffekt kommst du, gerade wenn ich jetzt so an PHP und Python denke in der Webentwicklung, kommst du beides mal an ungefähr das gleiche Ziel. So, man muss nicht unbedingt beides können. Viel lieber, muss ich jetzt zurückblickend sagen, hätte ich damals schon gedacht, lerne ich lieber was in die Breite, um halt irgendwie, also wenn ich jetzt irgendwie an Fullstack denke, so Full-Fullstack zu werden.

Das heißt nicht nur Front- und Backend, sondern halt auch DevOps, Infrastruktur, wie auch immer, dass ich ja auf der einen Seite eher Generalist bin, das ist natürlich auch mal Typenfrage, aber trotzdem kann ich in allen Bereichen sehr, sehr gut eigentlich helfen. Aber ich habe immer noch meinen Fokus. Das heißt, mein Fokus ist im Backend. Und das habe ich seit 2010, habe ich keine andere Programmiersprache im Backend quasi gemacht.

Also ich habe jetzt nicht gesagt, ach, ich mache jetzt heute mal irgendwie Ruby, ich mache mal, LXC habe ich mal ausprobiert. Ich glaube, da hatten wir, glaube ich, mal drüber gesprochen.

Aber ich bin eigentlich immer bei Python geblieben, weil ich eigentlich recht zügig mittlerweile in dieser Sprache zu dem für mich guten Ergebnis komme, wenn ich jetzt mit Django eine neue REST-API baue oder mal FAST-API, bevor ich jetzt irgendwie überlege, ah, da ist vielleicht irgendwie dieses eine Feature besser. Wir können darüber reden, Node im Backend zu verwenden, wenn es mal um Sockets geht. Also da ist es vollkommen offen für mich.

Aber ansonsten muss ich jetzt nicht irgendwie denken, ach komm, ich mache jetzt mal, keine Ahnung, Java, JBoss, keine Ahnung, was man da heutzutage verwendet.

Ich sehe, ich sehe. Schmerzen. Ja gut. Ich sehe das auch so. Ich glaube, ich habe den Fehler auch mal sicherlich gemacht, dass ich mir, als ich damals angefangen habe, und dann sollst du aufschreiben, was kann man denn so alles, und dann überlegt man so, ja, was habe ich denn alles in meiner Ausbildung, im Studium, was auch immer gemacht, und dann listest du einfach mal alle Sprachen auf, die man mal gemacht hat, und wenn das halt nur für ein Semester oder ein halbes Jahr oder sowas war.

Aber da merkt man dann schon auch so, okay gut, da listet einer einfach gerade alles auf oder hat sich halt sehr viel angeguckt. Es spricht auch nichts dagegen. Es gibt sicherlich einige Typen, die sagen, ja, nö, ich gucke mir gerne auch neue Sprachen an, weil mich das interessiert. Wie funktionieren die so vom Aufbau her und so?

Also glaube aber auch, dass es jetzt nicht unbedingt super wichtig ist, dass man sagt, okay, gut, ich kann die alle, ich kann überall eingesetzt werden, denn ich glaube, wenn du eine Sprache sehr gut kannst, erfällst dir nicht so schwierig, auch andere Sprachen zu lernen, weil, ich meine jetzt die aus der gleichen Ecke kommen vom Aufbau her, weil es meistens ja nur so ein bisschen ein anderer Dialekt ist.

Man kann das ja schon mit Sprachen vergleichen und ganz viele Sprachen sind halt eher so alle irgendwie deutsch und jeder spricht seinen eigenen Dialekt und du musst dich halt einfach nur an Syntax gewöhnen, an Sprachfeatures, die schon integriert sind und so. Klar, du kommst jetzt natürlich nicht auf die Idee und sagst so, boah, ich kann Python und nein, no problem, jetzt Assembler zu programmieren, weil es ist ja auch eine Programmiersprache, das ist natürlich nicht, ist klar.

Aber ob du jetzt Python oder dann in JavaScript oder von mir aus auch tatsächlich jetzt meinst, du musst mit Java anfangen oder C-Sharp, also solange du Solche Sprachen schreiben möchtest, da kommt man ja rein. Ich bin ja vorher auch nicht in der Python-Welt unterwegs gewesen.

So ja, ich habe mal vor Jahren auf deinen Anraten hin ein Python-Tutorial angefangen, aber das habe ich, glaube ich, auch nicht besonders weit getrieben und erst seitdem wir zusammenarbeiten, bin ich mit Python unterwegs und da bin ich ja auch schnell reingekommen. Das Ding ist einfach das Ökosystem, welche Abhängigkeiten nutze ich, welches, ich sag mal, Subframework da drin kann ich nutzen und so weiter und,

Was sind die Stärken, was sind die Schwächen? Wie du gerade schon sagtest, eine Programmiersprache an sich, so von der Syntax her zu lernen und so weiter, ist alles kein Thema, aber trotzdem gibt es halt immer wieder so Eigenheiten, Architektur und so weiter und so fort. Aber heute, finde ich, ist wirklich das Grundding das Ökosystem, weil du ziehst ja halt immer so viele Abhängigkeiten mit rein und du lernst irgendwann damit umzugehen, wo so die Eigenheiten sind.

Und das hat an sich ja gar nichts mehr mit der Programmiersprache an sich zu tun. Genau, eine Sache noch, weil wir gerade ein bisschen abschweifen, glaube ich, und tief in die Programmiersprachendebatte eintauchen. Ich glaube auch, dass es halt hilfreich ist, sich in der Breite aufzustellen oder in der Breite umzuschauen, weil du dann verstehst, hey, wie arbeiten denn die anderen?

Sondern wenn ich jetzt keine Ahnung davon habe oder habe ich halt teilweise auch gar nicht, wie DevOps halt eben so funktioniert, dann baue ich so meine Software und dann sagst du, ja, und das ist jetzt dein Problem, wie du damit umgehst.

Vielleicht kann ich aber beim Entwickeln ja noch was besser machen oder etwas besser gemacht haben, damit nachher zwar vielleicht nicht der DevOps-Prozess als solcher leichter ist, aber das System halt besser irgendwie funktioniert, weil ich weiß, okay, so und so funktionieren Server, dann wäre es schlau, vielleicht nicht so ressourcenhungrig zu arbeiten oder halt eben das Docker-Image schon mal richtig aufzusetzen.

Das ist ja schon so ein bisschen DevOps-mäßig, aber du wirst ja in den seltensten Fällen jemandem sagen, hey, du machst mir das Docker-Image und ich mache den Rest. Meistens setzt man es ja selber auf. Also so ein bisschen so einen Weitblick zu haben, hey, wie funktionieren Datenbanken oder so, das schadet ja auch nicht, weil man dann eben in der eigenen Arbeit das immer berücksichtigen kann, wie dann andere arbeiten und dann auch besser damit umgehen kann.

Wenn dir einer sagt, das funktioniert so nicht, dann brauchst du dich nicht aufregen, sondern du weißt, ja, stimmt, dafür muss man vielleicht ein bisschen anders arbeiten. Also du meinst jetzt quasi schon, dass man irgendwie im Team arbeitet oder wie meinst du das? Ja, einfach auch ein Verständnis für andere Rollen zu haben, um den Job quasi zu verstehen und zu wissen, was denn das bedeutet. Also das Klassische, wenn ich jetzt als Junior gedacht habe, so ein Tester, was soll denn der Quatsch?

Der macht die Anwendung auf, drückt auf ein paar Knöpfe, das funktioniert natürlich. Weiß ich nicht, warum beschäftigt man dafür einen?

Sowas zum Beispiel. Und wenn du dann halt mal guckst, wie arbeitet denn ein Tester und dass der ja auch einen ganz anderen Gesichtspunkt auf die Software schaut, dass man dafür halt ein Verständnis hat, also ein Verständnis, warum gibt es die Stelle, was tun die und wie kann ich in meiner Arbeit vielleicht optimieren, damit in deren Job es einfacher ist, mit dem, was ich ihnen liefere, zu arbeiten.

Also dieses klassische Ding, klar, bei Fullstack haben wir das nicht, aber Backend-Frontend-Entwickler, wenn der Backend-Entwickler so gar keine Ahnung hat von Frontend, das weiß ich gar nicht, ob es das überhaupt gibt, aber da hätten wir es ja.

Also, wenn die Person schon weiß, ja, okay, Frontend-Entwickler, der macht halt irgendwelche REST-API-Calls gegen mich, dann sehe ich mal zu, dass ich das vernünftig gestalte und nicht einfach nur irgendwie irgendwelche Daten rüber trommel und es macht alles gar keinen Sinn, auf welche Art und Weise oder, okay, ich entwickle die API, ich mache dazu aber auch schon einen JSON-Schema und kann die dem Frontend-Entwickler geben. Eben, davon profitiert der, obwohl ich da gar nichts von habe.

Ich habe davon nur mehr Aufwand, weil ich einen Schema geschrieben habe, aber dem hilft es. Um solche Erkenntnisse geht es mir da. Ja, das ist auf jeden Fall ein sehr, sehr wichtiger, richtiger Punkt, auch mal die Gegenseite zu verstehen.

Da sind wir schon bei dem Thema Kommunikation und Politik. Ich meine, man entwickelt ja oder man programmiert ja nicht nur, sonst wäre es ja der Beruf des Programmierers, sondern Softwareentwickler oder Softwareingenieur heißt ja viel mehr Beratung, Abstimmung mit anderen Dienstleistern, mit Kunden, mit UXler, Designer, wie auch immer. Das ist auch so ein Ding. Kommunikation ist extrem wichtig.

Kommunikation heißt auf der einen Seite, wenn man etwas nicht verstanden hat, aktiv nachfragen, wenn man irgendwie ein Problem sieht, aktiv sagen, so hey, das geht so nicht und nicht nur, ja, kriegen wir schon irgendwie hin oder so. Also niemand reißt einem irgendwie den Kopf ab, irgendwann mal was zu sagen, Verbesserungsvorschläge.

Vielleicht ist es auch in der einen oder anderen Unternehmenskultur nicht willkommen, finde ich aber sehr, sehr wichtig auch zu sagen, so hey, hier kann man noch irgendwie was verbessern, so eine gewisse Weitsicht oder was heißt Weitsicht, ein Interesse zu haben, das Projekt an sich auch vorwärts zu bringen.

Oder wenn man jetzt irgendwie gesehen hat, hey, lass uns mal ein Code-Format einsetzen, das bringt halt auch immer wieder was, oder irgendwie die Pipeline nochmal ein bisschen optimieren, Semantik-Versioning irgendwie einzuführen, wie auch immer, so Kleinigkeiten kann man halt von technischer Seite weiterbringen, aber auch irgendwie Kunden aktiv zu sagen oder Stakeholder-Products oder wie auch immer zu sagen, hey,

wir können das wieder auch so und so bauen. Das habe ich mir jetzt irgendwie überlegt. Ob das nachher so durchgesetzt wird, ist nochmal das andere. Aber es hilft enorm. Kommunikation heißt dann aber auch aktiv Hilfe anfragen. Wenn du jetzt irgendwie ein Problem hast, dann nicht weiterkommst oder vielleicht dich verhaspelt hast oder so. Das kann halt häufiger vorkommen. No problem. Einfach die anderen Entwickler anhauen und sagen, hey, ich habe jetzt hier gerade irgendwie ein Problem.

Die werden dir helfen. Auch mal irgendwie eine Pair-Programming-Session irgendwie einfordern oder das im Daily ansprechen oder hier, das passiert mir selber heutzutage auch noch, dass ich mal in so einem Ding halt irgendwie gefangen bin, wo ich den Wald vor lauter Bäumen nicht mehr sehe.

Einfach aktiv anfragen und Hilfe einfordern, weil jeder hat so sein eigenes Süppchen irgendwie in dem Projekt oder im Leben, sage ich mal, zu kochen. Da guckt man manchmal nicht nach links und rechts, so, ey, kann ich gerade irgendwie unterstützen oder manchmal weiß man es auch nicht, wenn man gerade remote arbeitet. Du siehst nicht diesen rauchenden Kopf vor dem Monitor. So, das ist sehr, sehr wichtig. Und aber auch, tu Gutes und rede drüber.

Man darf es vielleicht nicht zu exzessiv machen, aber trotzdem sollte man auch mal sagen, hey, ich habe jetzt gerade was Cooles gebaut. Das funktioniert, dass man das halt nicht nur irgendwie im Team behält, sondern auch Richtung Kunden kommuniziert oder Richtung Stakeholder, wie auch immer, dass die halt auch einfach ein gutes Gefühl haben. Das wäre vielleicht nochmal etwas in Richtung Karriere oder so, wie man irgendwie auch mal mehr Gehalt raushandelt oder so.

Aber grundsätzlich ist es so, dass Nicht-Techniker selten ein technisches Verständnis haben und das genauso feiern das Feature, was du da gerade gebaut hast, wie du meinst. Und deshalb geht es halt eher so darum, irgendwie den Leuten ein gutes Gefühl zu geben. Das habe ich auch erst, ja, relativ spät, sage ich mal, gelernt, in der Anfangsphase nicht, dachte, ey, das ist ja jetzt voll geil, und dann kommt einfach nichts zurück, weil man es halt falsch kommuniziert hat, so, das muss man halt auch.

Man kann halt nicht mit den Leuten so rumläuten, wie wir das jetzt irgendwie tun. Das verstehen die halt nicht oder haben halt nicht dieses gleiche Interesse dafür, was halt natürlich schade ist, aber halt auch verständlich. Aber das ist, glaube ich, in jedem Bereich so. Wenn jetzt irgendwie Juristen untereinander sich austauschen, ist das was anderes, als wenn die jetzt irgendwie mit uns kommunizieren oder, keine Ahnung, Ärzte untereinander.

Das ist ja auch immer, das ist sehr, sehr speziell. Und da muss man halt auch mal lernen, irgendwie eine andere Sprache zu sprechen, aber auch regelmäßig mal zu sagen, hey, guck mal, ich habe das jetzt hier gemacht. Und nicht irgendwie die ganze Zeit irgendwie so vor sich hin, weil das Gegenüber fragt sich dann auch irgendwann, passiert da irgendwann mal was? Das ist halt auch so manchmal, wenn man nichts hört. Und das tut schon manchmal ganz gut.

Und wenn man dann auch so Feedback bekommt, es ist halt einfach häufig da, einfach ein gutes Gefühl zu geben. Ja, auf jeden Fall. War jetzt ein langer Take, deswegen muss ich ein bisschen in deinen Punkten nach hinten springen, weil ich zu allem noch, oder nicht zu allem, weil ich zu ein paar Sachen noch Gedanken habe. Zunächst einmal mit dem Pair-Programming und dem Nachfragen, wenn man was nicht versteht, vielleicht aber auch Nachfragen, wenn man was Gutes gemacht hat.

Ich finde es, glaube ich, ganz cool, wenn man auch aktiv sich halt eben im Pair für einen Review zusammensetzt, Remote dann halt eben als digitales Meeting oder die Person halt wirklich zum Schreibtisch holt, weil wenn es halt nur so ein anonymes Review ist, sprich du machst einen Pull-Request und irgendeiner deiner Arbeitskollegen schnappt sich den irgendwann mal und dann schreibt er da so ein paar Kommentare drunter.

Dann hat man vielleicht auch schnell mal so das Gefühl so, okay, das ist jetzt, das ist jetzt, vielleicht, vielleicht findet der mich jetzt dumm, weil dann kommt halt einfach nur, weiß nicht, du hast einen Fehler gemacht und darunter steht dann halt einfach nur total neutral, das ist die richtige Lösung.

So, und dann finde ich es halt schon gut, wenn du in einem persönlichen Gespräch