Jednom kada napokon dobiju željeni posao pri startup-u, Google-u, Amazon-u ili nekoj drugoj korporaciji, mogli bi shvatiti da vještine koje su koristili za dobijanje posla ne odgovaraju onima koje im trebaju u svakodnevnom poslu.
Naš tim bio je inspirisan sa sedam vještina vrlo učinkovitih programera koje je sastavio TechLead. Željeli smo da se sami pozabavimo tom temom.
Evo naših sedam vještina efikasnih programera.
- Naučite kako čitati kod drugih ljudi
Zato je jedna od velikih vještina koja ima višestruke prednosti mogućnost praćenja koda drugih ljudi.Svi osim vas imaju užasan kod.
Bez obzira na to koliko je neuredan ili loše osmišljen kod prethodnog inženjera, i dalje morate biti u mogućnosti da ga prođete. Na kraju krajeva, to je vaš posao. Čak i da je taj inženjer godinu dana ispred vas.
Ova vještina vam koristi na dva načina. Prvo, biti u stanju čitati kod drugih ljudi velika je šansa da naučite šta je loš dizajn. Dok pregledavate kod drugih ljudi, učite šta funkcioniše, a šta ne. Ono što je još važnije je da naučite kakav je kod lak za drugog inženjera i kakav je kod teško slijediti.
Trebate biti sigurni da razumijete što je više moguće dok čitate kod drugih ljudi. Na taj način drugi inženjeri razumiju koliko ste vrhunski inženjer.
Obavezno iznesite bodove o važnosti održivog koda i dobrih komentara. To dalje pokazuje vašu dominaciju u području programiranja.
Vaš kod treba biti tako dobro osmišljen da ne zahtijeva nikakvu dokumentaciju. Ustvari, ne biste trebali dokumentirati nijedan kod ako ste dobar programer. Ovo je samo gubljenje vremena i trebate trošiti vrijeme na kodiranje i sastanke.
Mogućnost čitanja neurednog koda drugih ljudi također olakšava ažuriranje po potrebi. To povremeno znači ažuriranje koda za koji vam nedostaje iskustvo. Na primjer; jednom smo pratili skriptu od Powershell-a do Python-a do Perla. Imali smo ograničeno iskustvo u Perlu, ali ipak smo imali dovoljno konteksta da shvatimo šta se događa i izvršimo potrebne promjene.
To dolazi iz pristojnog razumijevanja čitavog koda, kao i mogućnosti čitanja skripti Perl.
Čitanje tuđeg koda čini vam se dragocjenim jer možete slijediti čak i prekomjerne sisteme koji bi mogli omamiti druge.
- Smisao za loše projekte
Mnogo je vještina za koje treba vremena da se nauče. Jedna od vještina za koju vjerujemo da vrijedi znati je razumijevanje koji se projekti ne isplati raditi i koji su projekti očito koraci ka smrti.
U velikim kompanijama uvijek je mnogo više projekata nego što će to vjerovatno ikada biti dovršeno ili uticajno. Postoje neki projekti koji možda nemaju nikakvog poslovnog smisla (barem ne vama), a postoje i drugi kojim se jednostavno loše upravlja. Ovo ne znači da biste trebali oduzeti neku ideju upravo kada se ne slažete sa projektom. Međutim, ako zainteresovane strane ne mogu pravilno objasniti šta će raditi s krajnjim rezultatom, možda projekt ne vrijedi raditi.
Također, neki bi projekti mogli biti toliko fokusirani na tehnologiju, umjesto na rješenje da bi od početka moglo biti jasno da neće biti mnogo uticaja. Ova vještina zahtijeva mnogo loših projekata prije nego što dobijete ideju o tome šta je zaista loš projekt. Dakle, ne trošite previše vremena rano pokušavajući da razaznate svaki projekat.
U nekom trenutku karijere imat ćete samo dobar osjećaj.
3.Izbjegavanje sastanaka
Bez obzira jeste li softverski inženjer ili se bavite podacima, sastanci su nužnost jer morate biti u mogućnosti doći na istu stranicu sa svojim voditeljima projekata, krajnjim korisnicima i klijentima. Međutim, postoji i tendencija da sastanci odjednom preuzmu cijeli vaš raspored. Zbog toga je važno naučiti kako izbjeći nepotrebne sastanke. Možda je bolja riječ koju treba upotrijebiti upravljanje umjesto izbjegavanje. Cilj je ovdje osigurati da provodite svoje vrijeme na sastancima koji utječu na odluke i pomažu vašem timu da napreduje.
Najčešća metoda je jednostavno blokiranje dvosatnog bloka svaki dan koji je stalan sastanak. Obično većina ljudi uspostavlja ponavljajući sastanak u vrijeme koje im se čini korisnim. Iskoristiće to kao vrijeme za nadoknadu na njihovom razvojnom radu.
Drugi način da izbjegnete sastanke kako biste mogli obaviti posao jest da se pojavite prije bilo koga drugog. Osobno se volimo pojaviti rano jer je općenito ured mirniji. Većina ljudi koji se pojave rano su poput vas, samo žele obaviti posao tako da ih niko ne ometa.
Ovo je važno za pojedine saradnike jer naš rad zahtijeva trenutke u kojima smo fokusirani i ne razgovaramo sa drugim ljudima. Da, postoje slučajevi za koje možete rješavati probleme gdje možda želite raditi sa drugim ljudima. Ali kad jednom prevaziđete probleme sa blokiranjem, jednostavno je – treba da kodirate. Radi se o tome da uđete u onu zonu u kojoj stalno u glavi držite puno složenih ideja o poslu koji obavljate. Ako ste neprestano zaustavljeni, teško je ponovo početi tamo gdje ste stali.
- Github… Čekaj ne Git?
Neki CS majori počeli su koristiti Git onog dana kada su se rodili. Oni razumiju svaku naredbu i parametar i mogu voditi krugove oko profesionalaca.
Drugi ipak već na prvom poslu dobijaju ukus Gita. Za njih je Git pakleni krajolik zbunjujućih naredbi i procesa. Nikad nisu 100% sigurni u ono što rade (postoji razlog zašto su cheat sheetovi popularni).
Bez obzira koji sistem skladišta koristi vaša kompanija, sistem je koristan ako ga pravilno koristite i prepreka ako se koristi nepropisno. Ne treba puno da se jednostavno guranje ili obaveza pretvara u vas koji trošite sate pokušavajući odmotati poneku branu sa više grana i viljuški. Osim toga, ako stalno zaboravljate da izvučete najnoviju verziju spremišta, suočiti ćete se sa sukobima spajanja koji nikada nisu zabavni.
Ako trebate da zadržite cheat sheet Git naredbi, tada to učinite. Što god vam život čini jednostavnijim.
- Pisanje jednostavnog održivog koda
Jedna od tendencija mlađih inženjera je da pokušavaju implementirati sve što znaju u jedno rješenje. Postoji ta želja da shvatite objektno orijentisano programiranje, strukture podataka, obrasce dizajna i nove tehnologije i iskoristite sve to u svakom bitnom kodu koji napišete. Stvarate nepotrebnu složenost jer je tako jednostavno biti pretjerano vezan za rješenje ili obrazac dizajna koji ste koristili u prošlosti.
Postoji ravnoteža sa složenim dizajnerskim konceptima i jednostavnim kodom. Oblici dizajna i objektno orijentirani dizajn trebali bi pojednostaviti kod u velikoj šemi stvari. Međutim, što je više procesa abstraktno, kapsulirano i ucrtano, to je teže uklanjanje pogrešaka.
- Naučite reći ne i odredite prioritete
To vrijedi za stvarno bilo koju ulogu, bilo da ste financijski analitičar ili softverski inženjer. Ali naročito se čini da u tehničkim ulogama svako treba nešto od vas. Ako ste inženjer koji radi s podacima, vjerovatno će se od vas tražiti da napravite više od pukog razvoja. Nekim timovima će trebati izvlačenja podataka, drugima će trebati nadzorne ploče, a nekim će trebati novi cjevovodi za njihove naučnike podataka.
Sada, postavljanje prioriteta i govorenje „ne“ mogu zaista biti dvije različite vještine, ali one su usko povezane. Prioritetno značenje znači da trošite samo vrijeme koje ima visoki uticaj na kompaniju. Dok reći „ne“ ponekad znači samo izbjegavanje rada s kojim bi se trebao baviti drugi tim. Često se to dešava u tandemu za sve uloge.
Ovo može biti teška vještina jer je primamljivo preuzeti svaki vaš izazov. Pogotovo ako ste tek završili sa univerzitetom. Želite izbjeći da razočarate bilo koga i uvijek vam je osigurana dohvatna količina posla.
U velikim kompanijama uvek je beskonačna količina posla. Ključno je samo prihvaćanje onoga što se može učiniti.
Postoji puno vještina koje se ne testiraju u intervijuima ili čak uvijek podučavaju na fakultetima. Često je to više ograničenje okruženja nego nedostatak želje da se studenti izlože problemima koji postoje u stvarnim razvojnim okruženjima.
- Razmišljanje o operativnom dizajnu
Jedna vještina koju je teško testirati u interviju i teško je ponoviti kada pohađate kurseve na fakultetu je razmišljanje o tome kako krajnji korisnik može pogrešno koristiti vaš softver. Obično to nazivamo razmišljanjem kroz operativne scenarije.
Međutim, ovo je samo pristojan način da kažete da pokušavate lažno dokazati kod.
Na primjer; s obzirom da je velik dio programa održavanje, to često znači promjenu koda koji je u velikoj mjeri uklopljen s drugim kodom. Čak i jednostavna izmjena zahtijeva praćenje svake moguće reference objekta, metode i/ili API-ja. U suprotnom, može biti jednostavno slučajno probiti module za koje ne znate da su povezani, pa čak i ako samo mijenjate vrstu podataka u bazi.
Također, uključuje razmišljanje kroz rubne slučajeve i razmišljanje kroz cjelokupni dizajn na visokom nivou prije nego što se uđe u razvoj.
Što se tiče složenijih slučajeva kada razvijate nove module ili mikroservise, važno je izdvojiti svoje vrijeme i razmisliti o operativnim scenarijima onoga što grade. Razmislite o tome kako će možda budući korisnici morati koristiti vaš novi modul, kako ga oni mogu pogrešno koristiti, koji bi parametri mogli biti potrebni, te postoje li različiti načini kako će budući programer možda trebati vaš kod.
Jednostavno kodiranje i programiranje samo su dio problema. Lako je stvoriti softver koji dobro funkcioniše na vašem računaru. Ali postoji puno načina na koji kod može krenuti po zlu. Jednom kada ste u proizvodnji, teško je reći kako će se kod koristiti i koji će drugi kod biti povezan s vašim originalnim kodom. Za pet godina, budući programer može postati frustriran zbog ograničenja vašeg koda.
Originalan članak možete pročitati na linku.
