On n'est pas des pisseurs de code !

Je n'arrive pas à comprendre pourquoi mon application nodejs n'exécute pas le callback que je lui passe en argument. Pourtant la documentation de la bibliothèque que j'utilise est claire, il faut passer une fonction en paramètre, elle sera appelée avec la réponse ou une erreur.

plus.people.get({
  userId: 'me',
  auth: oauth2Client
}, function (err, response) {
  // handle err and response
});

Malgré ça, rien ne se passe et me voilà à afficher des console.log dans le code de la bibliothèque.

Il faudra vraiment que je pense à apprendre à faire du debug dans une application nodejs. Là encore, la doc est claire : https://code.visualstudio.com/Docs/editor/debugging (mais est-ce qu'elle m'éclaire ?).

Et pendant ce temps-là, je suis agacé : il n'y a rien de plus agaçant pour le développeur que je suis de ne pas comprendre ce qu'il se passe. Si en plus je dois expliquer les raisons techniques de mon embourbement, on n'a pas fini. Mais il faut avancer, on ne peut pas se permettre de perdre du temps, on a déjà du retard sur le projet. Il faudrait demander de l'aide.

Je ne comprends pas encore ce qu'il se passe, j'ai déjà utilisé cette bibliothèque dans un POC (Proof Of Concept) et je n'ai eu aucune complication. Je copie/colle le code dans le vrai projet et je n'ai ni erreur, ni résultat. C'est pourtant le même code ! Enfin, c'est ce que je crois, il y a forcément quelque chose qui change, rien n'est magique ou obscur dans l'informatique web. C'est juste compliqué.

Si je demande de l'aide, il faut que j'explique les points techniques, il faut que la personne soit capable de revenir à niveau. Ce serait plus simple de commencer directement par du pair-programming, mais ça n'a pas été le cas. Faut dire que c'est couteux pour l'entreprise, le pair-programming...

Si deux personnes peuvent parcourir 100 m chacune, l'équipe a parcouru deux fois 100 mètres, mais pas du tout 200 m. Si on "pair-programme", on ne fera pas 200 m non plus, on fera au plus 150 m, car si on est deux, il faut quand même que chacun porte l'autre sur son dos. Le développement informatique ça prend du temps. Et il n'y a pas de recette miracle ni de 10x-développeur.

Et puis, il faut justifier le temps passé à ne rien comprendre à ce qu'il se passe. T'as qu'à voir avec quelle motivation tu vas leur dire, à ton équipe, que t'es même pas fichu de refaire ce que t'as déjà fait et qui fonctionnait très bien.

Et puis, quand t'auras bien galéré, quelqu'un viendra peut-être te dire : « au fait, ton appli, y'en a finalement pas besoin, on va faire autrement ». Alors il faut savoir garder son sang-froid et sa motivation.

Le travail de développeur c'est aussi perdre du temps pour construire une réflexion. J'ai traduit il y a 3 ans un texte qui me semblait le meilleur retour d'expérience de ce que c'est d'être un développeur senior : le développeur Heisenberg.

Je n'ai aucun outil pour juger ou observer le nombre de visiteurs qui ont lu tel ou tel article. Ça ne m'intéresse pas et observer c'est déjà agir et changer le monde, donc même juste pour observer, je n'y vois aucun intérêt. Mais je sais que cet article a été apprécié par beaucoup de gens. Sûrement parce qu'il leur parle et qu'il s'y reconnaisse. Ce n'est donc ni une vue subjective, ni une lubie, ni une excuse, mais bien une réalité partagée.

Mon travail fonctionne beaucoup mieux si j'ai le temps d'aller respirer dans les bois comme le dit Coline Serreau, car la réflexion ne se commande pas comme d'autres efforts physiques.

Quand on a marché deux heures dans une montagne, on est plus intelligent. Coline Serreau

Barbara Oakley a étudié le fonctionnement du cerveau et a proposé un MOOC pour apprendre à apprendre. J'ai suivi ce cours et j'en ai retenu une leçon que répète le Dr Oakley dans chacune de ses interventions. Le cerveau en réflexion a besoin de deux phases, toutes les deux aussi importantes l'une que l'autre :

1. une phase de concentration intense mais courte (~30 minutes)
2. une phase diffuse un peu plus longue (~1 heure) sans réflexion consciente lors d'une balade en forêt par exemple pour permettre aux idées de se solidifier et de faire le pont avec d'autres expériences passées

En ce moment, je creuse des trous pour planter des arbres. J'ai trois trous à creuser de 70 cm de profondeur et 70 cm de diamètre. Cela représente 270 litres de terre par trou à déplacer à l'aide d'un louchet. J'ai creusé le premier trou en un peu plus de 2 heures. Je sais donc que pour les 2 autres trous, il me faudra encore un peu moins de 5 heures. Pour le raisonnement et le développement informatique, on ne peut pas raisonner de cette façon. C'est pourquoi je recommande la lecture des versions traduites du développeur Heisenberg et de #NoEstimate.

Lorsqu'on doit développer une application (ou une fonctionnalité ou une bibliothèque), amplifié par l'ampleur de la tâche, les attentes (et la pression) de chacun, de mauvaises décisions (desquelles on peut avoir honte, syndrôme de l'imposteur oblige), on se retrouve facilement en détresse. On a souvent plutôt besoin de temps pour réfléchir en paix que de taper sur son clavier, et on n'a aucune idée du temps que vont prendre les choses car on n'a pas d'avance une idée précise quant à l'implémentation. On expérimente pas mal, et ça finit par prendre forme, mais c'est long. Et c'est vraiment difficile d'avancer avec sérénité quand on est observé par des responsables qui veulent un point d'avancement quotidien, on se sent obligé de prouver qu'on a avancé contrètement, alors que souvent cette avancée n'est encore qu'abstraite.

Il faut prendre le temps de vider sa tête pour qu'elle soit capable de trouver des bonnes solutions. On n'est pas des pisseurs de code !

On n'est pas
des pisseurs de code !

On n'est pas
des pisseurs de code !

Grève générale !!! Wééé !!! \o \o/ o//

Qu'est-ce qu'on veut ? Travailler
Comment on le veut ? s'il te plait Sereinement
Quand on le veut ? Maintenant

On n'est pas
des pisseurs de code !

*siffle* *SIFFLE* *siffle* Merde, les CRS chargent… Mes yeux, mes yeux ! Non pas la matraque ! Nonnnnn 🍆 in da 🍑