Dinamica junior-senior

Useless sau nu, sunt un fel de a imparti responsabilitatea, daca e vro problema grava mai degraba tu ca senior care ai facut review o sa pici, nu ma refer ca te da afara, insa la marire sau avansare e un punct / pretex sa te refuze.

Ce vroiam sa evidentiez, pt mine e mult mai stresant sa ma uit pe un PR la un junior, trebuei sa ma uit la fiecare virgula, sa ma gandessc la cazuri la care nu sa gandit, pe cand la un senior ma uit asa in mare, mai relaxat, nu dupa orice posibil NPE.

In fine, poate eu am lucrat in medii mult mai cutthroat decat domnul, @Floris_Stoica_Marcu, dar imi amintesc clar un bug la o aplicatie financiara si sa pierdut bani, iar un ochii celor la nivel mai sus, cel mai de vina a fost senior-ul care a facut review, chiar daca nu i s-a zis in fata, s-au poate chiar i s-a zis, dar erau apropro-uri, gen, “dar cine a facut review”, sau … “nu ma astept de la x care e junior dar…” etc.

Cat despre pur si simplu vorbesti cu managerul si ii explici se rezolva, din contra eu am vazut ca managerul ori devine defensiv pt ca suna ca o critica la competenta lui, sau esti vazut ca te plangi, ori ca primesti asigurari, si da, da, da dar nimic nu se schimba concret in the numar, nu mai zic ca managerii au fost mereu foarte busy, si ocupati cu probleme mai mari, si anume sa multumeasca pe cei de care depinde proiectul, ceea ce apob.

Nu te-ai gandit ca se scrie “s-a gandit”

“Companiile mici dau vina pe oameni, cele mari dau vina pe procese”

Oricum ar fi, am vazut situatia descrisa destul de des. Nu as zice ca e vina senioriului, o parte a responsabilitatii o are toata echipa. Cea mai mare responsabilitate este totusi a juniorului care a scris codul si acela nu trebuie sa scape fara un pic de … “responsabilizare” : participare activa la rezolvarea problemei impreuna cu un senior, expunerea sa la toate efectele pe care le-a cauzat si obligatoriul “hey you fucked up, but we can fix it”. Pe de alta parte si restul membrilor echipei trebuie sa se gandeasca si sa creeze un test/plasa de siguranta ca sa nu se mai intample.

Pana la urma urmelor nu-ti iei junior sa te uiti la el, il iei sa faca parte activ din echipa, iar asta inseamna si o parte de responsabilitate.

Code review-ul este un proces care nu prinde efectiv decat problemele maxim de evidente, e un strat subtire de protectie atata tot. Daca te prinde ca si code reviewer obosit … e degeaba. Asa ca eu nu m-as stresa prea mult cu el ca ai alte layere de protectie care sunt mai robuste decat noi la 6 seara inainte sa inchidem calculatorul :slight_smile:

1 Like

Juniorii sunt cam asa: https://twitter.com/allenholub/status/1444393138492116992?s=21
Daca ii pui la treaba, plang ca nu ii tii in brate si nu le arati. Pai ce sa le arati daca ei nu stiu chestiuni elementare… E tot mai greu sa ceri profesionalism atunci cand se incurajeaza pe fiecare nivel te comporti cu ei ca si cu un prescolar. Desigur ca seniorii sunt aglomerati cand fac 2-3 joburi intr-unul si ajung la burnout.

2 Likes

Discuția asta cu junior-senior este foarte subiectivă, fiecare o privește dpdv al categoriei din care face parte. La fel ca și grupele de vârsta. Seniorul uită că a fost și el junior și juniorul nu conștientizează că va ajunge la rândul său senior. Ce proști sunt boșorogii, ce iresponsabili sunt tinerii.

5 Likes

De acord ca juniorii sunt din ce in ce mai slab pregatiti. Eu cand eram junior deja contribuisem la Debian si KDE, dar nu poti sa ceri asta de la toata lumea.

In general, se asteapta sa inveti juniorul on-the-job, ceea ce depinzand de experienta sa poate sa prinda repede sau nu. Am intrebat odata un manager care e diferenta dintre un intern si un junior si mi-a zis ca nici una, ambii fac aceleasi lucruri doar ca unul e full-time si altul nu. Aveam un intern tot pe atunci si cumva eu m-am ocupat mai mult de el, mi se parea ca se descurca ok pentru un intern. Dar cand l-am intrebat pe manager daca i se va face o oferta a zis ca in nici un caz ca nu ai vrea un junior care sta tot timpul dupa tine.

Practic daca din 100 de interni te faci cu 10 juniori buni e bine. Iar daca din acei 10 juniori, te faci cu unul care stie si nu iti intra in cale poti sa te consideri norocos.

E doar un joc de numere aici pe care poti sa il misti in favoarea ta doar daca ai un proces de interviu bun. In plus, sa nu uitam ca exista si perioade de proba. In 3 luni TREBUIE sa poti sa iti dai seama daca un om contribuie activ sau incetineste echipa.

1 Like

Eu am avut deface cu juniori chiar foarte buni, cea mai mare problema e ca nu stiu cand sa ceara ajutor si nu prea comunica intre ei.

As zice ca din punct de vedere tehnic rar exista o problema foarte mare, dimpotriva, cea mai mare problema e ca nu stiu cand sa ceara ajutor, nu se prea baga la pair programming si nici la code review. Un senior cand nu stie ceva intreaba peste tot, seteaza meeting-uri cu oameni care l-ar putea ajuta si incearca sa se foloseasca de toate resursele posibile intr-o companie, un junior va cauta doar pe Google. La proiectele greenfield e chiar bine sa lucrezi cu juniori fiindca poti sa ii convingi usor, nu trebuie sa faci tabele cu fiecare pro si cons, chiar un POC si o prezentare cu diagrame la fiecare decizie pe care o iei. (ceea ce e bine si nu e)
Un junior trebuie sa isi castige increderea si cel mai usor mod pentru asta e sa faci pair programming si sa ceri ajutor, cateodata dai de probleme chiar complicate pe care nici un senior nu le rezolva rapid si exista consens in echipa ca trebuie abordata diferit problema si ca nu tu esti de vina. Daca nu ceri ajutor o sa ajungi sa tragi echipa in spate cu velocity-ul. (stai prea mult pe un task)

Pair programming-ul e ceva ce ori merge, ori nu merge, trebuie sa exista o dinamica in echipa, sunt pur si simplu oameni cu care nu vei putea face pair programming sau mobbing, se simte ca nu va potriviti.

3 Likes