FR - Le nouveau : boulet ou messie

TL;DR

J’ai eu le plaisir de participer au PHP Tour 2014 à Lyon, pour parler de ce sujet.

Disclaimer

Je n’ai pas 10 ans d’expérience, et 25 boites différentes. Juste quelques boites, et quelques équipes.

Mon but c’est de dire ici ce que j’aurais aimé que l’on m’ait dit quand j’étais

• “l’ancien” à Wid’op, accueillant nos deux nouveaux employés — soit 20% d’augmentation de masse salariale à l’époque
• le nouveau à Profilsoft, rejoignant un editeur de logiciel où l’application a 8 ans et les devs chacun plusieurs années d’expérience.
• “l’ancien” à Profilsoft, accueillant 5 nouveaux developpeurs américains et scrum masters, passant d’une équipe de 4 dans un bureau, à une équipe de 11 sur 2 continents, 3 timezones et 4 bureaux.

Définissons un peu ces gens, que l’on appelle “nouveau” ou “ancien”

Nouveau

“Non mais c’est quoi ce bordel… Tain je pige rien.”

Caractéristiques

Moins bien

• Casse un peu les pieds à poser tout le temps des questions
• Connaissance superficielle des projets, des process, des gens.
• Dispersé, pouvant souffrir d’un deficit d’attention façon Bruce (Squirel! !)

Plus mieux

• Energique
• Neuf et motivé (de toute façon il est encore en période d’essai, il a intêret)
• Même hors menace de la période d’essai, quelqu’un joignant une entreprise est souvent sincèrement motivé pour s’investir, prendre ses marques et faire ses preuves.
• Bref, chaud chaud chaud (à ne pas sous-estimer)

Ancien

“Ah oui, mais en fait faut que je t’explique. A l’époque, on a fait ça pour…”

Caracteristiques

Moins bien

• Il a souvent beaucoup de travail. En tout cas il est souvent très occupé. La causalité entre ces deux états n’étant pas obligatoirement présente.

“Je suis sous l’eau” — tous les anciens, toujours.

• Parfois lassé, blasé
• Et parfois même condescendant, frustré de ce nouveau qui ne comprend pas et pose toujours des questions.

Plus mieux

• Il fait souvent preuve d’un connaissance approfondie (des années).
• Qui lui apporte le savoir, la sagesse, et la réponse aux secrets de Jedi WTFs qui peuplent tout projet/application sur lesquels suffisamment de mains sont passées suffisamment longtemps.
• Il a surtout de l’experience, de l’expérience, de l’expérience.

Conseils

J’aimerais proposer humblement quelques conseils basés sur l’expérience que j’ait eux dans ces deux entreprises incroyables que sont Wid’op et Luceo. J’ai eu la chance d’être accueilli le mieux du monde, rapidement mis en confiance, poussé à donner le meilleur de ce que je sais faire.

Parrainage

Non, pas celui de votre salle de sport.

Plutôt une relation maitre/élève, dans l’esprit de ce qu’on peut retrouver dans le compagnonage.

Il s’agit de mettre en place un système de parrainage, entre deux personnes, l’une expérimentée, disponible l’autre nouvelle, volontaire et curieuse (oui, je vis dans le monde des bisounours).

Mais il faut jouer le jeu pour de vrai:

1. Allouer du temps exprès, dédié à ce parrainage, en plus de la collaboration quotidienne pour gérer le travail de tous les jours

Dans mon cas, j’avais le plaisir de passer quasiment une après-midi par semaine, seul avec le CTO et le lead dev. On l’on choisissait une portion de l’application, puis on me prenait par la main pour une visite guidée pitoresques : beaux monumens, musées, quartiers mal famés, j’avais droit à un plan plutôt précis, le tout agrémenté d’anecdotes historiques sur la construction, et parfois quelques legendes folkloriques.

1. Mettre ensemble des gens qui s’entendent bien personnellement, ou au minimum, qui se respectent.

Un grande partie de la relation de mentorat passer par la motivation et l’envie de bien faire, et je n’ai pas le sentiment que ce soit quelque chose qui puisse arriver sans une relation un peu privilegiée.

On ne peut pas motiver les gens, on ne peut que créer un cadre qui rend possible à la motivation d’éclore. — Je ne sais plus qui, mais c’est très vrai.

Donner des responsabilité et faire confiance

Faites confiance au nouveau et donnez lui de vraies responsabilités :

• Développer des vraies fonctionnalités, fixer des vrais bug et pas les vieux bugs de 500 ans qui sont tellement peut importants que le client les ayant rapportés est aujourd’hui décédé.
• Le/les mettre en prod lui-même
• Mettre en place un outil ou un nouveau process (dans mon cas Behat, Github, des code review, …)
• Le lancer là dessus, lui demander si ça l’interesse, eventuellement lui proposer, mais sans jamais forcer. Suggérer sans avoir la main lourde. Le but est de mettre en confiance, et de donner de l’autonomie.

A éviter :

• Le side-project-etude-de-faisaibilite-ecrire-un-rapport qui traine depuis 6 mois et dont personne ne veut.
• Ne pas donner de suite à ce qui est proposé **(A éviter plus que tout).
  • Si c’est non, expliquer pourquoi jusqu’à être d’accord/être compris
  • Si c’est oui, donner les moyens de le faire: du temps, des serveurs, payer des abonnements de trucs acheter du matériel, impliquer la hierarchie, menacer, faire chanter.

