public enum { java, logiciels libres,…}

Après avoir soumis mon article sur le coaching des développeurs, je me suis rendu compte que j’ai oublié pas mal de points qui, à bien y réfléchir, me paraissent essentiels.
Dans mon précédent article ( the first blood pour le coup ) je me suis attardé sur le « quoi » : toutes les actions que j’ai testé dans l’encadrement des jeunes développeurs et des développeurs en général.

Maintenant, je vais essayer de m’attarder sur le « comment » : ma démarche, la posture que l’on doit adopter ( ce n’est que mon ressenti ) etc.

Je vais commencer par ce dernier point. Quand on est architecte, développeur sénior ou bien encore tech lead, on est amené à encadrer techniquement des développeurs.

Vous pouvez adopter plusieurs postures:

A ce stade de lecture de cet article, vous vous dites, quelle est la bonne photo et donc la posture à adopter ?
A mon avis, elles sont à proscrire individuellement. Je pense qu’il faut les panacher.

Tout d’abord, il faut se souvenir de notre début de carrière et se rappeler du code que l’on a réalisé. J’ai par exemple gardé les premiers programmes réalisés en entreprise ( Servlet, JSP, JAVA 1.2, des méthodes de 3km de long, de la duplication de code en veux tu en voila, …) . Ça me permet de relativiser, d’être assez compréhensif et d’éviter de prendre les gens de haut.

Cependant, cette prise de conscience ne doit pas vous empêcher de faire progresser votre entourage et surtout de leur faire éviter les écueils que vous avez vécu. Les ateliers et documentation que vous pourrez leur transmettre sont donc primordiaux. Par exemple, faire lire « Clean Code » ou « Effective Java » aux développeurs – je ne l’oblige pas mais incite fortement – est un moyen de leur faire gagner du temps dans leur apprentissage du code.

Ensuite, même si vos padawans vous voient soit comme Pascal le grand frère ou maître Yoda (pour flatter mon égo), il ne faut pas oublier les exigences que vous avez fixé. L’industrie logicielle a gagnée en maturité en favorisant par exemple l’industrialisation via les outils de CI/CD ou bien encore en facilitant l’application de principes de qualité via des outils d’analyse des dépendances (dependency track) et du code (sonarqube). Vous devez vous adapter, favoriser l’adoption de ces pratiques et imposer quelques étapes qualité de préférence automatisée via de la CI.

Pour favoriser l’adoption de toutes vos exigences, je conseille d’y aller progressivement. Il ne faut pas oublier que votre objectif est de faire « grandir » vos collègues. Pour cela essayez de les adapter et les faire évoluer dans le temps.
Par exemple, pour les tests unitaires, commencez pas mettre en place les différents indicateurs qui vous permettront de mesurer la couverture de code. Ensuite, exigez un niveau de couverture de code (ex. 30%). Suivez le, via les quality gates SonarQube et enfin augmentez le progressivement : 30% , 40%,… Si vous commencez dès le début par un objectif trop haut, ce dernier paraîtra inatteignable et découragera tout le monde. Mieux vaut commencer volontairement très bas pour favoriser l’adoption.

Dans un autre domaine, pour vos workflows GIT, vous pouvez commencer dans un premier temps par le workflow de feature branch. Ce dernier posera les bases des pipelines CI, des merge requests et des bonnes pratiques liées à la gestion de configuration. Une fois tout le cérémonial lié à GIT assimilé par votre équipe, passer à GITFLOW sera beaucoup simple.

Bref, cette démarche revient à parler de conduite du changement. Il faut identifier vos exigences minimales. Celles-ci doivent être acceptées par votre hiérarchie ET par vos collègues. Sans ça vous échouerez!

Si ils vous soumettent quelques idées ou adaptations, n’hésitez pas à les incorporer. Ça peut faciliter l’adoption!

Ensuite, planifiez une progression sur 1 ou 2 ans. Cela donnera à vos collègues dans un premier temps des premiers objectifs atteignables puis une marge de progression leur permettant de s’améliorer.

Enfin, n’hésitez pas à faire un bilan ( par ex. au bout d’un projet ou après la première année ). Ou encore mieux, faites le faire par un de vos collègues pour avoir son ressenti. Cela mettra en exergue le chemin parcouru … et ce qu’il reste à faire 🙂

Conclusion

A mon avis le management et l’encadrement de personnes n’est pas à prendre à la légère. Votre attitude ainsi que la démarche que vous voulez mettre en œuvre feront autant voir plus que toute la documentation et formations que vous mettrez en place.

En changeant de société l’année dernière j’ai eu l’impression de monter d’un cran dans la pyramide des ages.
Pour faire plus simple, je me suis senti un peu plus vieux.

Si vous avez quelques années d’expérience dans le développement ou tout simplement dans la technique, vous avez déjà eu l’occasion de coacher ou d’encadrer techniquement des jeunes diplômés.

Et oui, c’est un signe !

