larlet-fr-david/david/blog/2017/code-vitesse/index.md

title: Code et vitesse
slug: code-vitesse
date: 2017-01-27
chapo: J’ai tendance à penser qu’il y a autant de façons de coder qu’il y a de façon d’écrire.

> Alors cela fait sens pour moi d’écrire et de publier vite, comme on ferait de la photographie : c’est un portrait de soi à un instant précis. Y revenir plus tard, ce serait comme ajouter des rides sur une image de soi plus jeune. J’ai donc beaucoup de respect pour celles et ceux qui écrivent et publient vite. Je ne préjuge pas de la valeur de leurs écrits en fonction du ratio temps écoulé/nombre de caractères. C’est mystérieux, une bonne histoire. Personne ne sait vraiment comment ça fonctionne. Et s’il suffisait de passer cinq ans sur un roman pour le rendre parfait, ça se saurait, non ?
> 
> <cite>*[Peut-on écrire trop vite ? Peut-on publier trop ?](https://page42.org/peut-on-ecrire-publier-trop/)* ([cache](/david/cache/e7bb29ea6d68ade4a78756dfdeefa7b1/))</cite>

Est-ce qu’un bon code est tout aussi mystérieux ? Personne ne sait trop comment cela fonctionne non plus, il y a bien quelques principes ou *patterns* mais ça ne garantit pas grand chose au final. Ce qui me parait certain à ce jour c’est qu’en passant cinq ans sur un produit on est davantage enclin à le rendre bouffi de fonctionnalités et croulant de dette technique que parfait.

**J’ai tendance à penser qu’il y a autant de façons de coder qu’il y a de façon d’écrire.** Je me base sur l’observation des différentes personnes avec lesquelles j’ai pu pair-programmer (ce qui [se pratique moins](/david/blog/2016/ecriture-collaborative/) en écriture). Cela permet d’apprendre à se connaître au regard de ses différences. Je sais par exemple que sur du tactique je suis davantage dans l’essai-erreur quitte à comprendre ensuite. En revanche sur du stratégique, je vais collecter des données pendant un long moment avant de passer à l’acte de code qui sera parfois très rapide, brutal même, mais plus solitaire aussi. Il en est de même dans ma façon d’écrire.

Que ce soit pour du code ou des mots, j’ai beaucoup de mal à me retenir de publier. Lorsque les idées, concepts, algorithmes sont formalisés, la dernière étape est de les offrir au monde. **Il s’agit d’un rite de passage avant de pouvoir s’en libérer.** Avant cela ils n’existent pas. Un travail invisible m’est frustrant et c’est peut-être pourquoi l’*open-source* me tient tant à cœur. Les rares fois où j’ai pu écrire sans avoir la libération rapide du produit ont été déprimantes (il y a bien une fois où ça a duré neuf mois mais c’est une autre histoire :-P).

Il y a un certain plaisir dans [l’édition](https://robinrendle.com/notes/the-fire-in-the-smoke/) ([cache](/david/cache/b2d4236881eb0624ba2c75a7574d2b59/)) aussi. Que ce soit via les [code reviews](/david/blog/2016/code-reviews-croisees/) ou les optimisations de performances ou les découplages ou même les réécritures. Mais l’acte de création égoïste n’est plus et l’envolée lyrique est retombée. C’est terrible car j’aimerais laisser davantage d’espace à [la part de designer](http://www.heydonworks.com/article/signs-you-may-be-a-designer-not-just-a-coder) ([cache](/david/cache/8c377f507c74bfbc1b3db3ca92563bd3/)) qui est en moi, celle qui affine et se rapproche progressivement du besoin réel de l’utilisateur. J’y retrouve le tiraillement de cette dualité dans mon rapport au monde : entre [confort](/david/blog/2013/confort-convivialite/) et utilité.

> Without requirements or design, programming is the art of adding bugs to an empty text file.
>
> <cite>Louis Srygley</cite>

Difficile de terminer un billet sur le code et la vitesse sans parler du [mythe](http://10x.engineer/) des *10x engineers* (je me demande s’il existe chez les écrivains tiens). Est-ce que vous voulez dans votre équipe quelqu’un qui code dix fois plus rapidement ou quelqu’un qui produit un code compréhensible et maintenable par au moins dix personnes ? Je trouve cela plus valorisant aujourd’hui d’être un 10x [inclusive developer](/david/blog/2016/inclusive-developer/).