Temps de lecture estimé : 27 minutes
Comprendre le software craftsmanship avec sa définition, ses principes, ses valeurs… D’ailleurs, comment devenir software craftsman ?
Software craftsman, software craftsmanship, software craft, artisanat logiciel, artisan développeur…
Des mots que j’entends de plus en plus dans la communauté dev.
Tous les experts en programmation sont passés par là.
Une fois en entretien, on m’a posé la question : « Alex, tu sais ce que c’est le craft ? Ça te parle ? »
Et tu sais ce que j’ai répondu ?
Rien.
Car même si j’avais une vague idée de ce qu’était la mouvance du software craftsmanship, je ne savais pas l’expliquer.
Aujourd’hui, je te propose de découvrir avec moi ce qu’est le software craftsmanship, comment il fonctionne et ce qu’il peut t’apporter en tant que développeur !
En français, le terme « software craftsmanship » désigne l’artisanat du logiciel.
On l’écrit aussi parfois « software craftmanship » (sans le « s »).
(Même si c’est une faute d’orthographe !)
Le principe derrière ce terme un peu compliqué à écrire :
En tant que développeur, notre travail peut être qualifié d’artisanal.
On design, construit, fabrique des logiciels… Souvent uniques.
Notre code est tapé « manuellement », n’est jamais similaire d’un développeur à un autre, permet de créer des choses qui n’existaient jusqu’alors pas, met en avant notre créativité.
Tout comme l’artisanat classique, il s’améliore aussi avec les années.
Être développeur, c’est maîtriser un réel savoir-faire.
Tu vois, pour moi l’artisanat logiciel s’oppose à l’industrialisation du développement.
C’est-à-dire des entreprises qui ont besoin de trouver un développeur, une ressource pour « pisser du code » et livrer rapidement quelque chose de non qualitatif.
Des boîtes qui tirent les prix vers le bas, quitte à avoir 3 devs pour le prix d’1 au mépris du bon sens et de la qualité de code.
Cette déshumanisation du métier de programmeur est aux antipodes de ce que veut apporter le mouvement des craftsmans.
(Ou la software craftswoman, d’ailleurs)
En une phrase, c’est souvent un développeur passionné qui cherche à écrire le meilleur code possible avec la meilleure architecture pour répondre au besoin.
Il code par passion.
Et comme toute passion, il n’attend pas que quelqu’un vienne lui apprendre quelque chose.
Le software craftsman est en perpétuelle recherche d’amélioration.
L’artisan du logiciel se reconnaît grâce à ces traits :
Le software craftsman ne passe pas 2h à déboguer un problème sans trop comprendre ce qu’il fait.
Il utilise ce temps pour réfléchir au problème et trouve une solution intelligente qui fait sens.
Alors si toi aussi tu aimes coder et que tu as envie d’en apprendre encore plus sur ton métier de développeur…
Rejoins l’esprit Craftsman !
Mais attention, car être un artisan du logiciel requiert un certain état d’esprit.
Ce n’est pas une fiche de poste 😉
Le rôle du développeur et de l’informaticien en général a beaucoup changé ces dernières années.
Aujourd’hui, coder est devenu mainstream.
(Parce-que oui, aujourd’hui tout le monde ou presque connaît le HTML)
Du coup, en tant que développeur, c’est un peu plus facile de battre certains clichés…
L'époque où tout le monde nous voyait comme des barbus, geeks, en mode no-life ou avec des grosses lunettes style année 80 est révolue.
Désormais, on est « un peu plus » considérés en société.
On peut aller à des vernissages pour discuter blockchain, NFT, IA…
Qui aurait cru ça quelques années en arrière ?
Changer l’état d’esprits des gens concernant les développeurs aura pris des années, mais on y est !
Pour autant, je ne compte plus le nombre de fois où j’ai eu cette conversation :
– Tu fais quoi dans la vie Alex ?
– Euh… Je suis chef de projet web ! Et toi ?
Un développeur qui ne s’assume pas.
C’était plus facile de se définir en tant que « chef » (bien que le rôle de chef de projet n’a pour moi rien à avoir avec celui d’un « chef » au sens premier du terme).
Plutôt que de se définir en tant que développeur web, aka informaticien, aka codeur bizarre qui passe ses journées à regarder des animes (et qui ne sort pas le week-end hein, tant qu’à faire)…
"Informaticien" en France, c'est pas "computer scientist" aux USA.
On y reviendra, mais le courant « software craftsman » vise à rendre aux développeurs leur fierté de coder.
De donner à ce beau métier une image plus noble, plus artisanale, plus artistique…
Alors, soyons fiers de coder.
Désormais, j’assume totalement d’être un codeur passionné.
Parfois je code le week-end et je kiffe ça, ouais.
Tout est une question d’équilibre…
Coder, est-ce de l’art ?
C’est un débat qui durera je pense pour l’éternité.
Le fait que deux programmeurs / développeurs ne produisent pas le même code pour répondre à une problématique donnée…
Ça fait assez artisanal je trouve !
Quant à savoir si le code en lui-même est beau ou non, je trouve ça assez subjectif.
Je comprends l’idée d’art derrière.
On crée des choses uniques, faites d’une manière spécifique (la nôtre), avec notre méthode, nos outils… et dont on est fier.
Ça fait très ARTisanal !
Avec du code on peut faire de l’art, mais est-ce que le code en lui-même est de l’art ?
Pour pouvoir répondre à cette question, il faudrait se demander « qu’est-ce que l’art » déjà ?
Mais là, c’est sans moi 🙂
Est-ce que la définition suivante est correcte ?
L’artisanat logiciel ou le software craftsmanship, c’est l’art du code.
Je te laisse y réfléchir.
Fondamentalement, on n’est pas là pour faire des trucs jolis mais plutôt des trucs qui marchent.
Mais là aussi, ça se discute.
C’est quoi ton avis à toi ?
En tout cas si jamais tu souhaites plus de lecture sur le sujet, je te conseille la lecture de Dan North : Programming is not a craft.
Tout comme Agile a son manifeste…
Les software craftsmans ont aussi leur manifesto !
Si le manifeste agile est à destination des entreprises au sens large (managers, chefs de projets, dirigeants, développeurs…).
Le manifeste du software craftsmanship est uniquement à destination des développeurs.
(la traduction française est en dessous)
J’aimerais détailler les principes du software craftsmanship afin qu’on puisse voir ce qui se cache derrière !
En tant qu’aspirants Artisans du Logiciel, nous relevons le niveau du développement professionnel de logiciels par la pratique et en aidant les autres à acquérir le savoir-faire. Grâce à ce travail, nous avons appris à apprécier :
…[4 principes (détaillés en dessous)]
Première phrase du manifeste
Les artisans du logiciel sont donc des leaders dont le but est de pouvoir élever le niveau du code produit en aidant les développeurs et les parties prenantes autour d’eux à avoir une vision beaucoup plus qualitative.
Comme aujourd’hui il est très facile de mal coder (comprendre : de produire un code dégueu sans savoir ce qu’il fait réellement).
L’artisan logiciel s’oppose à cela et essaye d’orienter le développement vers un chemin plus propre, plus clair, « mieux fait », plus vertueux quelque part.
…[4 principes (détaillés en dessous)]
Phrase de fin du manifeste
C’est-à-dire qu’en recherchant les éléments de gauche, nous avons trouvé que les éléments de droite sont indispensables.
Les éléments de gauches sont obligatoires lorsque l’on est développeur.
Dialoguer avec le client, changer le besoin, maintenir un soft opérationnel, discuter avec ses collègues…
Pour autant, les éléments de droites sont les éléments vers lesquels on doit tendre en tant que software craftsman (même s’ils ne sont pas obligatoires au sens premier du terme) :
Un logiciel bien conçu, de la valeur ajoutée, une communauté professionnelle, un partenariat qui bénéficie à tout le monde…
Si les premiers éléments sont obligatoires, les seconds sont optionnels mais c’est sur ces derniers que se concentre le software craftsman.
Pas seulement des logiciels opérationnels, mais aussi des logiciels bien conçus.
1er principe du manifeste
Personnellement, il m’arrive parfois d’être fier du code que je produis.
Tu sais, c’est cette sensation de satisfaction quand tu regardes ta merge request avec fierté…
C’est exactement ce que le premier principe du manifeste des software craftsmans souhaite que tu éprouves.
Faire du code de qualité est important pour tout le monde.
Un code bien conçu c’est un code que tu n’as pas peur de toucher de peur qu’il t’explose à la figure 🙂
Et cerise sur le gâteau, c’est un code durable qui fait plaisir aux équipes qui travaillent dessus.
Pas seulement l’adaptation aux changements, mais aussi l’ajout constant de la valeur.
2ème principe du manifeste
Il ne suffit pas de changer une feature (s’adapter au changement).
Il faut aussi être capable d’ajouter de la valeur à cette feature en tant que développeur pour nous-même, participer au changement.
Le but, c’est de ne pas créer du code poubelle qui sera à refaire tous les 4 ou 5 ans.
D’autant que faire du code non-qualitatif a un coût que l’on paye tôt au tard…
Changeons de techniques pour coder !
Refaire du code de merde tous les 4 ans ne fait rêver personne.
Le legacy code on s’en passerait bien… Mais comment faire ?
En utilisant les outils du Software Craftsman et en cherchant toujours à rajouter de la valeur au projet.
Pas seulement les individus et leurs interactions, mais aussi une communauté de professionnels.
3ème principe du manifeste
En tant que développeur, on a la chance d’avoir avec nous une communauté de passionnés du code.
Aussi, tu trouveras toujours des gens amicaux pour t’aider à progresser.
Il ne s'agit pas simplement de coder au boulot pour coder.
Mais plutôt d’essayer de faire avancer le monde par le code que l’on produit.
C’est exactement ce qu’essaye de faire l’opensource d’ailleurs !
Les conférences, les blogs, Twitter…
Nous sommes une communauté super jeune mais une super communauté !
Continuons de nous apprendre des choses à chacun, comme ce que l’on fait ici.
Aidons-nous les uns les autres à progresser ❤️.
Pas seulement la collaboration avec les clients, mais aussi des partenariats productifs.
4ème principe du manifeste
Il faut aider les clients à comprendre ce que l’on fait pour eux afin qu’ils comprennent la réelle valeur ajoutée.
Les clients ne parlent pas technique.
Ils ne connaissent pas Docker.
En revanche ce qu’ils comprennent, c’est qu’une journée à répliquer l’infra sur Docker pour bosser en local, c’est seulement 2h d’installation pour chaque nouvel onboarding de développeur (au lieu de prendre une demi-journée à configurer les postes de travail).
Sans compter les bogues et autres soucis, le « chez moi ça marche pas »…
Ici, le client comprend l’utilité d’avoir un environnement local qui matche celui de la production ; c’est dans son intérêt !
Aidons les clients à comprendre que plus il y a de valeur dans notre travail, plus notre travail nous ressemble, plus nous mettons du cœur à développeur le produit…
Et plus le produit aura de la valeur.
Car non, la qualité n'est pas acquise par défaut et elle a un coût !
On n’est pas des robots.
Si on veut de la qualité, il faut y mettre les moyens.
Ce mouvement tend à ce qu’on ne soit pas « seulement » des créateurs de logiciel.
Qu’on ne soit pas de simples développeurs, codant ce qui correspond au besoin client tout en respectant le chiffrage, les délais : de fait le coût de l’application.
Non, le software craftsman pense à la qualité du code mais pas que.
Il pense à la qualité du logiciel créé, au fait qu’il soit stable, efficace, bien fait, que les développeurs sur le projet prennent plaisir à travailler avec.
La fierté du travail bien accompli rend le projet attrayant et qualitatif pour ceux qui travaillent dessus.
C'est un win-win pour les développeurs ET pour les clients.
Ainsi, les développeurs continuent de se former et tout le monde bénéficie de cet apprentissage.
Le client quant à lui, dispose de personnes motivées sur son projet dont le but est de tout mettre en oeuvre pour livrer qualitativement.
Génial non ?
Il s’agit aussi d’être pragmatique et d’avoir les pieds sur terre.
Va-t-on mettre en place des tests de non régressions visuelles avec BackstopJS si cela ne fait pas sens pour le client ?
Est-il obligatoire d’avoir un code coverage à 100% et de TOUT tester ?
C’est sans doute super pour des libs externes mais…
Est-ce que ça a du sens pour le projet de ton client ?
Probablement pas…
En tout cas il faut se poser la question.
On ne va pas passer la moitié du temps en hackathon ou en veille techno si cela n’a pas d’intérêt.
L’artisan du logiciel, il choisit les bons outils au bon moment et avec dicernement.
Les deux approches sont clairement liées entre elles.
Et pour cause :
De par sa création en 2008, un des signataires originels du manifeste Agile souhaitait qu’un des principes du craft y soit inclus.
Or, comme cela n’a pas été fait, le manifeste des software craftsmans a été créé à côté.
La distinction majeure que l’on peut faire entre agile et software craftsmanship, c’est celle-ci :
Agile est une méthodologie avec des process de management, là où le software craftsmanship met l'accent sur le code.
Tu peux y voir un lien avec l’Extrem Programming bien évidemment…
Notamment car les outils utilisés sont sensiblement les mêmes.
Le but d’agile c’est d’avoir des feedbacks rapides pour s’adapter au changement et avancer rapidement.
On parle d’agilité dans ce sens-là : on est réactifs.
Mais agile crée aussi du code legacy.
Les deux ne sont pas forcément incompatibles.
Moralité : ce n’est pas parce que ta méthode est agile que ton code est qualitatif…
Pour le coup, ces questions ne sont pas de moi mais issues d’une slide de Sandro Mancuso.
Voici comment séparer agilité et artisanat logiciel en deux questions.
Est-ce qu’on code le bon produit ?
Agile permet avec des feedbacks soutenus de très vite se rendre compte si :
Est-ce que le produit est bien codé ?
Pour le coup, le logiciel mentionné ci-dessus peut parfaitement répondre aux exigences fonctionnelles.
Pour autant, est-ce que…
Dans un premier temps, il faut garder à l’esprit que ceux qui ont écrit le manifeste du software craftsman sont des gens passionnés.
Et le développeur passionné : il aime s’améliorer, il aime apprendre, il aime coder, il veut en faire toujours plus…
Comme n’importe quel passionné dans n’importe quelle discipline finalement.
De fait, cela ne s’applique pas vraiment au monde professionnel.
On ne demande pas à tous les développeurs d’être passionnés par leur métier…
Et encore heureux.
Les design patterns, l’architecture des logiciels, l’utilisation de la mémoire ou des fonctions avancées d’un langage de programmation…
Beaucoup de développeurs n’ont pas besoin de tout ça pour exercer le job de tous les jours 🙂
Mais si toi tu veux devenir software craftsman car coder est ta passion, j’ai une bonne nouvelle.
C’est que l’amour du code propre et de faire des choses qualitatives va forcément te pousser dans cette voie.
En revanche j’ai aussi une mauvaise nouvelle.
Comme le software craftsmanship est un état d’esprit et non un but en soi, il n’y a pas vraiment de méthodes.
Un software craftsman autoproclamé ne vaut également pas grand-chose.
Mais voyons ensemble quelques préceptes à suivre pour se rapprocher du mindset d’artisan développeur 👇
Les bonnes pratiques, ce sont le fruit des erreurs des développeurs qui nous ont précédés.
Des centaines de développeurs sont passées par là avant toi et ont tracé la voie.
Ils ont commis des erreurs, on fait des choses de oufs, de choses pourries, en ont tiré des leçons, des conclusions.
Alors même si tous les développeurs ne sont pas d’accords sur les bonnes pratiques, on a quand même un consensus.
Les tests, la réplication des environnements de prod en local, l’intégration continue, l’utilisation des design patterns…
En 2021, on est à peu près tous d’accord là-dessus.
Alors apprends les bonnes pratiques de ton langage, de ton framework !
Si on parle de bonnes pratiques, je me sens obligé de parler de DevOps.
L’intégration continue, le déploiement continue, le linting, les tests unitaires, les tests e2e, la couverture de code…
Tout ceci fait aussi partie de la culture software craftsmanship.
La culture devops est très liée au mouvement des artisans développeurs car bon nombre des techniques et des outils utilisés par ces derniers sont également présents chez les devops.
Cette culture s’inscrit avant tout dans une démarche de qualité.
On choisit les bons outils pour un besoin précis dans le but d’améliorer le processus de livraison et la qualité du logiciel livré.
Si ça, c’est pas être software craftsman dans l’âme !
L’amour du travail bien fait, la recherche de la qualité, la transmission du savoir…
Ça aussi, ça rentre dans la culture devops.
Si tu veux en savoir plus je t’invite à écouter le podcast de Christophe sur le sujet.
On a tous des connaissances à partager et peu importe le domaine finalement.
Partager ses connaissances, ça aide réellement à les assimiler !
En devenant formateur en PHP dans mon ancienne école, j’ai dû aller fouiller dans des notions que j’avais oubliées…
Les interfaces, les classes abstraites, le principe de substitution de Liskov…
J’ai dû réviser tout ça pour faire mes slides et ça m’a été TELLEMENT bénéfique.
Autant pour moi que pour les étudiants.
Le partage de connaissance, c’est du gagnant-gagnant.
Peu importe le moyen tant que tu aides quelqu’un… 🙂
La transmission du savoir est une compétence importante du software craftsman, alors n’hésite pas.
Ah.
Et si tu as un problème avec le syndrome de l’imposteur, c’est ici !
Car ça ne doit pas t’empêcher d’aider les autres !
Si tu n’as aidé ne serait-ce qu’une personne, tu as déjà gagné.
Tous les outils qui aident à faire du code qualitatif finalement, sont les outils du software craftsman.
Et par outils, on entend pas seulement les langages de dev.
Car oui, les langages de programmation sont des outils.
Java n’est pas une religion, c’est un outil.
Tout comme XDebug ou Docker.
Tu peux tout à fait te spécialiser si tu adores la techno en question.
Mais utiliser Java pour tout (alors qu’un tout petit script Python aurait été plus simple et rapide), ça ne se justifie pas 🙂
Si jamais tu cherches à level-up tes skills de développeurs, voici quelques acronymes et de notions pour t’aider dans ton voyage.
J’en parle un eu plus dans l’article « code de qualité » et dans l’article dédié sur « comprendre SOLID« .
Tous les sujets n’ont pas encore été traités sur le blog, mais tu peux déjà consulter le guide pour comprendre les méthodes agiles.
* Merci à Benoit cité plus haut pour son aide dans la liste.
Comment devenir meilleur au volley ?
En jouant au volley.
Comment devenir meilleur en programmation ?
En programmant.
C’est pareil pour toutes les disciplines !
Pour le software craftsman, la théorie et la pratique sont obligatoires pour progresser.
Lire des livres, regarder des conférences, faire de la veille au sens largement finalement…
Tout ça c’est génial, car c’est en s’intéressant au développement qu’on devient un bon développeur.
Mais n’oublie pas de pratiquer, de coder, de t’amuser !
Comment ?
Tout est bon pour coder et prendre du plaisir !
La blockchain et la crypto t’intéressent ?
Regarde le Web 3.0 et renseigne-toi sur tout ça !
Même si tu n’en fais pas au taff, on s’en fout de ça, AMUSE-TOI !
Ce que le client veut, ce sont des logiciels qui marchent.
Et peu importe comment.
Le comment, ton client s’en fiche un peu pour peu qu’il puisse utiliser le logiciel…
Le « comment », c’est ton problème.
En tant que software craftsman, c’est à toi de trouver comment réaliser le logiciel de la meilleure de manière.
Donc…
Il faut arrêter de parler technique !
Parlons argent et parlons valeur ajoutée.
Et vendons-la à notre client.
Tu mets 1 semaine à créer un système qui :
La valeur ajoutée de ce truc-là ?
Les deux sections parlent de la même chose, et pourtant, la valeur perçue est différente.
Il faut se mettre à la place du client.
Le software craftsmanship permet de proposer à son client le bon outil, l’outil qui répond parfaitement à la problématique.
Et ce genre d’exemple, j’en aurais plein à te donner, c’est comme avec les tests…
On n’a pas le temps pour les tests.
Phrase qu’on n’entend à peu près par tout le monde.
Par contre…
On a tout le temps du monde pour gérer les bugs immédiats (qu'on fixe avec du code encore plus dégueulasse) à cause du code pas qualitatif et du legacy qu'on crée chaque jour.
Arrêtons le massacre !
La morale ?
Vends à ton client que la formation et la qualité du code lui seront bénéfiques autant à toi, qu’à lui 🙂
Personnellement, je n’ai pas beaucoup lu de livres de programmation jusqu’ici.
Pourtant, j’entends tellement parler des livres ci-dessous comme des références que :
* Moment honnêteté : Certains des liens que tu vois ici sont affiliés Amazon.
Décrit comme la référence des bouquins pour coder proprement et faire des choses qualitatives (la version en française existe est pas trop mal traduire, il parait !).
Le site refactoring.guru, je le trouve tellement bien fait que j’aimerais beaucoup m’offrir ce livre ! Et tiens-toi bien car les premières pages en PDF qui sont offertes gratuites vendent clairement du rêve.
Si les Design Patterns t’intéressent, n’hésite pas une seule seconde et commande-le !
Là on commence à discuter technique. Ça parle de refacto, de legacy, du design des applications en général… J’en ai entendu du bien de ce bouquin, c’est un incontournable aussi.
Pour moi qui ne fais pas assez de tests dans mon quotidien de dev (eh oui un de ces quatre je ferai un article dessus si ce n’est pas déjà fait), ce livre me donne envie plus que tous les autres.
Le TDD, c’est dans ma tête le Graal du code. Ce sera sûrement mon premier achat (c’est très personnel).
La vidéo de Sandro (juste en dessous) m’a tellement hypée que ça me donne clairement envie de livre son livre.
De plus, ce serait une superbe extension à la lecture de cet article… J’aimerais me considérer davantage comme un artisan qui rend le monde meilleur à chaque ligne de code.
Si c’est ton cas aussi… Tu sais quoi faire 🙂
Il y a peu de vidéos en français sur le software craftsmanship et c’est bien dommage !
Il en existe quelques-unes sur YouTube, mais voici les deux que j’aie pris le temps de regarder pour cet article.
Celle-ci de date un peu mais est toujours forte intéressante !
La phrase que je retiens de la vidéo :
Pour devenir un musicien d'élite, il faut s'entraîner pendant des années. Avec le code, c'est pareil.
Trop de développeurs se blâment de ne pas réussir à programmer parfaitement bien.
Mais on oublie souvent la règle des 10 000 heures, à savoir qu’il faut en moyenne 10 000 heures pour devenir un expert de quelque chose…
Et ça prend DES ANNÉES !
D’autant que tu le sais comme moi maintenant, la base du software craftsmanship, c’est la pratique.
La preview de la vidéo que l’on voit juste en dessous l’exprime plutôt bien d’ailleurs 👇
Si jamais tu ne devais regarder qu’une vidéo, ce serait celle-ci !
Rien que pour l’histoire où Sandro explique comment son « lead » a supprimé son code pour qu’il le refasse de 0 est à voir.
J’aurais tellement de choses à dire sur cette vidéo mais je vais essayer d’être bref !
We move the world, look around you, everything, there is a software behind it!
We are the people developing these softwares.
Soyez fiers de faire avancer l’humanité car c’est ce que nous, développeurs, faisons !
Être développeur, c’est vraiment un métier passionnant, tellement à apprendre, tellement à construire…
Tous les développeurs ne sont pas passionnés, en revanche tous les software craftsmans le sont !
Si tu attends que ta boîte te paye des formations, des livres, te prenne du temps pour que tu puisses regarder des conférences ou lire des blogs (comme ici).
C’est que tu n’as pas (encore) le mindset du software craftsman !
Pour conclure cette vidéo avant que je ne parle trop :
Quelqu’un sur Twitter a dit :
Se percevoir en tant qu’artisan engendre une nécessité de perfectionner sa technique continuellement.
https://twitter.com/j0rdan_m/status/1454788338154627073
Et ceci résume pour moi tout à fait l’esprit du software craftsmanship.
Que dire de plus ?
Des milliers de développeurs nous ont précédés et ont tracé la voie d’un code plus propre, plus juste, plus durable.
Notre rôle de développeur, est de suivre ces préceptes.
Non pas aveuglément, mais en s’en inspirant pour pouvoir devenir un meilleur développeur.
Je ne sais pas si coder est un art, mais ce que je sais…
C’est qu’en tant que développeur passionné, je ferais tout pour m’améliorer et progresser.
Alors devenir software craftsman ?
Pourquoi pas !
Car une chose est certaine : chaque mois, je deviens un peu plus un meilleur développeur en pratiquant.
J’aime aussi à penser que les softwares craftsman ne sont pas des gens prétentieux.
Il faut être humble : peu importe ce que tu sais déjà, il y a toujours quelque chose à apprendre, à maîtriser.
C’est mon avis.
Quel est le tient ?
Pour finir cet article sur le software craftsmanship avec une belle citation.
Choisissez un travail que vous aimez et vous n’aurez pas à travailler un seul jour de votre vie.
Confucius (il paraît)
J’aime bien cette phrase car c’est exactement ce dans quand je m’inscris…
Pour lire plus de contenu similaire dans le même thématique.
Merci beaucoup pour ton article très intéressant et détaillé.
Je voudrais me lancer comme développeur freelance cette année. Je vais bien analyser tous ça avant de me lancer.
Merci à toi pour ton commentaire !
Tu as 2 autres articles sur le freelancing dans la catégorie « senior » et un cours gratuit 🙂
Bonne chance pour ta nouvelle aventure