Pourquoi je suis nulle en algorithmique alors que je suis développeuse ?

Il y a des moments dans une carrière de développeur où on prend une claque.

Pas une erreur en production, pas un pipeline GitLab qui décide de casser alors qu’il fonctionnait parfaitement depuis trois mois… Non… Un petit exercice d’algorithmique.

Et là, soudainement, après plusieurs années à développer des applications, à faire du Docker, du CI/CD, des migrations Angular et à écrire des tests… je ne sais plus parcourir un tableau.

Enfin… techniquement, si.

Mais quand on me demande de le parcourir avec trois contraintes, sans utiliser telle méthode et avec un résultat à produire en moins de 15 lignes, mon cerveau décide qu’il est temps de prendre sa retraite.

Et c’est là que je me suis posé une question : Est-ce que je suis devenue une quiche en algorithmique… ou est-ce simplement que je ne pratique plus ?

Spoiler : surement un peu des deux.

Développer tous les jours ne veut pas dire faire de l’algorithmique tous les jours

C’est probablement la première chose que j’ai réalisée, depuis le début des études de développement on nous répète que l’algorithmie fait tout, qu’un bon développeur est bon en algorithmie… La vérité est que dans mon quotidien, je ne passe pas mes journées à résoudre des problèmes du genre :

« Étant donné un tableau de nombres, trouvez la plus longue sous-séquence croissante en O(n log n). »

Non. Je passe plutôt du temps à me demander :

• pourquoi cette API renvoie un 500 ;
• pourquoi mon composant Angular ne se met pas à jour ;
• pourquoi ce test casse uniquement dans la CI ;
• pourquoi Docker utilise une image différente de celle que je pensais ;
• pourquoi quelqu’un a mis un setTimeout(..., 3000) dans ce service ;
• et surtout…

Qui a écrit ça ?

Et généralement, la réponse est : Moi, il y a deux ans. 😐

Le développement fait travailler énormément de compétences :

• l’architecture ;
• les API ;
• les frameworks ;
• les bases de données ;
• les tests ;
• la lisibilité ;
• le debugging ;
• le déploiement ;
• les performances ;
• la compréhension du besoin.

L’algorithmique pure représente une partie du métier, mais ce n’est pas nécessairement la partie que je pratique le plus.

Et comme toutes les compétences… si on ne pratique pas, on rouille.

Le problème n’est pas forcément de savoir coder

Il est possible de savoir coder sans être forcement très bon en algorithmie, comme l’inverse est possible aussi. Cependant est ce que le fait d’être bon en algorithmie ne fait pas de nous un/une meilleur codeur/codeuse ? Je pense que si.

C’est là que les challenges de code deviennent intéressants.

Prenons un problème très simple.

On a un tableau, on veut calculer la somme. Facile, en 5 minutes c’est fait, je suis heureuse, la vie est belle.

Puis l’énoncé ajoute :

Vous ne pouvez pas utiliser reduce.

Bon… On fait une boucle, toujours facile.

Puis :

La collection peut contenir plusieurs millions d’éléments.

Ok.

Puis :

La méthode doit être optimisée.

Puis :

Vous avez une contrainte mémoire.

Puis :

Et maintenant, faites le sans modifier le tableau.

Et là… on commence à réfléchir, ou à jeter le PC par la fenêtre, au choix.

C’est précisément ça qui m’intéresse dans les challenges. Ils obligent à réfléchir mais surtout à réfléchir différemment et à penser a des solutions originales. Quoi de plus amusant ?

Est ce que vous voyez venir la suite ?

🎃 Le OctoberQueen Challenge

Mais qu’est ce que c’est que le OctoberQueen challenge ? (Oui, il y a forcément mieux comme nom je vous l’accorde)

31 jours.
31 défis.
1 objectif : coder tous les jours.

L’idée n’est pas de devenir une experte en algorithmique en 31 jours., l’objectif est beaucoup plus simple :

retrouver l’habitude de résoudre des problèmes de code différents régulièrement.

Les règles

