C’est une bonne question. Intéressant de voir comment les choses dérapent, un peu au début, beaucoup ensuite !
Tout commence avec un post un brin provocateur de Kevin sur linkedin :
https://www.linkedin.com/feed/update/urn:li:activity:6943520332855054336/
Aujourd’hui, j’ai du écrire un code affreux. 😭
Alors j’ai besoin d’écrire cet article pour m’excuser.
Non en fait j’assume. Et je pense que c’est important de t’expliquer ce qui s’est passé.
Continuer la lecture de « Software craftsmanship : une question de compromis »Cet article est rédigé en paire avec Hadrien. On s’est dit que c’était bien d’illustrer le concept par la pratique !
Photo de Tudor Baciu sur Unsplash
Le pair programming, ou travail en binôme, est une pratique qui consiste à travailler à deux en même temps sur une même tâche de développement.
En gros, au lieu de bosser à un seul cerveau, tu bosses à deux.
Tu trouveras ici un article assez complet sur le pair-programming dans lequel tu verras comment le pratiquer et le mettre en oeuvre. Si tu n’est pas au clair avec cette pratique, je te conseille de commencer par là !
“Un mob, c’est réunir toutes les personnes qui sont nécessaires au succès d’une tâche autour d’un seul poste de travail.”
Piqué par Hadrien à Woody Zuill
Bon, dit comme ça, c’est abstrait, mais concrètement, ça donne quoi ?
Si tu as connu les tasks forces, ça y ressemble !
Tu sais, le moment où c’est la m$#§e sur le projet, que la deadline arrive et qu’on met tout le monde dans une ‘war room’ pour sauver le monde (et le projet).
Ben c’est la même chose, mais avant que ce soit le bordel.
Concrètement, tu mets les développeurs du projet, et tous ceux qui sont utiles dans une même salle, en même temps, devant un seul écran.
La différence avec le pair-programming: ben c’est juste le nombre.
Au lieu d’être 2, tu peux être 3, 4, 5 ou plus si affinité.
Bon en vrai, au-delà de 6, ça va être compliqué à tenir dans le temps. Si tu as besoin de plus d’une pizza (format américain) pour nourrir ton équipe c’est qu’il est temps de la diviser.
Et finalement cette toute petite différence, tel un battement d’aile de papillon, engendre de grandes différences.
C’est ce qu’on va voir maintenant.
Continuer la lecture de « Pair Programming VS Mob Programming »Le pair programming, ou travail en binôme, est une pratique qui consiste à travailler à deux en même temps sur une même tâche de développement.
En gros, au lieu de bosser à un seul cerveau, tu bosses à deux.
Photo de Alvaro Reyes sur Unsplash
Cet article est encore en cours de rédaction. Si tu as des suggestions sur ce qui manque, te semble erroné ou si tu te poses encore des questions après avoir lu l’article, tu peux me contacter ici : https://www.linkedin.com/in/benoitgantaume/
Quelle drôle d’idée après tout : mettre deux personnes au travail sur une tâche, alors qu’une seule pourrait suffire.
Pourquoi diable y mettre autant d’énergie ?
Si on reste dans une logique productiviste fordienne, cela ne fait aucun sens.
Mais si on prend conscience qu’on est sur une activité complexe, développer un logiciel, qui nécessite des interactions hautement complexes, des humains qui bossent ensemble, on se rend compte que ce n’est pas si stupide.
Deux paires de bras qui travaillent ensemble vont apporter un gain linéaire : 1 + 1 = 2.
Hors, développer demande d’utiliser principalement son cerveau. Et quand deux cerveaux réfléchissent ensemble, le gain n’est plus linéaire.
Parfois 1 + 1 = 11.
Par moments 1 + 1 = 0.
Donc la première raison de travailler en pair programming est que les solutions apportées vont être beaucoup plus riches et le code de bien meilleure qualité.
La deuxième raison est de faire circuler la connaissance.
N’as-tu jamais été stressé à l’idée de partir, toi ou un collègue en vacances ?
Si tu veux pouvoir partir tranquille, il vaut mieux éviter d’être le seul détenteur d’une connaissance. Ça tombe bien, le pair programming est un formidable circulateur de connaissance.
Enfin, d’un point de vue humain, cela permet d’aller à la rencontre de ses collègues d’une manière plus profonde. Mais ce point peut être à double tranchant. On en parle plus bas.
Dans le pair programming des origines, les ordinateurs étaient encombrants, onéreux, et les outils de communication peu répandus. Donc on bossait à deux, l’un à côté de l’autre, sur le même ordinateur. Il n’y avait qu’un clavier/souris et une seule personne touchait le clavier pendant que l’autre réfléchissait avec lui.
Aujourd’hui, les ordinateurs portables sont répandus et les outils de communication beaucoup plus développés grâce aux connexions fibrées.
On peut donc élaborer d’autres manières de binômer.
Continuer la lecture de « Pair programming : le guide ultime »Le software craftsmanship, ou craft, est devenu tendance. Mais qu’est-ce qui se cache derrière ce concept ?
On peut définir l’artisanat logiciel, le software craftsmanship, comme un mouvement porté par des développeurs passionnés par leur métier.
On peut le décrire selon ses valeurs, son état d’esprit ou encore ses pratiques.
Difficile de parler de software craftsmanship sans parler d’agilité tellement les deux sont liés à leur origine, même si les choses ont bien évolué depuis.
On parlera aussi dans cet article de la relation des pratiquants avec les reste du monde et aussi comment s’y former.
C’est aujourd’hui le 18 Mai mon freedom day de freelance.
Qu’est-ce que le freedom day ?
C’est le jour de l’année où je n’ai plus besoin de travailler pour assurer le minimum vital de ma rémunération.
C’est le jour où je suis libre de décliner une affaire que je sens pas, sans me demander si je vais pouvoir mettre de la nourriture sur la table pour les prochains mois, sans me demander si je ne vais pas le regretter dans quelques semaines.
En tant qu’agence, notre freedom day, c’était plutôt vers le 18 Novembre : on faisait notre résultat sur les dernières semaines.
Maintenant que je suis freelance, j’ai raccourci cette date.
Et c’est devenu un objectif pour moi : amener cette date le plus tôt dans l’année.
A partir de ce jour, je peux passer beaucoup plus de temps à me former, renforcer mon expertise, passer du temps sur des projets persos et ainsi développer les outils qui me permettront de raccourcir cette date l’année prochaine.
Tu la sens la boucle vertueuse ?
Mieux je choisis mes clients sur les critères qui me conviennent, et plus je fais avancer mon projet.
Plus je me forme, et plus je peux être pointu et valoriser mon expertise.
Plus j’investis de mon énergie sur des produits et mieux je pourrai faire grandir mon activité sans travailler plus, voire même moins.
Pour y arriver, ça commence souvent par sortir de la logique de régie à temps plein.
D’ailleurs, si tu veux connaître les mécaniques qui te permettent toi aussi d’y arriver, viens voir la conf que j’ai donnée sur youtube à ce sujet.
Cette notion de freedom day, je l’ai empruntée à Pierre Ammeloot, un des experts qui intervient dans le cercle. Concrètement, avec les logiques d’engagement et de facturations d’acompte, j’ai simplifié le calcul en disant que c’est le jour où le facturé dépasse le point d’équilibre de ma structure. C’est -à -dire que je couvre mes frais prévus : mon salaire, mais aussi les factures des partenaires avec qui je travaille.
Remarque bien que j’ai choisi d’investir une partie de ce temps libre, mais c’est à toi de voir.
Certains vont préférer dédier ce temps à leur famille.
D’autres voyager.
D’autres encore faire du pro-bono.
C’est ce que j’aime avec le freelancing : tu as le choix de ton mode de vie.
Ce n’est pas facile.
Certains moments sont franchement désagréables.
Mais tu as le choix de définir tes propres règles du jeu.
Envie de bosser dur : just do it.
Envie de lever le pied : vas-y si tu peux te le permettre.
Et toi, c’est quand ton freedom day ?
Si tu as envie de rejoindre un groupe de développeurs freelance qui ont envie d’aller plus loin, viens jeter un oeil au cercle.
Benoit Gantaume
Artisan Développeur
Le cercle, c’est un parcours de formation pour les développeurs freelance qui t’apporte les compétences pour faire développer ton activité, gagner en sérénité et sortir de la routine de la régie.
En septembre 2021 démarrait le premier cercle, et si tu n’as pas pu nous rejoindre, écoute les experts qui sont venus nous former, ça sera un peu comme si tu y étais !
On ouvre un second cercle qui démarre le 15 Juin prochain. Donc si tu veux nous rejoindre, passe une tête !
La première fois que j’ai travaillé en équipe, ça a été le fiasco total !
Aucun des deux développeurs avec lesquels je travaillais n’a réussi à démarrer le projet que je réalisais.
Le hic, c’est que je partais en vacances et il fallait que mes collègues puissent le reprendre pour continuer sans moi.
De mon côté, c’était l’éternel :
« Je ne comprends pas, ça marche sur ma machine ! »
Que s’est il passé ?
C’était il y a quelques années, NPM, le gestionnaire de dépendances JavaScript venait de passer en version 5, et avec lui, l’ajout d’une fonctionnalité de marque : le fichier de verrouillage des dépendances (le fameux « package-lock.json »).
C’est une fonctionnalité qui permet de figer l’arbre des dépendances installées et de reproduire cette installation à l’identique autant de fois que nécessaire.
Comment ça marche ?
Supposons que vous souhaitez installer la dépendance « axios » (un client HTTP) dans votre super application.
Vous allez taper la commande suivante dans votre terminal :
npm install axios
Votre fichier « package.json » contiendra alors l’information suivante :
{
"name": "my-super-app",
"version": "1.0.0",
"license": "UNLICENSED",
"dependencies": {
"axios": "^0.21.1"
}
}
Et votre fichier « package-lock.json » contiendra quelque chose comme ça :
{
"name": "my-super-app",
"version": "1.0.0",
"lockfileVersion": 1,
"requires": true,
"dependencies": {
"axios": {
"version": "0.21.1",
"resolved": "https://registry.npmjs.org/axios/-/axios-0.21.1.tgz",
"integrity": "sha512-dKQiRHxGD9PPRIUNIWvZhPTPpl1rf/OxTYKsqKUDjBwYylTvV7SjSHJb9ratfyzM6wCdLCOYLzs73qpg5c4iGA==",
"requires": { "follow-redirects": "^1.10.0" }
},
"follow-redirects": {
"version": "1.14.1",
"resolved": "https://registry.npmjs.org/follow-redirects/-/follow-redirects-1.14.1.tgz",
"integrity": "sha512-HWqDgT7ZEkqRzBvc2s64vSZ/hfOceEol3ac/7tKwzuvEyWx3/4UegXh5oBOIotkGsObyk3xznnSRVADBgWSQVg=="
}
}
}
Le fichier de verrouillage va stocker la version exacte installée à cet instant de axios (même si votre « package.json » autorise plusieurs versions) avec l’URL de téléchargement et la signature de la dépendance installée.
Et surtout, le plus important, il va faire la même chose avec les dépendances de vos dépendances (ce que l’on appelle les dépendances transitives).
Dans notre exemple, axios dépend du paquet « follow-redirects » (il en a besoin pour fonctionner), ce dernier va donc également se retrouver dans ce fameux « package-lock.json » avec une version figée, même si axios en accepte plusieurs dans son propre fichier « package.json ».
La prochaine fois que vous ferez un ‘npm install’, NPM utilisera le fichier de verrouillage pour reproduire la même installation (il suffira d’aller chercher les URL sauvegardées à l’intérieur).
NPM peut ensuite vérifier que c’est toujours exactement la même chose qui est installé en calculant la signature de la dépendance installée et en la comparant à celle du fichier de verrouillage.
Ce mécanisme permet de garantir que votre installation de dépendances est reproductible.
Sauf que, quand NPM s’est mis à jour sur ma machine, la seule chose que j’ai constaté, c’est qu’un nouveau fichier généré – que je n’avais pas demandé (le fameux package-lock.json) – était apparu et venait poluer mon beau projet.
Comme je ne comprenais pas ce package-lock.json, j’ai trouvé la configuration me permettant de m’en débarrasser et de retourner à mes petites habitudes bien rangées en deux temps trois mouvements (il suffit de créer un fichier « .npmrc » à la racine de votre répertoire de travail avec la configuration suivante).
package-lock=false
Le problème, c’est que certaines dépendances transitives avaient été mises à jour entre le moment où j’avais fait mon installation et celui où mes collègues l’ont effectué.
Et pas de bol, l’une d’entre elle avait introduit un changement cassant, autorisant notre dépendance directe à l’installer.
Sans le fichier de verrouillage pour figer la version qui marchait pour moi, mes collègues n’étaient pas en mesure de reproduire une installation identique, et dans ce cas particulier, ne pouvait même plus lancer le projet à cause du changement cassant (une fonction avait été renommée) !
Le fichier de verrouillage est donc de nos jours un élément indispensable pour tous les projets, que l’on travaille seul ou à plusieurs, au vu du nombre exponentiellement grandissant de bibliothèques utilisées (ce qui est d’ailleurs un problème, si le sujet de la performance et de la lourdeur des logiciels vous intéresse, je vous recommande la lecture de ma traduction de l’excellent article de Nikita Prokopov : https://blog.romainfallet.fr/desenchantement-logiciel).
Dans mon cas, si j’avais supprimé mon dossier node_modules, j’aurais rencontré exactement le même problème que mes collègues en essayant de réinstaller mes dépendances.
Pour profiter des bienfaits du fichier de verrouillage il faut donc bien l’ajouter dans vos commits et l’envoyer sur votre dépôt Git.
C’est donc après quelques heures de recherche et une petite remise en question que je suis parvenu à remettre en place une installation reproductible après avoir rétrogradé la version du paquet qui posait problème.
J’ai pu ensuite partir sereinement en vacances !
Mais mais mais, on ne peut pas se quitter là-dessus…
Si les mainteneurs du paquet incriminé avaient suivi la spécification de gestion sémantique des versions (Semantic Versionning ou SemVer en anglais), tout ceci ne serait pas arrivé !
Qu’est-ce que c’est ? Ce sera le sujet du prochain article !
Abonnez-vous sur https://compagnon.artisandeveloppeur.fr/veille et les numéros de version n’auront plus de secret pour vous (très utile si vous ne connaissez pas la signification des « ^ » et « ~ » dans votre package.json ;)).
Au plaisir d’échanger !
Salut,
En février de l’année prochaine, Artisan Développeur va fêter ses 4 ans.
C’est dingue d’y penser.
4 ans à publier régulièrement du contenu, que ce soit en email, en blog, en podcast ou en vidéo.
C’est plus de 300 épisodes de podcast, une cinquantaine de vidéos, des milliers d’écoutes tous les mois et autant de vues youtube.
Au moment d’écrire ces lignes et de prendre conscience de tout ça, j’ai un frisson.
J’en suis fier et j’aimerais partager ce moment avec toi.
Car c’est à la fois pour toi et grâce à toi que je fais tout ça.
Mais ça n’a pas été facile, loin de là.
Je ne vais pas te parler de la discipline que cela demande, mais plutôt du côté émotionnel du projet.
Car entreprendre des choses, c’est s’exposer.
S’exposer, c’est prendre le risque d’échouer.
Certes, se planter est le meilleur moyen d’apprendre.
Mais ça fait quand même mal.
Et ça fait peur.
J’ai une mauvaise nouvelle : je ne connais aucun moyen d’y échapper.
Le seul moyen de dépasser sa peur, c’est de la traverser.
Je vais te raconter quelque chose que je n’ai jamais dit à personne : comment j’ai vécu mes premières ventes en ligne.
J’espère que tu es bien assis•e, par-ce qu’on va monter sur des montagnes russes…
J’avais vu tous ces témoignages d’infopreneurs qui racontaient comment ils étaient stupéfaits de leurs premières ventes.
Ils avaient constitué avec le temps une liste de personnes intéressées par leur travail et il était temps de passer à l’étape d’après et vendre une première formation.
Ils insistaient sur ce moment magique d’appuyer sur le bouton ‘Send’ de leur outil d’email marketing et leur stupéfaction de voir les commandes tomber dans les minutes qui suivaient.
Leurs témoignages étaient émus, avec la bonne musique qui va bien en fond pour montrer à la fois le désespoir dans lequel ils étaient avant de devenir infopreneur, la tension au moment d’appuyer sur le bouton magique et l’allégresse qui suivait.
Je pense que naïvement, j’espérais vivre la même chose…
Je vais te raconter ma version.
Après des mois de travail à me manger le cerveau, après avoir produit une cinquantaine de podcast et collecté quelques centaines d’emails de gens intéressés, j’arrivais au moment fatidique et soi-disant magique d’appuyer sur le fameux bouton ‘Send’ de ma première campagne email.
Je ne peux pas dire que ce moment m’ait laissé un sentiment particulier.
Je sentais forcément de la tension : il y avait beaucoup d’enjeux pour moi.
J’ai cliqué sur ce bouton.
Et j’ai ouvert ma boite email, impatient de voir les commandes tomber.
Rien.
Mais comment ça ?
Elle est où la pluie de commandes promise ?
Une heure après, rien non plus.
J’ai même cru à un moment que ma boite email était plantée ou que le système de commande était buggé.
Mais non. Il n’y avait juste rien.
Et là j’aimerais te décrire les émotions que je vivais, mais je n’ai pas les bons mots.
Ils ne seraient pas assez puissants.
Mais dire que je me sentais nul était un doux euphémisme.
Ça se bousculait dans ma tête. Devais-je continuer ?
Si ce que je faisais n’intéressait personne, cela en valait-il la peine ?
Durant ces premières 24h, je sentais un mélange de honte et de nullité absolue.
Et puis la première commande est arrivée.
Et là c’était un feu d’artifice dans ma tête.
Je passais de l’état de pire merde du monde à celle de grand champion.
Les deux étaient autant ridicules l’un que l’autre, mais c’était comme ça que je le vivais.
Je commençais à négocier avec moi-même : est-ce qu’une commande était significative ?
Je me mangeais encore le cerveau quand une autre est arrivée quelques heures plus tard.
Au fil des jours de cette semaine, c’est au final 8 personnes qui m’ont fait confiance.
L’expérience était clairement validée et l’objectif rempli.
Mais quel arc-en-ciel émotionnel il m’a fallu vivre !
Autant être honnête : c’était trop pour moi.
Mais ce projet me tenait trop à cœur pour que je m’arrête à ça.
C’est mon message : si tu as un projet qui te tient à coeur, soit prêt•e à passer la tempête des émotions que cela va engendrer et fonce !
Juste fais-le.
Heureusement que j’ai pu traverser ces moments, sinon je ne serais pas en train d’écrire cet email.
Car depuis il y a eu du chemin.
J’ai appris, non pas à gérer, mais à accepter les émotions de chaque lancement.
Je suis encore passé par de sacrés ascenseurs émotionnels et je m’habitue un peu plus à chaque fois.
Avec le temps, je ressens plutôt de l’excitation quand je fais la promotion de mon travail comme aujourd’hui.
Je suis tellement heureux de partager ça avec toi, j’espère que ça t’inspirera pour entreprendre les projets importants pour toi.
Excité aussi de te parler de l’upgrade du cursus Artisan Développeur.
Après avoir aidé des centaines de développeurs à écrire du code durable, j’ai fait une (grosse) mise à jour qui est maintenant disponible ici :
https://artisandeveloppeur.systeme.io/cursus-artisan-developpeur
Pour marquer cette amélioration, le prix augmentera le 21 Novembre.
Alors si tu es intéressé, jette un oeil.
Aujourd’hui, Artisan Développeur, c’est devenu un petit business. Mais c’est surtout à la base une revendication et une vision.
Il me tarde de te raconter ça aussi. Car je crois n’en n’avoir jamais parlé non plus…
A bientôt !
Benoit Gantaume
Artisan Développeur.
Salut,
Quand j’ai commencé l’aventure Artisan Développeur il y a trois ans, je ne savais pas trop où j’allais.
Je testais des choses et j’avais besoin de feedback, d’essayer les nouveaux outils que j’avais appris.
C’est là qu’Artisan Développeur est né.
Ce qui n’était à la base qu’un side project occupe maintenant la moitié de mon temps.
D’ailleurs, je te raconte la génèse bientôt dans une vidéo Youtube.
Je savais que si je faisais du travail de qualité et que j’étais assez régulier assez longtemps, alors ce projet pourrait donner quelque chose d’intéressant.
Mais je savais aussi que pour durer, il fallait trouver un modèle économique. Je voyais beaucoup de confrères développeurs produire du contenu pendant plusieurs mois, quelques années pour certains, et finalement être rattrapés par le quotidien et arrêter le projet.
Si je voulais que le projet soit durable il fallait pouvoir rémunérer non seulement mon travail, mais aussi celui de l’équipe qui m’aiderait sur le chemin.
Alors je me donnais 5 ans pour voir si je pouvais développer une activité viable.
5 ans !!
C’était la première fois de ma vie que je réfléchissais à un projet sur un tel horizon de temps.
La première fois que je faisais une action en me disant que j’en tirerai vraiment les fruits dans plusieurs années.
Pour tenir aussi longtemps, je savais que j’avais besoin de retours concrets rapides.
Avancer par petites étapes et valider les hypothèses que je faisais.
Les deux grosses hypothèses étaient les suivantes :
Est-ce que mon travail va intéresser des gens ?
Est-ce que je vais trouver un modèle de revenu viable ?
La première hypothèse a été validée assez vite, en quelques semaines.
J’avais de supers retours sur le podcast et je prends toujours autant de plaisir à les recevoir.
Par contre, il restait une étape super importante : est-ce que j’allais arriver à générer un revenu ?
Alors à un moment donné, je me suis lancé.
J’ai créé ma première formation en ligne, et je l’ai mise en vente.
C’était un test en mode ça passe ou ça casse.
Soit je passais cette étape, soit j’arrêtais.
Je ne me souviens plus du minimum psycholoqique que je m’étais donné.
Mais c’était de l’ordre de quelques-unes.
L’important, c’était pas le montant des ventes, mais prouver que c’était possible.
Heureusement d’ailleurs…
Cette semaine-là, j’ai vendu 8 formations à 27€, soit 216€ TTC.
Il fallait encore enlever la TVA ! 😀
Des mois de travails pour ce résultat.
Et j’étais incroyablement heureux !
Bien sûr si je m’étais arrêté au montant, j’aurais pu pleurer.
Mais ce qui m’intéressait surtout, c’était que 3% des gens qui m’avaient confié leur email étaient devenu client.
Il suffisait donc d’intéresser (beaucoup) plus de monde et ça pouvait peut-être marcher !
C’était une étape importante qui avait été franchie.
Non seulement j’avais validé une hypothèse super importante, mais j’avais aussi dépassé l’ascenseur émotionnel que ça représentait.
Je t’en parlerai une prochaine fois !
Mais tout ça s’est fait à un coût.
Il fallait aller vite. Produire les formations rapidement pour être sûr de les publier et avoir du retour concret.
J’avais tellement peur de m’exposer, de prendre le risque de me foirer, d’échouer que mon corps résistait. Je me souviens encore des migraines de dingue que je me payais à chaque enregistrement. Et ce n’était pas juste à cause des lumières…
Il fallait donc aller vite, au risque de ne rien sortir.
“Si vous n’avez pas honte de votre produit quand vous le sortez, c’est que vous l’avez sorti trop tard”
Je ne sais plus trop qui a dit ça, mais il y a du vrai là dedans.
Mes premières formations : j’étais à la fois incroyablement fier d’y être arrivé, et un peu honteux du résultat.
Le contenu était bon.
Mais la structure pédagogique était améliorable.
Quant à la technique de production, certaines parties étaient à un niveau inférieur à ce que j’aurais voulu. Je filmais avec ma webcam de bureau à 20€. Heureusement le micro était à peu près correct, j’avais déjà investi pour le podcast.
Dans le décor, on voyait les bandes de placo qui restaient en attente. Je me suis fait chambrer quelques fois sur ce sujet…
Mais c’était à l’image de ce que je faisais : en cours de construction.
J’étais conscient de ces limites. Mais au lieu de chercher à raffiner encore et encore les choses, j’ai décidé de me jeter à l’eau et tester.
Après tout, la valeur est dans l’œil du client.
Si quelqu’un n’était pas content, je le remboursais.
Et en 3 ans, je peux compter sur les doigts d’une main ces demandes.
Mais j’ai surtout eu des tonnes de témoignages me disant tout ce que ça leur avait apporté dans leur vie pro et au-delà ! Dingue !
J’aurais pu m’arrêter là et considérer que ça suffisait.
Mais j’avais envie de relever le niveau.
J’ai amélioré progressivement le studio grâce aux revenus générés.
J’ai progressé dans la technique.
Et puis j’ai commencé à travailler avec un ingé son.
Puis avec un monteur et une community manager.
Au fil du temps, j’ai aussi gagné en confiance.
Je savais que je pouvais investir plus d’énergie car il y avait des gens qui me soutenaient et j’avais une équipe pour m’attaquer à des projets plus ambitieux.
Et je suis fier de t’annoncer qu’après des semaines de travail, le niveau est encore monté d’un cran avec la version 1.2 du cursus artisan développeur.
Je viens de la publier et elle est maintenant disponible ici :
https://artisandeveloppeur.systeme.io/cursus-artisan-developpeur
On a migré sur la plateforme compagnon pour offrir une meilleure expérience d’apprentissage. J’ai aussi créé un nouveau module 0 pour profiter à fond du cursus, refactorisé complètement le module 2 et amélioré la pédagogie du module 4.
Après avoir accompagné des centaines de développeurs, j’ai repéré des patterns d’apprentissage que j’ai rassemblé dans le module 0.
Au fil du temps, je me suis rendu compte que les vidéos plus courtes étaient plus efficaces sur le plan pédagogique. En plus, je suis passé au travail avec le prompteur.
Au final : un module 2 plus dense, mieux structuré avec une bien meilleure qualité de rendu.
Enfin, j’ai réalisé que le meilleur moyen de comprendre le TDD était de voir d’autres en faire.
J’ai donc enrichi le module 4 d’une série de 7 katas que je te propose comme exemple de pratique et de quelques points supplémentaires de théorie.
On arrive maintenant à un niveau global du cursus dont je n’ai plus honte.
Au contraire, j’en suis fier, et je voulais te dire merci, car c’est grâce à ton soutien que j’y suis arrivé.
Alors oui, il reste encore des choses à améliorer.
Il reste surtout des sujets à explorer.
Je me dis que j’ajouterais bien un module supplémentaire dédié à la clean architecture ou le DDD.
Peut-être aussi ajouter quelque chose sur les design pattern.
J’ai envie de faire évoluer le cursus et je le ferai en fonction des retours.
Toutes ces mises à jour, comme les précédentes, seront offertes pour ceux qui se sont déjà inscrits. C’est un moyen de les remercier de m’avoir fait confiance tôt dans le projet.
Car pour refléter ces améliorations, le prix augmentera régulièrement à chaque étape.
D’ailleurs pour célébrer la version 1.2, le prix augmentera le 21 Novembre prochain.
Si tu étais déjà motivé pour t’inscrire, et apprendre à écrire du code durable, c’est peut-être le moment !
https://artisandeveloppeur.systeme.io/cursus-artisan-developpeur
Encore merci pour ton soutien.
J’espère que cette histoire t’inspirera et te donnera envie d’entreprendre toi aussi les projets qui te tiennent à cœur.
A bientôt,
Benoit Gantaume
Artisan Développeur