7 habitudes des développeurs professionnels les plus efficaces (par un Tech Lead)

[@BlakvGhost]

Toujours là à suivre tes vidéos.

[@codeursenior]

Merci ça fait plaisir !

[@BrainStroming1789]

bonne vidéo. Je serais tenté de dire que la maturité peu encore te faire changer d'avis. 10 d'exp c'est pas mal mais c'est pas encore senior ;) quoi que maintenant j'en vois en entretient avec 6ans qui se disent senior (ptdr) Pour ma part ma phrase de senior c'est plutôt "ce qui différencie un junior d'un senior, c'est le nombre de murs qu'ils ce sont pris et de savoir quoi faire pour les éviter". Sans mur, on ne progresse pas. Tout refactoring apport au client, il y a ce qu'il voit (le dessus de l'iceberg) et ce qu'il ne voit pas (les 75% en dessous). Dire que passer du temps sur ce qu'il ne voit pas est difficilement justifiable "bah ca dépend". Si tu dis au client que dans 1 an il aura un soft encastré dans un mur et 2Millions d'€ foutu par la fenêtre... il va vite comprendre que le dessous de l'iceberg EST important. Notre rôle c'est aussi d'éduquer notre client et pas de répondre "oui" à toutes ses demandes. Notre expertise nous impose de lui communiquer le plus factuellement possible les risques de SES décisions. Ne pas oublier que si on vous demande de coder une bouze, c'est votre nom qui y sera associer (et donc votre cv), on a le droit de refuser. Pour le coverage... oui et non. 100% ne veut pas dire que t'es safe. Couvrir les interfaces en priorité en prenant par ordres "les test d'erreurs" (à mon avis ce sont les plus important de tous les test), puis "happy path" et enfin "test aux bornes de chaque paramètres". Ca permet de mettre en évidence le code mort et d'appliquer l'eXtrem programming. Reste les tests d'intégration semi/total et empirique. Mais avoir 100%de couverture n'est pas gage de sérénité. Pour les dépendances, si une lib est utilisé à moins de 50 voir 70%, c'est qu'elle n'est pas utile et que sauf groooos taf à faire, coder des libs c'est aussi notre métier. Après c'est du goût personnel mais je préfère autant que faire ce peu du fait maison que des black-box qui font tout même le café. Un point que tu n'aborde pas c'est le triangle qu'un dev doit avoir en tête "temps, ressources, objectif". On peu nous imposer que 2 sommets, le 3eme c'est nous qui l'imposons. Une erreur souvent commise par les junior qui se laisse imposer les 3 sommets et se retrouve dans des situations impossibles à tenir.

[@codeursenior]

Hello, merci beaucoup pour ce commentaire très complet. Je retiens plus particulièrement le point avec les 3 sommets « temps, ressources et objectif ». Très intéressant ! 👍 À bientôt, Simon.

[@Rodolphe28]

ça améliore pas l'insertion d'image dans une vidéo visiblement 😅 super vidéo quand même, comme d'habitude !

[@kodakodu]

Merci beaucoup

[@codeursenior]

De rien, bon développement !

[@deogratiasgnanvo6937]

Merci Simon. Excellente vidéo. J'ai une question un peu .... par rapport à ma Formation. Est ce que tu penses qu'on pourrait faire deux choses dans le domaine de l'informatique. Par exemple du développement web et de l'intelligence artificielle. Je pose cette question parceque j'ai appris l'ia mtn je suis intéressé par le développement web. Je me demande si je suis obligé de complètement oublié le domaine de l'ia pour devenir développeur web JavaScript.

[@codeursenior]

Hello, je ne me permettrai pas de te donner des conseils à la va vite, sans connaître réellement ta situation. Voici ce qui a marché pour moi : Faire une seule chose et la faire bien. Cela fait 6 ans que je fais du JavaScript/Web à temps plein et je n'ai toujours pas fait le tour. Quelle chance à développeur qui a fait 2 ans JS / 2 ans IA / 2 ans C++ face à un développeur qui a fait 6 ans JS ? C'est mécanique, pas besoin d'être très doué, juste discipline & focus. Voilà ce qui fonctionne pour moi en tout cas ! :)

[@deogratiasgnanvo6937]

