Comment juger un développeur?
Par Jean-Baptiste le jeudi 12 février 2009, 16:35 - General - Lien permanent
La question est classique, mais le débat est revenu plusieurs fois ces dernières semaines ou moi au d'autres collègues avons du faire passer quelques entretiens. C'est une question bien entendu très ouverte, donc je vous laisse vous défouler dans les commentaires 
Très personnellement, je ne pense pas que l'on puisse juger quelqu'un à la somme de ses connaissances. Mieux vaut une tête bien faite qu'une tête bien pleine comme disait l'autre. Donc, contrairement à ce qu'on pourrait penser, même si par curiosité je vais demander, je ne vais pas attendre de quelqu'un qu'il sache tout de l'agilité, des principes SOLID, de DDD etc. etc. Je vais sans doute me moquer encore plus des connaissances encore plus techniques comme les détails d'mplémentation de tomcat ou ses différents connecteurs. Mais alors qu'est-ce qui importe? Ce qui importe, c'est que tous les éléments que je viens de citer peuvent s'apprendre. C'est donc mon premier grand point: savoir et vouloir apprendre.
Ensuite, à mon sens ce qui fait le plus la qualité d'un développeur c'est la qualité de son code. Oh la belle phrase. Qu'est-ce que ça veut dire? Essentiellement pour moi qu'il est maintenable. Comment rend on le code maintenable? Essentiellement en lui donnant du sens. Ca a peut être l'air tout con comme ça, mais j'ai très personnellement le sentiment qu'en France le code est très mal vue, et que globalement la grande majorité des formations que nous recevons sont à base de "le code c'est le mal, mais plus tard vous serez chef de projet et vous en ferez plus". A partir de là pourquoi dépenser des efforts dans quelque chose qui est apparemment par définition imbitable et chiant?
Mais je digresse, pour résumer en deux principes, voilà finalement ce que je recherche:
- amélioration continue
- donner du sens au code
Ce qui me plaît dans ces deux principes, c'est qu'ils permettent de juger tant les débutants que les vieux routiers. Une fois que ces deux qualités sont identifiées, il suffit d'estimer "l'avancement" sur le chemin. Par exemple, donner du sens au code commence par bien nommer ses variables, et continue (bien) plus tard par DDD.
Commentaires
Pour juger un développeur je demande s'il maîtrise en lisp. Si oui, il peut tout apprendre et tout faire :D
J'aurais bien vu relationnel et rigueur. En fait, c'est comme la différence entre un mauvais et un bon chasseur... bon ok je sors
Il me semble que ton premier critère va nécessairement intégrer le deuxième.
On en revient à une discussion que j'ai tenue avec Jérôme : que faire d'un développeur qui n'a pas envie d'évoluer et qui se satisfait de ce qu'il sait? Et bien quand on est tout en bas de l'échelle et qu'on a pas son mot à dire, on fait avec... VDM.
Tu as bien de la chance de pouvoir recruter.
Je ne suis hélas pas en position de donner le dernier mot Michael
Je fais passer quelques entretiens et je donne mon avis.
Ensuite, c'est vrai que l'on peut considérer qu'amélioration continue et sens sont deux principes assez liés, mais je maintiens ma séparation pour le moment, car j'ai croisé des profiles qui était passionné de technique pure, mais alors la gueule de leur code, ils en avaient rien à foutre. Ca rejoint je pense ton avis Jérôme sur le relationnel, car finalement rendre son code lisible, c'est respecter ses collègues. Le relationnel on est d'accord c'est plus que ça, et c'est vrai que je devrai l'ajouter à ma liste, mais c'est un peu implicite finalement dans un entretien je trouve, de s'entendre avec le candidat.
La rigueur je l'inclue peut être à tord dans l'amélioration continue.
http://www.cio.com/article/478106/H...