Ce que le meilleur meneur d'équipe Ján Regeš m'a appris

18. 12. 2022

Ján Regeš, un collègue, un ami et surtout une personne formidable, travaille depuis plus de 15 ans à l'agence numérique SiteOne. Il a été mon premier chef d'équipe quand j'ai commencé à programmer. Je garde un excellent souvenir de notre collaboration, car il a toujours réussi à me transmettre de nombreuses connaissances utiles que j'ai notées et que je n'ai comprises que des années plus tard.

J'ai réussi à interviewer Janek il y a quelque temps, et je lui ai demandé rétrospectivement comment il perçoit le travail avec les juniors, et comment faire les choses vraiment bien. J'ai compris depuis longtemps la différence entre ce que je pensais il y a des années et la façon dont je perçois les choses aujourd'hui. Tout est question de collaboration, d'humilité (envers les gens, envers la technologie, envers les entreprises), ... bref, Janek l'a magnifiquement écrit.

Voici son point de vue :

Vous êtes jeune, intelligent et très compétent, mais, à mon avis, trop confiant, tant en programmation qu'en affaires. Vous avez sans doute fait un grand pas en avant dans vos connaissances, mais vous devez aller plus loin.
Acceptez vos connaissances actuelles, vos savoirs et même vos contacts éventuels avec humilité et donnez-vous encore quelques années pour explorer consciemment le monde (technologie, affaires, personnalités...). Vous ne manquerez aucun train. Lorsque vous devrez prendre des décisions plus importantes et plus difficiles, vous disposerez de plus de données, d'expérience et d'instincts plus affinés pour les prendre.
Déterminez quelles sont les compétences ou les technologies que vous maîtrisez le mieux ou que vous souhaitez développer le plus, et choisissez votre prochain employeur en conséquence.
N'y allez pas pour l'argent, mais pour le bon sentiment d'un travail accompli, d'une équipe enrichie, d'une valeur apportée ou d'un besoin satisfait. C'est un cliché, mais l'argent ira de pair avec lui si vous vous concentrez sur la bonne chose de votre professionnalisme.
Si vous commencez quelque part, cartographiez et comprenez à qui s'adresse votre environnement de travail et quelle est la perception réelle de votre "qualité" et de votre "valeur" par ceux qui commandent et paient le projet. Apprenez à vous concentrer et à fournir une qualité et une valeur élevées, et pas seulement un "bon code". Il existe des entreprises et des projets où votre livraison concerne un petit morceau de code qui doit être parfait, rigoureusement testé et dont on sait qu'il fonctionnera pendant les 10 à 15 prochaines années. Mais il y a des projets qui vont durer 2-3-4 ans, et pour lesquels la qualité et la valeur attendues sont complètement différentes de ce que pense le programmeur. Apprenez à percevoir cela, à faire la différence et, si nécessaire, posez des questions de ce type à vos collègues ou au client.
Admettez que, tous les deux ou trois ans, si vous regardez votre code d'il y a deux ou trois ans, il sera toujours mauvais, même si vous pensiez qu'il était à la pointe de la technologie auparavant. Il est préférable et plus prometteur de se concentrer sur la qualité du résultat telle que perçue par le "client" - qu'il soit interne ou externe. Ce sont les choses les plus positives qui resteront et vous rechargeront à l'avenir, vous et les associés ou clients avec lesquels vous avez travaillé dans le passé.
Donnez votre cœur à votre nouvel environnement - comprenez où se situe leur "problème", ce qui les aidera le plus grâce à vos compétences particulières, communiquez cela à votre superviseur, et faites-le en ayant à l'esprit un résultat de qualité, et non un code de qualité. Peut-être que l'environnement a besoin de vos forces autres que la programmation.
Aidez, mais toujours avec humilité - respectez et essayez de comprendre les perspectives et les opinions d'autres personnes qui ont de réelles responsabilités et sont prêtes à assumer les succès et les risques de leurs décisions pour les années à venir. Dans le contexte d'un programmeur, cela inclut les décisions technologiques, le choix de la pile, ou la direction et la stratégie à plus long terme.
En tant que programmeur, soumettez toujours un travail rigoureusement testé. Lisez chaque ligne de votre code dans le diff avant chaque livraison. Testez l'interface utilisateur préparée sur X scénarios différents et essayez de jouer un grand nombre d'utilisateurs simples mais sophistiqués en vous. Ne vous fiez pas aux testeurs ou à des CR étrangers - il s'agit simplement d'un bon bonus de soutien lorsque l'équipe a mis en place ces processus.
Gardez la règle KISS à l'esprit et faites attention à la sur-ingénierie. Si vous faites les choses simplement mais efficacement, sans défaut, en toute sécurité et avec des limites claires, c'est mieux que d'inventer une centrale nucléaire super-modulaire et une architecture. Cela dépend de ce que vous faites, mais dans la plupart des cas, il est préférable de choisir la solution la plus simple.
La question de savoir si vous avez pris de bonnes décisions architecturales apparaîtra toujours après des années de fonctionnement et de mise en œuvre de fonctionnalités futures. Malheureusement, la réalité est plutôt que la plupart des programmeurs d'aujourd'hui changent d'emploi assez rapidement et n'ont aucune idée de l'impact positif ou négatif de leurs décisions antérieures et donc du fait qu'elles étaient bonnes ou mauvaises.
Apprenez à reconnaître et à travailler avec des personnes raisonnables et justes qui ne se préoccupent pas seulement des affaires, mais aussi de la valeur réelle de ce qu'elles font et pour qui elles le font.
Vivez et travaillez de telle sorte que lorsque quelqu'un de votre famille vous demande sur quoi vous travaillez, votre réponse soit honnête et porte davantage sur le fait d'aider vos clients à satisfaire leurs besoins ou leurs rêves dans le monde de l'internet, mais pas sur le fait d'être un programmeur parfait et d'écrire un code parfait. Le code parfait n'existe pas, mais la seule preuve que vous aviez un bon code est lorsque, des années plus tard, le propriétaire ou le collaborateur d'un de vos projets/produits vous complimente en disant qu'il était agréable de travailler avec lui tout le temps, ou qu'il s'est bien développé.
Ne vous laissez pas abattre et pensez à votre santé physique et mentale. Ne travaillez que 8 à 10 heures par jour. Si vous choisissez de passer un peu de temps sur le PC après les heures de travail ou pendant le week-end, vous ne devriez pas appeler cela du travail que vous "deviez" faire. Assurez-vous de vous dire a posteriori que c'était une excellente décision. Je consacre moi-même énormément de temps au travail, mais c'est uniquement parce que les choses que je fais en dehors des heures de travail ne me stressent pas, me rendent heureux, améliorent le climat professionnel pour notre équipe ou pour moi-même, et même après de nombreuses années, je ne regrette pas le temps que j'y ai investi. Je ne fais que ce que je veux faire et ce que ma famille me permet de faire. Je me sens libre et je sais. Même si je le fais depuis plus de 16 ans.
J'ai écrit le point précédent principalement parce qu'il est clair pour moi que vous y consacrez à peu près autant de temps que moi, mais que, rétrospectivement, vous vous rendez souvent compte que ce n'était pas la meilleure utilisation de votre temps (généralement en travaillant pour les mauvaises personnes ou les mauvais projets). Soyez prudent et choisissez vos collaborations de manière consciente et avec des conditions clairement définies.
Connaître, percevoir et accomplir la mission de votre vie. Même si vous rencontrez des difficultés pour le réaliser, au moins vous ne douterez pas d'être sur la bonne voie, mais vous vous concentrerez sur le fait de surmonter les obstacles en cours de route au lieu de ruminer des absurdités.

Jan Barášek Více o autorovi

Autor článku pracuje jako seniorní vývojář a software architekt v Praze. Navrhuje a spravuje velké webové aplikace, které znáte a používáte. Od roku 2009 nabral bohaté zkušenosti, které tímto webem předává dál.

Rád vám pomůžu: