Cette semaine, le SAV de la Tech répond à la question d'Arno Nimousse:

"Dans notre équipe, nous avons des personnes (en plus des tech lead) pour amener un maximum de bonnes pratiques orientées (Pair programming, TDD, DDD etc). Ca fonctionne plutôt bien mais régulièrement nous voyons reculer certaines pratiques que l'on pensait acquises et intégrées dans le quotidien des devs.

Typiquement, tous les 3-4 mois, il faut rappeler que les démarrages de chantiers (fonctionnels ou techniques) ne doivent jamais se faire seuls, mais au moins en Pair programming (voire en mob/ensemble quand c'est possible). Il faut aussi souvent rappeler la nécessité d'un code bien testé (et testable).

Cette répétition est-elle vraiment une fatalité ? Est-ce que l'équipe ne le fait que pour faire plaisir puis oublie rapidement les bienfaits de ces approches ?

On a parfois l'impression de n'être là que pour redire ce qu'on a déjà dit plusieurs fois en ayant l'impression d'être devenus les pénibles de service…"

Épisode enregistré en Mars 2025.

Mastering audio automatisé par auphonic.com.

Crédits musique: "Guess Again", provided by https://slip.stream

Cette semaine, le SAV de la Tech répond à la question d'Alexandre:

"Salut le SAV et merci pour l’émission, c’est sympa de vous entendre.

Avez-vous des conseils sur comment se faire des amis en conférence tech ?

J’aime bien aller à ce genre d’événement. J’adore voir d’autres devs. Les 3 fois, j’y suis allé seul , mais j’ai du mal à aller vers les gens. Je repars souvent en étant déçu de ne pas avoir échangé avec plus de personnes.

Avez-vous des tactiques, des stratégies, des éléments d’état d’esprit pour vous faire des amis en conférence ?"

Épisode enregistré en Mars 2025.

Mastering audio automatisé par auphonic.com.

Crédits musique: "Guess Again", provided by https://slip.stream

Cette semaine, le SAV de la Tech répond à la question de Fabien:

"Hello le SAV,

De nouveau ; merci pour ce podcast. C'est très intéressant d'entendre vos réflexions sur les questions qu'on se pose, et ce serait dommage de ne pas en profiter.

Dans mon contexte, je suis positionné en transverse sur plusieurs équipes pour les aider et les accompagner à progresser sur leurs problématiques techniques. Dans ce cadre j'organise des conversations en tête-à-tête (parfois appelées one-to-one ou bilatérale) avec les différentes personnes des l'équipes.

Le contexte a changé, et le management m'a positionné en tant que lead des équipes, plutôt que soutien, et a demandé que j'arrête les conversation avec les personnes. Ces conversations ne faisaient pas partir du périmètre du rôle que j'endossais, et un nouveau manager était attendu pour prendre le suivi des personnes, par des one-to-one réguliers.Les personnes concernées et moi, avons trouvé cela dommage : ces conversations permettaient de déloquer des situations humaine et techniques, notamment sur des code review, et on percevais une montée de compétence de chacun/chacune.

Ma question :Quelle est le rôle du Lead Dev dans le management ? Doit il ou ne doit il pas avoir des conversations dédiées avec les membres de son équipe ?

Merci d'avance pour le temps que vous allez prendre à me lire et (peut-être) à me répondre."

Épisode enregistré en Mars 2025.

Crédits musique: "Guess Again", provided by https://slip.stream

Cette semaine, le SAV de la Tech répond à la question d'Arthur:

"J'ai 2 collègues, Scrum master et PO, qui ne sont pas a la hauteur. Il y en a 1 qui n'est pas impliqué et l'autre qui est junior et pas très perspicace. L'organisation de l'entreprise ne les challenge pas. Ça créer des tensions et ça me fait ruminer chez moi. Je leur ai déjà dit les choses ouvertement lors des rétrospectives sans résultats. Comment gérer cette situation de personnes incompétents qui ne sont pas challengés par la hiérarchie?"

Épisode enregistré en Janvier 2025.

Crédits musique: "Guess Again", provided by https://slip.stream

Cette semaine, le SAV de la Tech répond à la question que se posent secrètement les devs, designers, QA et managers:

"Est-ce que ChatGPT va me voler mon job ?"

... avec un invité spécial !

Épisode enregistré en Décembre 2024.

Crédits musique: "Guess Again", provided by https://slip.stream

Cette semaine, le SAV de la Tech répond à la question de Fabien:

"Hello le Sav,

Tout d'abord, merci de produire ce podcast ; il est très chouette tant sur le fond que la forme.

Dans des épisodes précédents, vous avez parlé à plusieurs reprises de "guidelines de code" et des "bonnes pratiques". D'où proviennent ces guidelines que vous mentionnez, et comment vous en servez vous ?

Pourquoi cette question : Dans mon contexte, nous avons mis en place une solution pour expliciter nos pratiques et en discuter. Je cherche à confronter cette solution à d'autres pour l'affiner et la faire évoluer.

Mon contexte ; en tant que consultant externe, j'endosse un rôle de lead sur plusieurs équipes. Ces équipes doivent respecter des guidelines provenant de différences sources:

• Des normes technologies (langages, outils, frameworks) venant d'une équipe d'architectes
• Des "bonnes" pratiques (structure des projets java, indentation, convention de nommage, workflow git) venant d'un responsable des développeurs (à la fois manager et responsable du parc applicatif).
• Des nommages d'objets métiers, venant d'un catalogue de donnée, qui homogénéise du lexique au travers de la DSI
• Les "bonnes" pratiques issues des équipes elles-mêmes

À titre personnel, je ne suis pas en accord avec certaines de ces pratiques (les bonnes pratiques n'existent pas (sans contexte)), car je trouve qu'elles empêchent les équipes d'apprendre et de progresser.

La solution mise en place : discuter en équipe et tracer nos décisions. Lors d'une instance de partage régulière entre développeur·euses, chaque personne met sur la table les difficultés rencontrées lors de la production du code ou les désaccords exprimés lors des Code-Reviews. Nous prenons le temps de formaliser la pratique, avec son contexte et ce que nous voulons faire (à la manière d'un ADR), avant de voter par consensus sur l'exigence collective de celle-ci (un peu à la manière de cataloguer des technologies avec un Tech Radar).

Pour le moment, cela fonctionne bien. On a un artefact qui nous permet d'onboarder explicitement les nouvelles personnes ; il sert de source unique de guidelines pour notre contexte d'équipes. Cet artefact nous permet de "désobéir" à certaines guidelines imposées (ex: structure des package java, indentation du code), car nous avons argumenté, dans notre contexte, les raisons de notre désobéissance ; cela permet d'entamer une discussion pour (éventuellement) revoir les guildelines globales à la DSI, mais aussi cela permet d'ouvrir une expérimentation.

Voilà :)

