Wie kann man als Junior-, Mittelstufen- oder Senior-Entwickler aufsteigen?

Durch Team-Redakteur - vor 2 Monaten / Apr 2020
Wie kann man als Junior-, Mittelstufen- oder Senior-Entwickler aufsteigen?

Ich habe daran gearbeitet, die Roadmaps zu überarbeiten - die Aufteilung des Kompetenzsets auf der Grundlage der Senioritätsstufen, um sie leichter nachvollziehbar zu machen und die neuen Entwickler nicht zu vergraulen. Da es in den Roadmaps nur um das technische Wissen geht, hielt ich es für eine gute Idee, noch einmal zu wiederholen und einen Artikel darüber zu verfassen, was ich von den verschiedenen Senioritätsstufen halte.

Ich habe gesehen, wie viele Organisationen über das Dienstalter von Entwicklern entscheiden, indem sie der jahrelangen Erfahrung mehr Bedeutung beimessen, als sie sollten. Ich habe Entwickler gesehen, die als "Junior" bezeichnet wurden, die die Arbeit von Senior-Entwicklern erledigten, und ich habe "Lead"-Entwickler gesehen, die nicht einmal qualifiziert waren, als "Senior" bezeichnet zu werden. Das Dienstalter eines Entwicklers kann nicht nur durch sein Alter, seine jahrelange Erfahrung oder sein technisches Wissen bestimmt werden. Hier spielen noch andere Faktoren eine Rolle - ihre Wahrnehmung der Arbeit, wie sie mit ihren Kollegen interagieren und wie sie Probleme angehen. Wir erörtern diese drei Schlüsselfaktoren im Detail für jede der folgenden Senioritätsstufen.

Unterschiedliche Senioritätstitel

Verschiedene Organisationen können unterschiedliche Senioritätstitel haben, aber sie fallen hauptsächlich in drei Kategorien:

  • Junior-Entwickler
  • Entwickler der mittleren Ebene
  • Senior-Entwickler

Junior-Entwickler

Nachwuchsentwickler sind in der Regel frischgebackene Hochschulabsolventen, und es ist entweder keine oder nur minimale Branchenerfahrung vorhanden. Sie haben nicht nur schwache Programmierkenntnisse, sondern es gibt auch einige andere Dinge, die Junior-Entwickler verraten:

  • Ihr Hauptmantra ist "make it work", ohne dass sie viel Aufmerksamkeit darauf verwenden, wie die Lösung erreicht wird. Für sie sind eine funktionierende Software und gute Software gleichwertig.
  • Sie erfordern in der Regel sehr spezifische und strukturierte Anweisungen, um etwas zu erreichen. Sie leiden unter dem Tunnelblick, brauchen Aufsicht und kontinuierliche Anleitung, um effektive Teammitglieder zu sein.
  • Die meisten der Junior-Entwickler versuchen nur, der Rolle gerecht zu werden, und wenn sie nicht weiterkommen, verlassen sie vielleicht die Arbeit für einen Senior-Entwickler, anstatt wenigstens zu versuchen, einen Versuch zu unternehmen.
  • Sie wissen nichts über die geschäftliche Seite des Unternehmens und wissen nicht, wie Management/Vertrieb/Marketing/etc. denken, und ihnen ist nicht klar, wie viel Nacharbeit, vergeudete Mühe und Ärger für den Endbenutzer durch das Kennenlernen des Geschäftsbereichs eingespart werden könnte.
  • Over-Engineering ist ein großes Problem, das oft zu Fragilität und Fehlern führt.
  • Wenn ihnen ein Problem gestellt wird, versuchen sie oft, nur das aktuelle Problem zu beheben, d.h. die Symptome zu beseitigen, anstatt das Grundproblem zu beheben.
  • Ihnen fällt vielleicht das "Jemand anders hat ein Problem"-Verhalten auf.
  • Sie wissen nicht, was oder wie viel sie nicht wissen, dank des Dunning-Kruger-Effekts.
  • Sie ergreifen keine Initiativen, und sie könnten Angst davor haben, an einer unbekannten Codebasis zu arbeiten.
  • Sie nehmen nicht an Teamdiskussionen teil.

