Mathieu Eveillard (Page 2)

Mathieu Eveillard

More issues

Coach ou consultant ?

Dans l'industrie du développement logiciel, ces termes sont peu ou pas définis. Nombre de personnes les emploient indifféremment, tandis qu'ils me semblent désigner des modalités d'intervention distinctes. Comme beaucoup, je suis venu au coaching "par glissement", parce que mon expertise technique était

Implémenter un Design System

Figma définit un Design System comme "un ensemble de blocs de construction et de normes qui aident à préserver la cohérence visuelle des produits et des expériences". Cela va du ton employé, reflet des valeurs et de la personnalité de la marque, à la définition du moindre espacement.

On ne coache pas par la force

Dit autrement, on ne coache pas quelqu'un qui ne veut pas être coaché – principe de base, commun à tous les métiers de l'accompagnement. La contraposée est intéressante : de la même manière que démarrer une thérapie, c'est avoir fait 50% du chemin, vouloir être coaché,

Un Bounded Context "utilisateur" ?

Quelle drôle d'idée : on m'a toujours dit que "User", c'était tout sauf un Bounded Context, la fausse bonne idée, le truc à pas faire. Alors quoi ? Partons du problème : la modularisation, c'est bien, mais comme le soulignent Mathias Verraes et

Je ne vous vendrai pas de formation "Clean Code"

Titre volontiers provocateur, mais on ne peut plus sérieux. Pourquoi ? Parce que se former au Clean Code en 2 ou 3 jours, c'est comme lire un dictionnaire ou l'API de NodeJS de A à Z : personne ne fait ça, parce que ça n'a pas

Pourquoi embaucher un coach à temps plein n'est pas une bonne idée

Disons-le très simplement : oui, faire coacher son entreprise, c'est un investissement. Voici la réalité en chiffres : * Un coach indépendant se paie au bas mot 1 000€ par jour ; * Un profil similaire salarié se paie environ 90K€ par an (salaire brut), soit 140K€ pour l'entreprise (salaire chargé)

Monorepo mon Amour

Écrire sur les monorepo en 2024, c'est arriver un peu après la bataille. Ou pas, vu que je rencontre tous les jours des équipes développant des Single Page Applications dont le front-end et le back-end font l'objet de 2 repositories distincts. Dès lors, la moindre fonctionnalité

Architecture Decision Record

Documenter ou ne pas documenter ? Que documenter ? Pour qui ? Ces questions sont à l'origine de débats enflammés au sein des équipes agiles. Courage, fuyons et n'abordons ici qu'un aspect très précis de la question : un aspect qui, à ma connaissance, fait plutôt consensus. L&

Tout ce que vous avez toujours voulu savoir sur le refactoring (sans jamais oser le demander)

La définition du refactoring ne souffre aucune ambiguïté : le refactoring consiste à modifier une implémentation sans modifier le comportement associé. Aussi, quand une nouvelle fonctionnalité mène à un refactoring préalable, on gagne à distinguer le temps du refactoring, qui procède à iso-fonctionnalités, du temps de l'implémentation de la

Property-based testing

PBT, pour les intimes. J'étais familier du concept depuis un moment déjà, mais je n'avais pas réussi à l'intégrer à ma pratique quotidienne du développement ; cela a enfin changé. Mais déjà, qu'est-ce que le PBT ? Considérons quelques exemples : * Une fonction random({ min,