Je suis preneur de vos lumières pour affiner cette solution."

Épisode enregistré en Décembre 2024.

Crédits musique: "Guess Again", provided by https://slip.stream

Cette semaine, dans le SAV de la Tech, on répond à la question de Louis:

"On a un sujet qui pop en rétrospective sur l'équilibre entre temps de dev et review qui fonctionne pas très bien chez nous. L'équipe est relativement jeune, composée de 5-6 devs et 1 super PO arrivé il y a peu. Concrètement les tickets restent ouverts trop longtemps et trop de tickets ouverts en parallèle… Avez-vous des pistes à proposer pour nous aider à trouver le bon équilibre ?"

Épisode enregistré en Octobre 2024.

Crédits musique: "Guess Again", provided by https://slip.stream

Cette semaine, dans le SAV de la Tech, on répond à la question de Joseph:

"Je dois faire un dossier à chaque fois pour obtenir la promotion d’un membre de mon équipe. Ce dossier est soumis à un comité qui va déterminer quels sont les personnes qui vont être promues ou non.

Un membre de mon équipe opère déjà au niveau supérieur mais s’est vu refuser une promotion car les éléments du dossier ne sont pas assez “démonstratifs” de sa valeur. En particulier c’est un solide contributeur individuel mais le comité s’attend à ce qu’un développeur aie un impact “multiplicateur” (oui le 10x engineer…) sur les autres membres de l’équipe, et même d’autres équipes.

D’une part c’est assez compliqué de trouver un projet sur lequel illustrer ces compétences du fait du scope de notre équipe mais aussi la personne a du mal à tracker son travail (résout des taches sans passer par jira, skip la phase de doc, etc) ce qui rend la tâche de “démontrer” sa valeur complexe.

Par ailleurs j’ai vu des gens briller dans la manière de démontrer leur impact malgré des contributions particulièrement limitées. J’en viens à penser que “démontrer” sa valeur est une compétence - et radicalement differente que celle de générer de la valeur - mais pourtant essentielle pour la progression de carrière.

Que me recommandez-vous pour 1- identifier les sujets sur lesquels se mettre en avant, et 2- comment présenter ses achievements sans avoir l’air de “brag de l’air” (comme j’ai pu aussi le voir par ailleurs)."

Épisode enregistré en Octobre 2024.

Crédits musique: "Guess Again", provided by https://slip.stream