NewCrafts, la conférence incontournable pour les craftsmen passionnés et investis, était de retour le mois dernier pour son édition 2019.
Nous avons assisté aux deux jours de la conférence et vu d’excellents talk (comme d’habitude !) On notera une forte tendance cette année autour du Domain Driven Design et de la programmation fonctionnelle, avec beaucoup de présentation autour de l’éthique du développeur, la psychologie des relations interpersonnelles et du travail en équipe (mob programming).
Voici les talks qui nous ont le plus marqués :
KEYNOTE : The one with the compiler always wins – Ulrika Malmgren – @ulrikama
Ulrika a commencé sa carrière en tant que testeuse de logiciel et s’est laissée emporter par le mouvement agile pour devenir coach.
Mais à chaque fois qu’elle a coaché une équipe son constat est le même : « Le cycle de feedback est trop long ». La mise en oeuvre de pratique telle que BDD mettait trop de temps à faire effet.
C’est à ce moment qu’elle décide de se concentrer sur le développement. En tant que développeuse elle voit très rapidement le résultat de son travail et ses choix.
Le développeur décide ce qui est possible de faire et comment le communiquer. C’est l’expert ; sans elle le logiciel n’existerait pas !
Mais c’est aussi une grande responsabilité. Nous devons à nos product owners des explications sur les bonnes pratiques de développement logiciel.
En tant que développeur le pouvoir de choisir l’approche est le nôtre et les choix doivent être faits ensemble en tant qu’équipe.
Le mob programming est une pratique très efficace pour éviter que des individuels prennent des décisions seuls – l’équipe décide ensemble le moment d’appuyer sur le bouton deploy.
Enfin, elle a abordé l’aspect moral de notre métier de développeur. Est-ce que le code que vous êtes en train d’écrire, va être utilisé pour des activités en accord avec vos valeurs ? Vous êtes aussi responsable de prendre le poste qui correspond à vos intérêts et valeurs.
Test && commit || revert – Xavier Detant – @xdetant
Dans ce talk, Xavier nous a fait découvrir le TCR et ces origines.
Le TCR est une variation du TDD où le développeur va écrire le test, écrire le code qui fera passer le test et exécuter le test par un script en une commande. Ce script s’assure que si le test passe, le code est commité. Autrement, le code est supprimé.
Donc, si tout va bien nous avons un test et une implémentation. Sinon on repart de zéro et le test doit être réécrit ; une méthode assez radicale et sans doute frustrante.
Pourquoi le faire ? Kent Beck s’est demandé comment une centaine de développeurs pouvaient mieux travailler ensemble sur un single repository tous sur une même branche (trunk-based development)
C’est ce qui lui a fait essayer cette approche. L’objectif de TCR est à la fois de réduire le feedback loop entre le test et l’intégration avec le reste de l’équipe et aussi de créer des commits qui ont le moins d’impact possible sur la branche de développement.
En effet cette approche va forcer à faire des petits commits et Xavier a fait le parallèle avec le jeu de limbo : « How low can you go », ou jusqu’à quel point pouvez-vous réduire la taille de vos commits ?
Enfin Xavier est revenu sur l’importance du feedback rapide et fait référence à une matrice démontrant les différents types de feedbacks qu’on peut avoir classés par leur rapidité et force :
Le TCR est en haut avec TDD sur les feedbacks fort et rapide – feedback automatisé par un ordinateur. Et le pair programming qui est un feedback rapide mais doux, des humains qui collaborent ensemble.
Xavier nous invite à tester cette approche et insiste sur le fait d’essayer de faire tout ce que vous détestez. Ça risque de vous surprendre.
Talking with Tech Leads – Patrick Kua – @patkua
Selon Patrick, devenir Tech Lead n’est pas une évolution de carrière d’un ingénieur, c’est un changement de rôle. Et on est rarement préparé à ce changement.
Patrick a décrit les différents rôles techniques dans une organisation ainsi que leurs compétences. Le Tech Lead se trouve entre le rôle de manager et celui d’ingénieur, nécessitant un mélange de toutes ces compétences.
Il a ensuite parlé des surprises et challenges d’un Tech Lead. Il doit gérer le bruit de l’extérieur de l’équipe et le côté incertain. Il n’y a souvent pas une seule bonne réponse.
Gérer les aspects humains, identifier des archétypes, comment les gens réagissent dans des situations différentes, font aussi partie des défis d’un Tech Lead.
Et il doit trouver une structure de support, des gens avec qui il peut échanger sur ces problèmes et valider ces hypothèses.
Être un bon Tech Lead, c’est diriger selon la situation – dire, vendre, participer ou déléguer. Enfin l’ingénieur passé Tech Lead doit se transformer d’un créateur à quelqu’un qui donne l’effet multiplicateur à son équipe (From maker to multiplier)
Rescuing legacy – from legacy to TDD – Johan Martinsson – @johan_alps
Dans cet atelier nous avons travaillé en binôme sur un code kata.
Il existe déjà pas mal de katas sur le thème refactoring legacy, mais ce qui rend ce kata unique est comment le code est couplé avec la base de données : plusieurs appels de base de données imbriqués dans des conditionnels. L’objectif est donc d’abord de mettre en place des tests pour ensuite refactorer le code vers un état où la pratique de TDD est possible.
Le kata existe en plusieurs langages, je vous invite à l’essayer : https://github.com/martinsson/Refactoring-Kata-Lift-Pass-Pricing
Bourdieu’s Social theory and our work in tech – Romeu Moura – @malk_zameth
Romeu Mourra nous présente le travail du sociologue Pierre Bourdieu et comment il influence les relations interpersonnelles dans le travail en entreprise.
Selon Pierre Bourdieu, les relations interpersonnelles ne sont jamais neutres. Il y toujours un rapport de hiérarchie, bien souvent invisible.
En effet, tout, que ce soit le statut, notre manière de paraître, nos origines, notre genre, notre aisance à nous exprimer, notre âge, notre apparence, notre ancienneté etc, tout nous permet inconsciemment de nous comparer les uns aux autres et d’établir à partir de là une hiérarchie invisible et informelle entre les personnes, et de par-là un rapport de dominant-dominé.
Le problème étant que dans cette relation inégalitaire, la personne en situation de force n’a souvent pas conscience de son propre pouvoir sur l’autre. Or, d’après Bourdieu, c’est justement car la personne en situation de force n’a pas conscience de son pouvoir, qu’elle va inconsciemment le renforcer : l’autre personne va alors être obligée de s’adapter à la situation, de faire des concessions pour ne pas déranger ou ennuyer son « supérieur », ne pas le contredire, douter de lui etc.
Parallèlement, tout cela va permettre à la personne en situation de force de conserver son énergie, se concentrer sur ses objectifs et renforcer son pouvoir encore plus, tout en lui donnant l’illusion d’une situation égalitaire et juste.
Le seul moyen pour Bourdieu d’éviter cette situation est, pour le « dominant », de prendre conscience de son emprise sur l’autre, afin de pouvoir recentrer la communication et faciliter la situation du « subordonné ».
Slim Down Diet & TDD – Dorra Bartaguiz – @dorrabartaguiz
En s’inspirant du régime « Slim Down Diet », Dorra Baraguiz fait un parallèle entre les raisons qui nous font retarder le démarrage d’un régime et celles de nous mettre au TDD : le poids des habitudes et la difficulté d’être le premier (et seul) à faire du TDD. Elle nous expose dans un quick-talk quelques conseils pour se mettre au TDD rapidement avant l’été :
- Commencer par de petites stories et augmenter progressivement leurs taille et complexité.
- Réduire et fractionner la taille des stories pour faciliter les alternances du tests au code.
- Essayer de viser la qualité plutôt que la quantité.
- Évaluer et chiffrer la complexité des stories.
- S’attendre à ressentir de la frustration au début, mais en progressant les obstacles disparaîtront peu à peu.
- Réduire les nuisances qui empêchent de faire du TDD (tests trop longs, manque de librairies utilitaires, code illisible, etc).
- Avoir conscience de sa propre paresse et de la tentation d’arrêter de faire du TDD.
- Faire au moins une fois par jour des katas pour s’entraîner aux outils du TDD et gagner en expérience.
Four Languages from Forty Years Ago – Scott Wlaschin – @scottwlaschin
Que peut-on apprendre des langages inventés dans les années 1970 ?
Dans ce talk, animé par Scott, nous avons fait un tour d’horizon des langages et paradigmes qui ont influencé le design des langages d’aujourd’hui.
Il commence par nous poser une question : « quel est l’outil que vous utilisez pour faire du bricolage ? Uniquement un marteau ? Et pour le développement d’un logiciel ? » Il est important d’utiliser les bons outils pour un bon travail.
Et c’est une bonne chose d’en maîtriser plusieurs. Il fait le constat que les langages les plus populaires aujourd’hui sont des dialectes de la même chose (C-like)
Dans SQL nous déclarons des expressions qui facilitent le refactoring. Prolog consiste à déclarer des « facts » et des « rules » qui rendent les programmes très cohérents et utiles pour faire de la programmation par contraintes. Dans ML nous trouvons le type inférence (très récemment introduit dans Java), l’immutabilité par défaut et un système de typage composable.
Il a enfin présenté son langage préféré, Smalltalk, où tout est objet, avec une syntaxe minimale, facile à utiliser – tout se passe dans un IDE où on n’a même pas besoin de sauvegarder les fichiers, car ce n’est pas considéré comme une tâche de développeur !
The Passions of Programming – Kevlin Henney – @kevlinhenney
On attend de plus en plus que les développeurs soient passionnés. Mais qu’entend-on par passion ?
Kevlin revient dans son talk sur les différents sens du mot « passion » :
Étymologiquement, passion viens de pathos, la souffrance. Elle sous-entend un désir incontrôlable.
À l’opposé, on a le mot anglais « dispassion » que l’on peut traduire par « calme, détachement », c’est-à-dire être libéré des biais émotionnels, faire preuve de logique.
De manière générale, produire du code peut être résumé par « codifier du savoir », plutôt que de « produire » un objet physique. Coder peut également désigner un processus d’apprentissage : à la fois nous apprenons à nos programme, et nous gagnons en compétence. Coder revient également à un processus de communication, en traduisant le besoin de nos clients en instructions pour un processeur. Coder, est également une activité très créative de résolution de problèmes, mais la créativité implique beaucoup d’émotions, et rend les développements moins logiques et rationnels que prévus.
Enfin de nombreuses entreprises exigent de la passion afin de masquer une culture du burn-out en se focalisant exclusivement sur les performances individuelles comme gage de succès. Pourtant, apprendre à travailler en équipe est un moyen efficace de gagner en productivité grâce à l’intelligence de groupe (surtout si les équipes sont diversifiées)
Kevlin Henney résume ainsi par : « Le développement logiciel doit aller plus loin que juste la stack technique, le full-stack doit inclure aussi bien le monde entier que les gens utilisant le logiciel. »
Un développeur passionné doit être capable aussi bien de créativité et de rationalité, de concentration et de communication. Il a aussi bien besoin de compétences individuelles que collectives. La culture d’entreprise doit avoir conscience de ces multiplicités de la « passion » et doit également laisser de la place au bonheur et à l’humanité au sein de ses équipes.
Estimates or No Estimates, Let’s explore the possibilities – Woody Zuill – @woodyzuill
Woody a popularisé la mob programming et il est également impliqué dans le mouvement « no estimates ».
Dans son atelier, il nous a demandé d’estimer le temps pour remplir une grille de 3 par 3 avec les chiffres de 1 à 9. Dans la réalisation, nous étions assez proche de notre estimation. Pour l’itération suivante, les chiffres de la dernière ligne verticale doivent faire un total de 21. Cette fois-ci, les estimations ont commencé à beaucoup diverger entre les participants.
Les itérations suivantes ont introduit d’autres complications qui donnaient des estimations encore plus différentes.
Woody termine pour clarifier sa vision du « no estimates ». Ce n’est pas un commandement, mais peut-être que les équipes devraient se poser la question de la valeur apportée par les estimations, ainsi que la manière dont elles vont être utilisées.
Your Brain doesn’t have a Fix Flag – Sara Vieira – @nikkitaftw
Le syndrome de l’imposteur, en particulier, et les problèmes de santé mentale, en général, sont de plus en plus fréquents chez les jeunes développeurs.
Le cœur du problème est que la santé mentale est tue dans le monde du travail, en résultant un sentiment de honte et une exacerbation des symptômes. Afin de briser, ce silence Sara Vieira nous parle dans son talk de son expérience personnelle.
Le « syndrome de l’imposteur » est l’impression d’être incapable de tout accomplissement personnel. Quoi que l’on fasse, on n’atteindra jamais le niveau d’exigence requis et quelqu’un le remarquera bientôt.
Les personnes atteintes ont tendance à se dévaloriser et à compenser en sur-travaillant. Le feedback des autres est généralement positif mais ne parvient pas à rassurer la personne pour autant, qui attribuera sa réussite davantage à ses efforts qu’à ses compétences, ce qui le renforcera dans son impression « d’imposteur », et le poussera à travailler d’autant plus.
Ce syndrome et le surmenage associé à l’état de stress permanent finissent souvent par provoquer des troubles physiques, telles que des attaques de panique : tremblements, douleurs au ventre, sentiment de perte de la réalité, et surtout l’impression d’être en train de faire une crise cardiaque.
Paradoxalement, ces attaques de panique peuvent finir par provoquer l’effet inverse du syndrome de l’imposteur : la personne n’arrive plus à travailler, se renferme sur elle-même et va réduire son investissement au minimum afin de gérer son stress, et tombe en dépression.
À la fois le syndrome de l’imposteur et les crises de panique peuvent être gérées efficacement par une prise en charge thérapeutique légère. Suivant la phase dans lequel la personne avec un syndrome de l’imposteur se trouve (surmenage ou dépression), les conseils peuvent diverger:
- À une personne en phase de surmenage : se renseigner sur le niveau de qualité du travail attendu (et s’y tenir !), ne pas essayer de faire de la sur-qualité même en cas de dépassement. Prendre conscience que faire des erreurs est normal, que tout le monde doute, et que tout les développeurs apprennent tout au long de leurs carrières, même lorsque l’on est « senior » et qu’il s’agit de savoir de base.
- À une personne en phase de dépression (légère) on conseillera une prise en charge thérapeutique et de sortir de sa zone de confort, d’accepter de nouveaux challenges (participer à des conférences, voyager, accepter des missions-challenge…) pour accumuler les victoires et le sentiment « d’être capable de… »
En conclusion
2019 fut encore une excellente année pour NewCrafts. Nous sommes repartis avec des étoiles plein les yeux et des bonnes pratiques plein la tête.
Les vidéos seront bientôt disponibles.
Vivement l’année prochaine !