Niveluri de competență

Gabriela

Gabriela

Dominion
Deep C (and C++) by Olve Maudal and Jon Jagger

Programming is hard. Programming correct C and C++ is particularly hard. Indeed, both in C and certainly in C++, it is uncommon to see a screenful containing only well defined and conforming code. Why do professional programmers write code like this? Because most programmers do not have a deep understanding of the language they are using. While they sometimes know that certain things are undefined or unspecified, they often do not know
why it is so. In these slides we will study small code snippets in C and C++, and use them to discuss the fundamental building blocks, limitations and underlying design philosophies of these wonderful but dangerous programming languages.
Click to expand...
 
Multe din problemele de-acolo sunt mai mult muscle flexing, just for fun, un fel de bârfit C/C++. Foarte rar întâlnești cazuri în care chiar ai nevoie de ele, iar utilizarea lor e în multe cazuri contraproductivă. Variabile neinițializate? No fscking way. Da, teoretic vezi un "int i;" și ar trebui să te uiți imediat "e global, e static, e....", dar nu e mai simplu să faci un code style în care pur și simplu inițializezi tot, și nu-ți mai pui problema, ca să poată face debug și junioru', când vine de la cumpărat covrigi? Structuri împachetate? În afară de calcule cu pointeri linux-kernel-style (care arată groaznic, dar funcționează în orice situație), nu prea te interesează dacă sunt sau nu împachetate. Și să vezi distracție dacă folosești biblioteci care folosesc altă împachetare. i=i++? În C e nedeterminat (și unele compilatoare chiar îți zic asta), în Java nu e. Faptul că știi asta nu înseamnă că ar trebui să folosești așa ceva - ștergi prostia și o înlocuiești cu ce-ți trebuia de fapt.

Din păcate, un om care știe standardul, compilatorul și mașina la nivelul ăla nu lucrează pe alune, și mai trebuie să-i dai și ceva interesant de făcut, plus colegi de la care să învețe, că altfel se plictisește și pleacă. Sunt foarte puține proiecte în care se ajunge la nivelul ăla de detalii, în restul de 99.99% te mulțumești cu unu' care nu-ți dă baza jos cu un "delete from table1;" (unde table1 are al naibii de multe rânduri).
 
Nu am lucrat pana acum cu dezvoltatori in C pentru ca nu am avut nevoie, dar ca idee amatorul din articol e nivelul mediu al majoritatii dezvoltatorilor pe care i-am intalnit. Am dat si de cativa aproape de nivelul celalalt (unul in Java si unul in .Net/SharePoint care chiar m-au facut sa ii tin minte), dar prea putini. Pentru mine e un articol bun cand se pune problema la genul "ce inseamna nivel de competenta X" pentru ca in ultimii 2 ani am facut parte dintr-o echipa care incerca sa standardizeze intern asa ceva si de prea multe ori le-am spus "asta nu e nivel avansat, e nivel mediu, iar ce considerati mediu e doar incepator" fara sa imi fie usor sa le spun atunci ce ar fi avansat si ce ar fi expert. Le-am facut o data o lista de cerinte pentru VBA pe post de exemplu, au luat-o ca etalon si pana acum nu e nimeni certificat nici macar la nivel mediu :p
 
De stabilit bareme pe care să nu le atingă nimeni e ușor, dar nu e productiv. E un clopot Gauss, foarte puțini de top și destui medii (ăia slabi se cern mai ușor). Pe cei medii îi faci să se înțeleagă între ei cu code styles, patterns & tdd, iar dacă ai unul de top îi dai să rezolve probleme serioase, și să rezolve chestii pe care nu le reușesc ceilalți. Partea faină e că ăia medii/slabi nu-s foarte interesați de programare și au mai mult timp liber, așa că se promovează mai mult. Și devin șefii ălora care fac treabă, iar asta e dezastruos. În proiectul actual am "convins" un technical team lead de la furnizor să scrie în documentația de operațional că e normal să apară deadlocks în timpul rulării aplicației (după ce au încercat să le rezolve și nu s-au priceput), și chiar a făcut asta; a fost distracția biroului o bună perioadă de timp. Acum vreo lună a auzit întâmplător un coleg de-al lui de asta, s-a crucit, și până la urmă le-a zis el și cum se rezolvă, chiar dacă n-avea legătură cu proiectul respectiv.

