Evo što sam naučio devet mjeseci u svom poslu softverskog inženjerstva

Otprilike devet mjeseci radim u Dexteru kao programer softvera. Napisao sam post na blogu o početku postavljanja posla, kao i tehnički post o komponenti za samopozicioniranje koji sam napravio u prvih par mjeseci u tvrtki. Zapošljavanje mi je bio početni cilj, a zadržavanje i rast kao programera bio je prirodni sljedeći korak naprijed.

Moje misli o mojoj ulozi značajno su se promijenile otkad sam započeo. Mislio sam da se kao programer treba brže otvoriti kôd. To je najudaljenije od stvarnosti. Brzo izbacivanje puno uskog koda nije skalabilan način za izgradnju posla ili razvojne karijere. Srećom, pronašao sam poslodavca koji se tako osjećao i čiji je proizvod softver.

Cilj je napisati pravu količinu dobrog koda i dobro komunicirati. Niste plaćeni za kodiranje, plaćeni ste za razmišljanje i otkrivanje problema. Nusproizvod je iskristalizirana misao i uputa za stroj koji slijedi u obliku koda. Radije bih problem riješio u jednom retku jasno čitljivog koda, nego u 10 redaka koda koji je teško razumljiv. Radije bih problem riješio u 5 redaka čitljivog komentiranog koda, nego u jednom retku vrlo složenog, više ugniježđenog koda s višestrukim ternarnim operatorima. Shvatili ste ideju.

Postavljajte puno pitanja i dokumentirajte odgovore

Šef mi je poslao ovu poveznicu koja je sadržala puno stresa i tjeskobe koje osjećam kao novi inženjer. Potcjenjivanje je reći da sam vrlo samosvjestan u postavljanju pitanja.

Koristim ovaj kontrolni popis prije nego što zatražim pomoć od drugih:

  • Je li ovo pitanje koje sam već postavljao, i ako je tako, gdje sam dokumentirao odgovor?
  • Je li to nešto što bih mogao Google-u?
  • Je li to netko interno dokumentirao?
  • Što se ovdje događa? Koji je osnovni uzrok pogreške ili neočekivanog ponašanja koje imam?
  • Razumijem li doista pitanje na koje pokušavam odgovoriti? U redu je odvojiti malo vremena i ponovno pročitati problem, a ne davati polovičan odgovor ili brzoplet odgovor.

Nakon što slijedim ove korake, problem rješavam samostalno, pronalazim dokumentirano rješenje ili postavljam pitanje s puno boljim kontekstom i detaljima što nekome drugome olakšava pomoć. Još bolje, ako postavim dobro pitanje i na njega se može odgovoriti putem chata, moj suigrač ne mora sve ispustiti da bi mi pomogao.

Ako sam otišao 90% puta prema rješavanju problema i trebam samo posljednjih 10% pomoći, stariji programer rado će pomoći znajući da sam sam stigao što dalje. Traženje nekoga drugog da riješi vaše probleme nije sjajan način za izgradnju povjerenja u vašem timu.

Pametni ljudi vole dobra pitanja - zato ih postavite.

Izbjegavajte ponavljati iste greške i postavljati ista pitanja iznova i iznova

To je lakše reći nego učiniti i moglo bi biti točno za bilo koji posao, ne samo za programiranje. Puno vam novih koncepata i informacija baca put, a pogreške su neizbježne. Budite svjesni toga. Razmislite prije nego što pitate. Google stvari. Pogledajte dokumente. Oni su ti prijatelji. Ako vidite trend, pokušajte ga prepoznati. Aktivno se potrudite uhvatiti se kako postavljate istu vrstu pitanja. Zapišite to i postavite si cilj da to popravite.

Svakako provjerite znate li sljedeći put kada naiđete na isti problem. Svi griješimo, ali biti svjestan sebe i truditi se promijeniti je kako svi postaju bolji.

Uvijek pregledajte svoj rad

Nitko ne voli prolaziti kroz PR i reći vam da uklonite svoje console.logs i programe za otklanjanje pogrešaka ili vam reći da popravite pogreške u povezivanju. Ne bih objavio ovaj post, a da ga nisam pročitao nekoliko puta, a da ga i prijatelj pogleda.

Zaista pogledajte svoj kod i postavite si sljedeća pitanja:

  • Napisao sam složenu logiku. Postoji li slična aplikacija u aplikaciji koja to možda čini na čitljiviji, fleksibilniji ili generički način?
  • Ako ne, bih li se sjetio zašto sam napisao ovaj kôd za tjedan dana? Ako je odgovor negativan, vjerojatno želim promijeniti kod ili ga komentirati. Osoba koja pregledava PR trebala bi imati određeni kontekst zašto sam donijela takvu odluku.
  • Provjerite je li vaš kôd prošao povezivanje i testove prije nego što ga date nekome drugome.
  • Ponavljam li se? Mogu li logiku koju ponavljam pretvoriti u funkciju?
  • Da je ovo tuđi kod koji sam pregledavao, koje bih komentare dao? Što bih želio promijeniti da bude jasnije?

Pogledajte svoj kod svježim očima (možda sljedeći dan). Postoji li specifična logička krvarenja u komponente koje ne bi trebale biti? Rukuje li vaša komponenta poslovnom logikom koja bi trebala ući u spremnik?

