Qu’est ce qui fait un bon développeur?
Publié le 29 April 2008, par Babozor dans la catégorie Développement, Discussion
[Article extrèmement intéressant, très juste, que je m'empresse de traduire et d'adapter...]
Qu’est ce qui fait vraiment un bon développeur? Certains diront une attitude positive, d’autres diront une bonne dose de sucre et de caféine, alors que d’autres parieront pour une absence de lumière et autant d’écran qu’un bureau peu supporter.
Tout le monde a des anecdotes avec des développeurs avec lesquels ils ont travaillé qu’ils trouvaient brillants. Malheureusement, la plupart du temps, ce jugement n’était pas basé sur la qualité du code produit, ou le fait de respecter les deadlines, mais sur des critères bien moins importants, comme le fait que le développeur connaissait le nom de ses collègues, le nombre de lignes de code qu’il était capable de produire ou combien ils semblaient professionnel en parlant de leur travail.
Malheureusement, les meilleurs développeurs sont une race difficile à apprivoiser. Voici donc une liste, qui n’est certes pas applicable à tous, mais qui pourrait vous aider à repérer un bon développeur.
Pessimiste
Les bons développeurs son toujours pessimiste par rapport à leur travail. Cela ne veut pas dire qu’ils sont abattus, sans vie ou même ronchons, mais juste qu’ils pensent toujours aux choses qui iront de travers et comment gérer cela.
Ils estiment qu’à un moment ou un autre ils devront casser une partie du code déjà effectué, que le hardware risque de crasher, que la sécurité risque d’être compromise, et que de façon ultime le bureau risque de partir en cendres. Les plus brillants penseront à tous ces événements arrivant en même temps. Et ils ne seront pas content avant d’avoir un plan spécifique, mis en action et testable pour contrer tous ces problèmes. Même avec ça ils ne seront toujours pas complètement tranquille.
Les développeurs pessimistes seront ceux qui trouveront toujours des défauts dans les idées, et la chose importante en travaillant avec eux à se rappeler c’est qu’ils ne le font pas pour ruiner votre merveilleuse idée, ils le font pour s’assurer que l’idée qui se transformera en projet a bien été pensée et que la plupart des problèmes possibles ont été anticipés. Cette attitude névrotique, paranoïaque et pessimiste est exactement ce que vous devez chercher chez un développeur, si vous chercher un code robuste, sûr et fiable.
Au contraire, un développeur optimiste sera enclin à penser que le code fonctionnera correctement, ou qu’il est sûr et vous donnera une deadline pour votre projet sans se soucier des problèmes qui l’attendent au tournant.
Feignant
La feignantise n’est jamais vu comme une qualité, et la plupart du temps ce n’est pas le cas. Ce qui par contre est désirable est la personne qui ne veut pas des tâches répétitives, ou gaspiller du temps à faire ce qu’une machine pourrait faire à sa place, ou encore écrire du meilleur code maintenant pour éviter d’y retoucher plus tard. Un développeur feignant est celui qui construit une librairie de code réutilisable, ou veut un processus de fabrication automatisé, plutôt qu’une série de copier/coller, ou encore des procédures de test unitaires rapides et simples, ou écrire du code surchargeable même si ce n’était pas demandé (plutôt que d’avoir à le refaire plus tard).
En bonus, en général un développeur feignant est celui qui essayera de garder le projet dans les rails et centré sur son objectif principal.
Par exemple, en designant une structure de catégorie, un développeur feignant assumera une structure 1-N (ou N-N), même si pour l’instant les besoins sont de type 1-1. Pourquoi? Parceque cela peut arriver un jour, et c’est plus simple de le faire maintenant que de le modifier après.
Curieux
Les bons développeurs s’ennuient souvent avec des tâches répétitives (cf Feignant) et passent une partie de leur temps à tenter de trouver des problématiques intéressantes à résoudre.
Les développeurs curieux seront constamment à la recherche de nouveaux problèmes à résoudre, et de meilleurs moyens pour résoudre d’anciens problèmes. Ils seront ceux qui encourageront à utiliser de nouvelles façons de travailler et transformeront constamment les systèmes existants. Ce seront aussi les plus conscients des problèmes actuels dans leur environnement de travail, et essayant de corriger ces problèmes. Les développeurs curieux ont en général une grande connaissance, pas seulement dans leur domaine ou langage, mais aussi de langages, solutions ou technologies alternatives.
La curiosité engendre souvent la créativité, un point aussi très désirable chez un développeur. Un profond désir de trouver des voix alternatives à un problème quand toutes les façons conventionnelles ont été usées est toujours utile. C’est ce genre de mentalité qui engendre “une pensée en dehors de la boîte” et du code créatif.
Méticuleux
Beaucoup de bons développeurs s’attachent aux détails. Ils demanderont de la constance dans leur travail, en particulier dans leur équipe (ils prennent en main par exemple, les standards et conventions de nommage par exemple). Ils voudront des tests unitaires et une revue de code régulière. Ils voudront que tout le monde dans l’équipe documente et annote son code. Ce seront ceux aussi qui vous embêteront avec les messages de log sous SubVersion (ou un autre logiciel de versionnning).
Ils seront aussi les plus pointilleux dans la communication, n’hésitant pas à poser des questions paraissant évidentes, juste pour être sûr de bien avoir compris la problématique. C’est d’autant plus vrai dans les rapports de bug par exemple. Même si ils ne sont pas souvent des communicants passionnés, ils sont souvent capables d’expliquer les concepts de façon clair et précise. Cette clarté est un avantage indéniable dans un environnement de production, en particulier si l’apprentissage est encouragé.
Article merveilleux qui résume toutes les qualité d’un bon développeur (en tout cas pour moi).
Par expérience, la bonne maîtrise d’une technologie ou d’un langage ne suffit pas, c’est surtout l’approche de la personne face au travail ou à certaines problématiques qui font de cette personne est très bon développeur.
Et vous vous en pensez quoi de cette définition?


