Accueil > The Software Craftsman : Professionalism, Pragmatism, Pride – Un livre pour qui ?
Steeven Ramaheridianina
27 février 2018

The Software Craftsman : Professionalism, Pragmatism, Pride – Un livre pour qui ?

The Software Craftsman : Professionalism, Pragmatism, Pride - Un livre pour qui ?

The Software Craftsman est un livre écrit par Sandro Mancuso qui a aujourd’hui un peu plus de 3 ans ! Si vous vous demandez si ce livre peut vous intéresser, et ce, même si vous n’êtes pas développeur, alors cet article vous aidera à répondre à cette question !

C’est un ouvrage très plaisant à lire, contrairement à de nombreux ouvrages techniques. Ce dernier est rédigé comme un récit. Il est donc très facile à lire.

 

Pourquoi vous parler de The Software Craftsman ?

Le but de cet article est de pouvoir vous faire un retour d’expérience et de partager mon ressenti sur la typologie de personnes qui devraient lire ce livre. En effet, l’idée n’est pas de vous faire un résumé, mais d’apporter une réelle plus-value sur les raisons de lire ce livre.

Néanmoins, si vous souhaitez avoir un résumé du livre, je vous partage une série d’articles écrits par un confrère Xebian. Vous pouvez également avoir une petite idée du contenu en regardant la table des matières.

 

A qui s’adresse ce livre ?

Comme je vous l’ai dit plus tôt dans cet article, The Software Craftsman traite certes de développement, mais il le fait sous un angle nouveau. Durant ma lecture, j’ai vécu 3 phases différentes qui m’ont aidées à déterminer qui pourrait ou plutôt qui devrait lire ce livre. Si je devais résumer chacune des phases en un seul un mot, ce serait dans l’ordre de lecture :

  • Wow
  • Vrai
  • Cool

Je vais donc tenter de vous expliquer mon point de vue à travers plusieurs exemples de personnes qui devraient se pencher sur l’ouvrage de Sandro Mancuso.

 

Les décideurs (chapitres 1 à 3 et 12)

1. Software Development – 2. Agile – 3. Software Craftsmanship – 12. The Cost of Low Morale.

Les 3 premiers chapitres ont été pour moi les plus marquants. Ce sont ceux qui m’ont fait dire : “Il faut absolument que tout le monde lise ça !”. Oui ! Toutes les personnes qui travaillent dans le secteur de la création logicielle devraient le lire, et tout particulièrement les décideurs.

Ces chapitres nous montrent qu’être développeur est un vrai choix de carrière, que cela devrait être reconnu et valorisé ainsi par tous ! On y trouve également l’histoire de la méthode Agile. Sandro nous ramène aux origines de l’agilité, tout en expliquant ce qu’il faut mettre en œuvre pour être Agile.

Même si le chapitre 12 n’est pas dans la continuité des 3 premiers, il n’en reste pas moins un chapitre que les managers devraient lire et digérer. Ce chapitre permet de mettre en lumière ce que coûte vraiment certaines attitudes qui peuvent nuire à la productivité d’une entreprise. Si certains développeurs semblent posséder une mauvaise attitude, c’est qu’il y a peut-être un mauvais management sous-jacent.

Chers décideurs, si vous lisez cet article, lisez ces 4 chapitres et partagez votre ressenti !

Les nouveaux (chapitres 4 à 8)

4. The Software Craftsmanship Attitude – 5. Heroes, Goodwill and Professionalism – 6. Working Software – 7. Technical Practices – 8. The Long Road.

Dans ces 5 chapitres, Sandro revient sur les différentes étapes de sa carrière. Il y raconte notamment qu’il a toujours été passionné, qu’il a toujours pris les devants pour élever sa carrière là où il le voulait. C’est ce qu’un Craftsman doit faire : ne pas être spectateur mais acteur de sa carrière. Néanmoins, même si on essaie de toujours faire de notre mieux pour satisfaire les besoins de nos clients, il faut parfois savoir prendre du recul et savoir dire non ! Le chapitre 5 en est le parfait reflet. Durant sa carrière, Sandro a eu l’occasion de travailler dans plusieurs sociétés. Il nous raconte des situations réelles dans lesquelles il a du convaincre les équipes d’utiliser les bonnes pratiques de développement. Il nous rappelle que la construction d’une carrière de Software Craftsman prend du temps et que pour y parvenir, il faut choisir ses expériences avec minutie.

