Einführung
Während meiner Zeit als Junior bei Thoughtworks hatte ich das große Glück, meine Fähigkeiten bei interessanten Projekten und mit der Unterstützung einiger wunderbarer Menschen entwickeln und vertiefen zu können. Gerne möchte ich darüber berichten, mit welcher Strategie ich mich beruflich optimal entfalten konnte. Wenn du in einer ähnlichen Lage bist, hilft dir das hoffentlich bei deinen ersten Schritten in der Branche. Wenn du bereits als Senior Developer oder Teamleiter arbeitest, lernst du hier vielleicht, wie du einen Junior bestmöglich bei seiner Entwicklung unterstützt. Unternehmen erfahren in diesem Artikel, wie sie einen Junior Developer ins Boot holen.Lernen lernen
Als Junior solltest du dir bewusst machen: Für einen Arbeitgeber zählen weniger deine aktuellen Fähigkeiten – dein Potenzial ist entscheidend. Thoughtworks hat mich bestimmt nicht eingestellt, weil mein technischer Lösungsvorschlag im Vorstellungsgespräch reif für den Produktivbetrieb war. Du solltest dich also nicht nur auf die Softwareentwicklung konzentrieren, sondern dich auch um den Ausbau deiner Kompetenzen kümmern. Lerne deine Schwächen kennen, indem du dich selbst beurteilst und Feedback von anderen einholst. Nutze alle verfügbaren Ressourcen, um deine Kenntnisse und Fähigkeiten zu verbessern. Bitte Seniors um Hilfe, lasse deinen Code prüfen, nutze Paarprogrammierung. Lerne dein Arbeitsumfeld kennen: Sprich mit Business Analysten, QAs und Stakeholdern. Stelle Fragen. Bleibe in Bewegung, ganz nach dem Motto: Es gibt immer etwas Neues zu lernen. Überlege, wie man Dinge anders anpacken könnte.Das Lernen an sich ist eine Fähigkeit, die sich entwickeln lässt. Als ich zu Thoughtworks kam, hatte ich keine umfangreichen technischen Kenntnisse. Mit jedem neuen Projekt stürzten daher unzählige neue Programmiersprachen, Tools, Frameworks und Konzepte auf mich ein – ganz zu schweigen von den geschäftsrelevanten Fähigkeiten. In solchen Momenten tritt das Hochstaplersyndrom besonders deutlich in Erscheinung und untergräbt dein Selbstvertrauen. Nach einiger Zeit erkennst du aber ein Muster. Es sieht ungefähr so aus:
- Enthusiasmus
- Verblüffung
- Oberflächliches Verstehen
- Frustration wegen nicht erfüllter Erwartungen an sich selbst
- Praktische Kenntnisse, Produktivität
- Alles wieder auf Anfang
Stufe 3 ist am gefährlichsten, denn hier ist dir nicht bewusst, dass du nicht verstehst, was du gerade tust. Es ist besser, frustriert zu sein und aktiv um Hilfe zu bitten, als vor sich hin zu programmieren und dabei haufenweise unbrauchbaren Code zu produzieren. Das Ironische daran ist, dass man in dieser Stufe ziemlich „produktiv" sein kann. Brich aus Stufe 3 aus, indem du Feedback zu deiner Arbeit einholst und eine Beziehung zu deiner Unwissenheit aufbaust. Nimm sie als vorübergehende Tatsache an.
Wenn du diesen Kreis ein paar Mal durchlaufen und es schließlich geschafft hast, vorzeigbaren Produktivcode für eine neue Technologie beizusteuern, entwickelst du eine positive Einstellung zum Lernen. Du vertraust dann auf deine Fähigkeit, dir neue Dinge schnell anzueignen, und lernen das zu schätzen. Und was noch wichtiger ist: Du kannst daraus bei Bedarf einen plausiblen, Fakten gestützten Business Case für Stakeholder ableiten. Ich habe festgestellt, dass selbst Senior Developern dieses Umdenken manchmal nicht gelingt, weil sie in ihrer Rolle zu einseitig denken und sich darin nicht flexibel bewegen müssen. Also: Verlasse immer wieder deine Komfortzone, und bringe dich sich dazu, Neues zu lernen. Diese Erfahrung wird zu deiner wichtigsten Stärke als Junior Developer, insbesondere bei einer Tätigkeit als Berater. Lege den Grundstein für deine berufliche Laufbahn.
Als Junior wertvolle Beiträge leisten
Lernen ist gut, aber irgendwann musst du einen Rhythmus finden, um Software zu liefern. Du solltest dir neben der täglichen Arbeit, zu der wahrscheinlich kleine Verantwortlichkeiten ohne hohes Risiko gehören, unbedingt unabhängige Bereiche aussuchen, in denen du deinem Team nutzen kannst, und diese zu Lieblingsprojekten machen.
In meinem ersten Projekt beispielsweise verwendeten wir C# im Backend, React und Redux im Frontend. Da ich noch nichts davon verwendet hatte, war die Hürde für den Produktivbetrieb ziemlich hoch. Zum Glück hatte ich einen Teamleiter, der andere wichtige Aufgaben auf mich übertrug und dafür sorgte, dass ich zuversichtlich und produktiv blieb, während ich außerdem lernte, mit unserem zentralen Delivery Stack umzugehen. In diesem Fall verwendeten wir ein unvollständiges Open-Source-Tool für einen Build Monitor für Visual Studio Online, und es war meine Aufgabe, die Implementierung abzuschließen.
Zur Erklärung: Ich wusste überhaupt nicht, wie Build Pipelines funktionieren, und der Monitor war in Clojure geschrieben, deren Paradigma sich vollkommen von der mir bekannten objektorientierten Programmierung unterschied. Also schlug ich mir einen Monat lang die Nächte um die Ohren, produzierte furchtbar imperativen Clojure-Code und sah mir Videos von Rich Hickey an. Am Ende hatte unser Team einen funktionierenden Build Monitor, und ich hatte meine Begeisterung für funktionale Programmierung entdeckt.
Mein nächstes Projekt war die Arbeit mit einer Java-Microservices-Plattform unter Verwendung von Docker, Kubernetes und Cassandra. Und wieder gab es einen neuen Tech-Stack. Diesmal überbrückte ich die Zeit, bis ich mit den neuen Tools und Konzepten vertraut war, indem ich mich in Sachen UI nützlich machte. Mithilfe meiner zuvor gesammelten Erfahrungen konnte ich mich für die Migration kritischer Business Flows von Reflux zu Redux einsetzen und daran mitwirken. So konnten wir die Testbarkeit von JavaScript und die Komplexität der von uns übernommenen Codebase reduzieren und dadurch die Entwicklungsgeschwindigkeit und Stabilität erhöhen.
In beiden Fällen brauchte ich Zeit, um zu lernen und produktiv zu werden. Indem ich Dinge erkannte, die ich erledigen konnte, wurde ich für meine Teams dennoch schnell zur echten Unterstützung. Dank dieser Lieblingsprojekte gewann ich Glaubwürdigkeit und das Vertrauen meiner Teams und der Stakeholder. Ich baute Selbstvertrauen auf und litt weniger unter dem Hochstaplersyndrom. Außerdem konnte ich herausfinden, wie es ist, etwas zu leiten (was allein eine ganz eigene Welt des Lernens ist).
Es bietet sich immer eine Möglichkeit, zusätzlichen Nutzen zu schaffen oder etwas zu überarbeiten. Zwar ist es besonders für dich als Junior wichtig, Lieblingsprojekte zu verfolgen und damit deine Entwicklung und die Beziehungen zum Team zu stärken, aber ich werde mir auch weiterhin solche Projekte suchen. Sie machen einfach Freude!
Auswahl von Lieblingsprojekten
Leider hat alles seinen Preis. So nützlich Lieblingsprojekte auch sind – es gibt auch eine Kehrseite. Vielleicht weißt du nicht, wo du anfangen sollst. Vielleicht fühlst du sich nicht unterstützt oder spürst einen Druck, Funktionalität abliefern zu müssen. Oder aber du machst dir Gedanken wegen zusätzlicher Zeit, Arbeit und Anstrengung.Aus meiner Erfahrung heraus kann ich bestätigen, dass diese Punkte in der Tat zutreffen. Du solltest außerdem damit rechnen, dass du häufig frustriert bist und deine Erwartungen, wie etwas zu funktionieren hat, enttäuscht werden. Damit es leichter wird, solltest du Projekte aussuchen, die:
- überschaubar sind
- klar definierte Ziele haben („erledigt“)
- Nutzen bringen/wertgeschätzt werden
- mit hoher Wahrscheinlichkeit unterstützt werden (z. B. von deinem Team, dem Unternehmen oder der Community), sobald du davon berichtest
- Freude machen/bereichernd sind
Und vergiss nicht, dir Auszeiten zu nehmen. Lieblingsprojekte sind bereichernd, aber niemand sollte von dir erwarten, dass du zusätzliche Arbeit hineinsteckst, für die du nicht bezahlt wirst. Tu es, wenn es für dich sinnvoll ist und du gerade den nötigen Raum dafür hast. Du kannst auch mit deinem Team besprechen, ob du sich während der Arbeitszeit mit solchen Projekten beschäftigen darfst. Wenn darin ein eindeutiger Nutzen steckt, ist das sicherlich möglich.
Fazit
Einer der zentralen Grundsätze des Manifests für Agile Softwareentwicklung besagt, dass das „Reagieren auf Veränderung“ wichtiger ist als das „Befolgen eines Plans“. Kontinuierliche Verbesserung, kontinuierliche Bereitstellung. Erzeuge eine Version des Produkts, ermittle Defizite, hole dir Feedback ein, bewerte die Anforderungen neu, erzeuge die nächste Version. Mache dabei kleine Schritte, und erzwingen niemals große Visionen, die auf veralteten Informationen basieren. Genau so solltest du als Junior Developer auch über dich selbst denken.Höre nie auf zu lernen.
#juniordevforlife
Hinweis: Die in diesem Artikel geäußerten Aussagen und Meinungen sind die der Autor:innen und spiegeln nicht zwingend die Position von Thoughtworks wider.