Bonjour ! Je suis François, développeur et software craftsman chez Ippon à Lille depuis 2019. Je suis actuellement en mission en tant que tech lead pour les Galeries Lafayette sur les services et APIs ! Mes domaines d’expertise sont principalement Java, Kafka et GCP mais je m’intéresse à beaucoup d’autres sujets (React, Go, …). Je suis également Tech Community Ambassador. Mon rôle consiste à animer la communauté en interne et en externe. Il consiste aussi à mettre en relation les développeurs avec les communautés (meetups et évènements type DevFest) et à les aider dans la création de contenu. Je m’intéresse à la DevX à travers tous ces aspects !
Comment améliorer l’expérience du développeur (DevX) ?
Ces dernières années, on entend de plus en plus parler de DevRel, Dev Advocate ou plus récemment de DevX. Mais qu’est-ce qui se cache derrière tous ces termes ? Du bullshit ou une réalité concrète destinée à adresser de vraies questions de manière authentique ? Tentons de démêler le vrai du faux et de mieux comprendre les tenants et aboutissants de la DevX, une pratique assez émergente ces derniers temps.
De plus en plus, on passe d’un monde où le développeur était un simple exécutant, parfois sans vision produit, sans reconnaissance, sans sentiment d’utilité, à un monde où il peut être un moteur au cœur de la satisfaction client/utilisateur.
⚠️ Avant d’aller plus loin, un petit disclaimer est nécessaire pour préciser que beaucoup ont leur propre définition ou vision de la DevX. Ce concept n’aura pas la même interprétation selon le type et la taille de la structure (TPE, PME, start-up, scale-up, ESN, néo-ESN, éditeur logiciel, intégrateur…). Je vous propose ici ma vision de la chose. Par ailleurs, je vous invite à lancer le débat et réagir si vous êtes d’accord ou pas en commentaire ou sur les réseaux sociaux !
C’est quoi la DevX ?
L’expérience du développeur (DevX ou DX pour developer experience) est au développeur ce que l’UX (user experience) est à l’utilisateur (user). Le développeur est lui-même un utilisateur dans la mesure où il utilise des outils, des services, des pratiques, etc. Comme l’indique Eric Evans dans le chapitre “Supple Design” de Domain-Driven Design (2003) : “The ultimate purpose of software is to serve users. But first, that same software has to serve developers” (“Le but ultime du logiciel est de servir aux utilisateurs. Mais d’abord, le même logiciel doit servir aux développeurs”).
Comme le DevOps, c’est une philosophie ou un ensemble de méthodes qui peut s’appliquer dans des organisations ayant des équipes de développement réalisant des produits.
La DevX n’est pas un métier, c’est un domaine à la croisée du développement (engineering), du management, du marketing, du business, des RH :
- Du développement (engineering) : il faut connaître le quotidien d’un développeur et donc les potentiels problèmes et besoins auxquels il peut faire face (onboarding, documentation, méthodes de travail, agilité, DevOps sans silos, discussion avec l’utilisateur en direct, vision claire, …)
- Du management : comment accompagner son équipe pour qu’elle travaille dans les meilleures conditions et dans la meilleure entente (compatibilité entre les profils, outils, méthodes…) ?
- Du marketing : comment communiquer en tant que développeur ? Comment faire connaître nos créations en interne / externe d’une organisation ?
- Du commercial : choix des missions pour diversifier le parcours d’un développeur au sein d’une organisation et lui permettre de monter en compétences.
- Des RH : comment faire en sorte de fidéliser des développeurs au sein d’une organisation (partage des connaissances, facilitation de la vie de développeur, poste de travail adapté, ordinateur portable satisfaisant, formation en soft et hard skills, mentorat, accompagnement sur de la création de contenu…) ?
Elle concerne donc les métiers des différents domaines listés ci-dessus.
Il est possible de lister plusieurs rôles qui tentent de l’améliorer et qui peuvent être pris au sein d’une organisation par des personnes ayant la casquette de développeur, d’architecte ou de chargé de marketing en fonction des cas :
-
- DevRel (developer relations) / (Tech) Community Ambassador : améliorer les relations entre les développeurs internes à une organisation et les développeurs externes à cette dernière.
- 🥑 Dev Advocate (developer advocate) ou évangéliste (par exemple Richard Stallman pour GNU/Linux et le logiciel libre) : faire activement la promotion d’un produit, notamment en créant du contenu (articles de blog, conférences, réseaux sociaux…).
- Solutions Architect / Customer Success Architect (pre-sales et post-sales) : proche du rôle précédent, mais plutôt centré sur le client (customer experience). Être un facilitateur pour la mise en place d’une solution / d’un produit (par exemple Kafka chez Confluent) et s’assurer de sa bonne intégration au sein du SI d’un client en veillant à atteindre la satisfaction de celui-ci.
Certaines personnes portant le rôle de DevRel (chez Microsoft ou encore OVHcloud) ont maintenant une influence importante au sein de la communauté. Toutes les entreprises n’ont pas de cellule dédiée à la DevX ni souvent même de rôle de DevRel ou de Dev Advocate. Ils n’ont souvent pas les moyens de dédier une personne à temps plein sur ce poste/rôle. C’est pourquoi il est d’autant plus important d’avoir un fonctionnement bottom-up où les propositions des développeurs sont prises en compte et où chacun peut se sentir utile pour améliorer le quotidien de chacun au sein d’une organisation. Il est possible dans une telle situation de répartir le rôle sur plusieurs personnes motrices et volontaires ayant des affinités sur certains sujets.
Enfin, un DevRel doit connaître un minimum la tech et le monde du développement. À l’inverse, un développeur n’est pas obligé de connaître la DevRel ou la DevX, mais c’est dans l’intérêt de chacun que tout le monde ait des bases a priori.
L’iceberg du developer advocate par Wassim Chegham dans The Subtle Art of Being A Developer Advocate donne une idée de ce rôle et surtout de ses tâches souvent cachées et méconnues :
De plus en plus de communautés et d’événements se forment autour de la DevX. Citons par exemple le DevRel Salon (site et meetup) ou encore la DevX Conf lancée par GitPod qui a eu lieu début mai 2022 (vidéos disponibles sur leur chaîne YouTube). Des podcasts (en anglais) permettent aussi de s’intéresser à l’actualité de la DevX : DevRelX Podcast et celui de Community Pulse. Enfin, des vidéos YouTube fleurissent à droite à gauche comme celle de la table ronde WeLoveDevs ou celle de Tech Rocks.
Pourquoi prendre soin des développeurs ?
…et donc de l’expérience qu’ils ont avec eux-mêmes, avec leurs outils, leurs produits, leurs organisations ?
Il existe différentes raisons de prendre soin des développeurs :
- Faciliter / améliorer leur quotidien
- Les fidéliser en interne (au sein d’une organisation)
- Les fidéliser en externe (lorsqu’ils utilisent un produit ou une solution)
- Être meilleur que la veille
- Répondre au besoin de reconnaissance
- Répondre au besoin de se sentir utile
Le rapprochement entre la DevX et la permaculture peut être fait, car cette dernière repose sur trois piliers : prendre soin des humains, prendre soin de l’environnement et partager/réutiliser/recycler.
Le parallèle se fait rapidement avec la vie d’un développeur : prendre soin des développeurs, prendre soin de leur environnement (technique, organisationnel…) et partager/réutiliser/recycler (de bons outils utiles et efficaces par exemple, notamment à travers l’inner-source ou l’open-source).
Comment prendre soin des développeurs ?
Un concept central à la DevX est l’authenticité à travers des faits qui peuvent se retrouver à différents niveaux que nous allons aborder.
Concrètement, la DevX peut s’améliorer sur deux axes : individuel / collectif et interne / externe (à son organisation ou sa communauté).
Pour les organisations, il s’agit ici de se demander comment aider les développeurs à améliorer leur quotidien sur chacun des points listés.
Comment prendre soin des développeurs sur leur produit / projet ?
En tant que prestataire sur une mission chez un client ou en tant que développeur interne chez un client final, sur un produit ou un projet, il y a de nombreuses façons d’améliorer la DevX.
L’onboarding des nouveaux arrivants n’est pas à négliger et peut durer parfois plusieurs mois selon les organisations :
- Est-il ponctuel au début ou sur une plus longue période ?
- Ai-je tous les accès / droits à mon arrivée ?
- Pair/mob programming sur une feature simple pour démarrer ?
- La documentation est-elle suffisante pour m’aider à être autonome (README.md, CONTRIBUTING.md, ADR, diagrammes, Confluence, Wiki…) ?
- Est-ce que j’ai les bons outils à ma disposition ?
La DevX porte également sur le niveau de maturité des organisations en termes d’agilité et de DevOps. Une entreprise se dit-elle agile et DevOps pour la simple hype ? Ou y a-t-il des choses mises en place qui attestent réellement d’une maîtrise de ces sujets ? Si ce n’est pas le cas, cela peut affecter parfois la vie du développeur au quotidien et créer des silos. Relire le manifeste agile et les ressources à propos de la philosophie DevOps peut permettre d’être force de proposition en tant que développeur pour pallier certains manques.
De la même façon, est-ce que le manifeste du software craftsmanship est pris en compte ? Y a-t-il des pratiques telles que le TDD (test-driven development), le BDD (behavior-driven development) ou le DDD (domain-driven design) #combo ? Le développeur dialogue-t-il directement avec les utilisateurs de son produit ? Comment est gérée ou perçue la pyramide des tests ? La qualité du code livrée est-elle vérifiée ? Comment se passent les revues de code ? La boucle de feedback est-elle courte ou trop longue ? Y a-t-il une intégration continue ? Est-ce que l’équipe pratique le pair ou le mob programming ?
Ensuite, un point important peut être d’organiser des rituels réservés uniquement aux développeurs. Comme des points hebdomadaires pour parler de tout sujet touchant au quotidien du développeur. (problème récurrent, proposition d’architecture, présentation d’un outil, retour d’expérience, retour sur un événement donné, idée à proposer, etc).
Comment prendre soin des développeurs dans leur organisation interne ?
Par organisation interne, j’entends ici leur entreprise (ESN ou client final) ou leur communauté (de freelances, open-source, meetups…). Par exemple, chez Ippon, un certain temps est alloué aux consultants Ippon hors prestation client pour capitaliser sur des connaissances apprises en veille technologique (articles, talks, formation, etc) ou en mission. Ces créations de contenu impliquent des primes de capitalisation, ce qui n’est pas négligeable. Mais surtout, elles permettent d’améliorer le quotidien de tous au sein de l’entreprise à travers le partage de connaissances.
Ensuite, le rôle de Tech Community Ambassador a été lancé pour la première fois, notamment sur l’agence lilloise de Ippon début 2022. C’est un rôle en pleine construction que j’ai endossé et qui recouvre plusieurs domaines. Ce rôle implique l’animation des communautés internes et externes. En interne, un comité d’aide et de relecture pour les CFP des événements techs a été mis en place. En externe, la mise en relation des consultants Ippon pour participer à des BBL, meetups et aux communautés. Mais également l’implication de ces derniers dans celles-ci.
Le Tech Community Ambassador se veut un ambassadeur au service des développeurs au sein d’une organisation et peut donc en ce sens améliorer la DevX !
Comme je le disais, il peut alors être intéressant d’avoir du temps alloué pour la veille technologique. Elle recoupe la lecture d’articles et des réseaux sociaux (notamment Twitter et LinkedIn), la lecture de vidéos de talks ou autres podcasts, la création de projets personnels, la contribution à l’open-source, apprendre un nouveau langage de programmation, un framework, une façon de faire ou encore préparer une certification.
Pour transmettre la connaissance (dans les deux sens : donner et recevoir), la formation est également un outil très puissant. Elle peut être interne ou externe (à destination de clients par exemple), elle peut servir à former de nouveaux arrivants, des stagiaires ou encore des collaborateurs ayant des besoins spécifiques. Elle n’est pas forcément technique, mais peut aussi porter sur des soft skills. La pratique des coding dojos et katas (de développement et d’architecture) permet, elle aussi, parfois d’apprendre des manières de faire.
Créer du contenu
La création de contenu (ou capitalisation sur les connaissances acquises) peut s’avérer très efficace pour monter en compétences sur un sujet ou tout simplement pour synthétiser ce que l’on a appris. Elle se traduit par l’écriture d’articles de blog, la création de talks à destination de conférences, meetups, BBL ou Twitch par exemple et encore la création de contenus de formation. Le corollaire à la création de contenu est la communication. C’est important pour la diffusion de nouveaux contenus de toucher un certain public via Twitter, GitHub ou LinkedIn pour générer du débat et enrichir les échanges. Cela permet de gagner en impact et influence, mais aussi en confiance en voyant les progrès que l’on fait en créant du contenu.
Pour la création de contenu (entre autres), le développeur peut s’appuyer sur le mentorat. Tout développeur, quel que soit son niveau, peut à un moment donné avoir un mentor et être un mentor. Un développeur junior sortant d’école peut tout à fait être le mentor d’un stagiaire quelques mois après ! Le mentor est à l’écoute et permet de guider et conseiller son padawan pour lui permettre de progresser par étapes en définissant avec lui des objectifs. C’est le cas chez Ippon avec le programme Black Belt qui permet de progresser de manière ludique (proche de la “gamification”) dans différentes filières (développement full-stack, front-end, back-end, architecture, data, DevOps, …).
Le deuxième pilier, avec le mentorat, est justement cette notion de filière ou practice (on parle aussi de communautés de pratiques). Elle permet de regrouper au sein d’un même groupe ou d’une même communauté des développeurs partageant les mêmes intérêts (back-end par exemple). Leur rôle est d’animer les développeurs autour d’événements, de moments de partage et de retours d’expérience lors de certains rituels.
Les entretiens techniques
Les entretiens techniques peuvent également être l’occasion pour un développeur de se dépasser (que ce soit en tant que candidat ou en tant qu’auditeur). L’idée est de ressortir d’un entretien en ayant appris quelque chose quel que soit le bord de la table. Un développeur qui fait passer de nombreux entretiens techniques peut améliorer son empathie à l’égard de ses éventuels collègues en comprenant ce qui les poussent à le rejoindre dans son organisation. Les entretiens lui permettent également de se dépasser et de se poser certaines questions qu’il ne se serait peut-être pas posées. Enfin, ils lui permettent de travailler des compétences de recrutement non négligeables.
L’open-source
Pour finir, last but not least, la contribution à l’open-source peut faire partie de la vie d’une organisation dans sa stratégie d’innovation et pour faire monter en compétences ses collaborateurs sur certaines technologies. Un développeur qui utilise un outil mis à disposition gracieusement par un autre développeur peut l’améliorer. Il peut corriger une faute d’orthographe, un bug, un manque de documentation ou ajouter une fonctionnalité ou une traduction manquante en proposant une PR ou une MR. Un développeur fan d’un projet open-source peut aussi tout simplement en faire la promotion. Se pose aussi la question du financement de l’open-source. Certaines entreprises y contribuent à travers des dons via Open Collective par exemple et cela est plus que vital dans le contexte récent (Log4shell, FakerJS…). Dans le même ordre d’idée, les développeurs peuvent améliorer le quotidien de leurs congénères en contribuant à Stack Overflow.
Comme pour l’apprentissage d’une langue, améliorer la DevX nécessite de travailler sur quatre plans : la compréhension orale et écrite ; l’expression orale et écrite.
La compréhension implique la prise en compte et l’assimilation de concepts, qu’ils soient exprimés à l’oral (lors d’un atelier ou d’un talk par exemple) ou à l’écrit (via une documentation technique par exemple).
L’expression implique la façon de communiquer d’un développeur ou de son équipe à la fois à l’oral (lors d’ateliers ou d’un talk / retour d’expérience par exemple) ou à l’écrit. (éviter le bus factor égal à 1 en fournissant une documentation de qualité par exemple.)
La rédaction technique est quelque chose qui ne s’improvise pas et qui peut même faire l’objet d’un poste à part entière dans certaines organisations. (pour rédiger de la documentation technique ou des articles de blog). Cette série d’articles (en anglais) dédiée à la rédaction technique permet d’en comprendre certains aspects.
Le poste de travail
L’amélioration du poste de travail ne concerne pas que les développeurs, mais il est important de prendre soin de la posture à travers un équipement adapté (parfois les entreprises participent partiellement ou totalement au financement de celui-ci). C’est aussi la prise en compte de techniques diverses pour améliorer son quotidien comme la méthode des 20-20-20 qui consiste à regarder 20 secondes à 20 mètres toutes les 20 minutes pour protéger ses yeux d’une myopie trop précoce. La méthode du pomodoro permet aussi de mieux cadencer sa journée de travail et de réaliser ses tâches plus efficacement tout en prenant des pauses régulières.
Pour finir, dans un contexte post COVID où le télétravail s’est démocratisé, il est important pour les organisations d’être flexible, de laisser au moins quelques jours,une certaine facilité et une certaine liberté pour faire du télétravail et gagner en qualité de vie (a priori).
Finalement, cet article pointe également certaines choses à respecter pour améliorer la DevX : avoir une architecture solide et évolutive, faire en sorte d’automatiser le maximum de choses, éviter la culture du blâme, etc.
Conclusion
Tous les éléments abordés dans cet article concernent tous les développeurs quel que soit leur niveau (junior, confirmé, senior), leur career path (contributeur individuel, leader ou engineering manager), leur statut (en entreprise ou freelance) et leur rôle ou appétence (full-stack, front-end, back-end / tech lead / architecte / CTO). Finalement, l’amélioration du quotidien des développeurs permet simplement de les rendre plus heureux ! Elle passe parfois par de nombreuses petites actions qui peuvent être mises en place dans les équipes par les développeurs eux-mêmes.
Des organisations comme WeLoveDevs travaillent beaucoup sur l’amélioration de la vie des développeurs. De plus en plus d’entreprises ont même une cellule dédiée à la DevX ces dernières années, signe que le sujet est important. Ceci dit, la route est encore longue. C’est important pour nous développeurs de tenter de porter de notre mieux les éléments listés plus haut (et sans doute d’autres manquants) !
—
Pour en savoir plus sur la DevX, on a sorti un Parlons Tech avec Microsoft, et il y a d’autre chose qui arrive bientôt 🔥
