Avez-vous déjà été témoin de la frustration d’un développeur face à du code qui n’est pas le sien ?
Il y a de fortes chances que oui. Les développeurs ont souvent la réputation d’être grincheux.
J’appelle cela la “douleur de la courbe d’apprentissage”.
Cependant, il est risqué de faire de la “grumpiness” des développeurs un argument.
Les déclarations telles que :
C’est mal fait
ou
On devrait refactorer tout cela.
Ce sont des signaux à prendre en compte, mais ils ne devraient pas être les seuls facteurs à considérer lors du choix d’un outil.
Trop souvent, ces affirmations découlent de la douleur de la courbe d’apprentissage. Il est difficile d’apprendre quelque chose de nouveau et cela peut être douloureux.
Personnellement, je considère cela comme une phase dans la courbe de “grumpiness du développeur”.
Je viens de créer ce terme, mais il existe sûrement déjà ailleurs, à l’instar du concept de Dunning-Kruger. Quoi qu’il en soit, gardez cette image à l’esprit, s’il vous plaît.
Et si la “grumpiness des développeurs” pouvait être un indicateur de l’expérience du développeur (ED)?
Mettant de côté ceux qui demandent de l’aide directe pour résoudre des problèmes mal décrits - et qui devraient suivre la licence DBAD de Phil Sturgeon - je pense que oui.
Si la “grumpiness” à l’égard d’un outil est répandue, cela pourrait signifier :
- Que l’expérience du développeur n’est pas une priorité ou est absente.
- Que le public cible de l’outil se compose principalement d’utilisateurs finaux.
- Il n’y a rien de mal à cela, mais il faut en tenir compte pour le type de fonctionnalités que l’on souhaite développer.
- Que l’outil en est encore à ses débuts et est utilisé en surface pour le moment.
- Que le tutoriel “hello world” laisse de côté trop de détails importants.
- Que la documentation ne reflète pas l’utilisation principale de l’outil.
- Il est possible que l’outil ait du mal à évoluer.
- Cela pourrait être dû à un manque de temps ou de ressources, comme je le pense souvent.
Améliorer l’expérience du développeur pour un outil est un processus laborieux. Même en interne, au sein d’une équipe de développeurs, cela devient un produit en soi, mais s’avère extrêmement bénéfique à long terme.
Chaque petit pas vers une meilleure expérience du développeur est crucial.
Si vous envisagez d’adopter un nouvel outil et que vous constatez beaucoup de frustration dans les discussions, envisagez de contribuer à la documentation de l’outil sur son dépôt Git.