Planuri pe 2008

Începutul de an pare să fie permanent o situaţie care poate genera momentum pozitiv. “Vreau să fac asta în anul care vine”. Şi, de cele mai multe ori, ajungi undeva cam la 60-70% (din estimările proprii, care evident sunt mult prea optimiste) din drumul care trebuie să-l parcurgi ca să-ţi atingi obiectivul.

Niciodată nu m-au încântat jumătăţile de măsură, aşa că renunţam din start. Chiar şi la examenele de la facultate: o groază de restanţe le-am acumulat pentru că n-am mai mers la examen. Pentru că nu ştiam materia şi, în sinea mea, ziceam că n-are sens. (Sfat pentru politehnişti: niciodată să nu faceţi asta. Un examen e picat sigur doar dacă nu te prezinţi la el.)

Anul trecut am zis “What the fuck? Hai să încerc!”.

Pe la sfârşitul lui martie m-am angajat la o companie, Brainient pe nume. Ruby on Rails developer amator, cu ceva cunoştinţe generale despre programare. Nimic impresionant. Am încercat să prind tot ce am putut de acolo până când am simţit că nu mai evoluez şi că performanţele mele de la serviciu erau din ce în ce mai slabe. Era vorba de mediu, de lipsa experienţa oamenilor cu care lucram (nu o zic cu răutate, media de vârstă era undeva pe la 22 de ani, Emi, patronul, având 21), de nerăbdarea unor clienţi, calitatea rezultatelor.

Toate aceste lucruri m-au făcut să-mi pierd interesul, deşi am avut marea şansă să discut cu oamenii care plăteau pentru software. Am apucat să văd nişte sume pentru vreo două proiecte, am apucat să primesc un mail entuziast de la o clientă, mulţumindu-mi mie şi programatorului care a făcut toată magia într-un timp foarte scurt. Pe de altă parte, am avut şi un proiect ratat complet, cu întârzieri de vreo 3 săptămâni şi mare parte e vina mea, pentru că nu reuşisem să creez un momentum şi că eram destul de detaşat de soluţia respectivă (erau momente în care habar n-aveam cam ce s-a implementat, ce bug-uri s-au rezolvat, etc).

După Brainient, am învăţat câteva lucruri:

• Orice unealtă e bună, cât timp e folosită. De exemplul, software-ul de planning. Fusese cândva Basecamp, apoi am trecut la ActiveCollab, apoi Trac, apoi RedMine şi apoi nimic. Aşa că mai nimeni nu folosea uneltele respective pentru că erau şanse ca peste vreo 2-3 săptămâni să se piardă totul. Doar bug-tracking-ul se făcea via Google Spreadsheets, o decizie nu neapărat fericită.
• Cel care conduce echipa e responsabil de viteza de execuţie. Foarte rapid după ce am ajuns “in charge” am observat că interacţiunile mele cu codul erau nule. Ceea ce e foarte fals. Un Project Manager bun rulează codul zilnic, ştie ce se întâmplă pe acolo şi nu se uită prin cod cum mă uitam eu prin PHP (eu m-am apucat de Ruby pentru că nu suport PHP-ul). Eu nu făceam acele lucruri şi acesta era motivul pentru care un proiect a fost ratat (sau era să fie ratat).
• “Best practices” se numesc “best” dintr-un motiv anume. Utilizarea unui sistem de versionare a codului sursă era oarecum opţională şi se făcea un “push” în direcţia aceasta. Dar dacă dădeai un `svn log` nu vedeai nici un mesaj de commit. O unealtă specifică pentru bug tracking nu exista (spreadsheet-ul nu prea se pune, avem nevoie de screenshot-uri când lucram cu web-ul). Testare ioc, şi aici nu mă refer la unit testing, ci la verificat dacă merge codul pe care l-ai scris.
• Cuvântul dat contează foarte mult. Şi aici nu mă refer la discuţiile cu clienţii, ci promisiunile făcute în interiorul firmei. Dacă ai spus că faci un lucru la un moment dat, atunci să te asiguri că faci asta atunci. Aşa creezi viteză în cadrul echipei, nu mai vorbesc de respect şi de o comunicare mai bună. Şi mişcarea asta trebuie să vină de sus în jos, nu invers.

Interestingness-ul contează mult. Aşa, ca întrebare de 1000 de puncte şi excursie la mare: câte soluţii identice (sau aproape identice) din punct de vedere tehnic poate un programator să facă până când se plictiseşte?

Imediat după, la insistenţele unui prieten bun de-al meu, am intrat într-un proiect ASP.NET. Ştiu că nu eram pregătit, dar eram destul de la pământ cu finanţele şi am acceptat. Big mistake. Şi încă nu băgasem la cap ce învăţasem la Brainient.

După o perioadă de repaus, lucrez cu un mic start-up din Silicon Valley, TrexGlobal. Fac aplicaţii financiare pe Ruby on Rails, deşi acum 2 ani aş fi putut să jur că nu-s în stare să fac aşa ceva. Adevărul e că n-ai nevoie de un strop de ASE pentru asta (oricum legislaţia e diferită) şi, oricum, domain expert-ul ştie să vorbească pre limba programatorilor. Iar problemele cu care mă confrunt sunt strict de natură tehnică.

Pe 2008 sper să devin un programator mai bun. Sunt două laturi deficitare, pe partea tehnică: testarea automată a codului şi documentarea. Am început să presar comment-uri prin codul sursă, dar nu e nimic compatibil RDoc şi în maxim o lună vreau să fumez rSpec. Mai sunt două proiecte la care vreau să lucrez, separat de munca pentru startup-ul de care ziceam mai devreme. O idee a unui amic plus un proiect pe care l-am început acum un an şi l-am abandonat (nu-i o idee uimitoare, dar vreau să-l finalizez).

Iar la sfârşitul anului aş vrea să ajung commiter la un proiect open source, cum spuneam acum două luni. Mă gândeam la Rails, dar acolo numai membrii echipei core au drepturi de commit. Apoi, cu lansarea Ruby 1.9 mi-am dat seama că m-ar încânta să contribui la Ruby, nu doar la Rails (şi, în acelaşi timp, aş învăţa o groază de lucruri). Cu puţină ambiţie, poate o să am patch-uri la amândouă, dar… Who knows ;-)

Pe plan personal, aş vrea să fiu un pic mai independent de ai mei şi cred că dacă m-aş muta într-o garsonieră (un fost coleg de liceu ar fi interesat să share-uim un apartament de 2 camere, we’ll see) ar fi un pas în această direcţie.

Peste vreo 12 luni tragem linie.