Her er hvad jeg har lært ni måneder i mit software engineering job

Jeg har arbejdet i cirka ni måneder hos Dexter som softwareudvikler. Jeg skrev et blogindlæg om oprindeligt landing af jobbet samt et teknisk indlæg om en selvpositioneringskomponent, jeg lavede i mine første par måneder hos virksomheden. At få et job var mit oprindelige mål, og det var det næste skridt fremad at holde det og vokse som udvikler.

Mine tanker om min rolle har ændret sig betydeligt siden jeg startede. Jeg troede, at det at være en udvikler drejede sig om at få kode ud så hurtigt som muligt. Det er den længste ting fra virkeligheden. Det er ikke en skalerbar måde at opbygge en forretning eller en karriere i udvikling på, når man slår meget skidt kode ud. Heldigvis fandt jeg en arbejdsgiver, der følte det på samme måde, og hvis produkt er software.

Målet er at skrive den rigtige mængde god kode og kommunikere godt. Du betaler ikke for at kode, du betales for at tænke og finde ud af problemer. Biproduktet er krystalliseret tanke og instruktion til en maskine at følge i form af kode. Jeg vil hellere løse et problem i en linje med tydelig læsbar kode end 10 linjer kode, der er vanskelige at forstå. Jeg vil hellere løse et problem i 5 linjer med læsbar kommenteret kode end en linje med meget kompleks, multi-nestet kode med flere ternære operatører. Du får ideen.

Stil mange spørgsmål, og dokumenter svarene

Min chef sendte mig dette link, der indkapslede en masse stress og angst, jeg føler som ny ingeniør. Det er en underdrivelse at sige, at jeg er meget selvbevidst om at stille spørgsmål.

Jeg bruger denne tjekliste, før jeg beder andre om hjælp:

  • Er dette et spørgsmål, jeg har stillet før, og i bekræftende fald, hvor dokumenterede jeg svaret?
  • Er det noget, jeg kunne Google?
  • Er dette dokumenteret et sted internt af en anden?
  • Hvad sker der her? Hvad er årsagen til den fejl eller uventede adfærd, jeg oplever?
  • Forstår jeg virkelig det spørgsmål, jeg prøver at besvare? Det er okay at tage noget tid og læse problemet igen i stedet for at give et halvt røv eller forhastet svar.

Efter at have fulgt disse trin løser jeg problemet alene, finder en dokumenteret løsning eller stiller et spørgsmål med meget bedre sammenhæng og detaljer, der gør det lettere for en anden at hjælpe mig. Endnu bedre, hvis jeg stiller et godt spørgsmål, og det kan besvares via chat, behøver min holdkammerat ikke slippe alt for at hjælpe mig.

Hvis jeg har gået 90% af vejen mod at løse problemet og bare har brug for de sidste 10% hjælp, vil en seniorudvikler være glad for at hjælpe med at vide, at jeg kom så langt jeg kunne alene. At lede efter en anden til at løse dine problemer er ikke en fantastisk måde at opbygge tillid inden for dit team.

Smarte mennesker kan lide gode spørgsmål - så spørg dem.

Undgå at lave de samme fejl og stille de samme spørgsmål igen og igen

Dette er lettere sagt end gjort og kan være sandt for ethvert job, ikke kun programmering. En masse nye koncepter og information kastes på din måde, og det er uundgåeligt at lave fejl. Vær opmærksom på det. Tænk inden du spørger. Google-ting. Se på dokumenterne. De er din ven. Hvis du ser en tendens, skal du prøve at identificere den. Lav en aktiv indsats for at fange dig selv og stille den samme type spørgsmål. Skriv det ned, og gør det til et mål at ordne det.

Sørg for, at du ved, hvad du skal gøre, næste gang du støder på det samme problem. Vi laver alle fejl, men det at være selvbevidst og gøre en indsats for at ændre er, hvordan alle bliver bedre.

Gennemgå altid dit arbejde

Ingen kan lide at gå gennem en PR og fortælle dig at fjerne din console.logs og debuggere eller bede dig om at rette fnugfejl. Jeg ville ikke offentliggøre dette indlæg uden at læse det et par gange og få en ven til at kigge også.

Se virkelig på din kode og spørg dig selv disse spørgsmål:

  • Jeg skrev et komplekst stykke logik. Er der lignende funktionalitet i applikationen, der måske gør det på en mere læselig, fleksibel eller generisk måde?
  • Hvis ikke, ville jeg huske, hvorfor jeg skrev denne kode om en uge? Hvis svaret er nej, vil jeg sandsynligvis ændre koden eller kommentere den. Den person, der gennemgår PR, skal have en vis kontekst i, hvorfor jeg tog denne beslutning.
  • Sørg for, at din kode passerer fnug og test, inden du giver den til andre.
  • Gentager jeg mig selv? Kan jeg indkapsle den logik, jeg gentager, til en funktion?
  • Hvis dette var en andens kode, som jeg gennemgik, hvilke kommentarer ville jeg fremsætte? Hvad vil jeg ændre for at gøre det mere ligetil?

Se på din kode med et nyt sæt øjne (måske den næste dag). Er der specifikke logiske blødninger i komponenter, der ikke burde være? Håndterer din komponent forretningslogik, der skal gå i en container?

Derudover sparer god selvkodeanmeldelse tid og penge for virksomheden. Det er langt billigere for dig at finde dine egne fejl og rette dem selv i stedet for at have en anden til at finde dem to dage senere.