Câteva link-uri strânse în timp ce încercam să standardizăm și noi nivelurile de competență, poate te ajută:
https://sites.google.com/site/steveyegge2/five-essential-phone-screen-questions
http://sijinjoseph.com/programmer-competency-matrix/
http://www.joelonsoftware.com/articles/Unicode.html
http://www.jfsowa.com/logic/math.htm

Și dacă tot suntem aici, link dump:
http://lwn.net/Articles/250967/ ( + link-urile către următoarele părți)
http://aosabook.org/en/index.html
http://programmer.97things.oreilly.com/wiki/index.php/Contributions_Appearing_in_the_Book (și http://programmer.97things.oreilly.com/wiki/index.php/Other_Edited_Contributions)
 
miahi said:
De stabilit bareme pe care să nu le atingă nimeni e ușor, dar nu e productiv.
Click to expand...
Nu asta fac; stabilesc bareme pentru niste nivele si apoi stabilesc tinte de atins in functie de nevoi. Am in vedere nu programatori, ci vreo 300 de oameni care conduc proiecte de dezvoltare cu furnizori externi. Pentru asta trebuie sa aibe un nivel minim de competenta, ori de baza ori mediu daca proiectul e complicat si important. Problema mea e ca am gasit domenii in care baremul pentru avansat (intr-un sistem in 4 trepte, basic-proficient-advanced-expert) era foarte simplist. Nu exista barem si tinta de expert pentru ca nimeni nu e programator si nivelul exista doar pentru a fi clar ca "advanced" nu e limita cunostintelor.
Exemplu: pentru un proiect mediu in SharePoint (cam 500.000 USD, sa zicem) recomandarea pentru persoana respectiva e proficient in SharePoint si basic in SQL daca exista si custom databases; daca nu are cunostintele respective vine furnizorul cu o oferta aiuritoare gen pret triplu, hardware de 2 ori mai mult decat e nevoie si care nu se integreaza corect cu restul sistemelor (fara single sign on e cel mai raspandit caz) etc. Pentru asa ceva daca omul stie macar sa programeze un pic in VB cat sa inteleaga codul scris de furnizor, sa stie ce e un memory leak, care sunt API-urile si obiectele de baza din SharePoint (daca poti sa scrii intr-o lista SP dintr-o aplicatie .net si ce iti trebuie pentru asta) e o cerinta de bun simt.

Dar daca stie sa faca asta si pretinde ca e SharePoint guru black belt code-fu master e aiurea si de-aia vreau un barem rezonabil care sa spuna: nu, esti proficient, taci si fa-ti treaba in continuare.
miahi said:
Partea faină e că ăia medii/slabi nu-s foarte interesați de programare și au mai mult timp liber, așa că se promovează mai mult. Și devin șefii ălora care fac treabă, iar asta e dezastruos.
Click to expand...
Sau au o cariera cu alt curs, nu neaparat ca se promoveaza mai mult. Am o colega, mi-a fost intern la inceputuri, acum e un nivel peste mine, dar s-a mutat in alta zona, alta tara si a avut alte oportunitati de cariera; e fata buna si competenta, faptul ca a avansat mai rapid si mai sus a fost doar o conjunctura favorabila si fara nici un context negativ.
Partea frumoasa e ca atunci cand a venit nu stia ce e o baza de date relationala, dupa vreo 2 ani rula queries complexe peste weekend (lua cate 8-10 ore executia) si a invatat tot ce trebuie sa stie si chiar mult peste cei de nivelul ei. Exista si cazuri fericite, asta e morala. Da, la fiecare caz fericit stiu inca 5 din alea de care zici mai sus, dar asta e viata.

Sau e cazul unora care se pricep la management mai mult decat la programare si atunci fac o treaba mai buna in jobul ala. Am un coleg de echipa din Manila care are ca punct forte project management, dar nu e prea bun pe parte tehnica. Cine crezi ca a fost pus sa faca tot ce tine de PM in proiectele curente pentru toata echipa? Acum toata lumea stie care e expertiza fiecaruia in echipa si nu isi pune nimeni problema "de ce e x PM si y e doar team member cand y stie mult mai multe decat x despre SAP?". A intrebat cineva, apoi ne-am obisnuit sa punem in documentatia de initiere a proiectelor: X e PM, Y e technical lead, Z e user experience specialist - nu au mai fost intrebari vreodata.

Face cineva un split? Cred ca gasim un loc potrivit sa punem asta.
 
You must log in or register to reply here.
Back
Top