De ce îmi eșuează proiectele tehnice personale

După o discuție de ieri am reușit să-mi identific o întrebare mai veche pe care o aveam: de ce ultimele mele proiecte personale în materie de software mi-au eșuat. Ultimul din lista asta este proiectul legat de motorul pentru blog, dar înainte sunt nenumărate proiecte legate de te-miri-ce, cu excepția notabilă a roboțelului de Discord care e o hăcuială dezordonată.

Îmi pusesem diagnosticul undeva între burnout și analysis paralysis, și dacă e un răspuns pe care l-aș putea aplica tot timpul pentru 90% din oamenii care au ceva în cap și care chiar vor să facă niște lucruri bune, burnout-ul e cel care contribuie decisiv la eșecuri. Dar în cazul meu nu burnout-ul e problema - nu acum, cel puțin - cu toate că sunt sub ceva presiune am reușit să mă eliberez și să-mi reorganizez proiectele în așa fel încât să le pot realiza (chiar dacă asta a cerut să fac o pauză lungă de la Podcastul de Istorie).

Și mi-am dat seama că am o problemă cât se poate de tehnică, pe care o voi descrie întâi la nivel teoretic pentru că de ce să începem cu o durere de cap?

Problema de parcurgere a arborelui

Există două strategii majore de a parcurge un arbore (adeseori în scop de căutare). În momentul în care ai o structură arborescentă și vrei să parcurgi toate nodurile ei ai de ales între a aborda fie o parcurgere pe lățime sau în adâncime. Ambele strategii pot fi la fel de pline de succes, unele sunt mai ușor de făcut decât altele în funcție de context, dar în principiu ambele strategii sunt corecte și duc către același rezultat, chiar dacă ordinea nodurilor e diferită.

În cazul parcurgerii pe lățime, primul lucru pe care îl faci e să te uiți la toate nodurile de sub nodul rădăcină, și de-abia după ce ți-ai prelucrat toate acele noduri să treci la următorul nivel - practic e o parcurgere pe niveluri a arborelui. În cazul parcurgerii în adâncime în principiu te uiți la rădăcină, apoi la primul copil, apoi la primul copil al copilului, până termini cu toți, treci la al doilea copil și faci aceeași operație, șamd (oare peste câțiva ani lumea va crede că noi chiar pronunțam treaba asta „șamd” și nu ziceam „și-așa mai departe”?).

Cum se aplică la proiecte?

În primul rând, în momentul în care ai de făcut ceva operațiune mai complexă (și vorbim despre absolut orice fel de operațiune sau proiect), ceea ce se întâmplă e că chiar dacă îți este sau nu clară împărțirea, fiecare operațiune este spartă în operațiuni mai mici, și se formează o structură de tip arborescent. Uneori pașii sunt făcuți în ordine obligatorie (nu poți să faci o prăjitură începând cu băgatul aluatului la copt, ci va trebui să faci întâi aluatul), alteori, mai ales în zona creativă, pașii pot fi făcuți independent unii de ceilalți. De exemplu dacă ai de pictat o scenă complexă cu o casă înconjurată de pădure, lângă un luminiș în care pe marginea unui lac se bate un urs cu un extraterestru cu săbii laser în timp ce un rechin cu cască de motociclist privește la înfruntare fumând de pe o floare de lotus, iar fumul țigării ar obscura nava extraterestră care se prăbușește pe lună, atunci după ce ți-e oarecum clar cum vin toate treburile astea aranjate în pagină te-ai putea apuca de oricare element în oarecare izolare. Întâi te apuci poate de casă, sau poate de desenat rechinul, că într-o zi preferi să desenezi rechini fumători. Ideea e că și acolo ai o împărțire a proiectului în subproiecte din ce în ce mai clar definite până când rămâne un singur pas de făcut (de exemplu, o singură tușă trasă cu penelul).

Cum se aplică la mine?

Problema, la mine, și cred că nu e doar la mine, e că în momentul în care mă apuc de o bucățică, tind să intru în foarte mult detaliu, având o abordare în adâncime a problemei. Și problema devine cu adevărat complicată în momentul în care cunosc suficient de multe lucruri încât să vreau să intru mai în detaliu și să rezolv niște probleme pe care oamenii normali nu le au.

De-asta, de exemplu, Podcastul de Istorie nu a putut să se oprească la a se uita superficial la istoria imperiilor care ne-au înconjurat. Am intrat în detaliu suficient de adânc încât să ajungem să ne-ntoarcem în timp și să-l studiem pe Platon doar ca să ne dăm seama că Marcus Aurelius nu era chiar suprazeu al filosofiei.

Iar în ceea ce privește programarea, chestia la care chiar mă pricep, vă pot explica care sunt câteva din piedicile pe care le-am întâlnit în timp ce doream să implementez un engine de blog:

• Nu am un build system pentru C++ suficient de bun, deci am început să scriu eu unul.
• Am început să modific un analizor de loguri pentru blog, și care e scris prea prost ca să îl pot salva, și
• sunt nemulțumit de faptul că standardul POSIX se bazează pe zero-terminated strings, probabil cea mai proastă alegere făcută de Dennis Ritchie și cea mai costisitoare greșeală de un byte din istorie. M-am oprit înainte de a scrie un sistem de operare (nu înainte de a-l începe, aia o începusem acum ceva vreme).

Problema, așadar, e că dacă pictorul Rechinului contemplând la Războiul Interplanetar are un spațiu limitat în care să se desfășoare, are un număr limitat de centimetri pătrați de acoperit, câmpul programării îmi permite să rescriu un sistem de operare de câțiva gigabytes de mână. Și probabil că singurul motiv pentru care nu am început cu treaba asta e că chiar trebuie să fac și alte treburi.

Cum repar treaba?

Acum că am formulat lucrurile într-o formă în care o pot înțelege și eu, nu o să mă pun să repar greșeala lui Dennis Ritchie (care rămâne mai influent decât cel care a murit în aceeași săptămână cu el, chiar dacă numele lui e mai greu recunoscut). De fapt, mi-am dat seama de ce mi-e mult mai simplu să nu fac asta când lucrez pentru clienții mei. Pentru că cei pentru care lucrez îmi pun la dispoziție un sistem care îmi permite să mă concentrez pe un subarbore foarte îngust, și pot lucra doar în anumite limite, între anumite etaje ale arborelui respectiv. Asta este de fapt soluția de succes - un programator trebuie nu doar să primească libertatea de a face lucrurile ci și limitele între care să le facă, astfel încât abordarea lui preferată (că e breadth-first sau depth-first) să nu fie un handicap.

Dar am mai învățat un lucru - chiar dacă nu sunt capabil să fac o abordare breadth-first în mai nimic din ce fac, pot să fac un sistem hibrid în care îmi fac o planificare la nivel superior astfel încât să am o structură care să mă ghideze. Treaba asta funcționează cât de cât pentru proiectul pe care îl vedeți pomenit în coloanda din dreapta, și funcționează pentru alte treburi la care lucrez. Și îmi dau seama că o parte din oboseala pe care o resimt este nevoia de a supra-analiza fiecare chestie pe care o fac, până la cel mai mic gest, și ăsta e adevăratul motiv pentru care ajung în paralizie analitică.

Să vedem cât de bine pot să mă țin de asta. Poate chiar repornesc proiectul de motor de blog cu treaba asta în minte. Vedem. Vedem. Oricum, înainte să fac motorul de blog ar trebui să scriu analizorul ăla, și să nu reinventez Javascript de mână.