Hvad du kan forvente i din første uge som softwareudvikler

Du ved, du nyder at kode, men hvordan er det at gøre det til et job? Hvad kan du forvente i din første uge?

Jeg kunne ikke forestille mig min første uge i et nyt job. Begynder du at kode med det samme? Hvad hvis de bruger et sprog / en ramme, du ikke har lært? Hvordan får du fart på kodebasen og ved, hvad prioriteterne er? Er det let at placere holdet i holdet? Åbner du bare ... din editor og begynder at kode? Hvad hvis du får noget forfærdeligt galt og bryder alt?

Jeg arbejdede i 2 år på et kodende bootcamp, og jeg hørte lignende spørgsmål fra mange studerende. De vidste, at de kunne lide kodning og elskede, hvad de lavede på bootcampen dagligt - men de ønskede at vide, hvordan det føles at gå ind i et rigtigt job.

I dette indlæg bruger jeg eksempler på, hvad jeg gjorde i de første par dage i min seneste rolle for at prøve at give dig en idé om, hvad du kunne forvente.

Baggrund

Jeg arbejder som en fuld stack-udvikler i et lille firma. Der er fire udviklere i teknikerteamet (inklusive mig) og en CTO. Vi arbejder også tæt sammen med en produktejer, der er en af ​​grundlæggerne. Jeg gik ind med et par års kodningserfaring.

Alle tjenester er på AWS, og vi bruger NodeJS og Ruby.

Dag 1: For det meste opsætning

Jeg ankom til kontoret kl. 9. En skinnende ny MacBook Pro ventede på mig på mit skrivebord, komplet med adaptere og to skærme. Dev-teamet tog mig ud til morgenmad på en nærliggende cafe, og da vi kom tilbage, satte jeg mig ned og begyndte at få min maskine sat op.

Da jeg tidligere har oprettet utallige dev-miljøer, mens jeg arbejdede på et kodende bootcamp, var dette ret ligetil og tog mig ikke lang tid. Imidlertid havde jeg kun oprettet et Ruby / Rails-miljø på min egen bærbare computer en gang, så den del tog mig lidt længere tid.

Jeg fik et A4-ark med krav, versionsnumre osv., Som jeg sørgede for at følge nøje. Jeg fik også adgang til forskellige websteder som BitBucket, en adgangskodeadministrator, AWS og Gitlab og opsatte mine SSH-nøgler på min nye maskine.

Før frokost tog jeg en snak med CTO, og vi talte detaljeret om produktet, arkitekturen og de mål og prioriteringer, som teamet har i overskuelig fremtid.

Efter frokost klonede jeg ned nogle af de tjenester, der udgør applikationen, og begyndte at gøre mig bekendt med kodebasen. Heldigvis for mig kom jeg ind i teamet på et tidspunkt, hvor der var nogle nye, friske dele af tjenesten under udvikling, hvilket betyder, at jeg ikke havde for meget kode til at komme op i hastighed med.

I de sidste par timer af dagen sad jeg med en af ​​seniorudviklerne, mens han implementerede en funktion. Vi brugte det som en mulighed for ham til at guide mig gennem den del af appen og forklare, hvorfor ting var blevet gjort på bestemte måder, de dele, der havde forårsaget problemer, og de aspekter, der måske ender med at ændre sig i fremtiden.

Dag 2: Test

Jeg fik opgaven med at teste et par funktioner i et af repos til appen. At give nye ansættelser til at skrive er en fantastisk måde at introducere dem til en kodebase og gøre dem bekendt med noget af programmets logik.

Jeg brugte en god del tid på bare at læse koden, finde ud af, hvordan det hele fungerede sammen, og se om jeg kunne følge strømmen af ​​logikken. Jeg var interesseret i de konventioner, holdet havde valgt, den måde, koden var blevet opdelt på, og de stilistiske valg. At skrive testene var ikke svært, men jeg er altid meget forsigtig med at sætte mit første mærke på en kodebase, jeg ikke har arbejdet med før!

