Excelența nu e o garanție a succesului

Zilele trecute mă întâlnisem cu Vasi, un coleg de muncă cu care am trecut prin prima mea „comandă” la cârma unui proiect. Un moment foarte interesant, din care am învățat multe, poate o să povestesc altă dată mai pe larg – unde vroiam să ajung e la faptul că de fiecare dată când ne întâlnim ajungem inevitabil să ne reamintim de experiența noastră comună. E cumva natural să se întâmple asta.

Interesant e că de fiecare dată, experiența acumulată peste timp ne face să mai vedem câte-un aspect pe care acum doi-trei ani nu am fi putut să-l vedem. De exemplu anul ăsta Vasi a adus un element important în poveste: Foarte des nu contează calitățile individuale ale omului care face treaba. „Între un om care e expert și un om care e relativ bun dar are atitudinea corectă, îl prefer pe al doilea”, zice el.

Prin anii 2000 încă era la modă ideea cu rockstar programmers, care îți rezolvă problemele de 10 de ori mai ieftin și mai rapid decât un programator normal. Mitul era o construcție convenabilă în epoca în care se nășteau cele mai importante startup-uri – o deviație de la cultura corporate clasică adoptată de greii de atunci, gen IBM sau Microsoft. În epoca în care se năștea mișcarea Agile, când lumea venea cu noi și noi paradigme de lucru (marea majoritate scoase de la păstrare din anii ‘60-‘70, când erau destul de nepractice pentru sistemele contemporane). Rockstar Programmer-ul era răspunsul la întrebarea care era pe buzele tuturor: cum vei putea să faci X atât de repede?

Cam toate startup-urile din epoca aceea sunt centrate unei figuri mitologice, un super-zeu hiper-productiv. Aveai hiper-programatorul, aveai super-ideea, deja aveai un startup gata să înghită milioane de dolari. Nu contează că ideea era impracticabilă, aveai rockstar-ul, rezolvă el tot. O mitologie convenabilă când mergi la vânat proiecte și la pitch-uit proiecte. Realitatea însă e un pic diferită. 90% din acele startup-uri eșuează, iar cele care nu eșuează întotdeauna au o poveste atât de romanțată că îți dai seama că e falsă. Mai nimeni nu vorbește despre cum se construiește real un produs în anii 2000+, și asta e prin muncă. Foarte multă muncă, chestia aia nasoală care nu dă bine pe TV, oameni în fața calculatorului tastând chestii, încercând, așteptând după o compilare, reîncercând. Cel mai des nu e dezvoltatorul ăla rock-and-roll care face flotări în timp ce citește Infernul lui Dante în latină, și face vloguri despre cum să faci bani din vlog. Cel mai des e o echipă de programatori bonomi, cu dureri de spate de la prea mult stat pe scaun, obosiți și stresați, și care abia așteaptă să plece în vacanță la Sovata.

E un lucru pe care și eu (care multă vreme m-am considerat un rockstar programmer de buzunar, deși n-aveam motive) l-am învățat în ultimii ani. Când am văzut că degeaba ești bun dacă nu ești sincronizat cu echipa cu care lucrezi, dacă nu poți să-ți sprijini colegii să crească și ei la rândul lor, dacă nu ești capabil să comunici suficient de bine în echipă. Atitudinea de rockstar, de individ la care toată lumea trebuie să se uite, să-l admire și să-l copieze, nu funcționează deloc. Și e cu atât mai tragică cu cât poziția rockstar-ului în echipă e mai importantă.

Problema pe care o are întotdeauna un rockstar e că nu are cum și de la cine să învețe. Când ești de unul singur, extraordinar în ceea ce faci, nu mai poți crește. Asta înseamnă că în momentul în care cei din jurul tău avansează tu, ca rockstar, nu ai ce face decât să bați pasul pe loc, pentru că ești obișnuit să te uiți doar înainte, nu și la direcția diferită în care se mișcă lumea, și proiectul. Rockstar-ul e ca omul ăla cu care pleci din Poiana Brașov și el ajunge în Predeal când tot restul grupului ajunge în Râșnov. Bravo lui, a luat un drum mai simplu și mai ușor, a lucrat mai inteligent și mai ieftin, dar a ajuns altundeva.

