Znate da uživate u kodiranju, ali kako je to raditi za posao? Što biste mogli očekivati u prvom tjednu?
Nisam mogao zamisliti svoj prvi tjedan na novom poslu. Počinjete li odmah kodirati? Što ako koriste jezik / okvir koji niste naučili? Kako ubrzati rad s kodnom bazom i znati koji su prioriteti? Je li lako ući u tim? Želite li samo ... otvoriti svoj uređivač i početi kodirati? Što ako nešto grozno pogriješiš i sve pokvariš?
Radio sam dvije godine na bootcamp-u za kodiranje i čuo sam slična pitanja od mnogih učenika. Znali su da vole kodiranje i voljeli su ono što svakodnevno rade na bootcampu - ali željeli su znati kakav je osjećaj otići u pravi posao.
U ovom postu koristit ću primjere onoga što sam radio tijekom prvih nekoliko dana u svojoj najnovijoj ulozi kako bih vam pružio predodžbu o tome što biste mogli očekivati.
Pozadina
Radim kao programer cijelog steka u maloj tvrtki. U inženjerskom su timu četvorica programera (uključujući mene) i tehničkog direktora. Također blisko surađujemo s vlasnikom proizvoda koji je jedan od osnivača. Ušao sam s nekoliko godina iskustva u kodiranju.
Sve su usluge na AWS-u, a koristimo NodeJS i Ruby.
1. dan: Uglavnom postavljanje
U ured sam stigla u 9 sati. Na mom stolu čekao me sjajni novi MacBook Pro, u kompletu s adapterima i dva zaslona. Razvojni tim izveo me na doručak u obližnji kafić, a kad smo se vratili, sjeo sam i počeo postavljati svoj stroj.
Budući da sam ranije radio bezbroj razvojnih okruženja dok sam radio na bootcamp-u za kodiranje, ovo je bilo prilično jednostavno i nije mi trebalo dugo. Međutim, samo sam jednom na svom prijenosnom računalu postavio okruženje Ruby / Rails, tako da mi je taj dio trebao malo više vremena.
Dobio sam A4 list s popisom zahtjeva, brojevima verzija i tako dalje, koje sam pažljivo slijedio. Također sam dobio pristup raznim web mjestima kao što su BitBucket, upravitelj lozinki, AWS i Gitlab i postavio svoje SSH ključeve na svom novom stroju.
Prije ručka otišao sam na razgovor s tehničkim direktorom i detaljno smo razgovarali o proizvodu, arhitekturi i ciljevima i prioritetima koje razvojni tim ima u doglednoj budućnosti.
Nakon ručka klonirao sam neke usluge koje čine aplikaciju i počeo se upoznavati s bazom kodova. Na moju sreću, pridružio sam se timu u vrijeme kada su se razvijali neki novi, svježi dijelovi usluge, što znači da nisam imao previše koda za ubrzanje.
Posljednjih nekoliko sati u danu sjedio sam s jednim od starijih programera dok je on implementirao značajku. Koristili smo ga kao priliku da me vodi kroz taj dio aplikacije, objašnjavajući zašto su stvari učinjene na određene načine, dijelove koji su stvarali probleme i aspekte koji bi se mogli promijeniti u budućnosti.
2. dan: Testiranje
Dobio sam zadatak testirati nekoliko funkcija u jednom od repoa za aplikaciju. Davanje novih testova za pisanje izvrsan je način upoznavanja s bazom koda i upoznavanja s nekom logikom aplikacije.
Proveo sam prilično vremena samo čitajući kod, shvaćajući kako to sve skupa funkcionira i provjeravajući mogu li slijediti tok logike. Zanimali su me konvencije koje je tim odabrao, način podjele koda i stilski odabir. Pisanje testova nije bilo teško, ali uvijek sam vrlo oprezan i prvi put označavam kodnu bazu na kojoj prije nisam radio!
Nisam želio da moj rad strši, pa sam pokušao promatrati i upiti stil koda koji se trenutno koristio. Do neke mjere dobra praksa poput oblaganja puno pomaže, ali postoje i općeniti arhitektonski i stilski izbori u kojima vam oblaganje ne može pomoći.
Jedan mali izazov koji sam imao bio je navikavanje na Git tijek rada koji je tim koristio. Svaki tim ima svoj način rada: neki se timovi stapaju, neki se timovi prebacuju, neki timovi izvršavaju skvoš, a drugi ne, neki slijede popularne tijekove rada poput ovog, a drugi samo prisilno guraju u majstora, hoće li ne htjeti. Uz to postoje konvencije poruke i opisa urezivanja kako bi se ispravilo, postupak pregleda i tako dalje.
Sve u svemu, postoji mnogo neeksplicitnih stvari "ovako radimo" stvari koje treba pokupiti. Nakon što sam nekoliko puta prošao kroz postupak, ispravio svoje pogreške i postavio pitanja, sada je to druga priroda.
Cijelo sam vrijeme pisao bilješke u bilježnicu i čuvao isječke koda u aplikaciji nazvanoj Medvjed. Trebalo je uzeti toliko toga - kako raditi stvari, preferirane procedure za tim, stvari koje prije nisam radio i nove jezike i okvire za učenje.
Morao sam biti stvarno aktivan u bilježenju onoga što učim. Na kraju ili na početku svakog dana naglasio sam da pregledam svoje bilješke, dodam dodatna objašnjenja stvarima koje sam napisao u žurbi i istraživam stvari koje nisam potpuno razumio. Sve je to također potrajalo neko vrijeme.
3. dan: Spiking AWS
Kao dio izdanja koje smo imali u tijeku, trebali smo odlučiti kako rasporediti uslugu koju gradimo. Koristili smo AWS, ali postojao je izbor između upotrebe instance EC2, što bi bio najjednostavniji izbor, jer je to samo poslužitelj u oblaku koji pokreće vašu aplikaciju ili nešto pomalo zaljubljenije poput Elastic Container Service. Prednost ECS-a je u tome što bi upravljao skaliranjem višestrukih instanci EC2 i stoga bio dobra opcija za budućnost. Ali to zasad nije bilo potpuno bitno.
S obzirom na to, dobio sam (dobrovoljno prijavljen) zadatak da istaknem kako bi bilo lako rasporediti našu službu na ECS. Šiljanje samo znači isprobati nešto kako biste istražili izvedivost. Ako će to biti teško, nije vrijedilo, jer je to bila buduća optimizacija koja nam trenutno nije bila očajnički potrebna.
To je za mene uključivalo puno učenja, jer prije nisam koristio Amazonov ECS, plus aplikacija je bila aplikacija Rails i bio sam puno manje upoznat s cijelim ekosustavom Ruby / Rails. Proveo sam možda ukupno 30 sati učeći Rubyja prije nego što sam se pridružio tvrtki, jer sam znao da je to dio njihovog stoga, ali jedva sam dodirnuo Rails. Uz to, zadatak je uključivao malo rada s Dockerom, što je također za mene bilo novo.
Zbog tehničkog vodstva započeo sam s jednim jednosatnim uvođenjem u Docker, što je bilo izuzetno korisno. Odatle sam proveo veći dio dana stvarajući novu aplikaciju Rails i prateći razne članke, dokumente i primjere kako bih vidio mogu li pokrenuti stvar na ECS-u. Skoro sam stigao, ali postizanje integracije baze podataka pokazalo se kao kamen spoticanja. Bilo je baš toliko novih stvari.
Siguran sam da netko poznavatelj ECS-a ili Railsa ne bi imao toliko problema. Nisam mogao pobjeći rekavši da je proces objektivno težak. Bilo je teško za mene , ali to ne znači da je teško za svakoga.
Nije bio izuzetno produktivan dan u smislu upotrebljivog koda ili rezultata, ali osjećao sam se kao da sam puno naučio iz te perspektive i bilo je sjajno.
4. dan: Uparivanje i mentorstvo
U ured sam stigao u 8 sati ujutro i dok sam čekao da dođu drugi, slijedio sam dio Docker tečaja koji sam gledao na Pluralsightu. I dalje sam želio dovršiti skok od jučer, ali prepoznao sam da mi treba više uzemljenja u barem jednoj od novih tehnologija s kojima sam radio.
Proveo sam oko sat vremena na tečaju, prije nego što je više ljudi stiglo u ured i odlučili smo tko će što raditi. Još jedan novi programer, koji je započeo nešto prije mene, upravo se vratio s odmora. Odlučili smo da ćemo se spojiti na zadatku. Gradili smo novu značajku u aplikaciji Rails. Ovo je bio prilično jednostavan zadatak, ali Rails je za nas oboje bio nov, tako da je bilo sjajno raditi zajedno. Kad bi nam trebalo nešto objasniti, jednostavno bismo pitali nekoga od drugih programera, bilo osobno bilo na Slacku. Imali smo sjajne rasprave na ovaj način i počeo sam shvaćati kako funkcionira Rails.
Poslijepodne sam održao mentorsku sesiju s tehnološkim vodstvom, koja je bila izdašna jer sam već dan prije imao privatni tečaj Dockera! Mentorstvo je prilika da preuzimate pitanja, zajedno prolazite kroz probleme, naučite nešto zajedno ili jednostavno odaberete nečiji mozak. Prijenos znanja je vrlo koristan.
Imao sam puno neobičnih pitanja o stvarima iz baze podataka i Railsima, ali žalim što nisam imao niti jedan cilj za tu prvu sesiju. Pretpostavljam da jednostavno nisam bio siguran što očekivati. U sljedećim sesijama zamolio sam svog mentora da mi pokaže kako napraviti nešto specifično, poput konfiguriranja NGINX poslužitelja ili konfiguriranja EC2 instance za pristup bazi podataka - stvari koje bi on već znao, ali trebalo bi mi puno više vremena da shvatim sama.
5. dan: Sastanci i spajanja
Mnogi softverski timovi koristit će kombinacije stand-up sastanaka (često svakodnevnih), redovnih retrospektiva (o radnim praksama ili tehničkim problemima) i planiranja sesija kako bi svoj tijek rada organizirali na visokoj razini, u kombinaciji s nekom vrstom alata za praćenje gdje rad u može se vizualizirati napredak i preostali posao.
Naš se tim ne razlikuje, a većinu zakazanih sastanaka imamo u petak. Kao i mnogi timovi, i tijekom naših sastanaka naglasak je na promišljanju o tome kako smo radili i što smo postigli, zajedničkom rješavanju bilo kakvih problema ili blokova te prepoznavanju i planiranju predstojećeg rada, tako da uvijek imamo nešto ispred nas spremni za prelazak na.
Izlazimo i na doručak da se vežemo, što je strašno!
Sve u svemu, veći dio jutra proveo je na tim aktivnostima. Nisam imao što doprinijeti jer sam se još uvijek bavio cijelom terminologijom i strukturom proizvoda, i uvijek sam imao rečenicu iza, pokušavajući sustići upravo rečeno. Sjećam se da sam tijekom tog prvog tjedna samo osjećao da mi se mozak topi dok sam u mislima pokušavao držati sve različite dijelove arhitekture na okupu (s vremenom postaje sve bolje, zato ne brinite!).
Poslijepodne smo moj par i ja uspjeli dovršiti ono na čemu smo radili, zatražiti pregled koda, unijeti izmjene i dopune i otvoriti zahtjev za spajanje našeg rada u aplikaciju. Nismo se rasporedili jer je bio petak popodne, ali sljedeći ponedjeljak. ?
Hvala na čitanju, nadam se da vam je ovaj članak dao neku ideju o tome kako bi mogao izgledati vaš prvi tjedan kao programera.
Volio bih čuti vaše komentare i iskustva!