Clément Bouillier, Expert et formateur sur le DDD et CQRS, et passionné de F#
Clément Bouillier, Expert et formateur sur le DDD et CQRS, et passionné de F#
Retranscription du Podcast « Clément Bouillier – Code Insider »
César : Clément, ravi de te recevoir pour ce podcast !
Clément : Bonjour, merci à toi de m’inviter pour parler Crafts et plein d’autres choses.
César : Eh bien, je vais faire comme pour les autres invités et te laisser te présenter, pour comprendre un peu plus ton parcours.
Clément : Alors, je travaille dans l’informatique depuis une vingtaine d’années. J’ai commencé en tant que développeur dans une société de services sur du .NET, un peu par hasard. J’étais accompagné par un expert technique qui en même temps épaulait une petite équipe sur une TMA*, avec un chef de projet qui commençait à mettre en place les prémices de l’agilité. Et je pense que ça m’a bien marqué sur le reste de ma carrière.
Après j’ai évolué sur des missions longues puis en internes. J’ai ensuite déménagé à Lyon où je suis retourné en société de services pour un temps, avant de devenir indépendant. Depuis, je suis freelance et je fais des missions d’accompagnement d’équipe sur des choses variées. Je n’aime pas que la technique.
César : Cela me donne envie de te poser une première question. Tu as parlé de l’accompagnement d’une personne un peu plus expérimentée, est-ce que tu pourrais nous en dire plus sur ce rôle de mentor ? Qu’est-ce que ça a changé dans ton apprentissage ou dans les bonnes pratiques ?
Clément : Ce terme de bonnes pratiques est ressorti rapidement. Mon mentor était Antoine Guet. Il avait deux ans de plus d’expérience que moi et était l’expert technique de TMA. Il m’a poussé à chercher des pratiques pouvant améliorer l’architecture, la testabilité, etc. À l’époque dans le monde .NET, on avait un framework de test unitaire peu utilisé. Avoir des tests unitaires à l’époque, en 2004, était vraiment rare.
César : Surtout sur de la TMA, qui est par essence, pas le meilleur projet sur lequel faire de la qualité.
Clément : *rire* Alors c’était de la TMA sur des choses assez récentes, que mon entreprise avait fait l’année dernière. Enfin, c’était quand même avec une architecture bien ancienne : des data sets typés, des procédure stockées monstrueuses de 600 lignes. Je me rappelle de ce premier chiffrage que l’on m’avait présenté, c’était une fonctionnalité. Je devais rajouter une colonne dans le tableau de reporting financier. Juste pour introduire une colonne dans un tableau, il nous a fallu 20 jours. C’était tellement mal fait qu’avec mon expert technique, on cherchait comment nous aurions pu le faire à notre sauce, avec les bonnes pratiques.
César : Tu veux dire qu’avant même l’apprentissage des bonnes pratiques, il y a d’abord cette réflexion autour de la simplicité ?
Clément : Je pense que les bonnes pratiques, il faut les entendre en termes d’efficacité, aussi par rapport à ce qui est demandé et où l’on veut aller. Je me rappelle avoir eu une discussion chez des gens travaillant chez M6 qui construisaient des sites pour les émissions. C’était du jetable, une fois la saison terminée, le site disparaît. Il faut se demander si on a le même déroulé sur un projet qui doit durer 20 ans que sur un court projet.
César : Je vois. Et donc en te posant ces questions, quelles sont les premières bonnes pratiques que tu mets en place ?
Clément : Sur ce projet-là, à part organiser le code, nous n’avons pas fait énormément de bonnes pratiques. Pourtant, à l’époque, ce n’était pas si courant. On ne parlait pas d’architecture de couche, même si aujourd’hui, on a des termes plus évolués. L’architecture de couche, c’est le béaba à la sortie des écoles maintenant. Et donc c’est surtout sur ça que l’on a travaillé, ça doit faire un peu old-school. *rire*
On a pas mal regardé ce qu’était un test unitaire. À chaque fois que l’on écrivait une ligne, on cassait l’autre. La volonté d’avoir quelque chose qui nous permette d’avancer sereinement nous motivait. Le souvenir que j’en ai, c’est l’exact inverse de l’approche du TDD.
César : Tu parlais du TDD, quand est-ce que tu as entendu ce terme pour la première fois et que tu l’as utilisé ? Dans quel contexte ?
Clément : Alors j’ai d’abord fait des tests unitaires avant de me mettre au TDD. J’ai fait l’amalgame entre les deux pendant un certain temps, puis j’ai compris que faire les tests en premier était plus intéressant pour documenter les choses. J’avais encore pas mal de contraintes, et tout ce qui était dépendant, j’avais encore pas mal de mal à le mettre en place dans les tests. Après, sur les dix dernières années, j’ai commencé à vraiment comprendre que faire du TDD dès le début sur son architecture, ça change totalement la vie.
César : Alors justement, cette montée en compétences, elle se fait à travers des meetups, des dojos, des rencontres, etc. ?
Clément : Ce que j’aurai aimé, c’est de le faire en live avec des personnes. Hélas, c’était plutôt moi qui poussais les autres à le faire tout en apprenant de mon côté. Même si je ne les maitrisais pas très bien à l’époque. J’espère que mes collègues ne m’en veulent pas trop. *rire*
César : Remarque, c’est le meilleur moyen d’apprendre.
Clément : En fait, j’ai mieux cerné le DDD après plusieurs Coding Dojos, notamment quand je suis arrivé à Lyon. En s’entrainant encore et toujours, c’est venu. Au début on fait un sujet minuscule, ça peut paraitre nul, mais en fait on se focalise sur la pratique, sans résoudre un problème. En-tout-cas, dans mon apprentissage et dans ma pratique, les Coding dojo sont essentiels.
César : Et c’est que ce tu recommanderais à des profils plutôt juniors, que ce soit pour débuter ou pour des projets persos ?
Clément : Carrément. Principalement parce qu’on le fait ave quelqu’un. J’ai rencontré plein de monde en allant aux Coding Dojos, en participant à la communauté Crafts. Dont Victor, mon associé aujourd’hui. Et donc j’ai fait pas mal de pair programming avec plein de gens différents, pour aussi voir si l’on arrive à transmettre ce que l’on sait. Pas forcément en tant que formateur, mais en tant que personne qui a appris d’elle-même. Je recommande à 100 % les Coding Dojos.
César : Justement, tu parles de Victor avec qui tu as créé ta boîte, est-ce que tu pourrais ne parler un peu plus ?
Clément : Bien sûr. Alors, la première boite qu’on a créée avec Florent Pellet et Emilien Pecou. Tous les trois indépendants, Emilien commence à me parler d’un projet en biologie axuqels on pourrait être intéressés. On a commencé quelque chose et au bout de quelques mois, on a structuré et décider de monter quelque chose. On avait même réussi à le vendre tous les mois, en échange du fait leur présenter le projet pour avancer ou non avec eux. Pour nous, on allait dans le bon sens, mais la partie métier trouvait que l’on n’était pas en train de faire le logiciel qu’ils attendaient. On a donc arrêté l’affaire-là mais on a compris qu’il fallait que l’on travaille ensemble. Notre première boite est donc Hacker Jobs, qui est une boite de formation autour du TDD, BDD, CQRS, etc.
César : Justement en termes de formation, comment est-ce que cela se structure ? C’est plutôt pour toi une incitation, ou cela peut aussi s’adresser à des profils plus expérimentés ?
Clément : Dans nos formations, on fait énormément de pratique. C’est-à-dire que l’on va faire des Coding Dojos sur deux jours. Et nous, formateurs, on passe en mob par trois, pair, ou juste en prenant le clavier et en essayant d’orienter la conversation. Il n’y a pas de contraintes sur le niveau à l’entrée. Le BDD est fait pour débutant, mais trois autres personnes nous ont rejointes dans l’aventure et nous pensons à proposer un autre module, avec des pratiques plus spécifiques. Comme ça, on peut proposer deux modules de DDD.
Par exemple du Refactoring ou faire du DDD sur Legacy. Parce que oui, c’est bien de savoir le faire from scratch, mais dans la vie de tous les jours, comment-est ce qu’il peut s’utiliser ? J’ai aussi fait une nouvelle formation l’année dernière : Refactoring derrière BDD. Comme toutes nos formations ont une approche du BDD, ça peut gêner. On leur demande d’écrire d’abord d’un test pour exprimer ce qu’ils veulent, et ensuite de le développer.
César : Justement, tu parlais de CQRS, est-ce que tu peux en parler un peu plus ?
Clément : Alors la formation, c’est une formation de 2 jours. Pas obligé d’avoir un background solide dedans, mais si l’on est complètement novice et que l’on ne maîtrise que le langage, ça peut être difficile. Mais globalement, les personnes qui y participent ont déjà rencontré cette problématique et ne savaient juste pas mettre un nom dessus. Donc on a une introduction au DDD, et ensuite, on essaye d’implémenter. Parce qu’au final CQRS ce n’est que des patterns tactiques de DDD. Le DDD ayant deux approches, une approche stratégique et une partie plutôt tactique. Pour celle-là, c’est plutôt de savoir comment on s’y prend et comment on l’implémente techniquement. On se focus dans l’implantation CQRS de DDD dans notre formation. On ne fait pas de CQRS sans DDD non plus.
Nous avions déjà vu des conférences sur CQRS sans que soit évoqué le DDD. Et cela me gênait, parce c’est comme si l’on parle de micro-services et qu’on oubli le DDD. J’aime bien l’élément que donne mon associé Emilien Pecoul dans un article, c’est que le stratégique est au final toujours un peu utile dans plein de contextes différents. Et typiquement tous ces patterns stratégiques du DDD sont très utile pour faire une approche microservice. Foncer la tête baissée dans les microservices en se disant « ok, j’ai un monolithe, je vais le transformer en micro-services en prenant chacune des tables », c’est la catastrophe assurée.
César : Comment est-ce que tu décrirais le DDD à quelqu’un qui ne connaît pas le concept ?
Clément : C’est toujours difficile de répondre à cette question. J’aurai tendance à dire que c’est une approche pour aborder un problème métier avant tout. C’est mettre l’emphase sur les aspects stratégiques du DDD et pas de savoir ce que c’est qu’une entité, qu’un agrégat, etc. C’est du détail technique. Pour moi, le DDD va être une première grille de lecture face au problème rencontré. Le problème est souvent orienté métier, avec tout ce qui gravite autour. C’est vraiment une approche qui permet de prendre du recul, avant d’être une approche purement technique.
Sur l’aspect du problème métier, oui c’est un peu comme un cyber bullet qu’il faut ressortir à chaque fois. Après ce n’est pas forcément le cas dans l’implémentation. Le DDD stratégique va nous permettre de se dire « Sur ce domaine-là, c’est juste de la gestion de référentielle, est-ce qu’il n’y a pas un outil qui existe déjà ? ». Puis on va définir ce qu’est le domaine essentiel, le cœur du sujet. C’est ça que je trouve très pratique avec le DDD. Et désolé, c’était pas du tout court comme définition du DDD. *rire*
César : Ce que je trouve intéressant, c’est le lien logique entre ce que tu appelles le pattern stratégique, la partie tactique. C’est finalement toute une méthodologie qui part du concept même du DDD, jusqu’à la mise en place qui est indissociable des micro-services et donc pour toi du CQRS. Quelle est ton approche si demain, tu arrives sur un projet, from scratch ou en refonte, et que tu peux mettre en place ces pratiques-là ?
Clément : La première chose à faire, c’est savoir quel est le problème métier que l’on veut résoudre. Ne pas se jeter tout de suite sur les solutions, mais rester dans l’espace problème comme on l’appelle. C’est-à-dire analyser le métier pour bien voir si les problématiques sont multiples, s’il y a des interactions entre elles, qui sont les prescripteurs, s’il y a différents clients, est-ce qu’ils interagissent entre eux, etc ?
Il faut regarder beaucoup plus loin que le cahier des charges et commencer à se faire des films. Il faut aller chercher m’essentiel de l’outil. Voir aussi si dans un logiciel, il y a de la complexité accidentelle et/ou essentielle. Le premier objectif du DDD c’est de trouver quelle est la complexité essentielle à adresser, de ne pas prendre trop de chose autour, ne pas commencer à rajouter de la complexité accidentelle avec tout un tas de choix technique fait dès le début.
César : Si je comprends bien, tu fais référence à une forme d’over engineering, d’utiliser des choses complexes qui n’ont pas forcément d’utilité au projet ?
Clément : Oui c’est ça. Je vais prendre un exemple tout simple. Tous les choix techniques que l’on fait vont nous apporter des contraintes à un moment donné. Le mieux c’est de les reporter à plus tard. Si je reprends l’exemple du premier projet que l’on avait fait avec Florent et Emilien, on avait fait des présentations au client, sans jamais avoir codé une ligne d’infrastructure ou de base de données. Donc on n’avait codé que du métier. Et quand on lançait l’application, on croisait les doigts pour que ça ne plante pas en plein milieu de la démo.
On a travaillé sans persistance pendant un long moment, parce que c’est un détail d’implémentation. Cela nous a permis de nous concentrer sur le côté métier et de pivoter sur certaines choses, alors que ce pivot métier n’aurait peut-être pas été fait si rapidement. Notamment à cause des ralentissements dût à l’adaptation des couches techniques d’accès aux données. On aurait été ralenti par un ensemble de dépendances (framework, outils, bases de données, etc.).
César : Le fait de les reporter, ces contraintes, est-ce que ce n’est pas un manque de prévision ? Et plutôt essayer de prévoir les problèmes qui peuvent subsister par la suite ou les changements ?
Clément : Effectivement, peut-être. Après ne pas le faire ne veut pas dire que l’on n’en a pas discuté ensemble. On va toujours se demander si cela va tenir d’un point de vue stockage ou d’espace. Si on aura besoin de répartition de données etc. Toutes ces choses-là n’interdisent pas d’identifier les risques au début, mais pour autant ce n’est pas la peine de se mettre ça en plus à chaque étape. On parle souvent de faire un sprint du début où l’on pose les bases techniques, mais je n’en suis pas fan. Ça ne veut pas dire qu’il ne faut rien faire et voir ce qui se passe après, mais c’est plutôt avoir des pratiques qui nous amènent dans de bonnes directions.
C’est un peu comme l’agilité, avec un chemin dont on connaît l’objectif, le même qu’un planning de cycle en V, et au fur et à mesure de l’évolution, on ajuste le chemin voire même l’objectif. Et le fait d’avoir pris différents détours pour arriver à des objectifs, cela nous permet de prendre de nouveaux bagages. Pour moi, c’est la même chose appliquée que la technique. Le fait de se dire « je ne fais pas tous les choix techniques dès le début ».
César : Est-ce que ça ne serait pas un peu de Cargo Cult derrière l’idée de se dire que l’on a la besace nécessaire pour créer le projet et que c’est seulement avec l’évolution du projet que l’on voit si cela fonctionne ou pas ?
Clément : Ah oui complètement. Pour moi, quand on parle de bonnes et de meilleures pratiques, j’ai un peu du mal. Tout simplement parce qu’elles sont bonnes dans un contexte précis, pas dans l’absolu. Se dire « je créer une boite, je me fais mon framework et à chaque projet qui arrive, je déroule la même manière de faire en se basant toujours sur les mêmes outils », je me dis qu’il y a un potentiel problème énorme.
César : Tu as des exemples de ce genre de pratiques chez des clients ? Certaines personnes disaient qu’il fallait utiliser cette méthode parce que c’était la meilleure réponse possible. Mais on se rend compte que ce n’est pas forcément ce qui fonctionne le mieux.
Clément : J’ai des exemples assez anciens mais qui se voient encore, c’est par exemple que la base de données est sur le serveur Oracle, ou SQL. Florent pourrait la raconter, mais dans une boîte, ils étaient partis sur de l’event sourcing dans une table. La solution fonctionnait très bien, mais elle avait fait sauter les DBA, puisqu’elle contenait un tera octet de données. C’est dommage, peut-être qu’au final ils seraient partis sur une base SQL et par simplicité, de prendre le SQL serveur. Mais prendre en pré-supposé un serveur SQL c’est un peu bourrin.
Dans le même esprit, on était dans une appli avec une recherche full texte. On s’est jeté sur la recherche full texte de SQL serveur. Et on est passé totalement à côté. Comme c’était en 2008, peut-être que les outils comme ElasticSearch n’étaient pas aussi matures et connus qu’aujourd’hui. Mais la recherche full texte du serveur SQL c’était une catastrophe, il n’y avait rien de bon. Il ne valait mieux pas faire le projet si on se mettait d’emblée de telles contraintes.
César : Justement, sur tous ces projets, est-ce qu’il y a cette notion de réflexion en amont et au fur et à mesure du projet. Ça fait écho à une critique constante sur l’agile que l’on voit apparaître, et qui est reprise par des chefs de projet. Ils critiquent la notion de Scrum en faveur du No Estimate et du Kanban. Quel est ton regard après toutes ces expériences, sur le cycle en V, l’Extreme Programming, l’agilité de manière générale ?
Clément : Je suis d’accord avec le fait que Scrum a réussi à populariser une approche un peu plus itérative. D’être un peu moins dans le cycle en V, qui a prévu à l’avance le chemin et d’arriver à l’ajuster au fur et à mesure. Mais on passe totalement à côté des pratiques techniques portées par l’eXtreme Programming. Pour moi, ces techniques sont indissociables de l’agilité. Je vois pleins de développeurs ne plus vouloir de l’agilité à cause d’un ras-le-bol des Scrum masters, de leurs petites réunions redondantes. Toutes les pratiques qui sont dans l’eXtreme Programming pour apporter du feedback le plus vite possible. La notion de feedback est indispensable dans l’agilité. Il ne faut pas faire des choses dans un tunnel et à la fin se rendre compte que l’on a perdu la moitié de son temps pour quelque chose qui n’est pas bon. C’est vraiment la force de l’agilité.
Après si l’on parle de Kanban, de se mettre plus dans le flux et de tendre vers du No Estimate, je trouve qu’il y a quelque chose d’intéressant. C’est le lead time et le cycle time, c’est-à-dire le fait de sortir des choses. Et plus l’on sort de choses, plus on a un flux constant et pas empiler les choses jusqu’à créer des patchs partout. J’aime bien ces approches qui essayent de fluidifier et de ne pas oublier la technique. J’avais vu à une conférence quelqu’un qui avait sorti une blague sur l’XP et Scrum. Comme quoi XP était trop compliqué et réservé aux développeurs tandis que Scrum était plus simple. Je trouve que l’on est sorti de cette diabolisation du développeur et que cela rattrapera la mauvaise aura du Scrum auprès des développeurs.
César : Justement de l’eXtreme Programming pur, lorsque l’on regarde ton profil LinkedIn, on voit que tu en as fait dans ta première mission, est-ce que c’est une méthodologie que tu as très vite retrouvée ? Ou finalement, c’était moins constant dans ta carrière ?
Clément : Effectivement, j’ai eu pas mal de missions où je suis arrivé avec un contexte de travail préétabli. J’ai rarement été dans un projet from scratch où l’on pouvait mettre en place ce que l’on voulait. J’ai souvent été sur du Legacy, avec une équipe et des pratiques existantes. Faire changer quelques pratiques et essayer de tendre vers d’autres, ça oui je l’ai fait, mais ce n’est pas simple. Il faut apporter des faits qui montrent que cela a un intérêt. Simplement le fait de faire davantage de feedbacks, j’ai trouvé ça compliqué. Les développeurs aiment bien théoriser, modéliser des choses complexes, donc faire vite quelque chose pour avoir du feedback, ce n’est pas facile avec tout le monde.
César : Justement, par rapport à ça, puisque Super Indep a été le prescripteur, le client et le développeur, quel regard est-ce que tu portes là-dessus ? J’imagine que tu as implémenté ces pratiques-là dans ce projet, c’est quoi ta manière d’appréhender maintenant avec ce retour d’expérience ?
Clément : Alors, avec ce retour d’expérience, effectivement, nous étions trois à développer dessus, donc pas une grosse équipe. Ce n’est pas comparable à une équipe où l’on est 7 ou 8 avec plusieurs équipes. Cependant, l’idée était de se focaliser sur le produit, pour qu’il trouve ses utilisateurs. Au début, nous n’avions pas d’utilisateurs, il fallait le créer, le vendre et qu’il soit en développement constant pour continuer à le vendre. Donc quelque part, si on faisait trop de choses, ça ne servait à rien.
On était en permanence en train de rationaliser, de se demander si ce que l’on faisait allait être utile ou non, essentiel. Clairement, au début nous faisions des choses à la main. Sur les pratiques de développement, à trois, on n’a pas vraiment utilisé de Back Log comme on peut le voir dans des grosses équipes. On savait vers quoi on allait, en priorisant le feedback permanent. Les mises en prod aussi, c’était tous les jours, dès que l’on avait quelque chose, on le livrait directement au lieu de le laisser de côté. On était vraiment dans une approche comme l’eXtreme Programming, avec évidemment le plus possible de pair programming et du mob programming.
On essayait de se retrouver tous les trois pour des sessions de mob, alors que nous n’étions pas en temps pleins sur ce projet. L’idée était d’avoir un collective ownership dans le code, d’avoir des tests quasi-systématiques. Peut-être pas sur tout mais on avait fait un simulateur de cotisation sociale où il n’y avait pas de tests sur le front. Du coup, l’idée c’est de piocher un peu partout. Et pour moi, c’est ça l’idée du Cargo Cult. De se dire « ok j’ai une trousse à outils, je sors tout ce qu’il y a dedans » alors que tout ce qu’il me faut, c’est une tapette à mouche. On a souvent été forcé de l’employer et je pense qu’il serait bon de le réadapter même en internet ou dans des grosses entreprises. De ne pas se forcer à industrialiser le bazar.
César : Cela me donne envie de te poser une autre question, puisque tu as aussi dit avoir fait du F# en back. Qu’est-ce que tu peux me dire sur la programmation fonctionnelle et pourquoi ce choix-là ? Vous le faisiez de manière perso sur des petits projets, ou sur un projet plus conséquent ?
Clément : *rire* On a commencé le F# en Dojo avec Florent, à galérer comme des fous sur un sujet donné et de lancer des tests au bout d’une heure et demie. Donc c’était à peu près ça notre niveau de débutant en F#. Et moi, plus largement, la programmation fonctionnelle m’a amené à me dire « Mince, je croyais que j’étais arrivé à l’architecture, aux bonnes pratiques, etc. ». Je pensais être arrivé à un stade où je comprenais ce qu’était la boîte à outils. Et j’ai découvert des choses via le F#, qui ont tout remis en question.
Rien que le premier point, la nomenclature, on définit des données des fonctions qui manipulent des structures de données. Un peu comme faire du lego. C’est comme la ré utilisation par héritage en objet, ce n’est pas une bonne chose. J’avais fais cette erreur en construisant des hiérarchies de classe trop violent. Et je me suis rendu compte que la composition avait beaucoup plus davantage. Je trouve que le fonctionnel m’a remis dans une recherche, dans une nouvelle façon de faire. C’est le premier point qui est intéressant. L’approche de la formation fonctionnelle avec des types algébriques permet de définir une personne, un type ou un autre, tout en ayant à la compilation un certain nombre de vérification qui assure que l’on traite bien tous les cas.
Il y a pas mal de sécurité qui sont apportés par le compilateur. Et par rapport à Super Indep, on se dit que peut-être on allait essayer avec ça, en F#. Au final on est très content de notre choix, du rendu en termes de visibilité, de simplicité de code.
César : Justement, ça va être ma dernière question. Il y a un engouement assez fort à travers les gens qui sont un peu fana des bonnes pratiques autour du F#. Comment est-ce que tu expliques, qu’il y est une si faible utilisation dans les grands groupes, de programmation fonctionnelle et de F# ?
Clément : Sur la programmation fonctionnelle, je vois que Scala a pas mal décollé, même si certains diront que c’est à moitié fonctionnel. Ça a bien école notamment avec tout ce qui est Big Data, et des outils qui le mettaient en avant. Alors, pourquoi F# n’a pas décollé ? Eh bien, pour l’avoir essayé et tenté de l’introduire, on me rétorque souvent les mêmes choses. « Non, il y a trop peu de personne sur le marché, c’est un trop gros gap, il y a trop de choses à apprendre » etc.
Après, certaines entreprises n’ont pas de mal à recruter non plus dans ce domaine donc bon. Effectivement, je pense qu’être dans les premiers à le faire permet aussi d’attirer des profils volontaires. J’aurai tendance à dire que dans les grandes sociétés, les DSI des grosses boîtes s’alignent tous entre eux. Si l’un dit qu’il va utiliser ça, alors les autres vont faire pareil, ils ne se différencient pas beaucoup. Si tu restes dans la masse, tu arrives à évoluer. Alors que si tu démarques et que tu te vautres, ça se voit beaucoup. C’est donc peut être lié aux décisions des grosses boîtes que le F# ne bouge pas.
César : Ils ont envie de limiter ce risque-là et de s’orienter vers des profils plus traditionnels.
Clément : Oui, et le fait de prendre la même chose que les autres. C’est se dire, s’ils se vautrent, on se vautre tous. Et c’est dommage. Comme je te disais, j’ai toujours eu tendance à prendre des risques, au grand dam de certaines personnes peut-être.
César : C’est en lien avec le Cargo Cult. Si on fait ce que l’on nous indique sans jamais réfléchir plus loin, on ne changera jamais les pratiques. Eh bien Clément, grand merci pour cette heure de discussion, on a parlé de plein de sujets différents. Je rappelle aussi pour nos auditeurs, Hack Your Job pour les formations. Et Super Indep pour les services pour les micro-entreprises. On peut te retrouver sur Linkedin et sur Twitter.
Clément : Exactement, je suis ouvert à ceux qui veulent discuter. Aussi, on a prévu d’avancer sur certains projets avec Hack Your Job, qui pourraient intéresser les développeurs, donc à suivre. *rire* Et encore merci César, et à très bientôt !
*TMA : Tierce Maintenance Applicative
Retrouvez Clément Bouillier :
Retrouvez nos Podcast :
