Le chemin le plus long

Quand on débute en programmation, le premier programme est souvent très gentil.

Il affiche « Bonjour ».

On l'exécute. Tout fonctionne.

Et on se dit que le reste suivra probablement le même principe.

C'est une petite illusion confortable. 😅

Quelques mois plus tard, on découvre les bases de données, les sessions, les erreurs de déploiement, les demandes clients et cette formidable catégorie de problèmes : « ça marchait hier ».

J'ai voulu apprendre à développer. Je ne savais pas encore que j'apprenais surtout à apprendre.

Au départ, une direction plutôt qu'un plan

Mon chemin vers l'informatique n'a pas été parfaitement linéaire.

J'avais commencé des études de droit avant de choisir le génie logiciel. Ce choix a demandé des efforts concrets, notamment pour financer mes études.

Ce changement de voie fait partie de mon parcours, raconté notamment dans Le retour.

Quand on change de voie, on aimerait parfois savoir exactement où elle mène. Mais « devenir informaticien » ne dit pas grand-chose du quotidien.

On peut développer des sites, des applications mobiles, des systèmes d'information, des outils métiers, travailler sur la sécurité ou l'infrastructure.

Le champ est immense. Au début, on essaie surtout de comprendre ce qui existe.

La première grande surprise : le code ne suffit pas

On peut apprendre la syntaxe d'un langage assez rapidement.

Créer un produit utilisable prend bien davantage.

Il faut savoir écouter un besoin, poser des questions, concevoir une interface compréhensible, structurer des données, protéger des accès, tester des scénarios et déployer une version stable.

Et quand on travaille avec de vraies personnes, il faut savoir expliquer tout cela sans leur imposer le vocabulaire du développeur.

Un utilisateur ne demande pas « une meilleure normalisation de base de données ».

Il demande de retrouver sa facture.

C'est à nous de relier le besoin à la technique.

Apprendre à travers les projets

Mes expériences professionnelles et mes projets personnels m'ont donné une manière très pratique d'apprendre.

Quand quelque chose doit vraiment fonctionner, on découvre rapidement ce qui manque à notre compréhension.

Il faut chercher, tester, se tromper, lire la documentation, revenir sur ses choix et demander de l'aide quand c'est nécessaire.

Cela ne remplace pas les études. Cela leur donne une autre dimension.

Je ne me reconnais pas vraiment dans l'idée qu'il faudrait choisir entre les diplômes et les projets.

Les deux peuvent se compléter. Et j'en parle aussi dans Le diplôme ou le dépôt GitHub ?.

Le piège de vouloir tout connaître

Quand on découvre le monde du développement, les technologies défilent.

Un nouveau framework. Un nouveau langage. Une bibliothèque qui promet de tout simplifier. Puis l'intelligence artificielle qui accélère encore le rythme.

On peut finir par passer plus de temps à décider quoi apprendre qu'à construire.

J'essaie désormais de partir du besoin.

Un projet nécessite-t-il une application mobile ? Une API ? Une base de données particulière ? Peut-on obtenir un résultat plus simple avec des outils déjà maîtrisés ?

Cela ne veut pas dire qu'il ne faut jamais découvrir de nouvelles technologies.

Seulement que la curiosité a besoin d'une direction.

Ce qui me paraît important aujourd'hui

Si je devais résumer mes apprentissages, je ne dresserais pas la liste de tous les langages utilisés.

Je parlerais plutôt de quelques habitudes :

• Chercher à comprendre avant de copier une solution.
• Savoir dire « je ne sais pas encore ».
• Tester les cas qui échouent, pas uniquement ceux qui réussissent.
• Écrire pour que d'autres puissent reprendre le code.
• Accepter de changer une idée lorsqu'un utilisateur montre qu'elle ne répond pas à son besoin.

Tout cela prend du temps.

Et la ligne d'arrivée ?

Je ne pense pas qu'elle existe vraiment.

Il y aura toujours un problème inédit, un outil inconnu ou une nouvelle façon de travailler.

Ce serait inquiétant si le métier consistait à tout savoir une fois pour toutes.

Heureusement, ce n'est pas le cas.

Je ne suis pas devenu développeur le jour où j'ai compris toutes les réponses.

J'ai commencé à le devenir quand j'ai appris à avancer malgré les questions.

Et elles sont encore nombreuses.