La passion dans l'informatique n'est pas synonyme de qualité de code

Je suis un passionné

J'adore coder.

Que ça soit dit et compris, j'adore l'informatique.

Ce que je trouve génial, en tant que développeur, c'est qu'on peut batir un monde. On peut littéralement construire des mondes, des univers qui n'existent pas, et cela comme on l'entend. C'est encore mieux qu'un architecte, qu'un chef de chantier, qu'un manoeuvre, qu'un ouvrier, même tous ensemble. C'est la transposition des jeux de lego et meccano de mon enfance à l'age adulte et à l'échelle supérieure. Je ne suis plus limité par la taille de ma chambre, la fortune (ou plutôt son absence) de mes parents ou la mienne. Mon imagination devient ma seule limite.

Je code sur mon temps libre (enfin, beaucoup moins depuis que je suis marié puis papa). Et je batis des trucs. Vraiment.

A un moment, j'ai codé un SGBD, juste parce que je voulais savoir comment MySQL marchait (à ne pas utiliser en prod, SVP). A un autre moment, j'ai codé un moteur de recherche, juste parce que je voulais savoir comment google fonctionnait. Et il utilisait le SGBD précédemment cité. Et puis, j'ai aussi codé un site web d'aggrégation d'articles d'actualité, parce que je voulais créer un robot-écrivain et que je me suis dit que ça serait bête de perdre toute la matière première. J'ai même gagné de l'argent avec. J'ai commencé un nombre incalculable de projets perso, juste parce que je pouvais le faire : un jeu vidéo de sous-marin pour aveugle, un livre (oui, je code un livre, et alors), un système pour pouvoir lire mes BD/Comics/Mangas depuis n'importe où sans perdre l'avancement, un bot de trading de crypto-monnaie (à ne pas utiliser en vrai), des sites web pour la famille et les amis, plusieurs jeux vidéos mobiles qui ne sont jamais arrivés en prod, et pleins d'autres choses.

Alors, oui, j'aime vraaaaiiiiment coder. Mais ce n'est pas pour ça que je vais passer ma vie à le faire. Et encore moins coder 12h par jour pour un employeur.

Je suis aussi un professionnel

Mais au fait, pourquoi ne suis-je pas développeur ?

Aujourd'hui, je suis AdminSys Linux/SRE/DevOps, selon la définition que vous accordez à chacun de ces mots. En gros, je ne code pas tant que ça, au niveau professionnel. Je "code" pour industrialiser et automatiser de l'infra, mais je ne code pas d'appli/site web/logiciel que des clients finaux utiliseront.
Il y a plusieurs raisons simple à cela. Le première, c'est que j'aime coder, certes, mais le code ne fait pas tout. Le code doit tourner sur quelque chose, et ce quelque chose m'intéresse tout autant. La seconde, c'est que parfois "passion" et "profession" ne font pas bon ménage.

Tout le monde connait cette maxime :

Choisis un travail que tu aimes, et tu n'auras pas à travailler un seul jour dans ta vie.

Oui mais non, en fait.

Prenons l'exemple de la construction d'un pont. Construire un pont en lego/meccano/imprimante 3D peut être génial, apporter du fun, être une passion, etc... Mais ça n'a rien à voir avec la construction d'un pont sur lequel des trains ou des semi-remorques pleins devront passer. Les contraintes ne sont pas les mêmes. Les responsabilités aussi. L'écroulement d'un pont en lego dans ma chambre n'aura pas les mêmes conséquence que l'écroulement d'un pont autoroutier. Il en va de même pour beaucoup de passions. J'aime écouter et jouer de la musique (>30ans d'expérience d'instrument) et sonoriser pour mon association, et pourtant je ne sonoriserais jamais pour la radio/télé/enregistrement ou un concert live ou ne jouerais de la musique contre de l'argent.

C'est pareil pour le code. J'adore coder, mais coder en environnement professionnel n'est pas pareil que coder par passion.

Quand je code mon projet pour le fun, je n'ai pas la responsabilité de la vie de gens. On reparle de Boeing et du MCAS de ses 737-Max ? Ou des programmes en milieux hospitalier ? Dans ma vie professionnelle, j'ai eu à administrer des serveurs informatiques hospitaliers. Si ça ne marche pas, des gens meurent.

Je ne pense pas qu'une passion devrait avoir ce genre de responsabilités.