Jeg ville ikke have, at mit arbejde stak ud, så jeg forsøgte at observere og absorbere den kodestil, der i øjeblikket blev brugt. I en vis grad hjælper god praksis som fnægt meget, men der er også bare generelle arkitektoniske og stilistiske valg, som fnug ikke kan hjælpe dig med.

En lille udfordring, jeg havde, var at vænne mig til den Git-arbejdsgang, som teamet brugte. Hvert hold har deres egen måde at gøre tingene på: nogle hold fusionerer, nogle hold rebase, nogle hold squash forpligter sig, andre ikke, nogle følger populære arbejdsgange som denne, og andre tvinger bare push til master willy nilly. Derudover er der konventionerne i kommitteringsbeskeden og beskrivelsen for at få ret, gennemgangsprocessen osv.

Alt i alt er der en masse ikke-eksplicitte ting “sådan gør vi ting” ting at hente. Efter at have gennemgået processen et par gange, rettet mine fejl og stillet spørgsmål, er det nu anden natur.

Hele tiden skrev jeg noter i en notesbog og opbevar kodestykker i en applikation kaldet Bear. Der var så meget at tage i - hvordan man gør ting, de foretrukne procedurer for holdet, ting jeg ikke havde gjort før, og nye sprog og rammer at lære.

Jeg havde brug for at være virkelig aktiv i at bemærke, hvad jeg lærte. Jeg gjorde det til et punkt i slutningen eller begyndelsen af ​​hver dag at gennemgå mine noter, tilføje ekstra forklaringer på ting, jeg havde skrevet i en fart, og undersøge ting, som jeg ikke helt forstod. Alt dette tog også noget tid.

Dag 3: Spiking AWS

Som en del af den igangværende frigivelse var vi nødt til at beslutte, hvordan vi skulle implementere en service, vi byggede. Vi brugte AWS, men der var et valg mellem at bruge en EC2-forekomst, som ville være det enkleste valg, da det bare er en server i skyen, der kører din applikation, eller noget lidt mere avanceret som Elastic Container Service. Fordelen ved ECS er, at den styrer skaleringen af ​​flere EC2-forekomster og derfor er en god mulighed for fremtiden. Men det var ikke helt vigtigt for tiden.

I betragtning af dette fik jeg (meldte mig frivilligt) opgaven med at finde ud af, hvor let det ville være at implementere vores service på ECS. Spiking betyder bare at prøve noget for at undersøge gennemførligheden. Hvis det skulle være svært, var det ikke det værd, da det var en fremtidig optimering, havde vi ikke desperat brug for det lige nu.

Dette involverede en masse læring for mig, da jeg ikke havde brugt Amazons ECS før, plus appen var en Rails-app, og jeg var meget mindre fortrolig med hele Ruby / Rails-økosystemet. Jeg havde brugt i alt 30 timer på at lære Ruby, inden jeg kom til virksomheden, da jeg vidste, at det var en del af deres stack, men jeg havde næppe rørt Rails. Plus, opgaven involverede lidt arbejde med Docker, hvilket også var nyt for mig.

Min tekniske føring fik mig til at starte med, hvad der dybest set var en 1 times introduktion til Docker, hvilket var enormt nyttigt. Derefter brugte jeg det meste af dagen på at oprette en ny Rails-app og følge forskellige artikler, dokumenter og eksempler for at se, om jeg kunne få tingene til at køre på ECS. Jeg kom næsten derhen, men det var en anstødssten at få databaseintegrationen til at fungere. Der var bare så mange nye ting.

Jeg er sikker på, at en person, der er mere fortrolig med enten ECS eller Rails, ikke ville have haft så mange problemer. Jeg kunne ikke komme væk og sige, at processen var objektivt hård. Det var svært for mig , men det betød ikke, at det var svært for alle.

Ikke en meget produktiv dag med hensyn til brugbar kode eller output, men jeg følte, at jeg lærte meget og set fra dette perspektiv, og det var fantastisk.