Parce qu’un challenge sans règles, c’est juste une bonne résolution qui va mourir le 4 octobre (et encore je suis sympa).

🗓️ Règle n°1 : un défi par jour

Chaque jour, je prends un problème.

Ça peut être :

• un puzzle CodinGame ;
• un problème Project Euler ;
• un exercice Exercism ;
• ou éventuellement un petit défi maison.

Le but n’est pas forcément de le finir mais surtout de ne pas passer 5 jours sur le même problème, cela ne me semble pas très profitable.

⏱️ Règle n°2 : environ 30 minutes

Je ne veux pas transformer ça en deuxième journée de travail. Le but est de pratiquer.

Pas de passer quatre heures sur un problème à 23h42 avec un café froid à côté du clavier. Cela ne tiendra pas dans le temps.

💻 Règle n°3 : priorité au Javascript

Parce que c’est un langage que j’utilise régulièrement et que je veux continuer à pratiquer. Le moment est mal choisis pour en plus apprendre un nouveau langage.

🚫 Règle n°4 : pas de honte

Un challenge n’est pas un examen.

Si je bloque, je peux chercher, je peux lire la documentation, regarder les concepts concernés…

Et surtout : bloquer fait partie de l’exercice.
C’est ce qui fait que ca rentre.

Ce que j’espère apprendre

Je ne cherche pas uniquement à améliorer mon score sur une plateforme. J’aimerais surtout retrouver certains automatismes.

Par exemple :

• reconnaître les problèmes classiques ;
• mieux manipuler les tableaux et les collections ;
• revoir les structures de données ;
• travailler la complexité ;
• apprendre à optimiser une solution ;
• mieux raisonner avant de coder ;
• et surtout retrouver le plaisir de résoudre un problème juste pour le plaisir de le résoudre.

Parce que c’est quelque chose qu’on peut facilement perdre avec les années.

Quand on travaille sur de vrais projets, il y a toujours une finalité : une fonctionnalité à livrer, un bug à corriger, une release à préparer, un ticket à fermer.

Avec un challenge de code, le problème est différent.

Le problème est le produit. Et une fois qu’il est résolu… il n’y a rien à déployer.

Est-ce que je vais tenir 31 jours ?

Alors là… C’est la vraie question.
Parce que faire un challenge pendant deux jours, c’est facile.

Maintenant, le faire tous les jours pendant 1 mois, c’est autre chose. Il y aura forcément ce jour où :

• j’aurai eu une grosse journée ;
• je n’aurai aucune envie de coder ;
• le problème sera incompréhensible ;
• et mon cerveau proposera très sérieusement de regarder Netflix à la place.

Celui la et surement d’autres, soyons honnêtes, on aime le confort quand même. Et c’est justement pour ça que j’ai envie de tenter l’expérience.

Parce que je veux voir ce qui se passe quand on remplace :

« Il faudrait que je pratique davantage. »

par :

« Pendant 31 jours, je pratique. »

Et si finalement je ne suis pas meilleure en algorithmique ?

Peut être qu’il sera temps de poser ce clavier et d’aller élever des chèvres…
Ce ne sera pas grave, parce que je pense que le vrai objectif n’est pas là.

Je veux surtout retrouver une habitude, réfléchir à un problème, tester une idée, trouver une meilleure solution.

Et parfois regarder son code en se demandant :

« Mais pourquoi j’ai fait ça ? »

La vie est tout de même moins amusante sans challenges.

Rendez-vous fin Octobre pour le verdict

Donc voilà, en octobre, je vais essayer quelque chose de différent.

Pas de grosse migration, pas de nouveau Framework à installer, pas de projet gigantesque.

Juste :

• 31 jours.
• 31 problèmes.
• 31 occasions de faire travailler mon cerveau.

Je vais principalement m’appuyer sur CodinGame, avec quelques détours par Project Euler… On avisera en fonction.

Pourquoi ne tenteriez vous pas de faire le challenge en même temps que moi ? Plus on est de fous, plus on ris non ?