Quelles sont les qualités réelles d’un bon développeur ?
traduit de “What Makes a Great Developer?”
Publié le 17/04/2007, 2008 : www.addedbytes.com
D’aucun pourrait parler d’une attitude positive. D’autres pourraient parler de son régime alimentaire, riche en sucre, dopé à la caféine ou nourri exclusivement à la bière belge. On pourrait le repérer parce qu’il n’a jamais été exposé au soleil ou parce il y a tellement d’écrans sur son bureau qu’il n’y a plus de place pour en rajouter un.
On trouvera toujours sans problème quelqu’un pour raconter des anecdotes à propos des développeurs avec qui il a travaillé en le décrivant comme un être bourré de talent. Malheureusement, la plupart du temps, ce jugement n’est pas établi sur la qualité du code, ou le respect des délais, mais sur des critères moins pertinents, comme le fait que le développeur connaisse ou pas le nom de ses collègues, le volume de lignes de code qu’il produit ou sa propension à se confier quand il parle de son boulot.
Malheureusement, les meilleurs développeurs ne sont pas forcement repérables de façon évidente. Même si la description qui suit ne s’applique pas forcement à tous les environnements de développement, voici quelques unes des qualités à repérer pour détecter un bon développeur.
Pessismiste
Les bons développeurs sont pour la plupart toujours pessimistes en ce qui concerne leur travail. Cela ne signifie pasque par ailleurs ils ne soient pas optimistes, actifs et énergiques voire même gai – c’est juste qu’il penseront toujours à ce qui peut mal tourner et comment le gérer.
Ils sont capables d’imaginer qu’à un moment donné il puissent avoir à recommencer un job complètement bouclé, parce que la machine plante, ou que la sécurité soit compromise, ou que leur entreprise disparaisse totalement dans un incendie. Les plus talentueux d’entre eux supposeront même que tout cela arrivera le même jour. Et il ne seront satisfaits que si le projet comprend des actions spécifiques, opérationnelles, testées – complètement testées – pour gérer ce genre de problèmes. Et encore leur satisfaction ne sera jamais totale.
Les développeurs pessimistes sont de ceux qui trouvent en permanence des imperfections dans les idées, et le truc important qu’il faut retenir en bossant avec eux est qu’ils ne font pas cela parce que les idées ne viennent pas d’eux ou pour casser les idées de autres – ils agissent pour s’assurer que les idées qui vont devenir des projets sont correctement posées et leurs conséquences imaginées jusqu’au bout et qu’un maximum de problèmes ont été anticipés à l’avance. Cette attitude névrotique, paranoïaque, finalement pessimiste est exactement celle que vous devriez rechercher si ce que vous attendez de votre développeur est qu’il produise du code robuste, sécurisé et fiable.
Au contraire, un développeur optimiste aura plutot tendance à s’assurer que le code fonctionne, ou qu’il soit sécurisé, ou encore il donnera un délai pour un projet sans envisager les pièges potentiels.
Il est du genre à dire : “et que se passe-t-il quand çà tourne mal ? “
Paresseux
La paresse n’est pas habituellement vue comme une qualité, et dans notre cas je ne parle pas de la paresse “je la ramène mais je fais semblant de bosser” ou de la paresse genre “pff.. y’a 3 lignes à écrire et c’est fait”. Je parle de la volonté de ne pas passer son temps à faire des taches répétitives, ou celle de ne pas perdre son temps à faire ce qu’une machine peut faire, ou encore de chercher à éviter de dépenser du temps et de l’énergie plus tard en commencant par écrire du code meilleur tout de suite.
Un développeur parresseux est celui est celui qui construit une bibliothèque de code réutilisable, ou qui veux metre en place une méthode de construction complètement automatisée plutot que travailler manuellement à coup de copié-collé, ou qui veut un systeme de test automatisé et complet, ou encore il écrira un code adaptable à des situations pas forcement prévues formellement par les spécifications (plutot que de le revoir plus tard).
En prime, un développeur paresseux est de ceux qui reussira à maintenir un projet centré sur ses objectifs primitifs, plutot que de tenter de faire plus de travail dans le même temps, en s’éloignant de fait des caractéristiques initiales de la fonction a développer.
Par exemple, en décrivant une structure de famille ou de catégories, un développeur paresseux pourrait imaginer un lien relationel de plusieurs à plusieurs entre les catégories parentes et les sous-catégories, même si les spécifications décrivent que cela doit être liées par une relation de un à plusieurs. Pourquoi ? Parce qu’on pourrait un jour en avoir besoin, et que dans ce cas ce choix d’écriture dès le début est préférable au fait d’y revenir plus tard.
Il est du genre à dire : “Il doit y avoir moyen d’automatiser çà. “
Curieux
Les bons développeurs sont comme le docteur House. Ils s’ennuie facilement du travail répétitif (voir “Paresseux”) et passent la plupart de leur temps en consacrant une énergie significative à la recherche de problèmes intéressants et gratifiants (encore mieux si nouveaux) à résoudre. Moins ils passent de temps aux taches répétitives plus la fréquence des défis augmente.
Les développeurs curieux sont à la recherche permanente de nouveaux problèmes à résoudre, et des meilleures façons de résoudre les problèmes rencontrés avant. Ils seront de ceux qui encouragent les nouvelles méthodes de travail et vont constamment essayer de remettre en question les systèmes existants pour les améliorer. Ils sont aussi de ceux qui sont le plus au fait des failles ou défauts de leur environnement de travail actuel, tout en travaillant à l’améliorer. Les développeurs curieux ont plutot des capacités ou compétences étendues, pas seulement dans leur(s) langage(s) de prédilection, mais aussi sur les technologies liées à celui-ci ou ceux utilisés pour parvenir a des fins similaires.
Les développeurs curieux (ou ceux qui s’ennuient facilement) sont souvent les moins coincés dans leurs avancées – les plus ouverts au changement. Ils ont certainement besoin de se poser les bonnes questions (ce qui n’est pas une mauvaise chose) avant de changer de methode de travail si celle ci est présentée comme meilleure. Mais si il s’agit d’améliorer la production et qu’elle permet de dégager plus de temps à consacrer aux problèmes interressants, ils adopteront la démarche avec un minimum d’hésitation.
La curiosité engendre la créativité, une autre caractéristique souhaitée chez le développeur. Une volonté forte d’établir la cause d’un problème et de le régler aide à se motiver pour évoluer en accomplissant des progrès tangibles. C’est ce type de cablage mental qui stimule et développe la reflexion originale et pertinente et qui induit un codage créatif.
Il y a des chances pour que la meilleure carte du développeur curieux soit ce désir de détecter et de régler un problème plutot que juste faire un rapport sur la faille.
Il du genre à dire : “Il y a surement une autre façon de voir “
Pointilleux
La plupart des bons développeurs sont des champions du détail. Leur travail se doit d’être homogène ainsi que celui de leur équipe (une forte préoccupation pour l’application de conventions communes de codage ou de nommage, par exemple). ils voudront des procédures de tests, et une révision du code par leurs collegues. Ils souhaitent que tous dans l’équipe commentent et documentent le code. Ils sont du genre tatillon sur l’enregistrement de rapports sur l’évolution du développement et ses différentes versions.
Ils seront aussi méticulleux sur le plan de la communication, et heureux de poser des questions pertinentes, simplement pour être certain d’avoir bien compris. Ce qui est particulierement vrai sur le plan des rapports de bugs. Alors qu’il ne sont pas forcement de grands communicants, ils sont la plupart du temps capables d’exprimer des concepts clairement et efficacement. Cette clarté est un avantage déterminant dans n’importe quel environnement de développement, et en particulier quand la formation et l’apprentissage sont encouragés.
Il est du genre à dire : “J’ai juste 2 ou 3 questions à poser … “