De la douloureuse productivité du programmeur

(Gabriel Scherer (gasche) @ 2010-08-28 17:04:41)

Depuis quelques billets, je suis coupable d’une forme de lâcheté et de procrastination tout à fait scandaleuse. En effet, je réponds rarement aux commentaires que les gens écrivent sur mes billets.

Dans le fond, je trouve que c’est très mal, mais j’ai aussi des excuses. D’une part, je publie souvent mes billets un certain temps après leur écriture, ou du moins le début de leur rédaction. Je suis très content quand j’ai l’impression qu’ils intéressent les gens, et je lis leurs commentaires avec avidité, mais je suis parfois moi-même un peu décalé et je renâcle devant l’effort de me replonger dans le bain, pour avoir une bonne vue d’ensemble du billet et pouvoir répondre à un commentaire en particulier.

D’autre part, vu la taille de mes billets, j’essaie plutôt de me faire discret dans la section commentaires. Après avoir attendu avec impatience les premiers commentaires, l’envie est forte d’y répondre une tartine sur le champ, mais il faut aussi savoir laisser les gens s’exprimer pour rendre du recul et ne pas écraser la conversation.

Sachez en tout cas que ce n’est pas parce que je ne réponds pas aux commentaires que je ne les vois pas. Je les lis tous, et ça me fait plaisir d’en avoir, alors n’hésitez pas à continuer.

Ce présent billet est en fait né comme une réponse à un commentaire. En effet, bien qu’il ne soit pas de moi, je me sens concerné par les commentaires sur le billet La voie de l’autodidacte (1/2). terres y a fait une remarque sur une des questions que pose rz0, remarque se plaçant en opposition à ma propre réponse. C’est intéressant et ça m’a donné envie de développer un peu plus mon point de vue. Ce qui est né comme un commentaire un peu plus long que d’habitude est finalement devenu un billet un peu plus court que les autres.

Pour bien replacer le contexte, je vais citer ici la question de rz0, la partie de ma réponse qui est concernée, et enfin la partie commentaire qui m’a fait réagir.

Question de rz0 :

Cela m’a pris un bon nombre d’années (je dirais bien six ou sept ans au moins) avant de produire du code utilisable « dans la vie ». Pour moi, il y a donc une phase improductive nécessaire, durant laquelle on apprend sans se soucier du résultat, juste pour apprendre, avant la phase productive, où, par définition, on tente de produire quelque chose (et l’on doit y sacrifier une partie du temps que l’on aurait pu passer à apprendre).

Le même constat vous a-t-il frappé ? Y a-t-il eu des rechutes dans l’improductivité ? Si oui, comment vous en êtes-vous sorti ?

Ma réponse :

Ce n’est pas l’état improductif qui est anormal ; c’est l’inverse ! Pendant l’apprentissage, tout est excitant, on essaie de nouvelles techniques et on apprend de nouvelles choses. Quand on essaie de produire quelque chose de définitif, il faut se mettre à se soucier de tous les détails pénibles (documentation utilisateur, distribution…). C’est encore pire quand on a des utilisateurs ! Se forcer à finir un produit, c’est accepter de passer du temps sur des choses sans intérêt, pour en conterpartie être utile à quelqu’un d’autre que soi-même.

Le commentaire de terres :

Contrairement à bluestorm, j’ai hâte de passer dans une phase productive pour pouvoir tester mes compétences et me rassurer sur mon niveau.

Et aussi pour ne pas avoir passé environ trois ans à apprendre sans rien produire.

En tant qu’amateur de programmation, quand j’écris un programme je m’intéresse au processus de développement, au code, etc. J’ai aussi souvent un regard de développeur sur les programmes des autres : je regarde leur code, comment ils ont transcrit leurs idées.

Par rapport à un programme, on peut aussi avoir une position d’utilisateur : on regarde le produit fini, ce qu’il fait et comment interagir avec lui. Ce sont deux aspects orthogonaux, mais que l’on peut combiner en appréciant les programmes à la fois d’un point de vue développeur et d’un point de vue utilisateur ; c’est d’ailleurs souvent comme ça que j’approche les logiciels libres.

Le terme « productif », sorti du contexte, est assez vague. Il désigne essentiellement le fait de faire un effort dans une direction avec efficacité : arriver à son but, et si possible rapidement.

Il y a donc deux ici dimensions de productivité :

La définition de rz0 est légèrement ambiguë : « produire du code utilisable dans la vie ». Est-ce qu’il est utilisable parce qu’il satisfait des standards de qualité, ou est-ce qu’il est utilisable parce qu’il est destiné à être utilisé ?

Alp semble traiter principalement le premier aspect, la productivité de développement. Ma réponse se concentrait au contraire sur le second aspect, le rapport aux utilisateurs.

Pour moi, un programme est destiné à être utilisé si l’on est dans l’une des situations suivantes :

  1. On se force à développer un programme dans le but de l’utiliser soi-même et-ou de pousser d’autres gens à l’utiliser. Situation courante chez les développeurs de petits projets libres.

  2. On est forcé par quelqu’un d’autre à écrire un programme qu’il souhaite utiliser pour répondre à ses propres besoins. Situation courante dans le monde de l’industrie, mais aussi pendant un stage, etc.

Bien sûr, il y a aussi des cas limite où la personne ayant besoin du programme est en fait un groupe de personne auquel on appartient. Je pense que pour bien distinguer les deux situations (ou un intermédiaire entre ces deux situations), il faut se poser la question suivante : « Va-t-il vous arriver quelque chose de désagréable si, finalement, le programme ne répond pas aux besoins ? »

Attention, je ne parle pas de la deuxième situation comme d’une forme d’exploitation ou de torture où le développeur est maltraité. Au contraire, je pense que c’est celle des deux que je préfère : un peu de contrainte pour garder sa motivation, des utilisateurs extérieurs avec qui discuter pour aider à résoudre certains choix délicats, et surtout la sensation agréable de travailler à améliorer la vie d’autrui. Bien sûr, il faut que le sujet soit intéressant.

Cependant, dans ces deux cas, ces programmes sont placés sous le signe de la contrainte. Et, dans ces deux cas, atteindre un stade où l’utilisation est agréable demande de faire des efforts sur un grand nombre de petits détails qui ne sont pas forcément intéressants ni même agréables, et dont on n’avait pas besoin de se soucier tant qu’on s’intéressait surtout à l’expérience de développement, la qualité du code, etc.

C’est une expérience différente, qu’il est bon d’avoir fait ou de faire, et qui est elle aussi très formatrice. Cependant, je la trouve tout de même sensiblement moins intéressante que l’expérience du développement du cœur du programme. C’est ce que j’ai essayé de faire passer dans ma réponse : apprendre c’est bien et on est libre, être utile c’est bien aussi mais il y a des contraintes qui vont avec.

Enfin, il est possible d’avoir le meilleur des mondes, en participant à un projet où ce sont d’autres personnes qui font l’interface avec les utilisateurs. Dans ce cas, surtout si notre participation concerne le cœur du programme, elle sera évaluée sur des critères de productivité de développement au moins autant que sur son action concrète sur le résultat du programme. C’est une des raisons qui fait qu’il est agréable et intéressant de travailler dans des projets où les exigence de qualité sont fortes.