La raison est simple : Sur quels points juger un bon développeur ? Est ce que l’on doit juger son côté technique ? Sa manière d’aborder les problèmes ? De les résoudre ? Tout cela à la fois ?

Evidemment, l’analyse qui suit est personnelle et fondée sur mon expérience, elle n’engage donc que moi. N’hésitez pas à me donner vos points de vues en commentaire

Le métier de développeur est quelque chose de complexe. Il nécessite des compétences diverses et variées qui s’écartent du code en lui-même la plupart du temps.

La logique reste le plus grand ami du développeur, elle permet d’aborder les problèmes sous un autre angle et de trouver une piste le plus rapidement possible pour le résoudre. Un bout de code reste avant tout une manière logique de résoudre un problème donné.

C’est ici qu’entre en jeu l’algorithmique, processus immuable pour réaliser la moindre ligne de code. Cette « science », si je peux me permettre le mot, est l’essence même du développement : Sans algorithme, point de code. Un bon développeur serait-il donc uniquement une personne dotée d’une grande logique ?

Pas vraiment. J’en arrive au point qui est le plus souvent mis en avant, et pas toujours à juste titre, l’aspect technique. En effet, un développeur se doit de posséder une maîtrise technique approfondie du langage et des outils qu’il utilise. Quelqu’un qui ne connait que l’aspect théorique de la programmation ne pourra jamais rivaliser avec un développeur qui maîtrise son sujet, techniquement parlant.

On pourrait en arriver à la conclusion toute faite qu’un bon développeur est quelqu’un de logique et de calé techniquement. Il s’avère que cela est vrai, mais pas tout le temps. Certaines autres qualités sont (trop ?) souvent passées sous silence et représentent pourtant, à mes yeux, des atouts loin d’être négligeables.

Même si je parle dans cet article d’un développeur en tant que personne, il ne faut pas oublier que 95% des développements, si ce n’est plus, sont réalisés en équipe. Je me demande presque si ce point n’est pas plus important que les deux autres au dessus. Un développeur se doit d’être conscient du fait qu’il fait parti d’une équipe, d’un tout et il doit mettre tout en oeuvre pour que son travail s’inscrive dans la dynamique de ce même groupe.

Si l’on devait mesurer l’efficacité d’un groupe de développement, on le ferait surement en mesurant la durée nécessaire pour réaliser un programme donné. En suivant cette idée, même en ayant des développeurs parfaits sur le plan algorithmique ou technique, je pense que le temps perdu à récupérer des individualités commises suffirait amplement à faire gagner une réelle équipe, moins bonne sur ces plans là mais soudée. Une équipe où chacun des développeurs code pour que les autres puissent passer derrière sans avoir à se prendre la tête. On gagne du temps, sur sa propre relecture, sur la relecture du voisin, les différentes phases de debug et j’en passe…

Un dernier point qui rejoint également celui là est la méthodologie. Pareillement, ce point est bien (trop ?) souvent oublié à mon gout. A une époque où les méthodes agiles sont incontournables, la méthodologie du développeur se doit d’être travaillée et réfléchie. Un développeur ne peut se permettre d’organiser son code n’importe comment, de nommer ses variables d’un nom incompréhensible et de faire d’innombrables horreurs qu’il est donné de voir bien trop souvent.

Encore une fois, le temps perdu à essayer de comprendre ce que mon voisin a essayé de faire (même si l’algorithme est optimisé et adapté au maximum à la technologie) est énorme lorsque le code est illisible et indéchiffrable. Je vais devoir le déranger pour pouvoir enfin comprendre et me mettre à travailler dessus. Résultat, on perd le double de temps car pendant que mon collègue essaye de m’expliquer le raisonnement logique qui lui paraissait évidente, il ne code pas non plus.

Cette dernière question soulève le problème des commentaires : Faut-il en mettre, ne faut-il pas en mettre ? Personnellement, j’ai appris le métier de manière scolaire en commentant mon code et en l’apprenant de manière professionnelle, j’ai appris à ne plus en mettre. Les raisons sont multiples : Les commentaires permettent de se contenter d’un code peu clair parce qu’on peut fournir le reste d’explication dans le commentaire alors qu’un code sans commentaires se doit d’être parfaitement clair. Je citerai mon mentor qui me répétait toujours : « Un bout de code doit être auto-suffisant à sa compréhension ».

Maintenant que j’ai pu travailler dans divers environnements (Multinationales, pme, projet agiles, projet non agiles), je me rends compte que chaque conseil qu’on a pu me donner est valable et que le seul problème est de les appliquer le cas échéant. Voilà où se situe toute la magie et le dilemme permanent du développement : Faire la part des choses.

Certains « bons » développeurs sont trop « extrémistes » dans leur manière de coder. Ils savent faire une chose d’une manière et jamais ils ne se remettront en question pour envisager la chose sous un autre angle. Ils feront comme ils savent si bien le faire, sans me se soucier de la méthodologie du groupe ou de l’avis du reste de l’équipe. Ils ont leur manière de résoudre un problème donné et jamais ne la changeront.

Ca me rappelle une phrase tirée d’un livre sur l’intelligence (Que je vous conseille) écrit par le réalisateur du Palm. Je ne me souviens plus des termes exacts mais cela donnait à peu près ceci : « Pour réussir à voler, l’homme n’a pas imité les oiseaux et leur battements d’ailes : il a utilisé des ailes fixes. Pour réussir à se mouvoir rapidement, il n’a pas imité le jaguar et ses pattes véloces : Il a inventé la roue ». Cela n’a pas vraiment de lien avec le sujet, et pourtant.

Il y a un million de façons de résoudre un problème donné, c’est pour cela que des gens arrivent à « réinventer la roue » chaque jour en la perfectionnant. S’il y avait une solution magique à un problème, ça se saurait. Chacun aborde la chose d’une manière différente et la résout à sa manière.

C’est pour ça que je trouve que les meilleurs développeurs sont également ceux qui échangent. Ceux là sont heureux de donner leur point de vue mais tout aussi heureux d’en entendre un autre qu’ils n’avaient pu imaginer jusqu’à maintenant. Et c’est grâce à cela qu’ils continuent de progresser là où d’autres stagnent.

Je terminerai en citant un superbe article qui m’a beaucoup fait réfléchir à ce sujet, malgré qu’il ne date pas d’hier : « Work on projects with other programmers. Be the best programmer on some projects; be the worst on some others. »