Ein Junior-Entwickler im Team zu sein, ist nicht unbedingt eine schlechte Sache; da Sie erst am Anfang stehen, wird von Ihnen nicht erwartet, dass Sie ein Besserwisser sind. Es liegt jedoch in Ihrer Verantwortung, zu lernen, Erfahrung zu sammeln, nicht mit dem "Junior"-Titel stecken zu bleiben und sich zu verbessern. Hier sind ein paar Tipps für Junior-Entwickler, die Ihnen helfen sollen, auf der Karriereleiter nach oben zu kommen:

  • Alle möglichen Probleme können gelöst werden, wenn man lange genug daran arbeitet. Geben Sie nicht auf, wenn Stack Overflow oder ein Problem auf GitHub keine Antwort hat. Zu Ihrem Vorsprung zu sagen "Ich stecke fest, aber ich habe X, Y und Z versucht. Haben Sie irgendwelche Hinweise?" ist viel besser als zu sagen "Das übersteigt meine Vorstellungskraft".
  • Lesen Sie viel Code, nicht nur den Code in den Projekten, an denen Sie arbeiten, sondern auch den Referenz/Framework-Quellcode, Open-Source. Fragen Sie Ihre Entwicklerkollegen, vielleicht auch auf Reddit, nach den guten Open-Source-Beispielen für die Sprache/Werkzeuge Ihrer Wahl.
  • Machen Sie persönliche Nebenprojekte, teilen Sie sie mit anderen, tragen Sie zur Open-Source-Gemeinschaft bei. Sprechen Sie Menschen um Hilfe an. Sie werden überrascht sein, wie viel Unterstützung Sie von der Gemeinschaft erhalten können. Ich erinnere mich noch gut an mein erstes Open-Source-Projekt auf GitHub vor etwa 6 Jahren, bei dem es sich um ein kleines PHP-Skript (eine Bibliothek) handelte, das Details zu einer bestimmten Adresse von Googles Geocoding API holte. Die Codebasis war super chaotisch, es gab keine Tests, es gab keine Linters oder Sniffer, und es hatte keine CI, weil ich zu dieser Zeit nichts davon wusste. Ich bin mir nicht sicher, wie, aber eine freundliche Seele fand das Projekt irgendwie, gab es ab, überarbeitete es, "modernisierte" es, fügte Linting und Code-Sniffing hinzu, fügte CI hinzu und öffnete die Pull-Anfrage. Diese eine Pull-Anfrage hat mich so viele Dinge gelehrt, die ich alleine vielleicht nie so schnell gelernt hätte, denn ich war noch auf dem College, habe für ein kleines Dienstleistungsunternehmen gearbeitet und ganz alleine nur kleine Websites erstellt, ohne zu wissen, was richtig ist und was nicht. Diese eine PR auf GitHub war meine Einführung in Open-Source, und dem habe ich alles zu verdanken.
  • Vermeiden Sie das so genannte "Somebody Else's Problem Field"-Verhalten.
  • Wenn Sie ein Problem zu lösen haben, versuchen Sie, die Grundursache zu ermitteln und zu beheben, anstatt die Symptome zu beheben. Und denken Sie daran: Nicht in der Lage zu sein, sich zu reproduzieren, bedeutet nicht gelöst. Es ist gelöst, wenn Sie verstehen, warum es aufgetreten ist und warum es nicht mehr besteht.
  • Haben Sie Respekt vor dem Kodex, der vor Ihnen geschrieben wurde. Seien Sie großzügig, wenn Sie ein Urteil über die Architektur oder die in der Codebasis getroffenen Designentscheidungen fällen. Verstehen Sie, dass ein Code aus einem anderen Grund als Inkompetenz oft hässlich und seltsam ist. Es ist eine große Fähigkeit zu lernen, mit veraltetem Code zu leben und mit ihm zu gedeihen. Gehen Sie niemals davon aus, dass jemand dumm ist. Finden Sie stattdessen heraus, wie diese intelligenten, gut gemeinten und erfahrenen Menschen zu einer Entscheidung gekommen sind, die jetzt dumm ist. Nähern Sie sich der Vererbung von Altlasten mit einer "Opportunity-Mentalität" und nicht mit einer klagenden Haltung.
  • Es ist in Ordnung, Dinge nicht zu wissen. Sie müssen sich nicht schämen, dass Sie Dinge nicht schon wissen. Es gibt keine dummen Fragen, stellen Sie so viele Fragen, dass Sie effektiv arbeiten können.
  • Lassen Sie sich nicht durch die Berufsbezeichnung, die Sie haben, einschränken. Arbeiten Sie weiter an Ihrer Selbstvervollkommnung.
  • Machen Sie Ihre Hausaufgaben. Sagen Sie voraus, was in die Röhre kommt. Nehmen Sie an den Teamdiskussionen teil. Selbst wenn Sie sich irren, werden Sie etwas lernen.
  • Informieren Sie sich über die Domäne, mit der Sie arbeiten. Verstehen Sie als Endbenutzer das Produkt von Anfang bis Ende. Gehen Sie nicht von Vermutungen aus, stellen Sie keine Fragen und lassen Sie im Zweifelsfall Dinge klären.
  • Lernen Sie, effektiv zu kommunizieren - Soft Skills sind wichtig. Lernen Sie, wie man gute E-Mails schreibt, wie man seine Arbeit präsentiert, wie man seine Fragen nachdenklich formuliert.
  • Setzen Sie sich mit den leitenden Entwicklern zusammen, sehen Sie ihnen bei der Arbeit zu, finden Sie einen Mentor. Niemand mag einen Besserwisser. Behalten Sie Ihr Ego im Griff und seien Sie bescheiden genug, um von erfahrenen Leuten Unterricht zu nehmen.
  • Folgen Sie nicht einfach blind dem Rat von "Experten", sondern nehmen Sie ihn mit Vorsicht zur Kenntnis.
  • Wenn Sie gebeten werden, einen Kostenvoranschlag für bestimmte Arbeiten abzugeben, antworten Sie nicht, wenn Sie nicht alle Details für eine vernünftige Schätzung haben. Wenn Sie dazu gezwungen werden, füllen Sie den Fragebogen zweimal oder öfter aus, je nachdem, wie viel Sie nicht wissen, was getan werden muss, damit die Aufgabe als "erledigt" gekennzeichnet wird.
  • Nehmen Sie sich etwas Zeit, um zu lernen, wie man einen Debugger benutzt. Debugger sind recht vorteilhaft, wenn es darum geht, durch neue, undokumentierte oder schlecht dokumentierte Codebase zu navigieren oder um seltsame Probleme zu debuggen.
  • Vermeiden Sie es, zu sagen "es funktioniert auf meiner Maschine" - ja, das habe ich schon oft gehört.
  • Versuchen Sie, jedes Gefühl der Unzulänglichkeit oder des Betrügersyndroms in Energie umzuwandeln, um sich selbst voranzubringen und Ihre Fähigkeiten und Kenntnisse zu erweitern.