Maintenant vous avez assez de recul ( pour ne pas dire que vous êtes vieux/vieille) pour encadrer techniquement des jeunes ingénieur.e.s
Certes vous n’avez pas fait le choix de partir vers la gestion de projet ou le management.
Cependant l’encadrement technique ( vous pouvez l’appeler mentorat, tutorat, apprentissage,… ) est nécessaire pour faire monter en compétence les nouveaux arrivants et les rendre autonomes.

Je vais essayer de mettre en lumière quelques pratiques que je mets en œuvre et que j’ai pu remettre au goût du jour depuis un an.
Si vous avez des idées, avis, n’hésitez pas à les mettre en commentaire.

Documentation

Il y a plusieurs types de documentation que je partage.
Tout d’abord, j’ai partagé quelques sites et ouvrages qui me paraissent indispensables.
Clean  Code arrive en premier. Effective Java en second.
A mon avis, ça ne sert pas à grand chose d’aller plus loin dans le développement si on n’a pas acquis les notions décrites dans ces livres!
Puis vient le refactoring puis les design patterns.

Ensuite, j’essaye de partager via notre chat interne les quelques solutions trouvées dans les projets.

Enfin, j’ essaye de m’ astreindre à mettre à jour la documentation.
Oui c’est un combat de tous les jours 😀
Ça commence par les exemples de code.

J’essaye d’ avoir des repos git assez lisibles (c.-à-d. avec un README intelligible) et un code à jour correspondant aux normes en vigueur.
Un exemple, j’ai crée un projet permettant d’ illustrer la mise en œuvre des tests unitaires et d’intégration dans un projet standard (spring, tomcat, docker,…).

Ces éléments nécessitent un travail important, que ça soit à la création ou pour tenir à jour la documentation. Cependant, ça me permet de ne pas me répéter, et d’ illustrer via un cas pratique ce que j’attends dans les Merge Requests. En effet, chaque développement est assujetti à une Definition of Done ( tests, qualité, …) . Il faut donc que la qualité de la documentation soit en rendez vous !

Veille

Au delà de la documentation, je « pousse » aux différents dev, les articles que je trouve pertinent pendant ma veille technologique.
J’invite également tout le monde à en faire.
Je ne peux pas les obliger.
Maintenant comme je peux le dire régulièrement.
Si on souhaite rester dans la technique, il faut se tenir à jour. La veille (sites web, confs, livres,…) en est le meilleur moyen.

Ateliers / Workshops

Organiser un workshop ou atelier d’une heure ou deux max est un bon moyen de fédérer les troupes.
J’essaye d’organiser deux types d’atelier.
Le premier est uni directionnel : Une personne présente un sujet technique et les autres en profitent.
Ça permet tout d’abord de diffuser plus simplement certains messages.
Par exemple, j’ai organisé une présentation de 30 mn sur l’utilisation de NULL dans le code et l’utilisation des Optional.

Le deuxième est plus long à préparer.
C’est un atelier organisé à la manière d’un hands on sur un sujet très précis.
Pendant 1H ou 2H, l’équipe planche sur un sujet. La session est organisé et animé idéalement par un ou plusieurs membres de l’équipe ( ça ne vous empêche pas d’avoir votre mot à dire lors de la préparation 😀 ).
Récemment j’ai co-organisé un hands on « Clean Code » en illustrant quelques notions qui nous paraissaient essentielles.

Ces évènements sont évidemment chronophages mais offrent un certains retour sur investissement.
Outre la présentation technique des différents sujets, les membres de l’équipe se forment et apprennent.
Ils peuvent voir en situation les différentes notions que vous évoquez (en fait je les rabâche) lors des MR ou pendant les revues de code.
Aussi, je pense que ça contribue à une certaine émulation technologique.
Ça prend du (beaucoup de) temps, mais ça en vaut la peine!
L’idéal dans ce genre d’exercice est quand tout le monde propose des sujets.
Pas seulement l’architecte ou le lead dev.
Les développeurs peuvent prendre le lead dans cet exercice. Ca permet d’une part de les valoriser, de les faire monter en compétence. Quoi de mieux pour approfondir un sujet que de monter un talk et/ou hands on dessus ?

Revues de code

Je ne vais pas aborder dans ce chapitre les revues de code que l’on peut faire dans le cadre des projets, lors des MR par exemple.
Pour certaines personnes, surtout les juniors, je fais régulièrement une revue de code alternative.
Je passe une 1/2 heure, une heure max sur un bout de code que le dev m’aura sélectionné. Je lis le code avec le développeur et je donne quelques axes d’amélioration: design patterns, tests unitaires, refactoring,… Tout y va.
Ça permet de se poser et d’aborder quelques sujets: la programmation fonctionnelle, les IO en java,…

Pour aller plus loin

Bien évidemment, beaucoup d’autres actions peuvent être mises en place. La plupart de l’accompagnement que je peux réaliser se fait quotidiennement, dans les projets.

Pour aller un peu plus loin, un collègue a mis en place un système de mentorat pour accompagner les jeunes développeurs et accélérer leur montée en compétence.
Cette idée est très intéressante et peut être appliquée dans beaucoup de contextes.

Si vous avez des idées, questions, remarques, pratiques que vous développez chez vous, n’hésitez pas à les partager!