Le SAV de la Tech

Cette semaine, le SAV de la Tech répond à la question de Rémi:"Salut salut salut ! Je suis tombé sur votre podcast et je m'y accroche comme à une bouée dans un tsunami de podcast vides générés par LLM 😅, alors merci !Petite question carrière : comment définiriez-vous les rôles de "staff" ou "principal" engineer ? J'ai l'impression d'en repérer de plus en plus dans la tech en France, mais la définition semble assez floue.Exemple: j'ai évolué de fil en aiguille comme un référent clean code, observabilité et architecture de systèmes dans une startup, en proposant notamment des librairies/package pour faciliter certaines bonnes pratiques, est-ce que ça fait de moi un bon candidat à un poste de staff dans une autre boîte ?La question me semble intéressante si ce chemin de carrière s'offre comme alternative à "monter en management", sans perdre en influence. Mais certains jours je me demande si ce n'est pas juste être senior++ 😅.Bonne semaine à vous deux !"Épisode enregistré en Mai 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 Kevin:"Bonjour,Je suis dev depuis presque 4 ans. Dès les premiers mois dans ma première entreprise, une agence web de 6 personnes, je me suis rendu compte des problèmes que posaient du code legacy. On utilisait un CMS maison, plein de code mort, mes 4-6 premiers mois ont été à 80% de debug la codebase. Dans l'entreprises suivants, même soucis, du code legacy très vieux, du gatekeeping, un rejet du changement, ou forcé par les managers qui expliquent comment coder. Dans mon entreprise actuelle j'ai plus de marge de manœuvre mais les tâches à faire réduisent les possibilités, création de back office avec seulement du CRUD, sans règle métier.J'ai vite compris que je recherchais plus que juste faire du code, qui marche plus ou moins, et après des recherches je suis tombé sur Benoît Gantaume avec son podcast artisan développeur et il y a eu un déclic.Je suis tombé dans le craft, appris le TDD, clean code, DDD, design pattern et d'autres outils par la lecture, les vidéos, podcast etc.Et pendant cet apprentissage j'ai aussi cherché un nouveau poste où la qualité logiciel était présente, ou à minima recherché.Mais les boîtes qui pratiquent ce genre de méthodologie sont inexistante dans ma région (Nice), ou très bien caché, et celles que je trouvais, même lors d'annonce pour des juniors, avaient des exigences très hautes, des expériences professionnel avec une mise en place de clean architecture, DDD etc.J'ai fait plusieurs entretiens, plusieurs tests techniques, avec des feedbacks positif, mais à chaque fois ça finissait par un refus par choix d'un candidat avec plus d'expérience, ou dans quelques rare cas, avec une proposition de salaire vraiment basse.Je fais des projets personnels où je met en place ces outils, je fais des katas, mais je ne suis toujours pas au niveau des attentes des entreprises.J'ai vécu un soucis similaire avec le monde startup, où ils demandent de l'expérience en startup, sans laisser de chance à ceux qui n'en ont pas encore.Je me doute que le climat actuel du recrutement n'est pas le plus propice pour les dév peu expérimenté.Après ce monologue, la question est, comment faire pour rejoindre une boîte comme Shodo, ou une autre qui pratique le craft, quand le contexte de l'entreprise ne permet pas de mettre en place ces pratiques, que l'on apprend de nous même ces pratiques ?Comment réussir à sortir du lot ?"Épisode enregistré en Mai 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'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