Entwickler der mittleren Ebene

Die nächste Stufe nach den Junior-Entwicklern ist die mittlere Stufe. Sie sind technisch stärker als die Junior-Entwickler und können mit minimaler Beaufsichtigung arbeiten. Sie müssen noch einige Probleme lösen, um auf die Senior-Ebene zu gelangen.

Entwickler der Mittelstufe sind kompetenter als der Junior-Entwickler. Sie beginnen, die Fehler in ihrer alten Codebasis zu erkennen. Sie eignen sich das Wissen an, aber sie geraten in die nächste Kette, d.h. sie vermasseln Dinge, während sie versuchen, sie "richtig" zu machen, z.B. übereilte Abstraktionen, Überbeanspruchung oder unnötige Verwendung von Entwurfsmustern - sie sind vielleicht in der Lage, schneller eine Lösung zu liefern als die Junior-Entwickler, aber die Lösung könnte Sie auf lange Sicht in einen anderen Kaninchenbau stecken. Ohne Aufsicht könnten sie die Ausführung verzögern, während sie versuchen, "die Dinge richtig zu machen". Sie wissen nicht, wann sie Kompromisse eingehen sollen, und sie wissen immer noch nicht, wann sie dogmatisch und wann sie pragmatisch sein sollen. Sie können sich leicht an ihre Lösung gewöhnen, werden kurzsichtig und können keine Rückmeldungen entgegennehmen.

Entwickler der mittleren Ebene sind recht häufig. Die meisten Organisationen bezeichnen sie fälschlicherweise als "Senior-Entwickler". Sie benötigen jedoch weitere Betreuung, um Senior-Entwickler zu werden. Der nächste Abschnitt beschreibt die Aufgaben eines Senior-Entwicklers und wie Sie einer werden können.

Senior-Entwickler

