Comme vous avez pu le constater, je suis un grand fan de la NDC depuis des années car c’est une conférence qui a su allier l’excellence des présentations techniques et les talks d’artisans expérimentés qui viennent partager leur longues expériences, le tout dans un contexte très technos Microsoft pour ne rien gâcher. Cette année j’ai loupé Oslo parce que j’ai préféré au DDD exchange qui avait lieu au même moment et parce qu’il y avait pour la première fois une version Londonienne.
Donc pour ceux que cela intéresse, c’est tout aussi bien en termes de contenu et d’organisation que la version Norvégienne, c’est un peu plus près et peu être aussi dans un contexte Londonien un peu mieux connu (encore qu’à Oslo tout le monde parle anglais et on est jamais vraiment perdus ;-).
London Excel building
La conférence se passe à l’Excel qui est un nouveau -énorme- centre de conférences et d’évènements à Londres.
Note pour plus tard, le bâtiment est tellement énorme, qu’il peut être intéressant de se renseigner avant sur la location précise à l’intérieur ou se passe l’évènement 
J’étais tout content avec mon hotel à 100m de l’entrée du centre de conférences mais c’était sans compter que la NDC se passe à l’autre bout du bâtiment, 1 km plus loin…
Cette année, je ne ferais pas de posts live de chaque session car cela n’a qu’un intérêt limité et que c’est une tache plus ou moins difficile suivant les sessions. J’essayerai donc de faire du live tweet (sur @rhwy, au cas où hein…) et posterai un petit récapitulatif de la journée dans la mesure du possible.
here we go
Note: les petites notes qui apparaissent sous cette forme en italique, sont des commentaires perso.
Dan North Keynote – Jackstones : the journey to mastery
Dan est quelqu’un de formidable à écouter car inspire beaucoup de sympathie et est très enthousiaste et quoi qu’on puisse en penser, c’est important et cela se ressent quand vous écoutez quelqu’un.
Dan nous parle de software craftmanship mais à sa manière…Cela part du principe qu’en discutant avec un certain nombre de personnes, la vision du craftman us, n’est pas forcément la même que cela de l’anglais, ni que celle de l’allemand. Du coup il faudrait peut être regarder un peu plus loin. C’est dans ce sens qu’il s’intéresse à cette quête de la maitrise.
Il nous donne différents exemples dans différents contextes et métiers de ce que représente cette maitrise. Il n’oublie pas de nous rappeler que les exemples, tout comme les modèles, sont des projections et mauvais par essence mais qu’il peuvent être utiles de manière restreinte pour une illustration (rappelez vous, tous les modèles sont mauvais, mais certains peuvent être utiles).
Par exemple pour un pianiste de concert:
The concert pianist
Ces qualités sont d’ailleurs pour un compositeur, qui en plus d’avoir toutes les qualités de l’instrumentiste de concert doit savoir en plus les techniques de composition ainsi qu’une connaissance approfondie de l’histoire de la musique.
Notes: L’analogie est intéressante, mais surtout ce qu’il l’est encore plus à mon sens c’est cette distinction entre apprentissage d’un coté et pratiques d’un autre. Cette distinction est importante car l’un ne va pas sans l’autre mais on ne les distingue pas assez souvent.
Dans nous rappelle qu’on parle souvent de pratique (practice, practice, practice!) et il en faut pour automatiser un certain nombre de gestes. C’est vrai dans tous les métiers, l’excellence ne s’obtient qu’à partir du moment où les gestes de base sont automatiques et où l’esprit est libre pour s’intéresser à des choses plus pointues ou créatives. Néanmoins, par rapport à notre métier, Dan nous interpelle pour savoir si on a déjà vraiment répété 2 fois le même code. Non bien sur. C’est pour ça que en plus de l’aspect manuel de la pratique, il y a l’aspect apprentissage. On ne répète jamais exactement 2 fois le meme code, par contre on apprend à chaque foi. Sans complètement automatiser notre geste, cette répétition, nous donne à chaque fois une meilleure compréhension du problème et des solutions.
Une série d’autres exemples s’en suit avec par exemple le joueur de Hockey sur glace. Cela parait idiot, mais avant de pouvoir devenir un bon joueur, ou joueur tout court, il faut déjà maitriser parfaitement le patin à glace.
Notes: j’aime beaucoup cette illustration car elle se rapproche bien de ce que l’on pourrait avoir dans notre métier. Avant de pouvoir devenir un professionnel du développement vous devez savoir programmer ainsi qu’un certain nombre de choses, et ça vous pouvez l’apprendre à l’école. Cela montre bien que ce que vous faites à l’école est juste l’ensemble des bases pour commencer dans le métier mais que quand vous sortez de l’école comme un débutant qui est prêt à apprendre le métier, pas un architecte-chef-de-projet-développeur-presque-senior-dans-2-ans…
Nous arrivons à la fin sur le sujet du talk, les jackstones et les origamis. Dan nous parle d’un origami -un modèle de pliage plus ou moins en forme d’étoile- qu’il essayait de faire étant petit sans y arriver. Beaucoup plus tard, en étant adulte, il est retombé dessus et alors qu’il pensait y arriver beaucoup plus facilement -puisque adulte- il s’est arrêté exactement au meme endroit. Ce qui était finalement normal, puisqu’il n’avait eu aucun apport supplémentaire de connaissances ou de pratiques sur le sujet entre temps! Puis il est revenu dessus un peu plus tard en faisant et refaisant le modèle, jusqu’au moment où il a vu la lumière. A partir tout s’enchaine et il arrive au bout de la construction. Puis il en fait d’autres, et encore, et encore.
Dan North – happy with JackStones ;-)
Notes: Cette illustration de “j’ai vu la lumière” est très intéressante car c’est un point essentiel dans l’apprentissage. Elle représente en fait le moment où l’on a acquis suffisamment de connaissances dans un sujet particulier pour être capable d’aller plus par soi même, de comprendre de manière autonome comment les éléments peuvent se combiner et en quelque part de pouvoir commencer à être créatif.
Dans une deuxième partie nous montre sa vision de l’approche de la maitrise. On reste quand même proche du software craftmanship, puisque l’on parle des roles de l’apprenti, du compagnon et du maitre.
As an apprentice
Une note importante dans tout ce discours, est bien sur que tout cela est une réflexion sur les rôles de chacun mais qu’en aucun cela n’enlève l’obligation de connaitre ses bases (théories, languages, XP, TDD, SOLID, etc…) et qu’il s’agit bien des bases à connaitre en tant qu’apprenti pour pouvoir aller plus loin.
Une vision importante du compagnon à retenir, c’est qu’en tant que compagnon, vous êtes déja un modèle pour d’autres, et donc que c’est à chacun de définir la projection de soi même que l’on veut faire parvenir aux autres. Il ne faut pas se contenter de montrer son compte github pour montrer ce que l’on a fait/peut faire mais bien d’avoir son espace dans lequel tout est maitrisé et dans lequel on indique la direction de comment on voudrait que les autres nous voient, ce qui nous intéresse et ce que l’on veut mettre en avant, bref, ce pourquoi on voudrait être reconnu.
Bref, une keynote très sympa et enjouée, très instructive par rapport à l’échange d’idées et la confirmations de choses personnellement ressenties. Merci Dan!
