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

"Bonjour Adrien, Bonjour Jérémie,

J'ai un question "onboarding" à vous soumettre.

Je viens de connaître une très mauvaise expérience à ce niveau qui m'a amenée à rompre ma période d'essai et malheureusement à quitter la boîte.Dès le départ les flags étaient au red :Personne pour nous accueillir le premier matin du premier jour, on a dû attendre une heure à l'accueil que les responsables arrivent 😶.Je me suis retrouvée seule toute la première semaine car la personne chargée de m'accueillir était soit malade soit en télétravail et personne ne l'a remplacée.Peu de senior disponibles pour l'encadrement et pas très à l'aise avec l'idée.Plusieurs personnes intégrées en même temps (3 juniors et 1 stagiaire) dans une équipe accueillant déjà 3 alternants, qui ont fait l'essentiel de l'accueil des nouveaux comme ils pouvaient.1 manager très désordonné, donnant l'impression de ne pas savoir quoi faire de moi et qui a essayé de m'introduire très maladroitement sur le code du projet avec des cours particuliers d'architecture très généraux sans lien avec mes tâches du moment. Un 1-1 a été mis en place au bout de 3 semaines mais arrêté dès que j'ai pu dire que c'était très aidant 😶.Et pour couronner le tout un changement radical sur la mission principale dont j'aurais dû m'occuper. Je devais migrer des composants d'angular.js vers vue3 et finalement en arrivant on m'a dit qu'on était pas prêts à m'accueillir, pas prêt à partir sur ce projet (qui en fait se discute depuis 2 ans 😱) et qu'en attendant on allait me faire faire du design system.Moi qui m'était assurée que c'était un poste où je pourrais rapidement évoluer du front au fullstack je me retrouvais à ne faire que de l'intégration.Si on ajoute à cela un management très à l'ancienne empreint de paternalisme et de surveillance....je ne m'y suis pas retrouvée du tout.

Du coup j'aimerais savoir quoi attendre d'un bon onboarding, dans l'équipe mais aussi sur le projet lui-même ? Comment c'est censé s'organiser dans l'idéal ? Et comment se positionner soi-même pour que ça se passe au mieux, voire rectifier le tir si ça part en cacahuète ?"

Épisode enregistré pendant l'été 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 Philippe:

"comment convaincre mes devs à compléter la documentation de notre produit au fur et à mesure des évolutions ? Non seulement c’est important pour les utilisateurs du produit, pour le support mais aussi pour que les devs trouvent rapidement des réponses aux questions qu’ils se posent pendant leurs taches.

Par exemple, un dev à bloqué une semaine sur sa tache parce que le collègue qui était expert sur une partie du produit était en vacances. Si son expertise avait été documentée, on aurait pu économiser cette semaine.

Parfois même, les développeurs se contentent de laisser un commentaire sur une page de documentation, pour proposer d’effectuer un ajout ou une modification, au lieu de faire la-dite modification directement !

Certes la documentation est centralisée dans un outil dédié dont l’ergonomie n’est pas top, mais il reste possible de faire un copier-coller depuis Word par exemple.

Bref, je suis preneur de vos conseils si vous en avez !"

Épisode enregistré pendant l'été 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 Gilbert:

"J'ai 13 ans de carrière, j'ai suivi beaucoup d'entreprises, parfois malheureuses. J'ai beau avoir managé plusieurs équipes et toujours avoir eu de bons retours de ma direction et de mes équipes, je n'arrive pas à me vendre maintenant que je suis à nouveau sur le marché de l'emploi. Ma carrière ne m'a pas incité à suivre la dernière mode, même si je sais que je peux prendre en main n'importe quel outil, mon CV détonne. Comment aborder les recruteurs en commençant à être un dinosaure alors que le web change tous les 4 jours ?"

Épisode enregistré pendant l'été 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 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