Ako pitate ljude koji nikada nisu radili u tehnološkom timu kako zamišljaju programere, verovatno ćete dobiti prilično sličan odgovor. Osoba koja sedi za računarom, sluša muziku na slušalicama, ne voli sastanke i najviše vremena provodi u komunikaciji sa tastaturom. To je stereotip koji se godinama ponavlja u filmovima, serijama i popularnoj kulturi.

U stvarnosti, međutim, najbolji developeri koje ćete upoznati često imaju osobinu koja na prvi pogled deluje potpuno suprotno tom stereotipu. Oni izuzetno pažljivo slušaju.

Na prvi pogled to možda ne deluje kao tehnička veština. Međutim, u svetu softvera ona je često presudna.

Razlog za to je jednostavan. Programiranje nije samo pisanje koda. Programiranje je zapravo rešavanje problema. A problem retko dolazi u obliku jasne i precizne instrukcije.

U većini slučajeva problem dolazi kroz razgovor.

Klijent pokušava da objasni šta mu treba, ali ne zna kako da to formuliše tehnički. Dizajner ima ideju kako bi interfejs trebalo da izgleda, ali nije siguran kako će to funkcionisati u praksi. Menadžer ima poslovni cilj, ali ne zna koji je najjednostavniji način da se do njega dođe kroz softver.

U tom trenutku developer ima dve mogućnosti. Može da uzme zahtev zdravo za gotovo i počne da piše kod. Ili može da zastane i pokuša da razume šta se zapravo krije iza tog zahteva.

Najbolji developeri gotovo uvek biraju ovu drugu opciju.

Oni postavljaju pitanja.

Ne zato što žele da zakomplikuju stvari, već zato što znaju da je najveći broj problema u softverskim projektima posledica pogrešno shvaćenog zadatka.

U svetu programiranja postoji nepisano pravilo koje mnogi iskusni inženjeri ponavljaju mladim kolegama. Ako je specifikacija potpuno jasna na prvi pogled, velika je šansa da nešto u njoj nedostaje.

Zato dobar developer sluša pažljivo, ali još važnije, sluša aktivno. On pokušava da razume kontekst problema. Pokušava da shvati zašto nešto treba uraditi, a ne samo kako.

To često vodi do zanimljivih otkrića.

Nije retkost da tokom razgovora postane jasno da problem koji tim pokušava da reši zapravo nije pravi problem. Nekada je rešenje mnogo jednostavnije nego što se na početku činilo. Nekada je problem u poslovnom procesu, a ne u softveru.

Programer koji zna da sluša može da prepozna takve situacije.

U tom trenutku njegova uloga prestaje da bude samo tehnička. On postaje neko ko pomaže timu da pronađe najbolje rešenje.

Zanimljivo je da se ova veština retko uči na fakultetima ili kursevima programiranja. Većina obrazovnih programa fokusira se na algoritme, strukture podataka, programske jezike i arhitekturu sistema. Sve su to važne stvari, ali one predstavljaju samo deo svakodnevnog rada developera.

Drugi deo posla dešava se u razgovorima.

U diskusijama sa kolegama iz tima. U sastancima sa klijentima. U porukama na internim komunikacionim kanalima. U neformalnim razgovorima pored bele table na kojoj neko pokušava da objasni ideju.

U takvim situacijama sposobnost slušanja postaje ključna.

Iskusni developeri često imaju zanimljivu naviku. Kada neko objašnjava problem, oni ne prekidaju odmah sa predlogom rešenja. Umesto toga, puste sagovornika da završi. Zatim ponove problem svojim rečima.

Ta mala tehnika ima dva efekta.

Prvo, sagovornik dobija potvrdu da je zaista saslušan. Drugo, developer proverava da li je dobro razumeo suštinu problema.

Vrlo često se upravo u tom trenutku pojavi nova perspektiva.

Možda je zahtev nepotreban. Možda postoji jednostavniji način. Možda funkcionalnost koju neko traži već postoji u sistemu, samo je niko do sada nije koristio.

Takvi trenuci štede ogromnu količinu vremena.

U svetu softvera postoji zanimljiva pojava koju mnogi timovi prepoznaju tek posle nekoliko projekata. Ponekad se nedeljama radi na funkcionalnosti koja na kraju gotovo niko ne koristi.

Razlog za to retko je tehnički problem. Obično je problem u komunikaciji.

Neko je pogrešno razumeo zahtev. Neko je pretpostavio šta korisnici žele. Neko nije postavio pravo pitanje na početku.

Zbog toga mnogi iskusni inženjeri smatraju da je najvažniji deo projekta upravo početna faza razgovora.

U toj fazi se ne piše kod. U toj fazi se postavljaju pitanja.

Šta tačno pokušavamo da rešimo.

Ko će koristiti ovu funkciju.

Koliko često će se koristiti.

Šta se dešava ako ne postoji.

Da li postoji jednostavniji način.

Takva pitanja ponekad izgledaju banalno, ali njihovi odgovori često menjaju pravac celog projekta.

Zanimljivo je da ova veština postaje još važnija kako developer napreduje u karijeri. Junior programeri uglavnom dobijaju jasno definisane zadatke. Njihov fokus je na implementaciji.

Kako iskustvo raste, zadaci postaju sve manje precizni. Senior developer često dobija samo opis problema.

Način na koji će taj problem biti rešen zavisi upravo od sposobnosti razumevanja konteksta.

U tom trenutku slušanje postaje strateška veština.

Možda zato mnogi najbolji developeri koje ćete upoznati nisu nužno najglasniji ljudi u prostoriji. Oni često više posmatraju nego što govore.

Ali kada progovore, njihove reči imaju težinu. Ne zato što su glasne, već zato što su promišljene.

U svetu softvera, gde tehnologija stalno napreduje i novi alati se pojavljuju gotovo svakog meseca, lako je pomisliti da su tehničke veštine jedina stvar koja pravi razliku između prosečnog i odličnog developera.

U stvarnosti, međutim, razlika je često mnogo suptilnija.

Odličan developer ne samo da zna kako da napiše kod. On zna kada treba da zastane i posluša.

Jer ponekad je najbolji kod onaj koji nikada nije morao da bude napisan.