"Et moi, je ne fais pas un seul projet sans full clean archi / DDD / TDD irréprochable depuis 2010 et ça marche du tonnerre !"
Qui a raison ?
Leur point commun : ce sont deux personnes extrêmement douées.
La première : pour monter rapidement un business en ne se souciant guère des bonnes pratiques, se basant sur son expérience et son intuition pour les futurs problèmes à venir et ceux à régler, ainsi qu'une réactivité sans faille sur le moindre problème en production. "Tout roule très bien".
La seconde, douée pour l'excellence technique. Appliquer ces différentes bonnes pratiques lui permet d'aller réellement plus vite que la très grande majorité des développeurs, en faisant preuve d'un grand professionnalisme pour le client final.
L'autre point commun entre ces deux personnes ? Elles travaillent très souvent seule, ou à 2. Pas plus.
Dès qu'il y a plusieurs développeurs, il devient très peu probable que chacun soit aussi exceptionnel.
Je parlais avec Benoit tout à l'heure. Nous partageons la même vision du Software Craftsmanship : aider les développeurs à développer de meilleurs logiciels plus rapidement, plus sereinement, pour moins cher.
Et lors de notre discussion, Benoit m'a ouvert les yeux sur quelque chose de très important dans notre métier : la reproductibilité, c'est-à-dire pouvoir aider la majorité des développeurs, pas seulement ceux "exceptionnels".
La première personne, qui va évangéliser pour sa façon de faire, souffre du biais du survivant. Ce n'est pas parce que sa méthode fonctionne pour elle, qu'elle fonctionnera pour tout le monde. La très grande majorité des développeurs n'aura pas une telle intuition et une telle expérience fine de cette manière de développer "à l'arrache".
Ce que j'ai compris en parlant avec Benoit, c'est que c'est la même chose pour la seconde. Elle ne peut pas imposer la même excellence technique à tous les développeurs. Ils n'auront pas lu le dixième de ce que cette personne a pu lire, ni n'auront sa profondeur technique.
Entre ces deux extrêmes, il y a tous les autres. Et l'apprentissage des bonnes pratiques, sont là pour permettre aux développeurs de ne pas refaire les mêmes erreurs sans cesse.
Donc, oui, on peut réussir plein de business en codant sans TDD et sans architecture hexagonale.
Oui, on peut aussi coder n'importe quel projet en y mettant du CQRS, du TDD, du DDD, de l'event-driven, etc., si l'on a une maîtrise tellement fine de ces concepts qu'on sait en tirer la substantifique moelle de façon pragmatique.
Mais si l'on est dans aucune de ces situations, on peut surtout continuer d'apprendre, pratiquer, apprendre, pratiquer, pour progresser, révéler notre plein potentiel, et s'épanouir, tout simplement.
Happy Coding !
PS : les soldes sur Craft Academy sont terminées, mais avec le code NEWSLETTER tu peux profiter de 25% de réduction sur tous les cursus :) https://craftacademy.fr?coupon_code=NEWSLETTER
Tout à fait d'accord, il faudrait faire de l'usabilité du développeur et de sa carrière.
Pousser les gens vers le haut, oui, mais en partant des personnes telles qu'elles sont, et de ce qu'elles ont vraiment besoin.
Et non pas de comment on pense qu'elles devraient etre
... c'est à dire souvent, modestie oblige, qu'elles deveraient etre comme nous.
Personellement je ne supporte plus tous ces articles qui veulent imposer à la terre entière "XXX Best Practices That Real Developers SHOULD know"
Le pire c'est qu'ils se croient très malin mais ils ne sont que des techniciens aux final, des gens qui vous submergent de détails techniques, c'est à dire du HOW, plutot que du WHAT et encore moins du WHY?
Tout à fait d'accord, il faudrait faire de l'usabilité du développeur et de sa carrière.
Pousser les gens vers le haut, oui, mais en partant des personnes telles qu'elles sont, et de ce qu'elles ont vraiment besoin.
Et non pas de comment on pense qu'elles devraient etre
... c'est à dire souvent, modestie oblige, qu'elles deveraient etre comme nous.
Personellement je ne supporte plus tous ces articles qui veulent imposer à la terre entière "XXX Best Practices That Real Developers SHOULD know"
Le pire c'est qu'ils se croient très malin mais ils ne sont que des techniciens aux final, des gens qui vous submergent de détails techniques, c'est à dire du HOW, plutot que du WHAT et encore moins du WHY?
Voir l'article d'Erik Dietrich dans mon lien
https://dev.to/daedtech/dont-throw-consulting-services-onto-your-website-3ll
PS: bravo pour diffuser ton contenu en dehors de LinkedIn en double publication substack, c'est exactement ce que je recommande moi aussi