Was Sie in Ihrer ersten Woche als Softwareentwickler erwartet

Sie wissen, dass Sie gerne programmieren, aber wie ist es, es für einen Job zu tun? Was könnten Sie in Ihrer ersten Woche erwarten?

Ich konnte mir meine erste Woche in einem neuen Job nicht vorstellen. Beginnen Sie sofort mit dem Codieren? Was ist, wenn sie eine Sprache / ein Framework verwenden, die Sie nicht gelernt haben? Wie kommen Sie mit der Codebasis auf den neuesten Stand und wissen, welche Prioritäten gesetzt werden? Ist es einfach, sich in das Team einzufügen? Öffnen Sie einfach Ihren Editor und beginnen Sie mit dem Codieren? Was ist, wenn Sie etwas schrecklich falsch machen und alles kaputt machen?

Ich habe 2 Jahre in einem Coding Bootcamp gearbeitet und ähnliche Fragen von vielen Studenten gehört. Sie wussten, dass sie gerne programmieren und liebten, was sie täglich im Bootcamp machten - aber sie wollten wissen, wie es sich anfühlt, einen richtigen Job zu machen.

In diesem Beitrag werde ich anhand von Beispielen zeigen, was ich in den letzten Tagen in meiner letzten Rolle getan habe, um Ihnen eine Vorstellung davon zu geben, was Sie erwarten könnten.

Hintergrund

Ich arbeite als Full-Stack-Entwickler in einem kleinen Unternehmen. Das Engineering-Team besteht aus vier Entwicklern (einschließlich mir) und einem CTO. Wir arbeiten auch eng mit einem Product Owner zusammen, der einer der Gründer ist. Ich habe ein paar Jahre Erfahrung im Codieren gesammelt.

Alle Dienste sind auf AWS und wir verwenden NodeJS und Ruby.

Tag 1: Meistens Setup

Ich kam um 9 Uhr morgens im Büro an. Auf meinem Schreibtisch wartete ein glänzendes neues MacBook Pro mit Adaptern und zwei Bildschirmen auf mich. Das Entwicklerteam brachte mich zum Frühstück in ein nahe gelegenes Café, und als wir zurückkamen, setzte ich mich hin und begann, meine Maschine einzurichten.

Da ich zuvor unzählige Entwicklungsumgebungen eingerichtet habe, während ich in einem Coding-Bootcamp gearbeitet habe, war dies ziemlich einfach und hat nicht lange gedauert. Ich hatte jedoch nur einmal eine Ruby / Rails-Umgebung auf meinem eigenen Laptop eingerichtet, sodass dieser Teil etwas länger dauerte.

Ich erhielt ein A4-Blatt mit den Anforderungen, Versionsnummern usw., das ich sorgfältig befolgte. Ich erhielt auch Zugriff auf verschiedene Websites wie BitBucket, einen Passwort-Manager, AWS und Gitlab und richtete meine SSH-Schlüssel auf meinem neuen Computer ein.

Vor dem Mittagessen unterhielt ich mich mit dem CTO und wir sprachen ausführlich über das Produkt, die Architektur sowie die Ziele und Prioritäten, die das Entwicklerteam auf absehbare Zeit hat.

Nach dem Mittagessen klonte ich einige der Dienste, aus denen die Anwendung besteht, und begann mich mit der Codebasis vertraut zu machen. Zum Glück bin ich zu einer Zeit in das Team eingetreten, als einige neue, frische Teile des Dienstes in der Entwicklung waren, was bedeutet, dass ich nicht zu viel Code hatte, um mich auf den neuesten Stand zu bringen.

In den letzten Stunden des Tages saß ich mit einem der leitenden Entwickler zusammen, während er eine Funktion implementierte. Wir nutzten es als Gelegenheit für ihn, mich durch diesen Teil der App zu führen und zu erklären, warum Dinge auf bestimmte Weise getan wurden, welche Teile Probleme verursacht hatten und welche Aspekte sich in Zukunft möglicherweise ändern würden.

Tag 2: Testen

Ich hatte die Aufgabe, einige Funktionen in einem der Repos für die App zu testen. Wenn Sie neuen Mitarbeitern Tests zum Schreiben geben, können Sie sie in eine Codebasis einführen und sie mit der Logik der Anwendung vertraut machen.

Ich verbrachte ein gutes Stück Zeit damit, nur den Code zu lesen, herauszufinden, wie alles zusammenarbeitet, und zu sehen, ob ich dem Fluss der Logik folgen kann. Ich interessierte mich für die Konventionen, die das Team gewählt hatte, die Art und Weise, wie der Code aufgeteilt wurde, und die stilistischen Entscheidungen. Das Schreiben der Tests war nicht schwer, aber ich bin immer sehr vorsichtig, wenn ich meine erste Markierung auf einer Codebasis mache, an der ich vorher noch nicht gearbeitet habe!

