Je sais qu'une peer review est très utile pour trouver les bugs avant la prod mais c'est pas pour autant que je suis à l'aise à l'idée que d'autres me jugent…
Michel vient de soumettre une PR qui réécrit du code que j'ai pushé il y a quelques jours, sans qu'on en parle avant et ça me met en rage
Nos blameless post-mortems n'ont rien de blameless... le fautif se fait dégommer par le CTO à chaque fois ! Ça donne plutôt envie de se couvrir qu'autre chose…
Ce code, il marche très bien comme ça, je ne crois pas du tout que le bug vienne de là, commence plutôt par regarder dans ton code...
Lorsque qu'un product manager qui ne connaît rien au code vient me poser des "questions bêtes", au mieux je lui réponds froidement, au pire, je l'ignore
On me propose de prendre en charge ce nouveau projet, mais ça me paraît impossible, je n'ai pas les compétences pour le réussir.
Au fond, à part moi, c'est tout de même une équipe de bras cassés... je dois repasser derrière systématiquement !
Je leur avais dit pourtant il y a 2 semaines qu'on pouvait pas implémenter ça comme ça et maintenant je ne vais pas manquer de leur répéter pendant une semaine
Encore une spec qui change, c'est sympa l'agile mais ils pourraient réfléchir un peu avant d'écrire les US !
Je n'aime pas trop la nouvelle façon que tu proposes d'appliquer, pourquoi est-ce qu'on ne ferait pas comme on a toujours fait ?
Tiens, il y a une nouvelle fonctionnalité trop sympa à implémenter (et en plus ça sera visible !)... allez hop, comme je suis le plus sénior, je me l'attribue
Je suis lead dev et j'ai l'impression parfois que Slim n'ose pas venir me voir au lieu de perdre 2 jours à essayer de trouver la solution tout seul sur StackOverflow
Si le chef l'a dit... de toute façon c'est lui qui en portera la responsabilité...
Nos rétrospectives ne servent à rien, on n'y aborde jamais les vrais problèmes en profondeur
Je le sens mal parce qu'à l'issue de cette réunion avec le métier, on n'a pas osé mettre le problème vraiment sur la table
↑ 1 ou 2 symptômes familiers ? ↑ Notre proposition, garantie sans bullshit, c'est :
Le programme de formation+coaching qui te fait devenir un·e bien meilleur·e développeur·se sans te faire écrire une ligne de code !
Comment ? En développant les soft skills et en renforçant la sécurité psychologique dans ton équipe (startup ou grand groupe), vous devenez tous plus productifs et plus épanouis.
C'est le rapport qu'on a au code et aux autres codeurs.
En mettant le développement personnel au service du développement informatique, on remet notre égo à sa juste place, au service de l'exigence et de la créativité, mais pas en travers de la collaboration.
Et les bénéfices sont nombreux :
C'est la base de tout. Google l'a identifiée comme le facteur n°1 de performance de ses équipes tech, et c'est pas sans raison.
Lorsqu'on ne passe plus son temps à gérer les égos ou à parler des faux problèmes, on peut enfin se concentrer sur la création de valeur.
Quand on doit se réinventer individuellement et collectivement, bien se connaître est devenu une compétence indispensable.
Pour travailler sur de larges bases de code et avec de nombreuses parties prenantes, il faut savoir communiquer sainement.
Pour nous, maîtriser la psychologie du code revient à intégrer 7 principes, ou croyances fortes, dans sa propre pratique.
J'en ai fait par le passé et je vais continuer d'en faire. Et c'est vrai pour n'importe qui d'autre. Donc, à moi de rester sympa avec moi-même et les autres.
J'écris du code, mais il ne me définit pas. Sa remise en question par d'autres ou moi-même (refactoring, bugfix) n'est pas une remise en question de qui je suis.
Je sais que je ne suis pas parfait et que n'importe qui a des choses à m'apprendre. Et je ne prends pas de haut ceux qui en savent moins que moi.
Il y a de nombreuses façons de voir et de faire les choses et rarement une vraiment meilleure. J'explore la richesse des autres points de vue.
Je reconnais que le changement (spécifications, contexte, outillage) est permanent. Je m'y adapte et je ne juge pas des choix passés hors contexte.
Je joue le jeu du long terme en sollicitant, développant et protégeant les membres de mon équipe. Notre travail n'est pas qu'une suite de sprints perso.
Je réduis le bruit (politique, personne qui parle le plus fort, qui a le plus haut "grade", habitudes, passé, préférences, peurs). J'ose poser le vrai problème pour y trouver des solutions.
Certains de ces principes peuvent paraître évidents, et ils ont été construits dans ce but.
Tout le sujet est justement d'aller creuser en profondeur ce qui se joue chez nous dans chacune de ces directions en explorant de nombreux modèles et protocoles de neurosciences, de psychologie et de philosophie (liste détaillée dans la FAQ).
Une équipe qui a développé un langage commun de compréhension de sa dynamique personnelle et inter-personnelle et a renforcé ses compétences softs vit mieux son quotidien. Le travail y est plus épanouissant et plus productif.
Notamment, elle a en main les outils pour régler les problèmes suivants :
On n'arrive pas à se parler des vrais problèmes, on met des sujets sous le tapis. Nos rétrospectives ne vont pas assez profond et ne remplissent pas leur rôle.
Je ne sais pas faire de bons feedbacks. Je suis parfois maladroit, j'ai peur de vexer l'autre ou bien j'ai du mal à les formuler clairement.
Je me sens désengagé, je ne trouve plus de sens dans ce que je fais.
J'ai une tension avec une personne en particulier. Deux personnes dans mon équipe sont en conflit.
Je n'arrive pas à lâcher prise sur des décisions extérieures sur lesquelles je n'ai pas le contrôle. Et parfois, je ne fais pas ce que je pourrais faire.
On me parle d'émotion, mais qu'est ce que ça peut m'apporter ? Je ne suis pas sûr de comprendre l'intérêt de développer mon intelligence émotionnelle.
J'ai du mal à accepter mes erreurs. Je ne suis pas à l'aise lors des peer reviews de mon code.
Je n'arrive pas à communiquer avec les personnes du produit (ou les non-tech), ils ne comprennent pas nos enjeux et nos limites. Il y a souvent de la tension dans nos échanges.
Je n'arrive pas à dire ce que je veux ou ce que je pense. Et du coup, je suis souvent frustré ensuite.
Parfois je m'agace, je suis tendu, j'accumule de la tension ou du stress et cet état m'empêche de fonctionner correctement.
Je suis tendu lorsqu'on refactore mon code. Je suis vexé quand quelqu'un fait une remarque sur du code que j'ai écrit, je le prends personnellement.
Les manières pratiques de développer la sécurité psychologique pour devenir plus performants ensemble.
Qu'elles soient en autonomie et 100% à distance ou sur-mesure en présentiel, les formules incluent de l'accompagnement individualisé avec un coach professionnel.
Les notions transmises sont complètement adaptées au contexte d'une équipe technique, avec des exemples pratiques du quotidien.
Pour une équipe de 5p. *
Pour 1 journée avec max 12 p.
* La version "Autonome" peut aussi être souscrite en solo (750 € HT) et le participant aura au total 2h de coaching individuel.
** Des sessions individuelles de 1h, à distance, additionnelles peuvent être ajoutées pour 250 € HT de l'heure.
Des réductions sont prévues pour les particuliers, les indépendants, les devs actifs dans l'OSS et les achats en quantité. Nous contacter.
Nous avons tous les deux une double-casquette codeur + coach professionnel qui nous a permis de concevoir un programme conçu sur des bases neuro / psycho / philosophiques mais sur mesure pour des devs.
Ingénieur de l'École Centrale Paris, j'ai commencé à coder avant l'âge de 10 ans (avec QBasic !) et j'ai toujours continué depuis plus de 25 ans, pour mon travail (dans des grosses entreprises, dans des startups ou en freelance) ou comme hobby (par intérêt et curiosité). Entre temps, j'ai accompagné de nombreuses équipes pour les aider à mieux fonctionner, et je me suis formé au coaching individuel afin d'accompagner psychologiquement des individus dans leur transformation (notamment des CTOs, devs, scrum masters, PO ou directeurs IT).
Ingénieur de formation (ECAM Arts et Métiers), j'ai fait un petit détour par le code durant quelques années. Je suis ensuite revenu à ma passion principale, l'accompagnement des humains dans leur développement professionnel ou personnel. Lors de divers programmes de transformation des organisations, j'ai accompagné des équipes de développeurs dans l'amélioration de leur fonctionnement.
Nous sommes développeurs.
Software is eating the world et nous jouons aujourd'hui un rôle fondamental de bâtisseurs dans la société. À ce titre, nous avons conscience de ce que nous faisons, pour quoi nous le faisons, mais aussi comment nous le faisons.
Notre soif de technicité et de qualité nous fait parfois oublier que nous ne sommes pas ce que nous codons. En prenant conscience de notre rapport au code et aux autres codeurs, nous pouvons débloquer, chez nous et autour de nous, un important potentiel de puissance, d'impact, mais aussi de légèreté.
Nous sommes coachs.
Nous avons travaillé à mieux comprendre le fonctionnement de l'humain à des niveaux neurologiques, psychologiques et spirituels. À ce titre, nous avons conscience des bénéfices de ce que nous avons appris et souhaitons les mettre au service de la société.
Notre impact est maximum lorsque nous aidons les autres à être dans les meilleures conditions pour constuire le monde. Nous connaissons les conséquences qu'un égo mal placé peut avoir sur notre fonctionnement et souhaitons aider notre entourage à le replacer à sa juste place, au service de la créativité et de la qualité.
L'intégration de ces deux facettes de nous-même nous a poussé à construire "La psychologie du code" et nous encourage à le diffuser largement.
La sécurité psychologique est caractérisée par le fait de ne pas craindre de perdre la face ou d'être agressé si l'on s'exprime librement, de ne pas courir de risque interpersonnel : poser des questions sans être traité d'incompétent. avouer des erreurs sans se faire dénigrer.
A partir de 2012, Google lance le projet Aristote, afin de mieux comprendre les facteurs clés de succès de ses équipes techniques (plus de 180). Il en ressort que les facteurs discriminants ne sont pas de l'ordre de la performance personnelle mais de la dynamique de l'équipe.
La différence qui fait la différence, c'est avant tout la sécurité psychologique. Mais d'autres facteurs ressortent aussi fortement :
Le programme "La psychologie du code" travaille principalement prise de conscience de son fonctionnement et de celui des autres et à la transmission d'outil permettant de renforcer la sécurité psychologique au sein de l'équipe, la confiance, le sens et l'engagement.
Aujourd'hui le coaching professionnel est souvent reservé aux dirigeants. C'est parce qu'il est particulièrement efficace dans les professions où la performance est hautement non-linéaire : où un petit déclic peut avoir de grandes conséquences.
Pour l'avoir observé directement, nous sommes convaincus que généraliser le coaching aux développeurs et développeuses peut accroître de façon incroyable la performance d'une équipe technique.
Enfin, avec un sujet tel que celui traité par notre programme, il est facile de ressortir de formation plein d'énergie et d'apprentissages mais de se rendre compte, quelques semaines plus tard que c'est finalement plus compliqué qu'anticipé. Les coachings d'ancrage et l'accès à la communauté permettent exactement de rester en mouvement, même longtemps après la fin de la formation.
Attention, on ne parle pas du coaching agile, qui n'est pas du coaching au sens propre mais plutôt du conseil en méthodologie et parfois de la facilitation. On parle de vrai coaching professionnel.
Dans les années 70, le développeur Jerry Weinberg publie un de ses best-sellers — même 50 ans après — The Psychology of Computer Programming. Il y aborde le rapport que les développeurs ont avec leur code et avec les autres et explore des pistes d'améliorations de leur fonctionnement.
Des années plus tard, émergent de sa pensée les 10 principes de l'egoless programming. Ils ont été repris par de nombreux programmeurs, notamment : Jeff Atwood (le fondateur de StackOverflow), Scott Gartner, Bertrand Le Foulgoc (Octo), Natali Vlatko, Stephen Wyatt Bush, @turnoff_us, etc.
Ceux-ci sont parfois très spécifiques et datent d'avant les apports du manifeste Agile. Nous nous en sommes donc inspirés pour construire les 7 principes évoqués plus haut, mieux adaptés selon nous au contexte actuel.
On parle d'égo car la programmation informatique est une activité à la fois créative et exigeante. Ainsi, on y retrouve un certain égo. C'est en général une bonne chose : c'est ce qui permet de rechercher toujours plus de qualité ou de passer des heures à traquer un bug pernicieux.
Mais l'égo, lorsqu'il est "mal placé", peut se mettre en travers de relations saines de collaboration. Dans ce cas, on observe souvent les symptômes cités en haut de cette page.
Ainsi, notre objectif avec ce programme n'est pas de "détruire l'égo" mais plutôt d'en prendre conscience et d'en contenir les effets néfastes.
À l'issue du programme (formation + coaching), nous fournissons une attestation qui certifie ton passage dans le programme avec un open-badge que tu pourras mettre sur ton CV ou sur ton profil LinkedIn ou Github.
Elle ne constitue pas la reconnaissance d'un titre (comme un master par exemple), même si nous sommes en train de travailler pour la faire inscrire au Répertoire Spécifique de France Compétences.
On ne parlera pas de :
Mais on parlera de :
On va te transmettre des modèles et des protocoles issus de :
Nous les avons complètement contextualisés au métier de dev, avec des exemples pratiques du quotidien d'une équipe technique.
Pour en savoir plus, tu peux aller regarder la vidéo (en accès gratuit) de la première partie de la conclusion, qui reprend tous les principes et les notions-clés transmises.
Même si c'est un petit plus compliqué, pour vous comme pour nous, c'est possible, oui !
En effet, nous nous ancrons dans une logique de développement des compétences de chacun et ceci peut être financé à ce titre.
Pour en savoir plus et le mettre en place, contactez-nous.
Une vingtaine de vidéos sont accessibles librement pour te faire une idée du contenu et des modalités du programme.