Uz to, dobar pregled vlastitog koda štedi vrijeme i novac za tvrtku. Puno vam je jeftinije pronaći vlastite greške i sami ih popraviti, a ne da ih netko drugi pronađe dva dana kasnije.

Zadnja stvar oko pregleda vašeg koda. Dodirnite i kliknite SVE na čemu ste radili. Želim da kod koji pošaljem bilo kome bude jako težak za razbijanje. Ako kliknu novu stranicu i dobiju veliku pogrešku ili bijeli zaslon smrti, to pokazuje da nisam stvarno pregledao svoj rad. Grep za kôd koji ste uredili i doista se pobrinite da niste dodali nešto zajedničkom komponentom.

Možda se čini glupo, ali velike baze koda su složene i možda nećete shvatiti da nešto slomite dok to ne učinite.

Ozbiljno, ne želite vidjeti prvi nacrt ovog posta na blogu :)

Ništa nije čarolija

Obično postoji dobar razlog zašto je kod dodijeljen LGTM (odobren i nalazi se u osnovi koda). Ako ne razumijete kako to funkcionira, provedite neko vrijeme smišljajući to. Zabilježite, razbijte stvari, pogledajte dokumentaciju o funkcijama i uzorcima koji su korišteni.

Možete li reći svojoj gumenoj patki kako je radila? Ako još uvijek niste sigurni, postavite nekoliko pitanja o određenim prazninama u vašem razumijevanju.

Udobno ispravite pogreške jer to puno radite

Otklanjanje pogrešaka znači razumijevanje osnovnog problema u funkcionalnosti vašeg koda, a zatim rješavanje greške. Morate razumjeti kako stvar funkcionira da biste shvatili zašto uopće ne radi. Mogućnost korištenja alata za otklanjanje pogrešaka preglednika olakšat će vam život i posao. Načini otklanjanja pogrešaka i konzole vaši su prijatelji.

Neki korisni resurs koji sam pronašao:

  • CSS trikovi o otklanjanju pogrešaka
  • Otklanjanje pogrešaka u Front-End Mastersu (plaća se, ali prilično dobro)

Pro-tip: output : console.log može se stilizirati pomoću CSS-a. To olakšava prepoznavanje dnevnika koji želite vidjeti.

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

Slijedite podatke

To se ponavljalo uvijek iznova, jer doduše to je bila pogreška koju sam neprestano činio. To je nešto u čemu sam se popravio, ali i dalje treba raditi.

Veliki dio razvoja softvera uključuje manipulaciju podacima u format tako da korisnik od njega može dobiti djelotvoran uvid ili ga samostalno ažurirati.

Aplikacije s jednosmjernim protokom podataka i globalnim stanjem imaju izravnu liniju podataka koje treba slijediti. Svi ti podaci dolaze odnekud. Jednom kada saznate odakle dolazi, lakše je otkloniti pogreške.

Izolirajte svoje probleme, a zatim ih integrirajte u ono na čemu radite

Codepen.io mi je blizak prijatelj, a trebao bi biti i vaš. Kad ne uspijem dokučiti što uzrokuje problem, napravim jednostavnu verziju onoga što gradim. Pazim da to funkcionira, a zatim ga integriram u svoje razvojno okruženje. Lakše je shvatiti što možda ruši vaše korisničko sučelje u ogoljenom okruženju.

Razmislite o tome kako bi funkcionalnost trebala raditi

Zapisivanje kako bi nešto trebalo funkcionirati s razine 30.000 ft, a zatim s tehničke razine pomoglo mi je da shvatim što bih trebao graditi, kako bih to trebao graditi i pomaže ublažiti padove jama. Ako ne mogu objasniti kako funkcionira stvar koju gradim (s visoke i niske razine), činim si medvjeđu uslugu. Bez plana ću se u vrlo bliskoj budućnosti puno okretati.

Uz to, mogu se vratiti na ono što sam napisao ili pokazati nekome što mislim što pomaže u smanjenju pogrešne komunikacije.

Prihvatite borbu

Nakon 10 000 sati muke na poslu, bit ćete puno bolji u rješavanju problema i rješavanju problema. Morat ćete to učiniti bez obzira na to, pa će vam uživanje u iskustvu svakodnevicu učiniti puno, puno boljom. Nasmijte se malo i pokušajte zaista razbiti problem. Doći ćete tamo, čak i ako vam zatreba malo dodatne pomoći.

Primite konstruktivnu kritiku i neprestano je ponavljajte

Vaši suigrači žele da vam ide bolje. Stariji programeri žele vas učiniti snažnijim programerom. Postupajte prema njihovim savjetima, čak i ako u početku ne razumijete zašto vam to govore. Nikad ne postoji samo jedna osoba koja sve zna. Razgovarajte.

Ne žurite

Jurkanje kroz posao uzrokuje naprijed-nazad, puno zbunjenosti i dodatne frustracije. Moj šef bi radije vidio bolji kod kasnije nego loši prije. Mislim, ne bismo li svi?

Nastavite učiti izvan posla

Koliko god učim na poslu, još uvijek želim učiti nove stvari, a ne samo raditi na našoj bazi koda. To bi moglo biti podizanje Pythona, izrada bota, rad kroz video seriju ili rad na osobnom projektu. Napravio sam ploču sa Zenhubom + Githubom kako bih pratio gdje sam i na što sam se obvezao za mjesec dana. Održavanje općeg cilja za ovaj mjesec prisililo me je da nastavim učiti, graditi i da, blogam u svoje vrijeme.