La qualité qui fait la différence en programmation

La quasi-totalité de ma vie, j’étais intimement persuadé que je n’avais pas les capacités de courir un marathon. Courir 42,2K d’affilés est réservé aux autres. Mon instinct naturel est d’éviter les efforts, les erreurs, la confusion et les défis. Mais nous avons une profession particulière. Ça rend cet instinct dangereux.

Volontaire

Il y a bien longtemps, dans une galaxie lointaine, très lointaine je faisais partie d’une équipe de dev qui marchait bien. Un jour, lors de la réunion de synchronisation du matin, notre manager a posé une tâche sur la table. Une tâche sur un sujet complètement inconnu pour tout le monde. Un sujet qui faisait peur.

Cette tâche puait vraiment les prises de tête et les problèmes à trente mètres.

Notre manager le savait que ca allait être le bordel cette tâche. Il a donc demandé un volontaire pour s’en occuper au lieu de forcer quelqu’un. S’en suivit un long silence malaisant.

Tout le monde a commencé à regarder dans le vide.

Tu te rappelles quand je te disais que j’avais pris pour habitude d’aller vers l’inconnu ? Faire ce que personne ne veut faire ? En particulier quand ça me faisait peur ?

Bon et bien c’était une nouvelle chance d’appliquer ce que je prêche.

Au soulagement de tout le monde, je me suis donc porté volontaire.

Pour le contexte, cette tâche concernait du SSL. Mais attention, pas le SSL du dimanche. Pas le SSL que tu génères en cinq minutes sur ta machine ou via let’s encrypt.

Non, c’était un cas très tordu.

Intégrer avec K8S via Istio sur plusieurs domaines et sous-domaines dynamiques. Derrière un proxy d’entreprise extrêmement parano. Appelable depuis le navigateur (bureau et mobile) en interne et externe, mais aussi depuis la GitLab CI.

Le problème ce n’était pas le SSL. Le SSL c’est facile. Le problème c’était les contraintes. Les contraintes internes de cette boite qui, pour des raisons de sécurité, compliquait absolument tout.

Le genre de contraintes qui renvoient zéro résultat quand tu commences à chercher sur Google.

J’allais devoir tout comprendre. Parler à une équipe IT interne pour le proxy. Parler à une autorité de certification externe. Faire en sorte que ces gens se parlent entre eux. Générer une chaine de certification. Et enfin l’intégrer d’une façon bien particulière.

Une virgule qui dépasse, tout explose sans message d’erreur utile.

Et il faut comprendre qu’avant cette tache, le SSL, je connais juste de nom.

Je ne sais pas ce que je ne sais pas

Le métier de développeur est monstrueusement flippant par son scope.

Une masse de connaissance infinie que tu ne pourras jamais complètement maîtriser. De façon journalière tu es confronté à des problèmes dans cette masse. Et très fréquemment, quand tu commences une tâche, tu n’as aucune idée de comment résoudre le problème.

Parfois, ça va encore plus loin. Parfois, même le contexte autour du problème n’est pas maîtrisé. Parfois, tu ne sais même pas par où commencer tellement le sujet est inconnu.

Tu ne sais pas ce que tu ne sais pas.

Arriver à cet extrême -c’est simple-, tu ne t’attaques pas tout de suite au problème. Tu t’autoformes sur le contexte avant. Tu vas chercher la connaissance du contexte là où elle est.

Et ça prend du temps.

Alors évidemment, la compétence de résolution de problème est centrale en tant que dev.

Je ferai un article privé réservé aux devs de la newsletter sur ce que je fais devant un problème complexe. La suite concrète de ma logique, étape par étape, pour résoudre n’importe quel problème de programmation. Mais ce n’est pas le sujet du jour.

Tu as besoin d’une qualité en particulier pour appliquer une résolution de problème efficace.

La persévérance

La persévérance est la clef. Tu peux l’appeler la ténacité, la résilience ou même la niaque. Tu l’appelles comme tu veux.

L’important c’est de comprendre son vrai concept et de l’appliquer.

La persévérance ce n’est pas se dire « je vais résoudre ce problème à telle date coûte que coûte ». La persévérance ce n’est pas de l’acharnement bête et méchant sans faire de pause ou demander de l’aide. La persévérance n’est pas une pression en plus à se mettre au-dessus de la tête.

La persévérance c’est avoir un état d’esprit ouvert, méthodique et détaché face un problème sur une longue période.

La persévérance c’est gérer sa frustration face à du code qui ne fonctionne toujours pas. C’est gérer cette frustration sur une longue période. C’est à quel point tu la subis ou tu l’utilises.

C’est le calme pendant la tempête.

La tâche que j’avais acceptée me prenait un temps fou à résoudre. Personne pour m’aider. Je ne savais pas combien de temps ça allait me prendre. Je ne savais même pas si c’était possible à faire tout court.

Et tous les matins, je devais expliquer devant tout le monde de quelle façon ça ne marchait pas aujourd’hui.

Sans persévérance -ou du moins un bon niveau de persévérance-, un autre sentiment prend rapidement le dessus.

La panique.