@@codeursenior oui. Je comprends. Mais le truc c'est que j'ai déjà passé 2 ans a faire du JavaScript web front end. Et ça me frustre un peu de devoir laisser tomber tous ce que j'ai appris pour me mettre dans l'ia. Mais bon les sacrifices sont nécessaires

[@codeursenior]

@@deogratiasgnanvo6937 Oui, il faut savoir couper les branches mortes, et ça peut faire peur au début. J'ai 2 croyances là-dessus : - On ne travaille jamais en vain : Toutes les compétences sont acquises et payeront un jour ou l'autre. - Viser un long horizon : Quel problème seriez-vous prêt à toujours résoudre dans 10 ans ? Cela ne me dérangerait pas de coder des logiciels dans un navigateur avec JS. Cela me permet de rester focus malgré les pseudos "opportunités". Bonne continuation ! Simon.

[@brinckau]

"Je voudrais vous partager 7 habitudes de développeur professionnel que j'ai acquis" Cette phrase signifie que tu veux découper des habitudes en parts pour nous, et que tu as fait l'acquisition d'un développeur professionnel. Dans un entretien d'embauche, ça peut faire le même effet que de venir en slip. Il faut dire "je voudrais partager avec vous" et "habitudes de développeur professionnel que j'ai acquises".

[@Christakxst]

Vraiment des conseils de Captain Obvious...

[@codeursenior]

De mon expérience, rien n’est si obvious que ça. Rabâcher des fondamentaux fault partie du job.

[@AtlantisArch]

Pour ton dernier point, un collaborateur avec qui j'ai travaillé il y a longtemps avait une ligne pertinente pour cela, lors d'une discussion en fin de repas d'affaire (aucun de nous deux ne bossait dans la prog) : "l'expérience c'est la capacité acquise de n'accorder aucune importance à ce qui, finalement, n'a aucune importance". Et cela résumait parfaitement nos parcours, nos aptitudes et notre capacité à résoudre nos problèmes respectifs (et chacun reconnaissait l'autre comme étant très expérimenté/efficace, même si on était chacun aux antipodes en chronologie dans le projet. Le client lui était content de nous avoir trouvé pour résoudre son problème, mais se trouvait un peu en dehors du cercle lol).

[@codeursenior]

Hello, merci pour votre témoignage, entièrement d'accord : "l'expérience c'est la capacité acquise de n'accorder aucune importance à ce qui, finalement, n'a aucune importance". J'ai une variante : "The main thing is to keep the main thing the main thing".

[@costa7409]

Tres utile , merci Bcp. Surtout sur les dépendances... mais mais mais faudrait-il coder entièrement certaines fonctionnalités en lieu et place de passer par une librairie... ??? Une demande : pourriez-vous produire une vidéo démonstrative des automatisations à mettre en place au lieu de designer des responsables des tâches ? (Comment cela fonctionne concrètement, avec les alertes... pour nous autres qui n'avons jamais été dans des grosses structures, svp)

[@cocoludo]

Bonjour. Je suis curieux de savoir si faut recoder une fonctionnalitée existante. Dans l'exemple concret du calendrier qu'aurait tu fait ?

[@remix2die4]

Pour les automatisations, à mon travail, on utilise les hooks de GIT, qui permettent par exemple de vérifier l'indentation du code css avant de pusher. Il y a aussi les linters qui peuvent aider, mais je ne sais pas si c'est 'automatique' si il faut lancer la commande linter à chaque fois. Je pense que les hook GIT font plus l'affaire. Pour les dépendances, je pense qu'on peut s'appuyer sur des librairies sûres comme Angular Material, si la libraire propose la fonctionalité recherchée. Sinon, on peut coder entièrement la fonctionalité en question si elle est trop spécifique. Ou encore, créer une libraire custom en s'appyant sur une dépendance sûre, par exemple, un wysiwig qui s'appuie sur prosemirror, avec une seule dépendance.

[@codeursenior]

Hello @costa, question très intéressante, qui mériterait une vidéo à part entière. 😉 Je me note ça !

[@codeursenior]

Hello, la première réponse est "ça dépend" (coût, compétence, équipe, volonté long terme/court terme). Pour ce qui est du calendrier, c'est très long à redévelopper et il existe des briques qui ont déjà fait leur preuve et qu'on peut réintégrer directement. Donc il est fort probable que l'on parte sur une librairie.

[@codeursenior]

Hello @Allan, je complète en vrac : linter, test unitaire et pipeline CI/CD. Pour le linter/formater, généralement les IDEs peuvent te l'exécuter automatiquement sur une sauvegarde CTRL + S.

[@ameltriki2497]

Merci beaucoup pour ce partage très intéressant!

[@sparfell7630]

Merci

[@codeursenior]

Au top ! Bon code pour la suite, Simon.

[@RodolpheLASSALLE]

Tes vidéos sont vraiment top. Cela m'ouvre l'esprit sur mon niveau et me défini des objectif clair pour mon avenir. MERCI Simon

[@rayenhidri584]

Parfaite explication comme d'habitude

[@codeursenior]

Au top, à bientôt pour une prochaine vidéo. Bon code !

[@mikapp802]

Merci!! toujours enrichissant.

[@codeursenior]

Merci Mika ! 👍

[@cocolg3427]

Très intéressant !

[@codeursenior]

Merci @Coco LG !

[@tamantaman]

Merci.

[@codeursenior]

De rien, bon développement à vous !

[@ntlandry9446]

Merci Simon

[@codeursenior]

Merci à toi, bon développement ! Simon.

[@FISS007]

Merci pour le partage =)

