Wie man einen Junior-Entwickler heranwächst

Ich habe vor zwei Jahren meinen Abschluss als Junior-Softwareentwickler bei Lighthouse Labs gemacht. In einer 8-wöchigen intensiven Phase wurde uns gesagt, was Programmieren ist, es wurden Ruby- und JavaScript-Sprachen unterrichtet, 3 oder 4 Frameworks eingeführt und wir haben uns bemüht, unser eigenes Projekt zu entwickeln.

Danach machten wir uns alle auf den Weg zu unserer Karriere. Glücklicherweise sind die Fähigkeiten von Entwicklern sehr gefragt. Leider mussten wir von diesem Zeitpunkt an aktiv lernen, wie man mit dem Imposter-Syndrom umgeht und wie man im Meer der Absolventen der Informatik schwimmt.

Letzten Monat nahm ich an der Polyglot-Konferenz unconference teil. Es fanden mindestens zwei Sitzungen statt, die sich an Nachwuchsentwickler richteten. Daher halte ich es für angebracht, ein paar Dinge mitzuteilen, die mir geholfen haben.

# 1 Zeit zum Einchecken

Als Neueinstellung wurde ich ermutigt, Fragen zu stellen. Nach ein oder zwei Monaten hatte ich das Gefühl, es endlich wissen zu müssen. Ja, ich dachte, ich sollte in der Lage sein, selbst Lösungen zu finden. Ich wollte keine Bürde mehr sein. Ich wollte nicht dumm, unintelligent oder geradeheraus dumm aussehen. Immerhin, wie lange kann es dauern, um zu lernen ... Richtig ?! Falsch.

Es dauert so lange wie es dauert, um zu lernen. Und einige Aufgaben sind komplizierter als andere.

Schließlich geriet ich in einen Kreis - ich glaube, ich kann das Problem lösen. Es dauert für immer. Ich bin gestresst. Ältere Entwickler hingegen wollen keine Mikromanagement-Aufgaben übernehmen, sie wissen, dass ich ein Selbstlernender bin. Und am Ende werden wir wochenlang wenig bis gar keine Fortschritte machen. (Oder bin es nur ich?) Auf jeden Fall.

Lösung: Wöchentlich (anfangs sogar zweimal pro Woche) 30-minütiges Einchecken in die Projekte, um Richtung, Fortschritt und Engpässe zu besprechen.

Anstatt alle 30 Minuten loszulaufen, um eine Frage zu stellen, kann ich das Problem besser untersuchen und verstehen und meine Fragen sammeln. Es ist von unschätzbarem Wert, 30 Minuten ungeteilte Aufmerksamkeit zu erhalten. Ich bekomme Antworten auf meine Fragen und erfahre mehr über die Organisation. Ich verbinde mich mit meinem Mentor. Und jeder verlässt ein Meeting mit dem Gefühl, dass wir Fortschritte gemacht haben.

# 2 Code Bewertungen

Bildnachweis: Unsplash | @tirzavandijk

Es ist eine Sache, ein Feature zu codieren, einen Fehler zu beheben und es auf meinem lokalen Computer auszuführen. Es ist eine völlig andere Sache, neuen Code in die Produktion einzubinden.

Die meisten Unternehmen setzen Code Review als Werkzeug für den Wissenstransfer ein, aber wie viele nutzen es als Unterrichtsmöglichkeit?

Ich werde immer einem meiner ersten Mentoren dankbar sein, der mich dazu gebracht hat, den Code-Überprüfungsprozess für jeden Code-Block, den ich als Pull-Anfrage eingereicht habe, zu durchlaufen.

  1. Stellen Sie das Problem vor - bringen Sie alle auf die gleiche Seite.
  2. Führen Sie den Code aus - zeigen Sie allen, dass er funktioniert.
  3. Führen Sie eine Lösung in einfachen Worten durch - zeigen Sie, dass Sie die Lösung verstehen.
  4. Gehen Sie durch den Code - zeigen Sie ihn im Code.

