12 ani. 12 ani lucreaza in medie un robot intr-o fabrica pana cand sa fie inlocuit. Destul de mult nu? Asa am zis si eu. 12 ani facand acelasi lucru zi de zi, aceleasi coordonate acelasi peisaj. Nici o schimbare… Si cumva multi dintre noi suntem la fel. Munca de robot (chinez batran cum ne place sa zicem) ce nu a reusit inca sa fie automatizata.
Si totusi noi o numim “EXPERIENTA”, experienta copy paste imi place sa o denumesc, experienta in care fiecare an nu il poti distinge de celalalt. Si totusi noua ne place atat de mult sa ii etalam. Fiecare CV ce il citesc, fiecare recomandare, toate incep la fel, Popescu Popestean 7 ani experienta pe o tehnologie, putem sa o facem si mai simplu: Model Popescu, fabrica divizia dezvoltare, functia: asamblare cod si testare usoara. Functioneaza pe incurajari si biscuiti si pizza bonus de craciun 😃.
Nu poti compara un developer ce a lucrat intr-o companie mare, pe acelasi proiect mai vechi decat el ani de zile. facand acelasi lucru zi de zi, cu un developer ce a fost poate printe singuri developeri dintr-un startup, pur si simplu anii nu sunt la fel.
Unul dintre ei are un an usor, liniar, stie in fiecare zi ce are de facut, pe cand intr-un startup fiecare zi e o surpriza, fiecare ora aduce ceva nou. Ai nevoie de tehnologii noi si multa viclenie sa ajungi in fata utilizatorior. inveti marketing, positionare, dezvoltare. Inveti ca un produs nu e de fapt creat sa faca pe plac “board-ului de conducere” ci intradevar sa ofere o anumita valoare unui utilizator.
Si poate cel mai important, inveti ca rolul unui developer nu este sa livreze feature-uri pe banda rulanta, ci sa rezolve o problema, cat de mica, dar bine. multi isi petrec toata viata traind aceasta minciuna.
Cum poti depista un developer valoros chiar daca anii lui de experienta nu sunt atat de multi:
1. Bazeaza-te pe cicluri complete de viata ale proiectelor.
De cate ori a dus un proiect end to end la capat, de cate ori a trecut prin toate ciclurile lui de viata, sau macar un feature, cate feature-uri a implementat de la un capat la altul?
2. A scris cod pentru un tool intern (presiune mica), pentru o aplicatie b2b (presiune mai mare) sau pentru sute de mii de utilizatori, unde e necesar sa stii sa optimizezi si sa scalezi resursele.
3. Cat de mult rau ar fi putut face daca ar fi produs o greseala, ar fi trecut neobservat, doar cativa utilizatori poate se bazau pe acel feature sau putea pune “in cap” tot sistemul daca a lucrat doar pe core value internals. Locurile unde “se intampla magia”.
Bonus points, a vorbit vreodata cu un utilizator de al aplicatiei, macar un minut. Sa inteleaga de ce face ceea ce face, sau face fara sa intrebe, a inteles valoarea ultimului proiect ce l-a creat. Daca il intrebi ce facea aplicatia, iti descrie feature-uri sau beneficiile aduse utlizatorului?
E timpul sa nu mai masuram lucrurile in unitati simple, usor de vizualizat si creat grafice pe ele, e ca atunci cand o aplicatie isi masoara succesul in feature-uri nu in numarul de utilizatori fericiti.
De ce facem asta? O facem ca e usor, accesibil, usor de inteles pentru toti, dar de cele mai multe ori ajungem frustrati cand vedem ca anii copy paste, nu prea aduc si ceea ce cautam.
Daca esti developer, take a step back, citeste-ti profilul, CV-ul, prezinta unitati usor de masurat sau prezinta valoarea ce ai adus-o in proiect/firma?
Daca esti recruiter, te bazezi doar pe anii de experienta? Ce alte “trucuri” mai folosesti, as vrea sa le stiu 😄. Hai la o cafea 😄
Pe curand.
