Cette fois vous vous dites, c’est sûr, l’auteur de ce post a fumé la moquette. Sans doute. Mais, cette moquette a à voir avec celle dont Woody Allen a dit : « Le doute me ronge. Et si tout n'était qu'illusion ? Si rien n'existait ? Dans ce cas, j'aurais payé ma moquette beaucoup trop cher ». Autrement dit, le réel n’est pas loin.

 

Impatience

Lequel d’entre nous n’a pas pesté devant son ordinateur trop lent à faire telle ou telle opération – dont souvent celle de démarrer. Un développeur impatient, c’est un développeur qui veut que ses programmes s’exécutent rapidement. C’est un développeur qui va chercher des algorithmes efficaces et qui les codera de façon robuste. C’est un développeur qui teste l’efficacité sur des données réelles et variées et pas seulement sur quelques tests simples. L’impatience du développeur va de pair avec celle de l’utilisateur et est un gage de satisfaction pour celui-ci.

Paresse

Je me souviens d’un étudiant qui au cours de sa thèse devait vérifier une condition entre les différents triangles qu’il manipulait. Il avait écrit pour cela plus de 800 lignes de code… qui buggait. J’en discute avec Jean-Pierre Uhry, son directeur de thèse et ancien dirigeant d’Alma. « Ça doit se faire en 50 lignes », « Je parie moins » me répondit-il. Quelques formules mathématiques et minutes plus tard, nous l’avions en 22 lignes.
La paresse pousse à faire des efforts pour, au final, écrire moins de code en écrivant du code plus générique, plus factorisé. Elle pousse aussi à bien documenter pour vous éviter de perdre du temps plus tard soit quand vous le reprendrez, soit pour l’expliquer aux autres. La paresse est sans doute un des moteurs les plus puissants de l’innovation : de la préhistoire à nos jours, l’invention d’outils de plus en plus sophistiqués économise le travail humain.

Orgueil

Vous avez un ego sourcilleux, vous supportez mal les critiques. Le mieux est qu’on ne puisse pas vous en faire. Pour cela, écrivez des programmes efficaces, documentez les abondamment, suivez les règles de programmation convenues. L’orgueil pousse donc dans la bonne direction ; à une petite réserve près, cela suppose que le code est partagé, ce qui devrait être la règle dans toute équipe de développeurs.

Conclusion

Commençons par rendre à Larry Wall ce qui, maintenant, appartient à tous (c’est le sort des idées) : c’est à l’inventeur du langage Perl que l’on doit ce triptyque des qualités du bon développeur. Un des meilleurs moyens de mettre en pratique ces conseils est de recruter des développeurs qui se sont illustrés dans l’open source. En effet, quoi de plus exposé aux regards et à la critique des autres que les codes open source et, c’est une constatation pratique pas seulement une déduction logique, ces codes sont d’une qualité bien supérieure aux codes propriétaires.
Le faisons-nous ? Pas assez. Refrain connu : ce sont aussi nos contradictions qui nous font vivre.