le 29 April 2008 à 15h00
Larry Wall, l’inventeur de Perl, disait qu’il y avait trois vertus cardinales pour le bon développeur : la feignantise (évident), l’impatience, et une “certaine-huate-estime-de-soi-et-son-travail” (en anglais: hubris).
L’impatience, c’est parce que le bon développeur veut que sa solution soit la plus rapide à mettre en place, et la plus efficace en terme de perfs.
“hubris”: c’est qu’il faut pouvoir être fier de son travail, au point de ne pas avoir honte de montrer le code à quelqu’un d’extérieur. Si on a bien commenté, bien documenté, bien testé, écrit un code lisible, alors on peut le montrer à quelqu’un et faire preuve “d’hubris”. Histoire que quelqu’un qui jette un oeil au code ne s’exclame pas : “mais c’est quoi cette merde ?”
http://en.wikipedia.org/wiki/Larry_Wall
le 30 April 2008 à 09h45
Ah ! je suis bien contente de voir la feignantise enfin reconnue, moi qui l’ai toujours considérée comme une qualité à remarquer ! Car, pour être pénard… il faut bien cogiter pour préférer le plus court chemin, pour s’épargner de recommencer plusieurs fois la même chose, etc. Et contrairement à ce qu’on croit, la feignantise est loin d’être couramment répandue. Hélas.
le 12 April 2010 à 13h59
Excellent !!
Je suis d’accord à 100%.
“Les développeurs curieux seront constamment à la recherche de nouveaux problèmes à résoudre, et de meilleurs moyens pour résoudre d’anciens problèmes.”
Haha c’est trop vrai !
le 10 November 2010 à 13h43
être un bon développeur, c’est d’abord être capable de résoudre un problème sans le traduire dans un langage informatique puis être a la fin capable de le transcrire dans un langage informatique tout en optimisant le code avec les connaissances qu’on a ce langage et ses astuces.
exemple, pour faire la somme de 1 à un nombre N. au lieu d’écrire:
pour i=1 à N
somme=somme+i
fin pour
on écrit astucieusement:
somme=N(N+1)/2
cela gagne plus du temps car tout le monde le sait, le processeur prend beaucoup du temps dans des boucles donc la deuxième instruction est optimisée