Les développeurs doivent être paresseux: voilà pourquoi
Published: 2022-11-25 07:25:49

**Je pense que c'est une bonne chose pour les programmeurs (ou, en réalité, n'importe quel travailleur) d'être paresseux.**  
Je pense vraiment que les recruteurs devraient rechercher le développeur le plus paresseux qu'ils puissent trouver.
OK, OK, tout le monde, posez vos fourches et vos torches, et laissez-moi vous expliquer.

# Deux types de paresse

L'autre jour, sur Twitter, quelqu'un a demandé s'il fallait utiliser des points-virgules en JS. Mon avis ? Je ne m'embête pas avec ça. Pour moi, c'est du gaspillage de frappe, un effort inutile. Cela ne rend pas le code meilleur ou plus facile à lire, et si ça peut faire gagner quelques millisecondes ici et là, je suis à 100% pour. J'essaie toujours de trouver la voie de la moindre résistance, ce que j'ai appelé "**l'option du plus faible effort**" dans mon tweet.
Cela a provoqué une tempête dans un vers d'eau, et certains ce sont vexé:

<blockquote class="twitter-tweet"><p lang="en" dir="ltr">Ew. Lowest effort option? That ethos couldn’t lead to great software…<br><br>That being said, when I’m speed coding on <a href="https://twitter.com/LeetCode?ref_src=twsrc%5Etfw">@LeetCode</a> I’ve begun dropping the semicolons. I’m so ashamed of myself. 🤦‍♂️😜</p>&mdash; Zakery Kates (@zakkates) <a href="https://twitter.com/zakkates/status/1591210130150150144?ref_src=twsrc%5Etfw">November 11, 2022</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

<blockquote class="twitter-tweet"><p lang="en" dir="ltr">I disagree. Semi-colons are there to separate the end of each line and therefore serve a purpose to both compiler and programmer. There&#39;s no way low effort is always the best policy - it just leads to lazy programming.</p>&mdash; Daniel Hartgrove (@danhartgrovexyz) <a href="https://twitter.com/danhartgrovexyz/status/1591423705821089794?ref_src=twsrc%5Etfw">November 12, 2022</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

Il y a quelques points techniques valables ici, mais la réponse qui m'a le plus dérangé a été le "ewww, peu d'effort ? Mais c'est pour les perdants !" viscérale. Cela me dérange parce qu'ils ont mal compris ce que je voulais dire. Je ne parlais en aucun cas de tout lâcher, de ne pas faire son travail sérieusement.

Je crois que ces commentateurs ont lu "l'option du plus faible effort" et ont compris "un faible effort tout le temps". Ce n'est absolument pas ce que je veux dire. Je parlais de la vraie paresse, comme Larry Wall le décrit dans [le livre Perl](https://www.amazon.co.uk/Programming-Perl-Unmatched-processing-scripting) :

> The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so you don’t have to answer so many questions about it. Hence, the first great virtue of a programmer. 

# La vraie « paresse » = optimisation

Voyez-vous, cher lecteur, nous ne parlons pas de relâchement ici. Il ne s'agit pas de copier et coller du code manuellement jusqu'à ce qu'il soit temps de rentrer à la maison, parce qu'on a la flemme d'écrire un script avec une ou deux regexps qui feront le travail en quelques secondes. L'écriture du script demande certe plus d'efforts au départ, mais vous fera économiser des heures de travail fastidieux sur le long terme. Et peut-être aider vos collègues. Et vous donner plus de temps libre pour travailler sur quelque chose de plus intéressant, ou simplement pour vous détendre un peu si vous en avez envie.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/911cryhhm8fgl7pmsyen.png)

Je veux prendre le chemin de la moindre résistance, oui, mais c'est seulement pour obtenir plus de qualité, pour avancer, pour accélérer les choses, et, au final, pour éviter de perdre un temps précieux sur du baratin inutile.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/lq95wvgu651y1fsg75tw.png)

En outre, [je ne crois plus à la paresse de toute façon](https://www.amazon.co.uk/Laziness-Does-Exist-Devon-Price-ebook/dp/B08C1G3J1T/ref=tmm_kin_swatch_0?_encoding=UTF8&qid=&sr=).

Je suis tombé sur un autre exemple l'autre jour. Un collègue implémentait une nouvelle fonctionnalité de paiement (temporaire) sur l'un de nos sites. Nous voulions savoir quand les utilisateurs ont finalisé un achat sur le site, à la fois dans Universal Analytics et dans GA4. Étant donné qu'il y avait quelques paramètres inhabituels dans le traçage de cette fonctionnalité, il avait initiallement envisagé de déclencher les événements directement dans son code, à l'aide du [protocole de mesure d'Universal Analytics](https://support.google.com/analytics/answer/9900444?hl=en) et du [protocole de mesure de GA4](https://developers.google.com/analytics/devguides/collection/protocol/ga4) pour suivre tout ça. Gardez à l'esprit que nous avions déjà une configuration complète de Google Tag Manager, avec UA et GA4 déjà en place.  
Mon cerveau paresseux s'est simplement demandé "a-t-on vraiment besoin de faire tout ce boulot pour une fonctionnalité *temporaire* ?". Il s'avère qu'il existait une solution simple avec très peu de code : il suffit de pousser les données concernant l'achat dans le datalayer, et d'ajuster GTM pour déclencher correctement les événements. Boom. Tout ça été bouclé en quelques heures.

Du coup j'ai passé le reste de la journée à regarder la télé. Je plaisante.