Principiul după care mă ghidez la muncă

Despre nevoia de munci după un principiu fundamental am aflat într-o prezentare făcută de Bret Vitor. Principiul după care se ghidează acesta spune că între creator și creație trebuie să fie o conexiune imediată: “when you make a change you need to see that change immediatly, without delay”.

Principiul după care mă ghidez eu e asemănator, dacă nu chiar identic, însă nu se referă doar la creație, ci la un spectru mai larg din munca mea.

Odată ce am o imagine clară despre scopul companiei în care lucrez, rolul meu e să identific și să îndepărtez orice barieră din calea acelui scop.

Cred cu certitudine că nimic n-ar trebui să intervină între tine și activitatea care contează cu adevărat. Și atunci trebuie să îndepărtez orice obstacol. Ăsta e principiul meu: “clear any barriers for important work”.

Acest principiu poate suna abstract așa că am să dau câteva exemple care să clarifice lucrurile.

Automatizez orice muncă repetitivă

Lucrurile pe care le faci în mod repetat nu sunt deloc “real work”, ci doar niște pași pe care trebuie să-i urmezi ca să ajungi la activitatea care contează cu adevărat. Rolul meu e să găsesc acele activități și să încerc să le automatizez.

Aveam la un job vreo 15 tabele care trebuiau șterse de fiecare dată când QA-ul testa un anumit feature. Timp de un an nimeni nu s-a gândit să scrie un script de 5 rânduri ca să automatizeze chestia aia. L-am scris eu în două minute. Nu e un câștig enorm, însă la cât de des testau chestia aia, după vreo două luni au fost pe profit în materie de timp. Și în loc să facă chestii repetitive s-au putut concentra pe ce contează cu adevărat: real work.

Poate că cea mai profitabilă chestie a fost un alt script care scria migrații automat în funcție de niște parametrii. Acolo am văzut cum o muncă a unui programator de două ore a devenit două minute.

Cât mai puțin efort din partea utilizatorului

Când fac o librărie nu mă mai gândesc la ce face, ci la cum e folosită. Cred că de aceea TDD-ul produce un cod flexibil, pentru că atunci când un programator face TDD, acesta scrie codul din perspectiva utilizatorului și nu din cea a dezvoltatorului.

Însă nu trebuie să fac TDD ca să-mi urmez principiul. E suficient să mă pun în papucii colegului care va lucra cu librăria mea. Și îl înțeleg ce vrea să facă: vrea să facă cât mai puțin efort, ca mai apoi să se concentreze pe munca adevărată. De aceea caut cu orice prilej să produc o librărie care să necesite cât mai puțin efort din partea celui care o va folosi.

Aici trebuie să subliniez că cine va folosi acest principiu trebuie să fie umil și să nu aibă așteptări. Cu cât faci o treabă mai bună atunci când scrii o librărie, cu atât mai puțini vor fi deranjați de ea. Și puțini observă lucrurile care nu-i deranjează, însă toți se plâng de codul care-i “jenează”. Git blame, annotate îți spune ceva? :)

Cât mai puțin efort din partea celor ce îmi citesc codul

Când scriu o bucată de cod, vreau să încerc să îndepărtez orice sarcină cognitivă a programatorului care o să-mi citească codul. De exemplu, detest if statement-urile. Cu fiecare if pe care-l citești, ocupi un anumit spațiu din memoria ta. Când trebuie să ții cont de prea multe if-uri, o iei razna și de multe ori trebuie s-o iei de la capăt ca să fii sigur că ai înțeles tot. Un fel de “allowed memory size exhausted” personal :)

Detest if-urile atât de mult, încât cred că dacă un programator se va concentra să scrie un program cu cât mai puține if-uri, va deveni un programator mai bun.

În acest gist am adăugat două exemple simple. Atunci când lucrăm cu date, în loc să ne gândim la un flow imperativ, ar trebui să ne gândim mai mult la structuri de date. Linus Torvalds spunea “good programmers worry about data structures and their relationships.