Cette semaine, dans le SAV de la Tech, on répond à la question de Pierre: "Hello, Je suis tech lead / manager d'une petite équipe (1 dev senior, 3 devs juniors + moi-même) qui travaille sur un projet qui fait appel à de nombreuses "nouvelles technologies". Les besoins du projet nous obligent souvent à nous pencher sur des sujets dont les solutions ne sont pas évidentes ni directes, et nécessitent souvent un travail de R&D pour rechercher la meilleure solution, et parfois même tout simplement pour vérifier la faisabilité ou non d'une fonctionnalité. Il arrive donc régulièrement qu'un travail de plusieurs jours soit stoppé car la piste explorée s'avère être une mauvaise piste et il faut alors réorienter les recherches. L'équipe a grossi très récemment, et est devenue très jeune, tous les juniors ont été recrutés en sortie d'école. J'ai justement énormément de mal à piloter ces juniors : j'ai remarqué qu'ils me vouent une confiance presqu'aveugle et ont tendance à assez peu remettre en question les choix techniques ou à appliquer les suggestions proposées lors des revues de code sans réfléchir à leur pertinence. Ils ont également du mal à accepter que je n’ai moi-même pas la solution en tête et que leur boulot est justement d’explorer pour la trouver. De plus, au moindre échec (tentative d'utilisation d'une technologie qui ne répond finalement pas au besoin, difficultés à trouver une solution technique, etc.), la démotivation se fait rapidement sentir et l'effort pour remotiver l'équipe est considérable. Cela pose pas mal de problèmes car à cause de cela, ils ont du mal à aller expérimenter et chercher des solutions d'eux-même. Les daily meetings aident un peu dans le sens où ils peuvent rapidement exposer leurs points de blocage, mais j’ai remarqué que cela avait introduit un effet secondaire : plutôt que de passer un peu plus de temps à rechercher une solution, ils peuvent attendre le daily meeting suivant pour appeler à l’aide, et cela finit par induire énormément de temps d'accompagnement pour mon senior et moi, qui sommes impactés sur nos propres tâches, et cela peut entraîner des retards de shipping. Pourtant, j'essaye de leur enseigner au maximum l'autonomie, et je m'assure que les objectifs sont clairs pour tout le monde et que les tâches sont les moins ambigües possibles. Ma question est donc la suivante : comment puis-je aider au maximum la prise d'autonomie de mes développeurs juniors, qu'ils montent en compétence et surtout qu'ils gardent la motivation même après des « échecs », qui sont inhérents à notre projet ?" É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 Robert, a.k.a. Dark Nounours: "Comment faire comprendre aux gens que les architectes ne sont pas là pour nous dire comment coder ? J’ai l’impression que c’est flou le métier d’architecte. Perso j’aime bien la comparaison avec l’architecte d’urbanisation. Il est là pour que ta maison s’insère correctement dans le paysage pas pour te dire comment décorer ton intérieur. Mais je me trompe peut être? Sinon bravo pour votre podcast il est fun (et intéressant)" Épisode enregistré en Septembre 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 Robert, a.k.a. Dark Nounours: "À chaque introduction de nouveauté (concept, nouvelle feature d’une techno) comment éviter d’être constamment face à une réticence au changement ? Je trouve ça incroyable de se contenter de ses acquis surtout dans notre métier. Je trouve ça surtout usant pour moi qui aime partager." Épisode enregistré en Septembre 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 Kelly: "Nous rencontrons des problèmes dans ma boite. Le customer service est objectivé en nombre de tickets à résoudre (entre autres). Le problème est le suivant : nous ne contrôlons pas le nombre de tickets entrants et quand il n'y a pas de bugs, il n'y a pas vraiment beaucoup de tickets. Si le nombre de ticket à faire n'est pas fait, l'agent du customer service ne bénéficie pas de son salaire variable (10% du salaire fixe). Cela crée de grosses frustrations et après plusieurs discussions avec la direction, le CSE, les syndicats, le CS ne réussit pas à modifier ces objectifs. Cela crée : des personnes qui se connectent régulièrement à 5h du matin pour pouvoir faire les tickets tombés dans le backlog le soir. Le reste de l'équipe qui se connecte pendant les business hours n'a pas de quoi faire son objectif. Résultat : burn outs, arrêts maladie, compétition malsaine, et tout ce qui s'en suit. Deux questions, comment faire pour ouvrir la communication et obtenir gain de cause ? et, quelles missions donner à des membres du CS de façon à changer les KPIs de manière intelligente ? Merci :)" Épisode enregistré en Juillet 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 Sachi: "Je bosse pour une ESN depuis un an et j'ai passé une grosse partie de mon temps en Inter-contrat. Je me suis naturellement dis que ce serait intéressant de Monter / Contribuer à des projets Open Source. Mais quand j'en ai parler avec mes collègues, ils étaient moyen chaud à l'idée et les plus anciens de la boite disant que le directeur n'est pas super fan vis à vis du fait de "travailler pour les autres" sachant que l'on utilise des technos open source dans nos projets. Mais du coup je sais pas vraiment quoi faire. Je suis sur 7 mois d'inter contrant et à part occasionnellement améliorer le socle, je fais pas grand chose." Épisode enregistré en Juillet 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 Tanguy: "Mon équipe travaille à 80% en remote et un de mes collègues, le tech lead mais qui est très jeune (et qui ne lead pas beaucoup, peut être lié), a pris la fâcheuse habitude lors de nombreuses visio meet, d'avoir la cam et le son coupé. Quand il ne s'agit pas d'un sujet à lui, il n'intervient pas du tout (même pas un mot) et quand on lui demande son avis, il répond toujours mais il faut souvent répéter la question ou redonner le context => On a clairement l'impression qu'il fait autre chose en même temps. Récemment il est même arrivé qu'il décroche en plein mob programming (en physique) et qu'il se mette à traiter un autre sujet dans son coin. Quand le team manager le remarque, il se justifie qu'il a été sollicité par mail pour un bug à résoudre... et c'est comme si c'était normal. Même en faisant du pair-programming avec lui, je me suis parfois retrouvé à coder seul et sentir qu'il a décroché de son côté et qu'il traite d'autres sujets. Je trouve ça de plus en plus désagréable en plus de trouver ça personnellement impoli. Je ne me sens pas du tout de lui reprocher directement, ni d'escalader auprès du team manager. Il y a une bonne ambiance dans l'équipe et je ne voudrai pas casser ça. Est-ce que je me prends la tête pour rien ? Est-ce que c'est normal de se dire qu'il a d'autres sujets à traiter et puis j'avance dans mon coin ?" Épisode enregistré en Mai 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 Robert: "Je suis manager d'une équipe où je manage plusieurs devs. L'un d'entre eux me pose des problèmes de productivité. Il fait du code très propre, mais il est trop perfectionniste et à beaucoup de mal à délivrer. Il s’intéresse énormément aux problématiques d'architectures logiciels, au clean code et à toutes les bonnes pratiques, ce qui en soit est très bien. Mais j'ai l'impression qu'allier ceci à son perfectionnisme l'empêche de mener à bien les tâches qui lui sont attribuées. Il passe énormément de temps à préparer ses développements avant de les débuter, à chercher la meilleure façon de le faire, et durant le dev il revient régulièrement sur ce qui a été fait pour tenter de l'améliorer. Régulièrement il fini par produire des mini usines à gaz pour des choses très simples après un temps de dev qui dépasse très largement les estimations les plus pessimistes. Cela pose également des problèmes quand d'autres membres de l'équipe collaborent avec lui sur un projet. Il m'est même arrivé de faire une choses que je déteste: reprendre from scratch certaines tâches pour sauver les meubles et qu'elles soient terminées pas trop hors délais. Ce qui fait que je sais que les délais en question étaient largement tenables ^^ Ma question est donc: comment réussir à transformer un développeur trop académique en développeur plus orienté vers les besoins d'une entreprise ? Pour l'instant mes tentatives y ont échoué." Épisode enregistré en Mai 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 Stéphane: "Je suis manager et je n'arrive pas à parler du tabou de la performance avec mes équipes de devs. Comment aborder le sujet ? Est-ce que c'est utile de mesurer la perf d'un dev/équipe ? Comment mesurer ?" Épisode enregistré en Mai 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 Dan: "Comment amener plus de diversité culturelle dans les équipes lors des recrutements ?" Épisode enregistré en Mars 2024. Crédits musique: "Guess Again", provided by https://slip.stream

Cette semaine, dans le SAV de la Tech, on répond à la question d'Elodie: "Dans une petite entreprise, l'habitude a été prise de manger en regardant la télé/JT et en discutant. Des nouveaux arrivants trouvent que ça fait mauvaise ambiance, et qu'il n'y a pas de cohésion d'équipes. Et en effet, les gens mangent devant la télé en se parlant à peine, ce qui n'était pas le cas avant. Devrait-on se débarrasser de la télé pour "forcer" les gens à se parler ? Comment améliorer cette ambiance/cette cohésion d'équipe ?" Épisode enregistré en Mars 2024. Crédits musique: "Guess Again", provided by https://slip.stream