[@codeursenior]

Avec plaisir !

[@isamu0810]

Pas d'images 😂😂

[@codeursenior]

Haha, je dois vraiment trouver un monteur vidéo !

[@isamu0810]

@@codeursenior je suis sûr que ce n'est pas grand chose, juste une petite case à cocher ☺️

[@nelsonbeneche2372]

Merci Simon

[@codeursenior]

Merci pour votre message @Nelson !

[@nelsonbeneche2372]

@@codeursenior je regarde toujours tes videos. continues comme ca

[@codeursenior]

@@nelsonbeneche2372 Votre message me motive à produire d'autres vidéos ! Bon développement à vous, Simon.

[@GoogleAccount-tc3zd]

Juste une remarque : je suis le contre exemple type de tes conseils. Ils sont très bon (loin de moi l'idée de remettre en cause ton super taf et tes bonnes vidéos) et me servent pour ma culture dev, mais ils ne peuvent pas toujours s'appliquer. Typiquement dans le monde de la prod, on doit livrer des petits sites ou petits appli très rapidement, et généralement la durée de vie d'un projet ne dépasse jamais 5ans (et la moyenne est même de 1 à 2ans). Dans ce contexte de flux tendu et d’éphémérité, "les bonnes pratiques" seraient plus des blocages voir rendraient totalement irréalisable une livraison dans les temps. J'aime donc toujours rappeler à mon équipe (chef inclut) qu'à chaque développement correspondra une stack qui lui sera optimal. Non dans une page promo qui dure le temps d'une communication on ne prend ni le temps de faire des tests ni d'écrire une doc ni même de faire des designs complexes ou d'utiliser des gros framework : on va au plus simple, au plus léger, au plus rapide, bref on s'adapte. J'aime le rappeler car je tombe trop souvent sur des puristes obsessionnels qui n'entendent pas faire autrement que leur stack préférées qu'ils ont réfléchis et maîtrisée pendant un certains temps par idéalisme mal placé. Et souvent je me méfie des "supers" méthodes ou paradigme car ils sont trop théoriques et très peut praticable (y-a-t-il une seule entreprise au monde qui respecte scrupuleusement à la lettre SCRUM ? J'en doute fort....) Chaque boite adapte les outils à leur convenance, c'est aussi ça le monde pro. Et c'est la première claque que chaque dev prendra en sortant du scolaire et en travaillant : on ne fait pas un projet perso, on se fiche bien de la qualité pure d'un environnement, il faut répondre à des impératifs et faire des compromis, ainsi va le business (et cet effet est encore plus vrai lorsqu'il s'agit d'entreprise dont l'informatique n'est pas l'activité). On a une punchline avec mon chef lorsqu'on est confronté à ce genre de personne : "Stop ton projet perso de fin d'année, arrêtes de faire ton geek puriste et soit pro." Voilà désolé pour le pavé mais ça me semble important à dire aussi. Super taf, continue comme ça :)

[@bossgd100]

C'est quelle conférence que tu as regardé ?

[@codeursenior]

Hello, c'est le SnowCodeCamp chaque année à Grenoble.