Ich wollte nicht, dass meine Arbeit herausragt, also habe ich versucht, den derzeit verwendeten Codestil zu beobachten und zu absorbieren. In gewissem Maße hilft es sehr, gute Praktiken wie das Flusen zu haben, aber es gibt auch nur allgemeine architektonische und stilistische Entscheidungen, bei denen das Flusen Ihnen nicht helfen kann.

Eine kleine Herausforderung bestand darin, mich an den Git-Workflow des Teams zu gewöhnen. Jedes Team hat seine eigene Art, Dinge zu tun: Einige Teams fusionieren, einige Teams werden neu gegründet, einige Teams quetschen Commits und andere nicht, einige folgen populären Workflows wie diesem, und andere erzwingen wohl oder übel einen Push in den Master. Außerdem gibt es die Konventionen für die Festschreibungsnachricht und die Beschreibung, den Überprüfungsprozess usw.

Alles in allem gibt es eine Menge nicht expliziter Dinge, die „so machen wir Dinge“ aufgreifen. Nachdem ich den Prozess ein paar Mal durchlaufen, meine Fehler korrigiert und Fragen gestellt habe, ist es jetzt eine Selbstverständlichkeit.

Die ganze Zeit schrieb ich Notizen in ein Notizbuch und hielt Code-Schnipsel in einer Anwendung namens Bear. Es gab so viel zu tun - wie man Dinge macht, die bevorzugten Verfahren für das Team, Dinge, die ich vorher noch nicht gemacht hatte, und neue Sprachen und Rahmenbedingungen zum Lernen.

Ich musste wirklich aktiv sein, um zu notieren, was ich lernte. Ich habe es mir am Ende oder am Anfang eines jeden Tages zum Ziel gesetzt, meine Notizen zu überprüfen, zusätzliche Erklärungen zu Dingen hinzuzufügen, die ich in Eile geschrieben hatte, und Dinge zu recherchieren, die ich nicht vollständig verstanden habe. All dies nahm auch einige Zeit in Anspruch.

Tag 3: Spiking AWS

Im Rahmen der laufenden Version mussten wir entscheiden, wie ein von uns erstellter Dienst bereitgestellt werden soll. Wir haben AWS verwendet, aber es gab die Wahl zwischen der Verwendung einer EC2-Instanz, die die einfachste Wahl wäre, da es sich nur um einen Server in der Cloud handelt, auf dem Ihre Anwendung ausgeführt wird, oder um etwas ausgefalleneres wie Elastic Container Service. Der Vorteil von ECS besteht darin, dass es die Skalierung mehrerer EC2-Instanzen verwaltet und daher eine gute Option für die Zukunft darstellt. Aber es war vorerst nicht unbedingt notwendig.

Vor diesem Hintergrund wurde mir die Aufgabe übertragen, freiwillig herauszufinden, wie einfach es wäre, unseren Service auf ECS bereitzustellen. Spiking bedeutet nur, etwas auszuprobieren, um die Machbarkeit zu untersuchen. Wenn es schwierig werden sollte, war es das nicht wert, da es sich um eine zukünftige Optimierung handelte, die wir im Moment nicht dringend brauchten.

Dies bedeutete für mich viel Lernen, da ich das ECS von Amazon noch nicht verwendet hatte. Außerdem war die App eine Rails-App und ich war mit dem gesamten Ruby / Rails-Ökosystem viel weniger vertraut. Ich hatte vielleicht insgesamt 30 Stunden damit verbracht, Ruby zu lernen, bevor ich zur Firma kam, da ich wusste, dass es Teil ihres Stacks war, aber ich hatte Rails kaum berührt. Außerdem war die Aufgabe mit ein wenig Arbeit mit Docker verbunden, was auch für mich neu war.

Mein technischer Leiter brachte mich dazu, mit einer einstündigen Einführung in Docker zu beginnen, die äußerst nützlich war. Von dort aus habe ich den größten Teil des Tages damit verbracht, eine neue Rails-App zu erstellen und verschiedenen Artikeln, Dokumenten und Beispielen zu folgen, um zu sehen, ob ich das Ding auf ECS zum Laufen bringen kann. Ich wäre fast dort angekommen, aber die Datenbankintegration zum Laufen zu bringen, erwies sich als Stolperstein. Es gab einfach so viel Neues.

Ich bin sicher, jemand, der mit ECS oder Rails besser vertraut ist, hätte nicht so viele Probleme gehabt. Ich konnte nicht sagen, dass der Prozess objektiv schwierig war. Es war schwer für mich , aber das bedeutete nicht, dass es für alle schwer war.

Kein äußerst produktiver Tag in Bezug auf nutzbaren Code oder Ausgabe, aber ich hatte das Gefühl, viel gelernt zu haben und aus dieser Perspektive heraus, und es war großartig.

