Ce que j'aime sur ses vidéos, c'est qu'il ne reste pas abstrait. Il explique des concepts qu'on ne voit pas en formation, et il confirme de par son expérience certaine choses qu'on fait sans forcément savoir si c'est la bonne façon de faire ou pas. Très instructif
Wow, excellent et merci! Je suis un tech lead aussi et je trouve que les principes donnés sont vraiment bons! Je crois qu'il en manque un. En tant que tech lead, il est primordiale de ne pas être un dictateur dans les décisions techniques. Lorsqu'il s'agit de prendre une décision sur un design par exemple, il est très important de donner la chance aux autres d'exprimer leurs arguments pour faire avancer la discussion et de finalement prendre la meilleure solution en fonctions des échanges. À la fin s'il n'y a pas de consensus et bien là le tech lead peut trancher.
Je plussoi ce commentaire, meme laisser la place a l'experimentation peut etre benefique. Eviter le compromis au maximum, la personne qui est en charge d'implementer une solution doit implementer sa solution et non un compromis ou la solution de quelqu'un d'autre. Le compromis sont energivore, et peuvent amener a des pertes de temps et de qualite du code.
Merci Simon ! Je ne suis pas encore tech lead, mais tes remarques sont pertinentes, au regard de situations que j'ai vécues ou dont j'ai été témoin depuis que je suis développeur.
Dans ma dernière expérience, lorsque je suis arrivé (en tant que dév), l'équipe (dont le tech lead) était restée sur une version obsolète de Visual Studio car depuis quelques temps, VS met grandement en avant les librairies externes déclarées vulnérables d'un point de vue sécurité. Personne ne souhaitait se taper lourde tâche (on parle d'une solution de + de 330 projets...) de mettre à jour les librairies sachant qu'il y avait pas mal de choses effectuées par scripts lors du build (dont des copies de ces librairies). J'ai donc fait ça quasiment en première tâche de mon dernier job (je n'ai pas fini la période d'essai, quand ça commence comme ça, faut pas s'attendre à ce que le reste soit meilleur, alors qu'on parle pourtant d'une solution logicielle installée chez de grands noms...). Pour le coup, le tech lead était bien au bord du terrain, il ne développait que très peu durant les sprints et surtout, ne faisait JAMAIS de relecture de code, je te laisse imaginer le carnage quand tu as 330+ projets dans ta solution... :) Bref, merci pour ton retour d'expérience, tu es de toute évidence le genre de tech lead que j'aimerai avoir. ;)
Hello, étant un grand fan de la CODE REVIEW, je ne peux que t'être favorable. Ce moment est clef dans la livraison d'une codebase qui veut rester saine. Bon code pour la suite et merci pour le compliment ! Simon.
Tiens j'ai démarré en sortie d'école sur les mêmes technos mais avec une expérience différente. Le tech lead avait toujours la main dans le code et avait développé un mapping relationnel comme le fait Entity Framework; plusieurs années avant que l'éditeur ne le sorte. Le problème c'est que c'était devenu un peu son bébé, il est resté le sachant et est devenu indispensable pour le projet en cas de problèmes. Il faut trouver le juste milieu, essayer d'avancer en équipe, surtout sur les gros projets (on était 20 développeurs sur 1 seule grosse application). Du coup si le mapping ne passe pas ou plante, il y a un single point of failure en cas d’absence du tech lead, personne d'autre n'osant toucher cette partie critique de peur de casser la compilation.
@@feckingud Merci pour ce partage d'expérience. Cela nous permet de constater le résultat des deux extrêmes : ne code pas, code un "truc que personne d'autre n'est capable de toucher". 👍
Ce que j'ai lis en place et qui n'a pas d'égal : prendre autant les feedbacks qu'on les donne. Seuls ceux qui affrontent les pain points qu'ils créent et prennent les axes d'amélioration de leurs équipes sauront évoluer tant sur le plan pro que perso. Peu osent... BTW super point que celui de sandre remplaçable pour pouvoir évoluer, ça fait toute la différence 👍
@@codeursenior oui depuis hier, j'ai remplacé mon Lead qui est parti pour un gros contrat. La vidéo restera mon guide durant cette période, avant que je de développe d'autres aptitudes, Merci infiniment
De ce que j’ai en tête : lead dev est un rôle que vous prenez dans l’équipe, tech lead est un poste, ou vous êtes responsable de la viabilité technique de ce que produit l’équipe dans laquelle vous opérez. Mais sûrement que quelqu’un d’autre aura une définition plus précise/complete. Bon code !
Hello, pour le moment je me concentre à donner suffisamment de valeur en vidéo pour mériter 100.000 abonnées. Ensuite attaquer quelques interviews 👍 est ce c’est clair pour vous ?
Cela va dépendre aussi du contexte et donc de la boîte en elle-même. Personnellement, en tant que tech lead, on me demande de me détacher du code et d'être plus du côté client. Un tech lead ca ne veut rien dire au final et je m'en rends compte de plus en plus. Chaque structure a sa définition de tech lead, et même encore pire, en interne dans la même équipe, chacun a sa propre image du tech lead. De mon côté, je suis plus dans l'erreur 3 mais à mon sens, elle n'est pas de mon fait... Pour l'erreur n°4, encore une fois cela dépend du contexte, quand on est tous à la bourre, je préfère donner la réponse et malheureusement on n'a pas trop le choix... Pour la 6, c'est la même histoire, c'est l'attente des managers qui est tellement énorme ... Sinon je suis totalement d'accord de façon générale, ce serait l'idéal et presque le job de rêve... mais on n'a pas la main sur tous les paramètres
Bonjour, merci pour votre retour d'expérience et votre avis sur les propositions de la vidéo. Effectivement, il existe plusieurs variantes du rôle de Tech Lead selon la structure, parfois ce n'est pas très clair...
La différence entre un "Tech Lead" et un "Lead Developer" (Lead Dev) peut varier selon les organisations, mais généralement, ces rôles diffèrent en termes de responsabilités et d'orientation. Voici une explication basée sur les principes généraux de leadership technique et de développement de logiciels : Tech Lead Orientation Stratégique : Le Tech Lead se concentre davantage sur la vision technique à long terme du projet ou de l'équipe. Il s'assure que les décisions techniques s'alignent avec les objectifs globaux de l'entreprise ou du projet. Prise de décisions techniques : Responsable de la prise de décisions architecturales et technologiques majeures. Le Tech Lead travaille souvent en étroite collaboration avec l'architecte logiciel (si ce rôle existe dans l'organisation) pour définir l'architecture du système. Mentorat : Joue un rôle clé dans le mentorat des membres de l'équipe sur les meilleures pratiques de développement, les principes de conception et les standards de code. Interface : Agit souvent comme point de contact entre l'équipe de développement et les autres parties prenantes, comme le management, les équipes de produits, ou les clients. Lead Developer Orientation sur l'Implémentation : Bien que le Lead Dev puisse aussi participer à la définition de la stratégie technique, son rôle est plus axé sur la gestion quotidienne de l'équipe de développement et l'implémentation des décisions techniques. Codage Actif : Le Lead Dev est généralement plus impliqué dans le codage et la révision du code, veillant à ce que les pratiques de développement soient suivies et que la qualité du code soit maintenue. Gestion de l'équipe : Peut être chargé de tâches administratives liées à la gestion de l'équipe, comme la planification des sprints, la répartition des tâches, et le suivi de la progression. Support Technique : Fournit un soutien technique et des conseils aux développeurs de l'équipe, résolvant les problèmes techniques et assurant la cohésion de l'approche de développement. Conclusion Le Tech Lead se concentre davantage sur la vision technique et la stratégie, agissant comme un pont entre les aspects techniques et les objectifs commerciaux ou de projet, tandis que le Lead Developer se concentre plus sur la gestion quotidienne de l'équipe de développement, l'implémentation technique, et le maintien des standards de qualité du code. Dans la pratique, ces rôles peuvent se chevaucher et varier selon l'organisation.
Ce qui est plus rigolo c’est que tout est dans la même liste ! Sauf que personne ne veut faire les grungy tasks et les autres se ruent sur les tâches sympas !
J’ai vu trop de tech lead donner des ordres sans jamais toucher une seul ligne de code et sans jamais devoir rendre des comptes à propos de leur travail mais bien à cheval pour presser les développeurs comme des citrons. Sans parler de ceux qui cherchent à minimiser le coût des tâches pour être toujours bien vu. Pire certains finissent par faire bande appart avec les POs etc… tt en reléguant les développeurs en de simples exécutants. Solution qui marche finir avec les tech leads et laisser les développeurs élire leur propre lead dev.
Totalement d’accord avec tout ce que tu dis. Je suis passer de développeur à Tech lead en interne et je m’entends très bien avec les devs de mon équipe. Si tu es de ce côté attend toi à avoir les PO et compagnie sur le dos, c’est insupportable car eux leur seule vision c’est les points , les points tout en mettant le minimum possible. Vision court terme toujours et encore. Et il y’a ceux comme tu dis qui ne veulent plus toucher une ligne de code etc…Je ne vois pas comment tu peux maintenir ton niveau sans pratiquer régulièrement. Pour moi Tech Lead s’est terminé, retour au dev, dans le nom du poste s’est si proche du dev mais dans la réalité ça a rien à voir. Je préfère aider mes collègues que être au milieu de tout pour un titre.
@@Macintoshdfr très intéressant car j ai aussi eu de très bons techleads qui comme ils osaient mouiller le maillot car passionnés, ils étaient détestés des POs. Des POs dont beaucoup sont en faites des chefs de projet véreux reconverti de manière éclair ⚡️ cherchant à avoir la main mise sur le développement 😂
Merci Simon, très bonne liste de principes. Tu m'as permis de connaitre "Software Engineering at Google: Lessons Learned from Programming over Time" que je vais lire sans faute ! :)
Ce que j'aime sur ses vidéos, c'est qu'il ne reste pas abstrait. Il explique des concepts qu'on ne voit pas en formation, et il confirme de par son expérience certaine choses qu'on fait sans forcément savoir si c'est la bonne façon de faire ou pas.
Très instructif
Merci, c'est top de pouvoir compléter ce que vous voyez en formation.
Wow, excellent et merci! Je suis un tech lead aussi et je trouve que les principes donnés sont vraiment bons! Je crois qu'il en manque un. En tant que tech lead, il est primordiale de ne pas être un dictateur dans les décisions techniques. Lorsqu'il s'agit de prendre une décision sur un design par exemple, il est très important de donner la chance aux autres d'exprimer leurs arguments pour faire avancer la discussion et de finalement prendre la meilleure solution en fonctions des échanges. À la fin s'il n'y a pas de consensus et bien là le tech lead peut trancher.
Merci pour votre retour éclairé sur le sujet, je vous épingle sous la vidéo. 👍
Je plussoi ce commentaire, meme laisser la place a l'experimentation peut etre benefique. Eviter le compromis au maximum, la personne qui est en charge d'implementer une solution doit implementer sa solution et non un compromis ou la solution de quelqu'un d'autre. Le compromis sont energivore, et peuvent amener a des pertes de temps et de qualite du code.
Merci Simon !
Je ne suis pas encore tech lead, mais tes remarques sont pertinentes, au regard de situations que j'ai vécues ou dont j'ai été témoin depuis que je suis développeur.
Au top, merci pour le retour !
Bon code à toi,
Simon.
remplacer tech lead par = chef d''équipe ou petit patron dans tout domaine ^^ (merci pour ces infos, ça m'aide beaucoup)
Sa fait maintenant 2 ans que je suis tes vidéos et tout est positif chez moi ! merci Simon
Haha tant mieux, ce n'est pas un hasard ! 💪
"le seul critère que vous avez compris, c'est qu'il fallait livrer vite" vécu
Vécu et regretté !
Et donc produire de la dette technique
@@charlyr6774 Il va falloir rattraper la dette en codant plus vite mon ami !
Une vidéo simple avec de vrais conseils. Thx pour le partage
Au top, bon code à toi pour la suite.
Simon.
Merci de partager ton expérience 👍
Avec plaisir !
Bon code, Simon.
merci pour cette vidéo très instructive😀 je me suis malheureusement reconnu dans qqs uns de tes points 😢 vite tenter d'améliorer ça...
Ah ! Lesquels ?
C’est peu être superficiel pour certains, mais la nouvelle qualité vidéo est géniale. Toujours aussi pertinent Simon 👌🏾
Hello, merci pour le retour. Vous êtes plusieurs à apprécier le nouveau montage. J’ai prévenu le monteur que son travail est apprécié !
Team "done done" 👊
#DoneDoneNation
Merci beaucoup pour ces vidéos
Merci pour votre message, j'espère pouvoir vous en proposer d'autres prochainement.
Bon code,
Simon.
Merci pour cette vidéo !
Toujours avec plaisir.
Bon code, Simon.
Merci pour vos conseils Simon : )
Merci à vous pour votre message, bon code !
Simon.
trés interessant ! merci
Avec plaisir, bon code !
Dans ma dernière expérience, lorsque je suis arrivé (en tant que dév), l'équipe (dont le tech lead) était restée sur une version obsolète de Visual Studio car depuis quelques temps, VS met grandement en avant les librairies externes déclarées vulnérables d'un point de vue sécurité.
Personne ne souhaitait se taper lourde tâche (on parle d'une solution de + de 330 projets...) de mettre à jour les librairies sachant qu'il y avait pas mal de choses effectuées par scripts lors du build (dont des copies de ces librairies).
J'ai donc fait ça quasiment en première tâche de mon dernier job (je n'ai pas fini la période d'essai, quand ça commence comme ça, faut pas s'attendre à ce que le reste soit meilleur, alors qu'on parle pourtant d'une solution logicielle installée chez de grands noms...). Pour le coup, le tech lead était bien au bord du terrain, il ne développait que très peu durant les sprints et surtout, ne faisait JAMAIS de relecture de code, je te laisse imaginer le carnage quand tu as 330+ projets dans ta solution... :)
Bref, merci pour ton retour d'expérience, tu es de toute évidence le genre de tech lead que j'aimerai avoir. ;)
Hello, étant un grand fan de la CODE REVIEW, je ne peux que t'être favorable. Ce moment est clef dans la livraison d'une codebase qui veut rester saine.
Bon code pour la suite et merci pour le compliment !
Simon.
Tiens j'ai démarré en sortie d'école sur les mêmes technos mais avec une expérience différente. Le tech lead avait toujours la main dans le code et avait développé un mapping relationnel comme le fait Entity Framework; plusieurs années avant que l'éditeur ne le sorte. Le problème c'est que c'était devenu un peu son bébé, il est resté le sachant et est devenu indispensable pour le projet en cas de problèmes.
Il faut trouver le juste milieu, essayer d'avancer en équipe, surtout sur les gros projets (on était 20 développeurs sur 1 seule grosse application). Du coup si le mapping ne passe pas ou plante, il y a un single point of failure en cas d’absence du tech lead, personne d'autre n'osant toucher cette partie critique de peur de casser la compilation.
@@feckingud Merci pour ce partage d'expérience. Cela nous permet de constater le résultat des deux extrêmes : ne code pas, code un "truc que personne d'autre n'est capable de toucher". 👍
Ce que j'ai lis en place et qui n'a pas d'égal : prendre autant les feedbacks qu'on les donne. Seuls ceux qui affrontent les pain points qu'ils créent et prennent les axes d'amélioration de leurs équipes sauront évoluer tant sur le plan pro que perso. Peu osent...
BTW super point que celui de sandre remplaçable pour pouvoir évoluer, ça fait toute la différence 👍
Ah oui effectivement. On crée parfois des "pain points" sans s'en rendre compte, en croyant bien faire pourtant. Le feedback est salvateur !
Ça tombe bien pck demain je serais un Tech Lead, merci d'avance
Sérieusement, vous démarrez demain en tant que Tech Lead ? J’espère que ces conseils pourront vous servir !
@@codeursenior oui depuis hier, j'ai remplacé mon Lead qui est parti pour un gros contrat. La vidéo restera mon guide durant cette période, avant que je de développe d'autres aptitudes, Merci infiniment
@@olivierrukabo7921 Au top, tous mes vœux de réussite dans cette honorable mission.
Salut. Cest quoi la différence entre tech lead et lead dev ?
De ce que j’ai en tête : lead dev est un rôle que vous prenez dans l’équipe, tech lead est un poste, ou vous êtes responsable de la viabilité technique de ce que produit l’équipe dans laquelle vous opérez. Mais sûrement que quelqu’un d’autre aura une définition plus précise/complete. Bon code !
Quand est-ce qu'il y aura une video avec un tech lead autre que toi ? question d'avoir des points de vue un peu large.😉
Hello, pour le moment je me concentre à donner suffisamment de valeur en vidéo pour mériter 100.000 abonnées. Ensuite attaquer quelques interviews 👍 est ce c’est clair pour vous ?
@@codeursenior super alors. Vive qu'on atteigne les 100k
@@faouzielmansour 💪
01:03 : il a un ptit air de Jason Chicandier je trouve :-)
Mdrr j'ai cru que vous parliez de moi, mais je viens de comprendre en cliquant sur le lien !
Cela va dépendre aussi du contexte et donc de la boîte en elle-même. Personnellement, en tant que tech lead, on me demande de me détacher du code et d'être plus du côté client. Un tech lead ca ne veut rien dire au final et je m'en rends compte de plus en plus. Chaque structure a sa définition de tech lead, et même encore pire, en interne dans la même équipe, chacun a sa propre image du tech lead. De mon côté, je suis plus dans l'erreur 3 mais à mon sens, elle n'est pas de mon fait... Pour l'erreur n°4, encore une fois cela dépend du contexte, quand on est tous à la bourre, je préfère donner la réponse et malheureusement on n'a pas trop le choix... Pour la 6, c'est la même histoire, c'est l'attente des managers qui est tellement énorme ...
Sinon je suis totalement d'accord de façon générale, ce serait l'idéal et presque le job de rêve... mais on n'a pas la main sur tous les paramètres
Bonjour, merci pour votre retour d'expérience et votre avis sur les propositions de la vidéo. Effectivement, il existe plusieurs variantes du rôle de Tech Lead selon la structure, parfois ce n'est pas très clair...
Quelle est la différence entre tech lead et lead dev ? Car ce que tu decris, chez moi c'est un lead dev.
La différence entre un "Tech Lead" et un "Lead Developer" (Lead Dev) peut varier selon les organisations, mais généralement, ces rôles diffèrent en termes de responsabilités et d'orientation. Voici une explication basée sur les principes généraux de leadership technique et de développement de logiciels :
Tech Lead
Orientation Stratégique : Le Tech Lead se concentre davantage sur la vision technique à long terme du projet ou de l'équipe. Il s'assure que les décisions techniques s'alignent avec les objectifs globaux de l'entreprise ou du projet.
Prise de décisions techniques : Responsable de la prise de décisions architecturales et technologiques majeures. Le Tech Lead travaille souvent en étroite collaboration avec l'architecte logiciel (si ce rôle existe dans l'organisation) pour définir l'architecture du système.
Mentorat : Joue un rôle clé dans le mentorat des membres de l'équipe sur les meilleures pratiques de développement, les principes de conception et les standards de code.
Interface : Agit souvent comme point de contact entre l'équipe de développement et les autres parties prenantes, comme le management, les équipes de produits, ou les clients.
Lead Developer
Orientation sur l'Implémentation : Bien que le Lead Dev puisse aussi participer à la définition de la stratégie technique, son rôle est plus axé sur la gestion quotidienne de l'équipe de développement et l'implémentation des décisions techniques.
Codage Actif : Le Lead Dev est généralement plus impliqué dans le codage et la révision du code, veillant à ce que les pratiques de développement soient suivies et que la qualité du code soit maintenue.
Gestion de l'équipe : Peut être chargé de tâches administratives liées à la gestion de l'équipe, comme la planification des sprints, la répartition des tâches, et le suivi de la progression.
Support Technique : Fournit un soutien technique et des conseils aux développeurs de l'équipe, résolvant les problèmes techniques et assurant la cohésion de l'approche de développement.
Conclusion
Le Tech Lead se concentre davantage sur la vision technique et la stratégie, agissant comme un pont entre les aspects techniques et les objectifs commerciaux ou de projet, tandis que le Lead Developer se concentre plus sur la gestion quotidienne de l'équipe de développement, l'implémentation technique, et le maintien des standards de qualité du code. Dans la pratique, ces rôles peuvent se chevaucher et varier selon l'organisation.
Dans ma boîte on fait tout l'inverse donc ça me confirme qu'il faut que je me barre ASAP
Haha, effectivement ce n'est pas bon signe.
"Les sept zerreurs"
Ben ça en fait une, déjà
Dakorre
Ah bah moi je ne suis pas tech lead mais je suis la seule à prendre les grungy tasks (documentation comprise)
Et la reverse grungy task list, qui s'en occupe ? ^^
Ce qui est plus rigolo c’est que tout est dans la même liste ! Sauf que personne ne veut faire les grungy tasks et les autres se ruent sur les tâches sympas !
J’ai vu trop de tech lead donner des ordres sans jamais toucher une seul ligne de code et sans jamais devoir rendre des comptes à propos de leur travail mais bien à cheval pour presser les développeurs comme des citrons. Sans parler de ceux qui cherchent à minimiser le coût des tâches pour être toujours bien vu.
Pire certains finissent par faire bande appart avec les POs etc… tt en reléguant les développeurs en de simples exécutants.
Solution qui marche finir avec les tech leads et laisser les développeurs élire leur propre lead dev.
Une sorte de méritocratie, ça me va. Quel le plus légitime prenne la place qui lui revient !
Totalement d’accord avec tout ce que tu dis.
Je suis passer de développeur à Tech lead en interne et je m’entends très bien avec les devs de mon équipe.
Si tu es de ce côté attend toi à avoir les PO et compagnie sur le dos, c’est insupportable car eux leur seule vision c’est les points , les points tout en mettant le minimum possible. Vision court terme toujours et encore.
Et il y’a ceux comme tu dis qui ne veulent plus toucher une ligne de code etc…Je ne vois pas comment tu peux maintenir ton niveau sans pratiquer régulièrement.
Pour moi Tech Lead s’est terminé, retour au dev, dans le nom du poste s’est si proche du dev mais dans la réalité ça a rien à voir. Je préfère aider mes collègues que être au milieu de tout pour un titre.
@@Macintoshdfr très intéressant car j ai aussi eu de très bons techleads qui comme ils osaient mouiller le maillot car passionnés, ils étaient détestés des POs.
Des POs dont beaucoup sont en faites des chefs de projet véreux reconverti de manière éclair ⚡️ cherchant à avoir la main mise sur le développement 😂
@@Macintoshdfr Merci pour votre partage d'expérience... et pour avoir chosit le camp DU BIEN. 💪
Merci Simon, très bonne liste de principes.
Tu m'as permis de connaitre "Software Engineering at Google: Lessons Learned from Programming over Time" que je vais lire sans faute ! :)
Vous ne le regrettez pas, il vaut l'effort de lecture !