U gotovo svakoj industriji postoji neka vrsta mita o produktivnosti. U proizvodnji to je brzina mašina, u prodaji broj sastanaka, u sportu broj treninga. U svetu softvera taj mit često se svodi na brzinu pisanja koda.

Mladi programeri ponekad imaju osećaj da je najbolji developer onaj koji najbrže otvara editor, najbrže piše funkcije i najbrže završava zadatke. Na prvi pogled takav način rada deluje impresivno. Linije koda se gomilaju, zadaci se zatvaraju, projekat napreduje.

Ali posle nekoliko meseci rada na istom sistemu često se pojavljuje drugačija slika.

Kod koji je napisan brzo počinje da pokazuje svoje slabosti. Funkcionalnosti se sudaraju jedna sa drugom, promene postaju komplikovane, svaki novi deo sistema zahteva dodatne zakrpe. Ono što je na početku izgledalo kao brz napredak počinje da usporava čitav projekat.

Iskusni programeri vrlo brzo nauče jednu važnu lekciju. Produktivnost u programiranju retko ima veze sa brzinom pisanja koda.

Mnogo češće ona ima veze sa kvalitetom odluka koje se donose pre nego što kod uopšte počne da se piše.

Ako posmatrate rad iskusnog developera tokom jednog dana, primetićete zanimljiv obrazac. Veliki deo vremena ne provodi u editoru. Provodi ga razmišljajući. Čitajući postojeći kod. Praveći male dijagrame na papiru. Razgovarajući sa kolegama o mogućim pristupima.

Na prvi pogled takav rad može izgledati spor.

Ali u stvarnosti upravo tu nastaje najvažniji deo posla.

Softver je kompleksan sistem. Svaka nova funkcija ulazi u odnos sa postojećim delovima sistema. Ako struktura nije pažljivo osmišljena, kompleksnost počinje da raste eksponencijalno.

Zbog toga mnogi iskusni developeri imaju jednostavno pravilo. Ako rešenje izgleda komplikovano, verovatno još uvek nije pravo rešenje.

Jedan od najpoznatijih principa u softverskom inženjerstvu zove se jednostavnost. Ideja je veoma jednostavna, najbolje rešenje je često ono koje ima najmanje nepotrebnih delova.

U praksi to znači da developer pokušava da pronađe način da problem razbije na manje, jasnije celine. Umesto jedne ogromne funkcije nastaje nekoliko manjih. Umesto složenog sistema zavisnosti pojavljuje se jednostavnija struktura.

Takve odluke možda deluju male, ali njihov efekat je ogroman.

Kod koji je jednostavan mnogo je lakše razumeti. Lakše ga je testirati. Lakše ga je menjati. Kada novi član tima dođe na projekat, može brže da shvati kako sistem funkcioniše.

Zanimljivo je da mnogi programeri ovu lekciju nauče tek nakon što naprave nekoliko velikih grešaka. Napišu sistem koji je previše komplikovan, provedu mesece održavajući ga i tek tada shvate koliko je jednostavnost zapravo vredna.

Iskustvo menja način razmišljanja.

Umesto pitanja kako da napišem ovo što brže, pojavljuje se drugo pitanje. Kako da napišem ovo tako da ga razumem i za godinu dana.

Jer u svetu softvera vreme ima neobičnu osobinu. Kod koji napišete danas gotovo sigurno ćete ponovo sresti u budućnosti. Možda za nekoliko meseci, možda za nekoliko godina, ali velika je šansa da ćete ga opet otvoriti.

U tom trenutku brzina kojom je napisan više nije važna. Važno je koliko ga je lako razumeti.

Zato mnogi iskusni developeri imaju još jednu zanimljivu naviku. Oni često brišu kod.

To može zvučati čudno ljudima koji tek ulaze u profesiju. Pisanje koda izgleda kao stvaranje, a brisanje kao gubitak vremena. Međutim u realnosti brisanje je često znak napretka.

Kada developer pronađe jednostavnije rešenje, staro rešenje postaje nepotrebno. Sistem postaje čistiji, pregledniji i lakši za održavanje.

U tom smislu produktivnost u programiranju ponekad izgleda potpuno drugačije nego u drugim profesijama. Ona ne znači uraditi što više stvari. Ona znači uraditi samo ono što je zaista potrebno.

Ta filozofija ima zanimljiv efekat na dugoročne projekte. Timovi koji rade sporije na početku često završe brže na kraju.

Razlog je jednostavan. Dobar temelj štedi ogromnu količinu vremena kasnije.

Kada je arhitektura sistema jasna, nove funkcije se uklapaju prirodno. Kada je struktura loša, svaka nova promena postaje mali projekat za sebe.

Zbog toga mnogi senior developeri imaju gotovo instinktivnu potrebu da zastanu pre nego što počnu implementaciju. Oni pokušavaju da zamisle sistem kao celinu.

Kako će izgledati za šest meseci. Kako će izgledati kada se broj korisnika poveća. Kako će izgledati kada drugi developeri počnu da rade na istom kodu.

Takva pitanja nisu uvek jednostavna, ali ona često prave razliku između sistema koji funkcioniše kratko i sistema koji traje godinama.

Na kraju se dolazi do zanimljivog zaključka.

Produktivnost u programiranju nije brzina, ona je sposobnost da se pronađe jednostavno rešenje za složen problem.

A to je veština koja dolazi polako, kroz iskustvo, greške i mnogo razmišljanja.