O structură care îți spune ceva e mult mai eficientă decât o logică cu multe if-uri.

Veți spune probabil că al doilea exemplu ar fi mai simplu cu if. În acel exemplu simplist da, însă când ai logică mai complexă ca aici, vei fi mai câștigat.

Polimorfismul ne ajută enorm, sau alte structuri simple precum un stack sau queue. Nu o să intru în detalii, însă o prezentare foarte bună pe această temă găsiți aici.

Nu sunt un obstacol când comunicăm în echipă

Felul în care mă comport se subordonează aceluiași principiu. Iar dacă vreau să îndepărtez obstacole, mă asigur să nu fiu eu însumi un obstacol.

La meeting-uri aleg să tac atunci când ceea ce aș spune nu contribuie cu nimic la tema întâlnirii. Atunci când se pune o întrebare, mă gândesc bine dacă din toată încăperea eu sunt cel potrivit ca să răspund la ea. Poate că acest lucru te va face mai puțin vizibil, dar felul ăsta de a fi nu te va ajuta să fii mai vizibil, ci să faci ceea ce e cu adevărat important.

Veți crede că dacă vorbiți mai puțin, ideile voastre nu vor fi luate în considerare. Nu e adevărat. Recent am avut un meeting în care soluția mea a fost acceptată, deși la început toți programatorii au vrut să facă altceva. Am preferat să tac și să-i ascult. La sfârșit CTO-ul m-a întrebat “Andrei, what do you think?”.  În 2 minute mi-am explicat poziția luând în considerare tot ce au spus colegii mei și în cele din urmă i-am convins.

Dincolo de multă vorbărie, prefer substanța și logica. Și nu poți să ai substanță dacă nu taci și asculți. N-o să fiu niciodată omul care vorbește cel mai mult într-un meeting, dar când voi spune ceva, atunci mă vei asculta pentru că știi că nu vorbesc decât atunci când am ceva util de spus.

Simplific procese complicate cu o documentație solidă

Când am observat că mai mulți programatori aveau o problemă cu o parte din sistem am profitat de această ocazie ca să mai îndepărtez un obstacol. Am documentat acel proces ca să mă asigur că nimeni nu va mai avea probleme cu partea aceea și vor putea face ceea ce e cu adevărat important: să producă valoare.

Dincolo de exemplele de mai sus sunt atâtea modalități de a îndepărta obstacole. Poate fi un refactor al unui feature important, poate fi o îmbunătățire a unui proces care ia prea mult timp(code reviews, workflow etc), sau să știi când să te oprești într-o dezbatere. Trebuie doar să fii atent și să observi obstacolele.

Uneori va dura ceva timp, obstacolele sunt deghizate în sisteme acceptate(“this is how we do things around here”), și poate fi greu să le observi pentru că toată lumea se folosește de ele.

Felul ăsta de a fi implică disciplină, modestie și proactivitate. Dacă vrei să fii cineva poate nu e cel mai potrivit mod de a munci. Dacă vrei să faci ceva, atunci cred că e un principiu bun.

Omul care a influențat extrem de mult armata americană e un tip necunoscut. Pentru că a ales un mod de viață care se opune ideii de a fi vizibil. Am să închei cu vorbele lui spuse unui tânăr:

“Tiger, one day you will come to a fork in the road and you’re going to have to make a decision about which direction you want to go.
If you go that way you can be somebody. You will have to make compromises and you will have to turn your back on your friends. But you will be a member of the club and you will get promoted and you will get good assignments.
Or you can go that way and you can do something — something for your country and for your Air Force and for yourself. If you decide you want to do something, you may not get promoted and you may not get the good assignments and you certainly will not be a favorite of your superiors. But you won’t have to compromise yourself. You will be true to your friends and to yourself. And your work might make a difference.
To be somebody or to do something. In life there is often a roll call. That’s when you will have to make a decision. To be or to do? Which way will you go?”