Senior-Entwickler sind die nächste Stufe nach den Mid-Level-Entwicklern. Sie sind die Leute, die Dinge selbstständig und ohne Aufsicht erledigen können, ohne später irgendwelche Probleme zu schaffen. Sie sind reifer, haben in der Vergangenheit Erfahrungen mit guter und schlechter Software gesammelt und daraus gelernt - sie wissen, wie man pragmatisch vorgeht. Hier ist die Liste der Dinge, die man normalerweise von einem Senior-Entwickler erwartet:

  • Mit ihren Erfahrungen aus der Vergangenheit, den gemachten Fehlern, den Problemen, mit denen über- oder unterentwickelte Software konfrontiert ist, können sie die Probleme vorhersehen und die Richtung der Codebasis oder der Architektur überzeugen.
  • Sie haben kein "Shiny-Toy"-Syndrom. Sie sind pragmatisch in der Ausführung. Sie können die Kompromisse eingehen, wenn es erforderlich ist, und sie wissen, warum. Sie wissen, wo sie dogmatisch und wo sie pragmatisch sein müssen.
  • Sie haben ein gutes Bild von dem Gebiet, wissen, was in den meisten Fällen das beste Werkzeug für die Arbeit ist (auch wenn sie das Werkzeug nicht kennen). Sie haben die angeborene Fähigkeit, ein neues Werkzeug/Sprache/Paradigma/etc. aufzugreifen, um ein Problem zu lösen, das dies erfordert.
  • Sie sind sich bewusst, dass sie in einem Team sind. Sie sehen es als Teil ihrer Verantwortung, andere als Mentor zu begleiten. Das kann vom paarweisen Programmieren mit Junior-Entwicklern bis hin zur Übernahme unrühmlicher Aufgaben wie dem Schreiben von Dokumenten oder Tests oder was immer sonst noch zu tun ist, reichen.
  • Sie haben ein tiefes Verständnis des Bereichs - sie wissen über die geschäftliche Seite des Unternehmens Bescheid und erkennen, wie Management/Vertrieb/Marketing/etc denken und profitieren während der Entwicklung von ihrem Wissen über den Geschäftsbereich.
  • Sie reichen keine leeren Beschwerden ein, sondern fällen ihre Urteile auf der Grundlage der empirischen Belege und haben Lösungsvorschläge.
  • Sie denken viel mehr als nur Code - sie wissen, dass es ihre Aufgabe ist, Lösungen für die Probleme zu liefern und nicht nur Code zu schreiben.
  • Sie haben die Fähigkeit, große, undefinierte Probleme aufzugreifen, sie zu definieren, sie zu zerlegen und die Stücke auszuführen. Ein leitender Entwickler kann etwas Großes und Abstraktes nehmen und mit ihm laufen. Er lässt sich einige Optionen einfallen, diskutiert sie mit dem Team und setzt sie um.
  • Sie haben Respekt vor dem Kodex, der vor ihnen geschrieben wurde. Sie sind großzügig, wenn sie über die Architektur oder die in der Codebasis getroffenen Designentscheidungen urteilen. Sie nähern sich der Vererbung von Altlasten mit einer "Gelegenheitshaltung" und nicht mit einer klagenden Haltung.
  • Sie wissen, wie man Feedback gibt, ohne jemanden zu verletzen.

Schlussfolgerung

Alle Teams setzen sich aus einer Mischung all dieser Senioritätsrollen zusammen. Mit seiner Rolle zufrieden zu sein, ist eine schlechte Sache, und man sollte immer danach streben, sich für den nächsten Schritt zu verbessern. Dieser Artikel basiert auf meinen Überzeugungen und Beobachtungen in der Branche. Viele Unternehmen legen mehr Wert auf die jahrelange Erfahrung, um das Dienstalter zu bestimmen, was eine beschissene Metrik ist - man sammelt keine Erfahrung, indem man Jahre damit verbringt. Man gewinnt sie, indem man ständig verschiedene Arten von Problemen löst, unabhängig von der Anzahl der Jahre, die man in der Branche verbringt. Ich habe gesehen, wie frischgebackene Hochschulabsolventen, die noch keine Erfahrung in der Industrie haben, sich schnell an die Arbeit eines Senior-Ingenieurs gewöhnt haben, und ich habe gesehen, wie Senior-Entwickler allein aufgrund ihres Alters und ihrer "jahrelangen Erfahrung" als "Senior" bezeichnet wurden.

Die wichtigsten Eigenschaften, die Sie mitbringen müssen, um in Ihrer Karriere aufzusteigen, sind: sich nicht mit Mittelmäßigkeit zufrieden geben, eine offene Denkweise haben, bescheiden sein, aus Fehlern lernen, an den herausfordernden Problemen arbeiten und eine Denkweise der Chancen statt einer klagenden haben.

Damit geht dieser Posten zu Ende. Was denken Sie über die Senioritätsstufen der Entwickler? Fühlen Sie sich frei, Verbesserungen an diesem Leitfaden vorzunehmen. Bis zum nächsten Mal, bleiben Sie dran!


Dieser Artikel wurde ursprünglich am 3. Dezember 2019 auf https://roadmap.sh veröffentlicht und wurde von Kamran Ahmed geschrieben: https://roadmap.sh/guides/levels-of-seniority Bitte beachten Sie, dass die Erlaubnis zur Nutzung des Inhalts vor der Veröffentlichung mit dem Autor über Twitter erfolgte.





Team-Redakteur
Team-Redakteur
Kuratieren von Blogs für cdrrazan.com! Hauptsächlich Code, Linux und Tech zur Unterstützung von Studenten und Fachleuten.


Kommentare powered by Disqus