Dag 4: Parring og mentoring

Jeg ankom på kontoret klokken 8, og mens jeg ventede på, at andre ankom, fulgte jeg en del af et Docker-kursus, som jeg havde set på Pluralsight. Jeg var stadig ivrig efter at afslutte spidsen fra i går, men erkendte, at jeg havde brug for mere jordforbindelse i mindst en af ​​de nye teknologier, som jeg arbejdede med.

Jeg tilbragte cirka en time på kurset, inden flere mennesker ankom til kontoret, og vi besluttede, hvem der ville gøre hvad. En anden ny udvikler, der var startet lidt før mig, var lige kommet tilbage fra ferien. Vi besluttede, at vi skulle parre sammen om en opgave. Vi byggede en ny funktion i Rails-appen. Dette var en ganske simpel opgave, men Rails var nyt for os begge, så det var dejligt at arbejde igennem det sammen. Når vi havde brug for noget forklaret, ville vi bare spørge en af ​​de andre devs, enten personligt eller på Slack. Vi havde nogle gode diskussioner på denne måde, og jeg begyndte at få fat på, hvordan Rails fungerer.

Om eftermiddagen havde jeg en mentorsession med den tekniske ledelse, som var generøs, da jeg allerede havde en privat Docker-klasse dagen før! Mentoring er en mulighed for at tage spørgsmål, løbe igennem problemer sammen, lære noget sammen eller bare vælge nogens hjerne. Videnoverførslen er meget gavnlig.

Jeg havde mange ulige spørgsmål om databaseartikler og Rails, men jeg fortryder ikke at have et enkelt mål til den første session. Jeg var vel ikke sikker på, hvad jeg kunne forvente. I efterfølgende sessioner har jeg bedt min mentor om at vise mig, hvordan jeg gør noget specifikt som at konfigurere en NGINX-server eller konfigurere en EC2-forekomst til at få adgang til en database - ting, som han allerede ville vide, men det ville tage mig meget længere tid at finde ud af ud alene.

Dag 5: Møder og fusioner

Mange softwareteams bruger kombinationer af stand-up-møder (ofte dagligt), regelmæssige retrospektiver (om arbejdsmetoder eller tekniske problemer) og planlægningssessioner til at organisere deres arbejdsgang på et højt niveau i kombination med en slags sporingsværktøj, hvor arbejdet i fremskridt og arbejde, der er tilbage at gøre, kan visualiseres.

Vores team er ikke anderledes, og vi har størstedelen af ​​vores planlagte møder på en fredag. Som mange hold er vægten under vores møder at reflektere over, hvordan vi har arbejdet, og hvad vi har opnået, kollektivt løse eventuelle problemer eller blokke og identificere og planlægge kommende arbejde, så vi altid har noget foran os klar til at gå videre til.

Vi går også ud til morgenmad for at binde, hvilket er fantastisk!

Alt i alt blev det meste af morgenen brugt på disse aktiviteter. Jeg havde ikke meget at bidrage med, da jeg stadig fik hovedet omkring al terminologi og produktets struktur, og jeg var altid omkring en sætning bagved og forsøgte at indhente det, der lige var blevet sagt. Jeg husker, at jeg i løbet af den første uge bare følte, at min hjerne smeltede, da jeg prøvede at holde alle de forskellige komponenter i arkitekturen sammen i mit sind (det bliver bedre efterhånden som tiden skrider frem, så rolig!).

Om eftermiddagen var mit par og jeg i stand til at afslutte det, vi havde arbejdet med, anmode om en kodegennemgang, foretage ændringer og åbne en anmodning om at fusionere vores arbejde i appen. Vi indsatte ikke, da det var en fredag ​​eftermiddag, men det gjorde vi den følgende mandag. ?

Tak for læsningen, jeg håber, at denne artikel gav dig en idé om, hvordan din første uge som udvikler kan se ud.

Jeg vil meget gerne høre dine kommentarer og oplevelser!