Il n’y a rien de plus efficace pour tuer l’envie, l’innovation et la volonté de bien faire que d’ignorer les efforts faits. Quelqu’un s’est donné la peine d’aller un peu (beaucoup ?) plus loin que ce qu’on attendait de lui ? Trouvez un moyen de lui montrer de la reconnaissance, que ce soit à travers quelques simples phrases, une prime, ou plus précieux encore, du temps.

Je vais le redire encore : trouvez un moyen de lui montrer.

Même si finalement ça ne sera pas utilisé. Surtout si ça ne sera pas utilisé.

A vous, nouveau

Vous choisissez.

Vous pouvez être deux types de nouveau:

Alternative #1: C’est de la merde. De la merde. De la merde.

Vous ne cherchez pas à comprendre, et vous perdez vite la foi. Un signe ne trompe pas, au bout de 3 semaines, vous ne posez plus vraiment de questions, vous cherchez juste à faire ce qu’on vous demande. Soit vous ralez tout le temps, soit vous ne ralez plus du tout — il est à noter que ce symptome d’hyper ou hypo-ralage est un signe à prendre avec le plus grand sérieux, même chez les anciens.

Vous êtes finalement persuadés qu’ils sont juste mauvais ici, et que vous feriez bien, bien mieux. Pourtant, vous pourriez probablement être très surpris de savoir le pourquoi d’une application qui en est arrivée là. Oui le code de telle ou telle portion de l’appli est complexe, velu, poilu, mais en fait c’est (peut-être dû au fait que les règles métiers sont elles-même complexes. Complexe != Compliqué. Ne sous-estimez pas vos anciens, et surtout faites preuve de curiosité et d’empathie.

Alternative #2: l’éponge

Vous venez, en déposant vos à priori, mais en gardant toute cette énergie, cette motivation, cette nouveauté. Vous pensez que votre collègue (ancien?) a tord, mais vous l’écoutez jusqu’au bout, avant d’essayer de lui expliquer qu’il a tord. Et une fois sur deux (voire plus), vous comprenez que finalement il a probablement raison, et que ce qui semblait une boule de pue façon spaghetti, est en fait une solution complexe et pensée, à defaut d’être élégante.

Vous ne lachez pas vos idées pour autant, et vous amenez ce que vous connaissez. Après tout, si vous êtes embauché, c’est que vous avez quelque chose à amener. Allez-y! Proposez, demandez, et demandez pourquoi, pourquoi et encore pourquoi.

A vous, ancien:

Vous choisissez.

Vous pouvez être deux types de vieux:

Alternative #1: le dinosaure.

Vous le connaissez. C’est ce développeur, toujours persuadé que DCOM et ces soit disant API REST sont la même chose, et que finalement VB c’était quand même plutôt bien, et puis ça permettait de faire des application rapidement et juste en cliquant.

Ne veille pas, ne lis pas, ne se forme pas. De manière générale, assez peu curieux.

Peut souvent être trouvé en train de ressasser le bon vieux temps, à l’époque où on était pragmatique et où on faisait des choses plus simples et soi-même.

Alternative #2: le vieux loup de mer.

Le visage buriné par ces années passés à parcourir les mers et les océans de projets, à travers les tempêtes emportant toute la prod’, résistant aux sirènes de la mode et du hype, mais suivant les courants menant à la qualité. Après 20 ans passés à affuter chaque jour ses armes avant de se rendre sur le pont, notre loup de mer est une source intarissable de conseil et d’anecdotes.

Pourtant malgré toute cette expérience, ce vieux briscard accueille avec sourire et humilité moins expérimenté que lui. Il écoute avec attention et curiosité, et non avec condescendance. Toute cette expérience acquise l’a rendu humble.

Les developpeurs juniors pensent tout savoir,
les developpeurs expérimentés pensent ne rien savoir,
les vieux de la vieilles detestent juste les ordinateurs.

Ca fait mal ? Tant mieux !

Le newbie vous gonfle, il pose toujours des questions genre “Où est la doc?”, “Mais, y a pas de tests ?”. Il est toujours paumé lorsqu’il faut mettre en prod, perdu dans ces 15 étapes manuelles dont le moindre oubli fait tomber la prod ?

Ca vous gonfle ? C’est normal.

Ce petit sentiment qu’on ressent là bas, tout au fond, c’est la de honte, teintée de culpabilité. Parce qu’au fond, il a quand même un peu raison ce nouveau. Il ne s’est pas acclimaté à ce qui manque, à ces petits quirks, ces hacks. Il les voit lui, et il en parle.

Mais il n’en parle pas pour se plaindre. Plutôt parce qu’il pense qu’il a raté quelque chose, qu’il a peur de mal faire. Pas pour raler ni mettre la honte.

Vous connaissez cette maxime agile : si ca fait mal, faites le plus souvent.

Conclusion

Investissez :

• dans vos nouveaux si vous souhaitez accueillir des membres actifs dans votre environnement professionnel
• dans votre ancien si vous souhaitez est à l’aise au travail, et y aller avec plaisir.

Epilogue

Même les héros les plus expérimentés
Doivent savoir respecter leur écuyers
Car la toile est un art où les divergences rapprochent
Donc tolérez les nouveaux, malgré leur tête de mioche
— Sud’web