L'informatique est aussi une industrie, comme l'industrie nucléaire ou l'industrie automobile. Quand on pratique une activité professionnelle, certaines pratiques viennent se greffer. C'est aussi le cas dans l'informatique. En simplifiant, il y a beaucoup de bonnes pratiques, en informatique, qui devraient être des contraintes fortes quand on code de manière professionnelle. Pour l'industrie automobile, il y des crash-tests, des obligations de ceintures, d'airbags et d'émission de CO2, des vérifications de ceci et de cela. Il existe des bonnes pratiques qui correspondent à la même chose : tests unitaires, d'intégrations, d'intrusion, test-driven development, CI/CD, etc... et j'en passe.

Et ces bonnes pratiques devraient, à mon avis, être autant obligatoires et contraignantes que ne le sont les obligations et tests dans l'automobile. Et toutes ses choses, sont nécessaires.

Mais elle ne sont pas fun (au moins pour moi). Elles ne sont pas passionnantes, mais il faut les faire.
Je ne cherche pas à m'en convaincre, je le suis déjà et autant que je le peux, j'essaye d'obliger mes co-équipiers à les pratiquer. Mais ce n'est pas comme ça que je code pour la passion. Oui, c'est un fait, la plupart de mes projets perso n'ont pas de tests unitaires. Même si mes projets perso sont en partie en CI/CD, ils ne sont pas "test-driven", etc...

C'est pour ça que coder n'est pas mon activité professionnelle principale.

On ne code pas de la même manière pour une passion que pour son job.

D'un autre côté, c'est également pour ça aussi, qu'ayant bien compris l'importance de ces contraintes, mon poste actuel me permet d'essayer de les faire appliquer autant que je le peux. Au travail. Pas sur mes projets perso chez moi.

Pour que la passion reste une passion

Dernière raison que je vais détailler ici : il faut que la passion reste.

Coder est une de mes passions. J'en ai d'autres. Et j'aimerais qu'elles restent à leurs place de passion. Je ne veux pas perdre la passion de coder. Car à imposer des contraintes (même si elles sont nécessaire), la passion peut partir. C'est pour cela que mes projets perso n'ont (pour la plupart) pas de tests unitaires, etc... et que je m'impose à moi une règle impérieuse : je fais mes horaires.

Ca ne veut pas dire que je serais pointilleux à la minutes près et sous-performant au travail, loin de là. Ca ne veut pas dire que je ne ferais pas un peu d'heure sup' de temps en temps, ou en cas de coup dur, mais ça doit rester anecdotique. Ca ne veut pas dire que je n'aime pas mon travail, pas du tout.

Faire uniquement mes heures, ça veut dire plusieurs choses pour moi :

• Ca veut dire que je respecte un contrat. Parfois, on a tendance à oublier, mais un contrat n'est pas à prendre à la légère, il a une valeur juridique et comporte des clauses contraignantes pour le bon profit de 2 parties : moi et mon employeur. Par exemple, je reçois une compensation financière pour le temps dont mon employeur profite de ma science. Travailler plus pour le même salaire rompt virtuellement le contrat en cela qu'il devient plus profitable pour mon employeur que pour moi.
• Ca veut dire que je dispose de temps pour me reposer et profiter de ma famille. Je serais donc plus performant (en qualité de travail, ainsi qu'en quantité de travail par unité de temps), si je suis reposé.
• Ca veut finalement dire que je disposerais aussi de temps pour assouvir et entretenir mes passions, y compris le code.

In fine, ça me permet de pratiquer ma passion et donc d'être meilleur dans ma passion. Pour mon code. Et donc, aussi pour mon travail.

En conclusion, quand je vois des offres d'emplois qui demandent des gens "passionnés", j'ai toujours tendance à me méfier. Pas parce que je ne suis pas passionné, loin de là. Mais parce que coder par passion, n'est pas pareil que coder pour un employeur. Et s'ils ne veulent que des développeurs passionnés, je ne veux pas imaginer la qualité de ce qu'ils produisent.

Je ne code pas de la même manière pour le fun ou pour le travail.

Si vous m'embauchez, vous embauchez un professionnel, qui fera un travail de qualité professionnelle. Avec tests unitaires, "test-driven", et cetera... Pas un amateur qui code par passion. Ca, je le réserve pour l'amusement chez moi.