Je dois avouer avoir eu quelques difficultés à lire ces chapitres. Tout était pertinent mais le “wow effect” des 3 premiers chapitres avait disparu. J’étais d’accord avec ce que je lisais, c’est pour cela que j’ai choisi le mot : vrai. Je me dis que c’est sans doute parce que j’avais déjà connaissance de ces notions et que je suis déjà convaincu, que j’ai ressenti cette baisse de régime.

Si ces notions sont connues des développeurs expérimentés, je pense que les personnes qui ne sont pas encore sensibilisées au Craftsmanship devraient lire ces chapitres. Cependant, le fait qu’il raconte son expérience sur comment amener les bonnes pratiques dans un contexte réel reste intéressant pour tous.

Quelques notions :

Pour n’en citer que quelques-unes, voici certaines notions abordées dans ces chapitres :

  • Pratiquer les katas
  • Se socialiser
  • La technique du promodoro (celle-là était nouvelle pour moi et me paraît intéressante dans l’absolu)
  • Savoir dire non
  • Travailler avec le legacy
  • Les pratiques TDD, Pair-Programming, Refactoring.

 

Les ressources humaines (chapitres 9 à 11)

9. Recruitment – 10. Interviewing Software Craftsmen – 11. Interview Anti-patterns

Mesdames et Messieurs les RH, ces chapitres sont pour vous !

Comme l’indiquent les noms de ces chapitres, il est ici question de recrutement. Comment l’aborder du point de vue des développeurs, mais aussi comment attirer de nouveaux profils de passionnés ? Je ne m’attendais pas à lire quelque chose sur la manière d’aborder un entretien pour un Artisan du logiciel, mais je suis content que Sandro ait traité le sujet et raconté son expérience.

Nous savons que le recrutement prend du temps. Mais ici, Sandro nous révèle pourquoi les fiches de postes qui sont le plus largement diffusées, ne sont pas du tout pertinentes pour recruter les bons profils. On y apprend pourquoi les “buzz words” ne sont pas forcément les bons “match words”. Plus important encore, comment filtrer efficacement pour recruter selon nos réels besoins ?

Pour les recruteurs, Sandro donne des techniques sur la manière de conduire efficacement un entretien, comme le mind map par exemple. On y voit aussi les éléments que les développeurs devraient prendre en compte lors d’un entretien :

  • Est-ce que le recruteur utilise une liste de questions prédéfinies ?
  • Est-ce qu’un autre développeur est intervenu pendant le processus de recrutement ?
  • Combien de personnes sont intervenues pendant l’entretien ? Une ou plusieurs ?

Enfin, il y a des techniques d’évaluation des candidats qui me semblaient intéressantes mais qui en fin de compte semblent désuètes et non pertinentes. En voici quelques exemples :

  • Les énigmes
  • Les questions d’algorithmiques
  • Coder sur papier ou tableau blanc

Il est souvent complexe pour vous, recruteurs, d’attirer les bons profils. Essayez de vous mettre dans la peau d’un développeur, de comprendre quelles sont ses attentes, ce qui le motive, les challenges qu’il souhaite relever.

 

Les développeurs (chapitres 9 à 16)

13. Culture of Learning – 14. Driving Technical Changes – 15. Pragmatic Craftsmanship – 16. A Career As a Software Craftsman.

Nous avons déjà abordé les chapitres 9 à 11, mais ils sont aussi intéressants du point de vue des développeurs. Quant aux chapitres suivants, ce sont de vrais outils concrets sur comment s’améliorer, comment aider les autres à s’améliorer dans un contexte professionnel et comment attiser la passion au sein d’une équipe.

