Le SAV de la Tech

Jérémie Girault × Adrien Joly

En s'appuyant sur leur expérience et une bonne couche d'autodérision, Jérémie et Adrien répondent aux questions non techniques mais compliquées des gens de la tech: dévs, tech leads et managers. Au programme: conflits entre collègues, soft skills pour les désamorcer, négociations salariales, développement de carrière... Nous répondons à VOS questions, alors: à vos claviers !

  1. 36. Comment rejoindre une entreprise "craft" ?

    JUN 12

    36. Comment rejoindre une entreprise "craft" ?

    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

    21 min
  2. 33. Le management me demande d'arrêter les 1-1 🤭

    MAR 27

    33. Le management me demande d'arrêter les 1-1 🤭

    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

    18 min
  3. 30. Faut-il respecter les guidelines qu'on nous impose ? ✊

    12/19/2024

    30. Faut-il respecter les guidelines qu'on nous impose ? ✊

    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

    18 min

About

En s'appuyant sur leur expérience et une bonne couche d'autodérision, Jérémie et Adrien répondent aux questions non techniques mais compliquées des gens de la tech: dévs, tech leads et managers. Au programme: conflits entre collègues, soft skills pour les désamorcer, négociations salariales, développement de carrière... Nous répondons à VOS questions, alors: à vos claviers !