De « ça tourne, c'est déjà bien » à « j'ose le modifier et le faire marcher » : le journal d'un mois de programmation d'un débutant

Précisons-le d’emblée : je ne suis pas ingénieur logiciel, et ce dont je parle ici en matière de programmation relève en réalité entièrement de ce qu’on appelle le Vibe Coding, celui où l’on se laisse porter par le feeling.

Ces derniers temps, pour que mon travail se déroule un peu plus rondement, je développe sans relâche mes propres petits outils. Ces deux derniers jours, j’ai fait trois choses : j’ai commencé à faire des sauvegardes avec Git, j’ai corrigé quelques bugs dans la logique du programme et j’ai connecté un nouveau modèle d’IA.

Le plus difficile, ce n’est pas la syntaxe, c’est « transformer ce qu’on veut en code »

Au bout d’un mois, mon plus grand enseignement, c’est que le plus difficile, quand on écrit du code, n’est pas en réalité la syntaxe, mais de convertir « ce que l’on veut au juste » en « code concret ».

Par exemple, « corriger un bug » se dit en un clin d’œil, mais avant de mettre réellement les mains dans le cambouis, il faut d’abord se poser tout un tas de questions :

• Faut-il d’abord sauvegarder ?
• Faut-il ouvrir une nouvelle branche ?
• Quand tester ? Et comment tester ?
• Une fois la modification faite, à partir de quand est-ce « terminé » ?
• Faut-il en profiter pour poser un numéro de version ?

Aucune de ces questions n’est en réalité une question de programmation, mais une question d’« habitudes de travail ». Ce déroulé est peut-être des plus courants dans le métier, mais pour un débutant en programmation, c’est tout bonnement un cauchemar.

Quelques petites choses que j’ai apprises

En ce mois, j’ai appris quelques petites choses, que je partage avec les débutants comme moi :

1. Dressez d’abord le bouclier de protection, puis lancez-vous dans les bidouilles. En utilisant Git pour le contrôle de version, même si vous cassez tout, trente secondes suffisent pour revenir dans le passé : aussi rassurant qu’un point de sauvegarde dans un jeu vidéo.
2. Ne faites qu’une chose à la fois. Surtout, ne « modifiez pas une ligne de plus tant que vous y êtes » : c’est exactement le genre de chose qui donnera au vous futur l’envie de se cogner la tête contre le mur.
3. Être lent, c’est normal. Tout un après-midi pour venir à bout d’une seule petite fonctionnalité ? Oui, c’est le quotidien. Ces tutoriels express, la plupart du temps, vous mentent.
4. Prenez des notes pour le vous futur. Sinon, la prochaine fois que vous y reviendrez, vous croirez que ce programme a été écrit par quelqu’un d’autre. (Bon, d’accord : ce programme, c’est vraiment une IA qui l’a écrit.)

De « ça tourne, c’est déjà bien » à « j’ose le modifier et le faire marcher », ce qui se trouve entre les deux, ce sont sans doute précisément ces habitudes de travail d’apparence anodine, qu’il faut pourtant combler une à une.