Sidste ting ved at gennemgå din kode. Berør og klik på ALT, som du har arbejdet med. Jeg vil have, at koden, jeg sender til nogen, skal være super vanskelig at bryde. Hvis de klikker på en ny side og får en stor fejl eller en hvid dødsskærm, viser det, at jeg ikke rigtig har gennemgået mit arbejde. Grib dig efter den kode, du redigerede, og sørg virkelig for, at du ikke ødelagde noget andet med din tilføjelse til en delt komponent.

Det kan virke fjollet, men store kodebaser er komplekse, og du indser måske ikke, at du bryder noget, før du gør det.

Seriøst, du vil ikke se det første udkast til dette blogindlæg :)

Intet er magisk

Der er normalt en god grund til, hvorfor kode er blevet LGTM'et (godkendt og i kodebasen). Hvis du ikke forstår, hvordan det fungerer, skal du bruge lidt tid på at finde ud af det. Log ting, bryde ting, se på en vis dokumentation af funktioner og mønstre, der blev brugt.

Kunne du fortælle din gummiand, hvordan det fungerede? Hvis du stadig er usikker, kan du stille nogle spørgsmål om specifikke huller i din forståelse.

Få behagelig fejlretning, da du gør det meget

At debugge er at forstå det underliggende problem i funktionaliteten af ​​din kode og derefter løse fejlen. Du skal forstå, hvordan tingene fungerer for at finde ud af, hvorfor det ikke fungerer i første omgang. At være i stand til at bruge browserens fejlfindingsværktøjer vil gøre dit liv og job lettere. Fejlfindings- og konsolmetoderne er dine venner.

Nogle nyttige ressourcer, som jeg fandt:

  • CSS-tricks til fejlfinding
  • Front-End Masters Debugging (Det er betalt, men ret godt)

Pro-tip: console.log-output kan styliseres ved hjælp af CSS. Dette gør log, du vil se, lettere at identificere.

console.log('%c I want this to be big and red', 'font-size: 30px; color: red;');

Følg dataene

Dette kom op igen og igen, for ganske vist var det en fejl, jeg fortsatte med at lave. Det er noget, jeg blev bedre til, men stadig har brug for arbejde.

En stor del af softwareudvikling involverer manipulation af data til et format, så en bruger kan få handlingsmæssig indsigt fra det eller opdatere det på egen hånd.

Applikationer med en envejs datastrøm og en global tilstand har en direkte datalinje at følge. Alle disse data kommer fra et sted. Når du først har fundet ud af, hvor det kommer fra, er det lettere at debugge.

Isolér dine problemer, og integrer dem derefter i det, du arbejder på

Codepen.io er en nær ven af ​​mig, og det skal også være din. Når jeg ikke kan finde ud af, hvad der forårsager problemet, laver jeg en simpel version af det, jeg bygger. Jeg sørger for, at det fungerer, og integrerer det derefter i mit udviklingsmiljø. Det er lettere at finde ud af, hvad der muligvis bryder dit brugergrænseflade i et afskåret miljø.

Tænk over, hvordan funktionaliteten skal fungere

At skrive ned, hvordan noget skal fungere fra et 30.000 fods niveau og derefter fra et teknisk niveau, har hjulpet mig med at forstå, hvad jeg skal bygge, hvordan jeg skal bygge det og hjælper med at mindske fald i pit. Hvis jeg ikke kan forklare, hvordan det, jeg bygger, fungerer (fra et højt og lavt niveau), gør jeg mig selv en bjørnetjeneste. Uden en plan vil jeg lave en masse hjulspind i den nærmeste fremtid.

Derudover kan jeg henvise tilbage til det, jeg skrev, eller vise nogen, hvad jeg tænker, hvilket hjælper med at reducere fejlkommunikation.

Omfavn kampen

Efter 10.000 timers kæmper på arbejde bliver du bedre til at kæmpe igennem og løse problemer. Du bliver nødt til at gøre det uanset, så at nyde oplevelsen vil gøre din dag til dag meget, meget bedre. Grin lidt af dig selv, og prøv at virkelig nedbryde problemet. Du kommer derhen, selvom du har brug for lidt ekstra hjælp.

Tag konstruktiv kritik og gentag konstant den

Dine holdkammerater vil have dig til at gøre det bedre. Seniorudviklere vil gøre dig til en stærkere udvikler. Handle efter deres råd, selvom du ikke oprindeligt forstår, hvorfor de beder dig om at gøre det. Der er aldrig kun en person, der ved alt. Chat det op.

Tag dig god tid

Rush gennem dit arbejde forårsager frem og tilbage, masser af forvirring og yderligere frustration. Min chef vil hellere se bedre kode senere end dårlig kode hurtigere. Jeg mener, ville vi ikke alle?

Fortsæt med at lære uden for arbejdet

Så meget som jeg lærer om jobbet, vil jeg stadig fortsætte med at lære nye ting uden for bare at arbejde på vores kodebase. Det kan være at hente Python, bygge en bot, arbejde igennem en videoserie eller arbejde på et personligt projekt. Jeg lavede en tavle med Zenhub + Github for at spore, hvor jeg er, og hvad jeg har forpligtet mig til i måneden. At holde et generelt mål for måneden har tvunget mig til at fortsætte med at lære, opbygge og ja, blogge på min egen tid.