Que font pour nous nos confrères et consœurs développeurs, et comment bien le leur rendre.

The english version is right here.

Des rétroactions annuelles se sont tenues dans ma compagnie il y a quelques semaines de cela. Elles font partie d’un processus plus complet se déroulant sur l’année entière. Plutôt standard c’est vrai, sauf que j’ai été invité aux rétroactions de quelques collègues, et alors là branle-bas de combat.

L’entretien se déroule en deux parties. La première, celle concernée dans ces lignes, consiste en une conversation ouverte entre toutes les parties présentes : le ou la développeuse, son ou sa supérieure et une couple de collègues. On dirait qu’a priori deux invités par rétroaction font l’unanimité dans ma compagnie. Sûrement un héritage bon flic / mauvais flic ou quelque-chose du genre. Bref, j’ai été invité… trois fois. Instant honnêteté : je travaille dans une équipe de quatre personnes. Mon effet est un peu foireux. Peux pas m’en empêcher.

Ceci étant dit, il a fallu se mettre à la préparation de ces événements, et en faisant ça bien. J’étais chargé en tant qu’invité de discuter avec les principaux intéressés de plusieurs sujets comme l’autonomie de la personne, son esprit d’initiative, son expertise, tout ça. Qu’on se le dise, les collègues peuvent compter sur moi, je les couvre. Qu’on se le dise aussi, c’est complètement inutile : nous travaillons de manière étroite avec notre responsable, qui fait pratiquement partie de l’équipe.

Assez de contexte, les faits.

Première question à moi-même, en français dans le texte : “Comment dois-je me préparer pour ça?” Réponse : par rassembler des faits, rien que des faits. J’ai donc travaillé fort pour me remémorer et réunir leurs succès de l’année, qui se sont potentiellement déroulés il y a des mois de ça. Il n’aura pas fallu bien longtemps pour que je me rende compte que ça ne servait à rien. Mes collègues allaient se charger de tout ça bien mieux que moi. J’avais jusqu’alors passé toute ma préparation à tenter de leur amener du contenu qui pourrait leur être utile, mais je ne suis parvenu à rien de pertinent. Bien sûr qu’ils savaient très bien ce qu’ils avaient accomplis. Et bien sûr qu’ils allaient plaider leurs cas bien mieux que moi. Rien de ce que je n’aurais pu amener ne le serait mieux que par eux-même. Et c’est alors qu’épiphanie, instant émotion : j’avais raison sur ce point, et je faisais tout faux depuis le début.

Je ne trouve rien à leur amener qui ne compte vraiment. Tout ce que je formule n’a pas le potentiel espéré. Que reste-t-il donc?

Tout ce qu’ils m’ont apporté.

C’est là où résident toute la valeur et la pertinence de ma présence : le témoignage sur la vie de l’équipe et sur la personne, par un pair. Pas seulement un pair, mais un autre membre de l’équipe. J’ai donc commencé à potasser le sujet pendant que je faisais la vaisselle. Souvent donc. En voici un modeste compte-rendu.

• me donnent-ils envie de me décoller du lit pour aller travailler? Sans déconner, on voit nos tronches constamment et on s’entend râler tout autant. C’est admis, c’est un vrai cauchemar d’interagir avec des personnes avec qui l’on est totalement incompatible. Et bien ceux-là ne le sont pas, ils sont géniaux. Nous sommes devenus amis après tout ce temps à brailler autour du code, de l’addiction à la caféine et de nos univers SF respectifs (Wars, Trek, Gate). Y aller simplement pour travailler? Nope. Y aller pour se réunir autour de tout ça, via cette famille de circonstance, hétérogène et compliquée qu’est la notre, ouep.
• deviens-je un meilleur développeur à leurs côtés? Voila un point bien intéressant car c’est ici que demeurent les faits évoqués plus haut. En tant que développeur, je cherche constamment à m’améliorer, à remettre en question ce que je sais, ou ce que je pense savoir. C’est un sous-ensemble de ce pourquoi j’aime mon métier. Leur expertise est ici mise en exergue : ils font parfaitement leur boulot, ils partagent leur savoir, aident leurs pairs… Tous les faits qu’ils mettent sur la table, succès ou échecs, renferment une source d’apprentissage pour moi. S’entraider et partager : deux concepts fondamentaux.
• deviens-je un meilleur moi-même à leurs côtés? Par sa présence, ce point se fait l’extension des deux précédents. Certaines relations transcendent leur contexte initial. Des collègues deviennent amis, des amis meilleurs amis, des amants, tout est possible. Dans tous les cas, bien s’entourer est primordial pour quiconque souhaitant s’améliorer. Pas parce que l’objectif est de devenir l’autre, ou son Némésis. Parce l’autre nous fait réfléchir. Améliorer ses compétences grâce à un ami est une chose, mais apprendre sur soi-même en est une autre.

J’ai débité cette petite analyse-de-vaisselle-parce-que-je-la-fais-souvent pendant ces entretiens. Pas parce que ç’aurait pu les aider, même si ça a relativement fonctionné. Plutôt parce que je voulais partager ce que c’est que de travailler à leurs côtés. Le penser c’est une chose mais le formuler c’est une autre paire de manches. Vous avez déjà essayé de changer de manches? On ne va pas se mentir : j’adore parler pour dire n’importe quoi, ou pour ne rien dire du tout, ça marche aussi. Ça n’a donc pas été simple.

C’est maintenant mon tour. La formulation de ces points ne me rend que plus reconnaissant envers eux, et je compte bien les appliquer pour eux au quotidien.

Renvoyons-nous l’ascenseur. Pourquoi ne pas commencer par de petites choses, comme contribuer à des projets ouverts, ou à partager et encourager la contribution? D’ailleurs, les vendredis open-source pourraient être un bon point de départ.

Tout ça pour dire : en tant que barbu, développeur et être humain, j’écris ces lignes pour remercier mon équipe. Mais aussi pour vous remercier vous, pair anonyme qui pensez de même pour vos collègues.

It’s payback time, mais positivement pour une fois.