Pentru că asta se întâmplă cel mai des. Prea deștept pentru propriul său bine, rockstar-ul eșuează în a se alinia cu obiectivele echipei cu care lucrează, și ăsta e motivul pentru care 9 din 10 startup-uri eșuează – ca și 9 din 10 rockstars.

Rockstar-ul e oricum un mit. Mitul productivității de zece ori mai mari provine din ceva studii făcute prin ‘68 în care se comparau două metode diferite de lucru – cea „normală”, interactivă, și „batch programming”. Programatorul rockstar era cel care auzise de faptul că poți să-ți pregătești programul din timp, și să-ți programezi din timp rularea programului. Caz în care era evident de zece mai eficient și mai ieftin. Productivitatea era ușor de calculat atunci – cât timp țineai sistemul de calcul ocupat – pe vremea când calculatorul costa zeci de milioane de dolari, fiecare secundă de operare te costa. Așa că un programator care își face temele de-acasă îți salvează enorm din resurse.

Nu mai e cazul. Lucrurile s-au schimbat – problemele cele mai importante au fost, în mare parte, rezolvate. Nu e nevoie să reinventăm roțile((ba da, dar discuția e mai lungă, promit că o să revin cu un articol să explic)), nu mai avem de cutting edge coders care scriu cod magic ce nu poate fi înțeles decât de un alt Rockstar.

Acum vreo 6 ani am participat la un interviu de job unde cel care mă intervieva îmi punea întrebări tehnice de duzină. Și i-am spus chestia asta, și i-am zis că asta îmi arată că nu are nevoie de lucrurile mult mai avansate pe care le știu eu și de care sunt capabil, și deci nici nu mă va putea plăti pe măsură. Și mi-a spus fix lucrul pe care îl zic acum: omul nu vroia oameni foarte buni, ci oameni mai slăbuți, pe care să-i pună să lucreze în echipă. Bine, el avea o atitudine greșită, dar vorbea corporația din el, nu e vina lui. Ideea, însă, e bună pe fond.

Acum vreo doi ani aveam o discuție legată de felul în care făceam code-review. „Ce faci când vezi ceva bucată de cod despre care programatorul îți zice că sigur că funcționează, îți demonstrează cu unit-teste?”. Răspunsul meu a fost simplu: îi rejectez codul. Pentru că dacă e prea deștept pentru mine ca reviewer, va fi prea deștept și pentru restul echipei, și va fi mult prea deștept pentru a fi reparat atunci când vine un bug din producție și sunt afectați 10.000 din cei 60.000 de clienți ai tăi. Când codul e prea deștept, toată lumea are de suferit.

Cel mai des, rockstar-urile lasă în urma lor dezastru. Să le preiei codul e infernal, cel mai des lucrurile pe care ei le construiesc sunt fragile și nerezistente la schimbări. Rockstarul ia toate scurtăturile posibile, foarte des în detrimentul productivități și mentenabilității. E aproape imposibil să nu ai o echipă suferindă la plecarea rockstar-ului, nu pentru că omul era atât de bun, un Dumnezeu între oameni, că nu mai ai cine să-i ia locul, ci pentru că lucrurile pe care le lasă în urmă sunt, cel mai des, lipsite de substanță, și cu probleme pe care omul le-a ascuns cu dibăcie.

Așa că nu am putut să nu fiu de acord cu Vasi când zicea toate astea. Oamenii cu atitudinea corectă pot învăța să fie mai buni. Asta înseamnă că o să prefer întotdeauna să lucrez cu oameni care nu au obiectiv să fie cei mai tari din parcare, ci care caută un echilibru în tot ce fac – în munca lor și în viața lor. Pentru că în cele din urmă, mintea sănătoasă se cultivă altfel decât în felul obsedant în care vârfurile astea sunt cultivate.

Asta, sigur, nu înseamnă că o să rejectez un om capabil și inteligent. Dar din punctul meu de vedere un om capabil și inteligent nu are cum să nu fie și un bun jucător de echipă. Așa că în loc să fie un rockstar care să alerge suta de metri în 9 secunde, va fi un om care o va lua la pas, cu restul echipei, și va fi cu un metru-doi în fața, suficient cât să vadă pericolele din față dar să nu piardă contactul cu echipa.