Dieser Prozess brachte mir das Denken bei, bevor ich programmiere. Es hat mich sicherer gemacht, meine Lösungen technisch auszudrücken. Ich achte mehr auf die Lesbarkeit des Codes.

Mit dieser Praxis können die im Clean Code festgelegten Grundsätze festgelegt und erlernt werden. Wenn mehr Nachwuchsentwickler im Team sind, schlage ich vor, sie ebenfalls in diesen Prozess einzubeziehen.

# 3 Solution Design Sessions

Eine der größten Beschwerden, die auf der Konferenz geäußert wurde, war die Unfähigkeit der Nachwuchsentwickler, den Überblick zu behalten. Und ehrlich gesagt sollte niemand sehr überrascht sein. Die meisten von uns sind am Anfang mit dem vorliegenden Problem überfordert. Ich erinnere mich, dass ich bei der Arbeit an dem ersten Projekt Angst hatte, den Code zu berühren, den jemand anderes geschrieben hatte.

Lösung: Besprechen Sie mögliche Lösungen und Architekturen, bevor Sie den Code schreiben. Whiteboard es. Welcher vorhandene Code kann angepasst werden, was kann ich erstellen, das in der Zukunft verwendet werden kann.

Was mir wirklich geholfen hat, war, als ich ein wenig Zeit hatte, die Lösung zu prototypisieren und meinen Vorschlag zu machen, auch wenn er später verworfen wurde. Dadurch konnte ich lernen, wo sich mein Denkprozess verbessern muss.

Ich finde diese Technik unglaublich wertvoll. Ich hatte das Gefühl, dass ich nicht nur Code schreibe und Fehler behebe, sondern auch etwas Neues und Nützliches für die Zukunft entwerfe und erstelle. Es zeigte mir ein größeres Bild. Das ist einer der Hauptgründe, warum ich in die Softwareentwicklung eingestiegen bin - um Lösungen zu entwerfen.

# 4 Exposition gegenüber mehr Code

Das erste, was mit Code zu tun ist, ist zu sehen, wie es zuvor gemacht wurde und wie es implementiert wurde, um ähnliche Probleme zu lösen. Der Umgang mit Code scheint also ein natürlicher Vorschlag zu sein.

Was mir jedoch am meisten geholfen hat, war die Arbeit an Nebenprojekten. Jemand hat Code umgeschrieben und gesehen, wie er Schritt für Schritt entwickelt wurde.

In einer Arbeitsumgebung versuche ich, eine Funktion an scheinbar unterschiedlichen Stellen der Plattform zu verwenden, um zu sehen, wie andere Entwickler denken und programmieren.

# 5 Jeder steckt bei dummen Fehlern fest

Dies ist nur eine Erinnerung daran, dass keiner von uns jemals aufhören kann zu lernen, und nur Zusammenarbeit und Wissensaustausch können die Entwicklung vorantreiben.

Nach zwei Jahren in der Coding-Community weiß ich, dass es manchmal Tage dauern kann, den kleinsten Fehler zu finden, und dass dies nichts mit Ihrem Scharfsinn, Ihrer Intelligenz oder Ihrem guten Aussehen zu tun hat.

Um Hilfe zu bitten ist der Weg zu wachsen und wir sollten uns niemals schämen, um Hilfe zu bitten und Hilfe anzubieten. Und wie mein Vater es ausdrückt:

"Wenn Sie zwei Stunden (Tage, Wochen, Monate) mit einem Problem verbracht haben, lassen Sie sich nicht enttäuschen, dass Sie es nicht in einer Stunde (Tag, Woche, Monat) geschafft haben. Sei froh, dass du nicht vier Stunden (Tage, Wochen, Monate) gebraucht hast. “
Vielen Dank an meinen Vater, der mir sehr geholfen hat, meine ersten Schritte zu machen und mir zu zeigen, wie interessant und lohnend Entwicklung sein kann. Vielen Dank an Voleo, der als brandneuer Lighthouse Labs-Absolvent eine Chance auf mich genommen hat. Und alle ehemaligen, gegenwärtigen und zukünftigen Lehrer. Ihre Zeit und Mühe bleibt nicht unbeachtet.