Tag 4: Pairing und Mentoring

Ich kam um 8 Uhr morgens im Büro an und während ich auf die Ankunft anderer wartete, folgte ich einem Teil eines Docker-Kurses, den ich bei Pluralsight gesehen hatte. Ich war immer noch daran interessiert, den Spike von gestern zu beenden, erkannte jedoch, dass ich mehr Grundkenntnisse in mindestens einer der neuen Technologien brauchte, mit denen ich arbeitete.

Ich verbrachte ungefähr eine Stunde auf dem Kurs, bevor mehr Leute im Büro ankamen und wir uns daran machten zu entscheiden, wer was tun würde. Ein anderer neuer Entwickler, der kurz vor mir angefangen hatte, war gerade aus dem Urlaub zurückgekommen. Wir beschlossen, uns zu einer Aufgabe zusammenzuschließen. Wir haben eine neue Funktion in der Rails-App erstellt. Dies war eine recht einfache Aufgabe, aber Rails war für uns beide neu und es war großartig, sie gemeinsam durchzuarbeiten. Wenn wir etwas Erklärtes brauchten, fragten wir einfach einen der anderen Entwickler, entweder persönlich oder auf Slack. Auf diese Weise hatten wir einige großartige Diskussionen und ich fing an zu verstehen, wie Rails funktioniert.

Am Nachmittag hatte ich eine Mentoring-Sitzung mit dem technischen Leiter, die großzügig war, da ich bereits am Tag zuvor eine private Docker-Klasse erhalten hatte! Mentoring ist eine Gelegenheit, Fragen zu stellen, gemeinsam Probleme zu lösen, gemeinsam etwas zu lernen oder einfach nur das Gehirn eines Menschen auszuwählen. Der Wissenstransfer ist sehr vorteilhaft.

Ich hatte viele seltsame Fragen zu Datenbankmaterial und Rails, aber ich bedauere, dass ich für diese erste Sitzung kein einziges Ziel hatte. Ich war mir einfach nicht sicher, was mich erwarten würde. In den folgenden Sitzungen habe ich meinen Mentor gebeten, mir zu zeigen, wie man etwas Bestimmtes wie die Konfiguration eines NGINX-Servers oder die Konfiguration einer EC2-Instanz für den Zugriff auf eine Datenbank ausführt - Dinge, die er bereits wusste, die ich jedoch viel länger in Anspruch nehmen würde alleine raus.

Tag 5: Treffen und Zusammenschlüsse

Viele Softwareteams verwenden Kombinationen aus Stand-up-Meetings (häufig täglich), regelmäßigen Rückblicken (über Arbeitspraktiken oder technische Probleme) und Planungssitzungen, um ihren Workflow auf hohem Niveau zu organisieren, in Kombination mit einer Art Tracking-Tool, in dem die Arbeit stattfindet Fortschritt und noch zu erledigende Arbeit können visualisiert werden.

Unser Team ist nicht anders und wir haben die meisten unserer geplanten Treffen an einem Freitag. Wie bei vielen Teams liegt der Schwerpunkt bei unseren Besprechungen darauf, darüber nachzudenken, wie wir gearbeitet haben und was wir erreicht haben, Probleme oder Blockaden gemeinsam zu lösen und bevorstehende Arbeiten zu identifizieren und zu planen, damit wir immer etwas vor uns haben uns bereit, weiter zu gehen.

Wir gehen auch zum Frühstück, um uns zu verbinden, was großartig ist!

Alles in allem wurde der größte Teil des Vormittags für diese Aktivitäten aufgewendet. Ich hatte wenig beizutragen, da ich mich immer noch mit der Terminologie und der Struktur des Produkts beschäftigte, und ich war immer über einen Satz im Rückstand und versuchte, das gerade Gesagte nachzuholen. Ich erinnere mich, dass ich in dieser ersten Woche das Gefühl hatte, mein Gehirn würde schmelzen, als ich versuchte, all die verschiedenen Komponenten der Architektur in meinem Kopf zusammenzuhalten (es wird mit der Zeit besser, also mach dir keine Sorgen!).

Am Nachmittag konnten mein Paar und ich das beenden, woran wir gearbeitet hatten, eine Codeüberprüfung anfordern, Änderungen vornehmen und eine Anfrage zum Zusammenführen unserer Arbeit in der App öffnen. Wir haben nicht eingesetzt, da es ein Freitagnachmittag war, aber wir haben es am folgenden Montag getan. ?

Vielen Dank fürs Lesen. Ich hoffe, dieser Artikel hat Ihnen eine Vorstellung davon gegeben, wie Ihre erste Woche als Entwickler aussehen könnte.

Ich würde gerne Ihre Kommentare und Erfahrungen hören!