Ces chapitres correspondent à ma phase cool et en effet, il y a une partie conjointe avec les Ressources Humaines. C’est d’ailleurs pour cette raison que j’ai apprécié cette partie.

L’ouvrage de Sandro aide les générations futures de développeurs à s’améliorer en partageant son expérience. J’ai particulièrement ressenti cette volonté de transmission dans ces chapitres. C’est ici qu’il nous donne des outils pour être meilleur dans différents domaines et aspects de notre vie professionnelle. On pourrait citer notamment :

  • les BBL (Brown Bag Lunch, ou BBS Brown Bag Session dans le livre) : un partage de connaissances durant le temps du déjeuner.
  • les Revues de code en groupe : un rassemblement autour d’un code identifié.
  • les Pet-Project : un projet personnel juste pour expérimenter une technologie, un Framework, une méthodologie.

 

Conclusion sur The Software Craftsman

Merci à Sandro pour ce bel ouvrage !

Un livre écrit pour tous les développeurs souhaitant devenir ou découvrir ce qu’est un Software Craftman. Il s’adresse aussi à tout ceux qui travaillent avec des développeurs et qui souhaitent en savoir plus sur leur job.

Je le recommande vivement à toutes personnes entrant dans une des catégories citées plus haut.

Une des valeurs de ce livre est le partage. Partager, diffuser l’information est un moyen de contribuer à l’amélioration de chacun.
Si vous êtes convaincu, alors n’hésitez pas à partager et à en discuter !

 

 

Nos autres articles
Commentaires

D’un côté le craftmanship, qui incite à voir la valeur du code pour ses qualités intrinsèques. De l’autre, le Lean, qui incite à voir la valeur du code à travers les services rendus au client. Le Lean indique qu’il appartient au métier d’innover. Le craftsmanship indique que le code produit devrait être excellent, et innovant. Les 2 approches sont-elles conciliables ? Si le Lean parle aux entrepreneurs, quid du craftsmanship ? N’avons nous pas finalement en IT 2 communautés de développeurs, que l’on pourrait croire irréconciliables, visant des enjeux diamétralement opposés ? Quel est ton avis sur l’ambiguïté de nos métiers, qui sont en fait totalement différents selon les contextes ?

Super intéressante réflexion !

Je pense que ce que tu décris comme étant le Craftsmanship, n’est que la partie “Connaissance” que j’expose dans mon article sur la triforce.
Ce serai réducteur de dire qu’un Craftsman ne s’intéresse qu’au code. Le Craftsmanship n’est pas que la “beauté” du code ou de l’architecture.
D’ailleurs dans le titre du livre il y a pragmatisme et professionalisme, il ne faut pas perdre de vue qu’ en tant que professionnel nous devons répondre à un besoin.
En ce sens, ça rejoint la valeur du Lean que tu exposes. Et le pragmatisme pour moi serait justement le gardien de l’excès de zèle lorsqu’ on écris du code.

Du coup je ne pense pas que les 2 approches soient opposées. Je pense qu’un Craftsman doit posséder la triforce répartie de façon homogène, être capable de voir ce qui se fait autour et tirer le meilleur en fonction du contexte.

Par contre je te rejoins pour dire que selon les contexte dans lesquels nous nous trouvons, c’est parfois compliqué de prendre du recul, d’être pragmatique et de choisir la solution la plus efficace, sans succomber à notre passion qui nous pousse parfois à faire des choses trop complexes.
C’est dans ces cas là, qu’avoir une équipe qui partage les mêmes valeurs peut aider à nous ramener à la raison.
Mais notre métier reste le même : aider nos clients à atteindre leurs objectifs du mieux qu’on peut avec les outils que nous avons à disposition et surtout en n’oubliant pas notre rôle de conseil !

(Si tu n’a pas lu l’article sur la triforce, je t’invite à le faire ☺️: http://bit.ly/2tNEoz5 )

Laisser un commentaire

Restez au courant des dernières actualités !
Le meilleur de l’actualité sur le Cloud, le DevOps, l’IT directement dans votre boîte mail.