La panique qui te dit que tu es un imposteur. La panique qui te fait partir dans tous les sens. La panique qui t’empêche de réfléchir. Qui empêche toute méthodologie. Et c’est ce qu’on voit beaucoup.

Les devs qui insultent leur écran, qui fracassent leur clavier et qui pètent les plombs sont nombreux.

J’ai énormément fait ça, dans le passé.

Mais pas au moment de cette tâche. J’avais pris conscience de l’importance de la persévérance quand je faisais cette tâche. Et cette prise de conscience a tout changé.

Chaque jour, une problématique. Chaque jour, un nouvel échec. Mais chaque jour, j’avançais un peu plus.

C’est la persévérance qui me tenait motivé, méthodique et ouvert à l’apprentissage face aux échecs répétés.

Et puis, un beau matin, j’avais relié tous les points.

J’avais maitrisé tous les concepts. À force de persévérance, je présentais une solution aux petits oignons à mon équipe. Accompagnée d’une documentation qui sera utilisée pendant plusieurs années jusqu’à aujourd’hui.

Et tout le monde était impressionné par le boulot.

Je suis immédiatement devenu le référant sur toute cette partie et tout ce qu’il y avait autour.

Chaque virgule changée sur cette partie était alors validée par moi. Ceux qui avaient évité la tâche étaient ceux qui me posaient les questions.

Quand je suis parti de cette équipe, j’ai gardé en tête ces connaissances avancées. J’ai beaucoup utilisé ces connaissances dans d’autres équipes. Et c’est ce qui m’amène au vrai message central que je veux te faire passer aujourd’hui.

Level up

Les échecs répétés pour arriver au bout d’une tâche ne sont pas seulement normaux, mais nécessaires. L’adversité est un excellent professeur. Et c’est la persévérance face à l’adversité qui fait toute la différence.

Il faut comprendre que quand tu galères sur quelque chose, chaque seconde passée dessus n’est pas perdue !

Ce processus fait partie de l’apprentissage. Chaque seconde à galérer est un apprentissage. Et ce sont ces moments-là qui vont vraiment te faire évoluer en tant que dev.

La tâche que tu connais par cœur réglée en 5 minutes, elle est super gratifiante. Et très franchement, on a vraiment besoin de ces taches-là. Pour l’égo, mais aussi pour un certain sentiment d’accomplissement. Elles font du bien. Mais elles ne permettent pas ton évolution.

On me pose souvent la question « Comment devenir un bon développeur ? ».

Cette question est biaisée par ton contexte. Un bon développeur est bon dans un contexte. Par contre, il y a une façon efficace et universelle pour amplifier ses connaissances et devenir un meilleur développeur.

Faire les choses difficiles.

Payer le prix de l’adversité. Tenir la traversée d’un long tunnel rempli de problèmes et de doutes. Utiliser la persévérance pour aller au bout. En ressortir plus grand avec une tonne de nouvelles connaissances.

Libre de les utiliser où tu veux.

La persévérance est la qualité que j’ai le plus vue chez tous les excellents développeurs que j’ai croisés.

Devenir un meilleur développeur n’est pas une question de QI. Ce n’est pas non plus une question d’année d’expérience. Devenir un meilleur développeur, c’est régulièrement accepter l’inconfort de ne pas savoir pour mieux apprendre.

Faut-il en permanence se jeter sur ce qui a de plus dur et le faire ?

Bien sûr que non ! Pas en permanence. C’est de la folie si tu le fais en permanence. C’est intenable.

Mais de temps en temps, c’est absolument indispensable.

Grit

J’ai lu pas mal de bouquins qui parlent de ce concept. Un en particulier a retenu mon attention. Ma recommandation du jour.

Grit en Anglais ou L’art de la niaque en Français. J’ai lu la version anglaise.

Ce que j’aime c’est la démarche scientifique qu’Angela Duckworth a utilisée pour prouver le pouvoir de la persévérance. L’étude scientifique faite dans cette école mêlée aux études sur la neuroscience qui fait ressortir clairement un fait. La persévérance est le point commun des gens qui ont du succès.

Un bouquin qui prouve que le talent inné n’est pas ce qui a de plus important pour réussir.

Les interviews de sportifs, d’artistes, de militaires et de grands hommes d’affaires à succès dans le bouquin ne font que valider ce fait. Et ça fait du bien.

Ce bouquin n’est honnêtement pas obligatoire pour tous les développeurs. Seulement ceux qui ont besoin d’un push dans leur motivation. Ceux qui refusent le statu quo sur leur situation.

J’en avais besoin personnellement. C’est une lecture qui a changé ma façon d’aborder tous les problèmes jusqu’à aujourd’hui. En dev, mais aussi dans ma vie de façon générale. Je ne peux que la conseiller.

Épilogue

Y’a pas longtemps, j’ai couru un 42,2k seul dans les rues de Montréal. En fait, c’est possible. Il suffisait juste de faire le travail difficile de l’entrainement. Je savais que chaque kilomètre était nécessaire. Et c’est entièrement ma persévérance qui m’a permis d’aller au bout.