S-au scris mii de liste cu „cărți esențiale pentru programatori” și toate par copiate la indigo. Primele trei recomandări sunt mereu aceleași: Clean Code, Pragmatic Programmer și eventual una de Design Patterns. Le-am citit și eu la început, dar sincer, nu ele m-au făcut un inginer mai bun, ci doar un executant mai tipicar.
După mai bine de 10 ani de scris cod și coordonat echipe, am realizat că problemele noastre grele nu sunt despre unde punem acolada sau dacă facem o funcție de trei rânduri. Problemele adevărate sunt despre cum gândim sistemele mari, cum gestionăm blocajele și cum comunicăm în interiorul echipei.
Uite trei cărți care nu apar pe toate gardurile, dar care mie mi-au resetat complet modul de lucru.
1. Thinking in Systems – Donella Meadows
Cartea asta nu are nicio treabă directă cu programarea. Este despre teoria sistemelor în general, de la ecosisteme naturale până la economie globală. Însă, când o citești ca dev, ai constant momente de tipul „păi exact așa face și microserviciul meu de facturare”.
M-a învățat să caut bucle de feedback (feedback loops) și stocuri (stocks). Am avut un proiect acum câțiva ani cu vreo 8.000 de utilizatori concurenți unde baza de date crăpa constant sub sarcină. Instinctul echipei a fost să adăugăm un strat de cache peste tot. Citind Meadows, mi-am dat seama că doar mutam „stocul” de request-uri dintr-o parte în alta și măream timpul de propagare a erorilor. Am rezolvat problema limitând rata de scriere (rate limiting) direct la intrare, adică modificând bucla de feedback a sistemului.
Trade-off: E o carte destul de abstractă. Nu te ajută să scrii un query SQL mai rapid mâine dimineață, dar te oprește din a desena arhitecturi proaste pe whiteboard.
2. The Goal – Eliyahu Goldratt
Este scrisă ca un roman de afaceri din anii '80 despre un manager care încearcă să salveze o fabrică de la faliment. Sună plictisitor? Este de departe cea mai bună carte despre DevOps și metodologii Agile pe care o vei citi vreodată. Goldratt introduce „Teoria Constrângerilor” (Theory of Constraints).
La un moment dat, lucram într-o echipă unde lead-ul voia să angajăm mai mulți developeri pentru că aveam prea multe feature-uri în backlog. Aplicând ce am învățat din carte, am analizat fluxul de lucru și am văzut că blocajul (bottleneck-ul) era de fapt la QA și deploy. Dacă aduceam mai mulți dev-i, doar măream muntele de tichete care așteptau la testare, creând și mai mult haos. Am oprit recrutarea de dev-i și am investit trei săptămâni în automatizarea testelor. Timpul de livrare a scăzut cu 40% în prima lună.
Trade-off: Stilul literar este destul de demodat și uneori siropos, dar lecțiile despre cum să identifici singurul punct care încetinește tot sistemul sunt de aur.
3. A Philosophy of Software Design – John Ousterhout
Dacă ai obosit să vezi clase de trei rânduri și interfețe pentru absolut orice (clasicul stil promovat agresiv de Clean Code), cartea asta e antidotul perfect. Ousterhout, profesor la Stanford, explică de ce este mai bine să ai „module adânci” (deep modules) – adică o interfață simplă care ascunde o implementare complexă.
Am aplicat filozofia asta pe un modul legacy de procesare de plăți. În loc să sparg codul în zeci de mici clase utilitare care doar pasau datele de la una la alta (ceea ce făcea debugging-ul un coșmar), am grupat totul într-un modul robust cu o singură metodă publică expusă. Complexitatea cognitivă a scăzut enorm, iar colegii noi au înțeles codul în jumătate din timp.
Trade-off: Cartea asta intră în conflict direct cu unele dogme din Clean Code. Dacă o aplici orbește într-o echipă de fani extremiști ai lui Uncle Bob, o să ai discuții foarte aprinse la code review.
Voi ce cărți aveți în bibliotecă care v-au schimbat perspectiva, dar care nu apar de obicei în listele mainstream?