J’ai quelques expériences avec du « mauvais code ». J’ai souvent travaillé seul, mais il m’est aussi arrivé, en équipe, d’écrire du code qui fonctionnait sans être optimal. Quand j’essayais de refactorer l’ancien code en même temps qu’un nouveau travail, c’était souvent refusé, et les refactorings ou corrections nécessaires, même consignés dans des tickets, finissaient généralement relégués en bas des priorités ou ignorés.
Quand on est seul, on peut prioriser ce qui doit être fait, mais en équipe, les décisions de second choix peuvent rester en place pour toujours, ou être laissées telles quelles jusqu’au moment où « le système tombe ». Ensuite, lors du post-mortem, si l’on pointe un ticket ouvert des mois plus tôt pour demander de désamorcer la bombe, c’est perçu comme une « accusation » ou comme quelque chose d’« agressif ». Au final, la solution semble devenir de ne jamais écrire de code de second choix, ce qui rend le codage plus frustrant et anxiogène.
En 2017, on m’a aussi contacté pour corriger du code que j’avais écrit en 2003/2004, et ce code était toujours en production. Revoir le code cassé et les compromis que l’on avait acceptés, puis réaliser que la personne responsable, c’était bien soi, est une expérience assez humiliante ; après cela, mon point de vue sur le code maintenable et la documentation a beaucoup changé.
Cela dépend des équipes et des entreprises. J’ai souvent connu des équipes où les développeurs étaient encouragés à consacrer du temps à la maintenance du code et au refactoring, où ils y étaient parfois même obligés, où les travaux centrés sur l’ingénierie passaient avant des demandes produit aléatoires, et où les plannings étaient ajustés pour finir correctement le travail.
J’ai vécu cela aussi bien dans de grandes entreprises du S&P 500 que dans des sociétés valorisées entre 100 millions et 1 milliard de dollars, ainsi que dans des startups. Dans ces cas-là, il y avait des ingénieurs logiciel et des managers expérimentés, capables de faire des compromis raisonnables tout en tenant compte des besoins métier, et les ingénieurs interagissaient souvent directement avec les clients.
L’essentiel, c’est l’équilibre, et cet équilibre vient généralement de personnes capables de juger avec mesure. Si l’on ne poursuit que la « perfection », on finit dans un refactoring sans fin et sans sortie de produit ; si l’on ignore la dette technique ou une qualité médiocre, l’activité peut finir par s’effondrer avec le temps. L’endroit où placer le curseur dépend du produit, du secteur, des clients et du business.
Soit on meurt en héros, soit on vit assez longtemps pour voir son nom dans un git blame vieux de 10 ans.
« Ça marche, mais ce n’est pas optimal » est souvent un compromis acceptable quand on manque de temps et qu’il y a beaucoup à faire. Les slogans façon MBA comme « le mieux est l’ennemi du bien » peuvent aussi servir quand quelque chose manque.
Être rappelé en 2017 pour corriger du code écrit en 2003/2004 signifie aussi que nous sommes tous des voyageurs temporels. Nous sommes indulgents avec notre moi passé et légèrement impolis avec notre moi futur.
Mon moi passé était jeune et naïf, mais productif, et il a abattu beaucoup de travail. Il m’a fallu deux jours pour comprendre le code, mais au fond il était plutôt malin ; si mon moi actuel a tout oublié, c’est peut-être juste que j’ai une mauvaise mémoire.
Mon moi futur corrigera toutes les erreurs. Il sera plus âgé et plus sage, transformera XXX et TBD en code intelligent, implémentera les bonnes idées et aura un temps infini pour réimplémenter les idées moyennes. Avec de meilleurs commentaires, ces trois versions de moi pourraient peut-être ne faire qu’une.
Je pense que cette attitude vertueuse du « cette personne-là » est nocive. Pour un développeur senior, pouvoir parler de ses erreurs et de ce qu’il a raté est très libérateur et sain.
Ce n’est pas seulement une occasion d’apprendre : cela montre aussi une culture ouverte et aide à combattre le syndrome de l’imposteur. L’attitude perfectionniste fait l’inverse : elle se résume à « fais plus d’efforts pour ne pas te tromper », sans rien apprendre, en exigeant seulement davantage d’efforts individuels.
Au moins deux fois, j’ai vu « cette personne-là » ne pas reconnaître une grosse erreur, préférer l’esquive quitte à perdre un bon client, et probablement médire en coulisses.
Une fois, j’ai pris sur moi une petite erreur d’un junior qui avait mis la mauvaise version du logiciel dans un rapport. Il aurait suffi de dire au client : « il y a eu une erreur, voici le rapport corrigé ». Mais mon supérieur ne pensait qu’à une chose : « peut-on cacher ça et préserver l’image que nous sommes parfaits ? ». La même personne utilisait les erreurs des autres comme occasions de réclamer des remises, des compensations ou des prestations gratuites.
La plupart des gens font leur travail et s’améliorent, à mon avis. Dans notre gestion de configuration, il y a pas mal de choses que j’ai écrites et qui fonctionnent très bien sur le plan fonctionnel, mais après avoir utilisé les outils pendant un an ou deux, j’en suis venu à les qualifier de qualité assez médiocre pour diverses raisons.
Ce n’est pas grave. Quand il y aura une raison de les changer, on les nettoiera ; jusque-là, elles restent des exemples de mauvaises pratiques et de meilleures approches possibles.
Si l’on ne trouve rien à critiquer chez soi, c’est que l’on ne progresse pas. Partager cette autocritique permet aux autres d’apprendre de mes erreurs et de comprendre qu’il est aussi acceptable d’apprendre des leurs.
En revue de code, j’entends souvent des phrases comme « pourquoi ne pas simplement éviter cette erreur ? » ou « pourquoi ne pas simplement faire comme ça ? ».
Ces temps-ci, je réponds : « C’est probablement parce que votre QI est plus élevé que le mien. Comme j’ai un QI plus faible, je dois faire des choses plus bêtes et plus simples. » Parfois, cela fait rougir l’autre personne quand elle réalise à quel point elle vient d’agir comme un petit geek rabaissant les autres sans aucune introspection.
Je suis un peu allergique aux questions qui commencent par « Pourquoi ne pas simplement… ? ». Dès que j’entends ces trois mots, je peux généralement deviner la proposition qui va suivre, non pas parce qu’elle est incroyablement complexe, mais parce que c’est en général la première solution évidente qui vient à l’esprit, et qu’elle a déjà été soigneusement examinée ou essayée.
La question n’est pas mauvaise en soi, mais les présupposés « mon idée est tellement simple » et « vous n’avez pas pensé à cette idée évidente et facile » peuvent être agaçants ou insultants. À l’inverse, quand je pose une question à quelqu’un, j’essaie d’éviter « pourquoi simplement », et il peut être préférable de demander quelque chose comme « puis-je comprendre qu’il y a une raison pour laquelle X n’a pas été fait ? », ou simplement de demander gentiment la raison.
Si la question vient d’un manque de contexte, on peut l’éviter en expliquant d’abord pourquoi les solutions les plus évidentes n’ont pas fonctionné, ou en exposant les exigences délicates et les entrées problématiques, avant de décrire ce que l’on a fait. Si le code est déjà commit, l’objectif est de réduire les remarques après coup via des commentaires dans le commit ou la demande de fusion. Parfois, il est aussi utile de ne pas se braquer, d’expliquer que cette méthode a été essayée mais pourquoi elle n’a pas fonctionné, puis de demander sincèrement s’il existe d’autres idées.
Si c’est vraiment une suggestion à laquelle je n’avais pas pensé et qu’elle semble pouvoir résoudre le problème, je dis que c’est une bonne idée et je demande de l’aide pour l’implémenter. Dans ces moments-là, on peut être tenté de répondre au présupposé ou au ton de l’autre, mais j’essaie plutôt d’accepter l’idée et d’avoir un bref moment de gêne.
C’est un très bon exemple d’application de grug brain : https://grugbrain.dev/
« Si grug doit choisir entre la complexité et un combat en un contre un contre un tyrannosaure, grug choisit le tyrannosaure. Au moins, grug peut voir le tyrannosaure. »
Si ce n’est pas une blague, la première question n’aide pas et relève presque de la méchanceté. Tout le monde fait parfois des erreurs.
La deuxième question peut généralement constituer un retour valable. Les compétences et les connaissances des gens ne se recoupent pas toujours. Ce qui est follement complexe pour A ne l’est pas forcément pour B, et l’inverse est aussi possible, sans que ce soit nécessairement parce que l’un est plus intelligent que l’autre. A peut ne pas connaître SQL et B peut ne pas connaître pandas
Si l’on suppose que la stack technique contient déjà à la fois SQL et pandas, il peut parfois être logique de déplacer du code de SQL vers pandas, ou l’inverse. Certaines personnes trouvent le style orienté objet plus facile, d’autres le style fonctionnel. Ce qui est le plus pertinent n’est pas toujours évident, donc la question peut être une bonne question. Si la suggestion est mauvaise, il suffit d’expliquer pourquoi ; si elle est bonne, on peut se demander si cela vaut la peine de le faire maintenant. Si c’est entre les deux, ou si l’on n’a pas le temps, on peut le reconnaître et passer à autre chose
L’autre option consiste simplement à être clairement d’accord. On peut répondre : « Oui, c’était idiot, non ? », « Oui, je n’aurais peut-être pas dû faire ça », ou encore « Je vais y réfléchir »
Il devient alors difficile pour l’autre personne de me faire honte ou de me culpabiliser parce que j’ai fait quelque chose de sous-optimal. Je pense que l’objectif de ce genre de remarque est souvent de prendre l’ascendant par la honte. Choisir de ne pas participer au jeu est généralement le coup gagnant
Si la remarque venait de l’ignorance, il n’est pas nécessaire de la prendre pour une attaque et de faire payer l’autre en l’humiliant
Je n’arrive pas à retrouver le blog ou l’article que j’avais vu autrefois, mais son message était : « ne pas supposer l’incompétence dès qu’on voit quelque chose de non optimal dans du code ». La personne qui a écrit ce code pouvait avoir des contraintes, comme une échéance serrée, d’autres priorités ou d’autres facteurs, qui l’empêchaient de faire immédiatement « ce qu’il fallait »
Même si le code était parfait au moment où il a été écrit, la croissance de la codebase et l’évolution des exigences peuvent le rendre mauvais
Par exemple, si l’on a 10 éléments à stocker, un simple fichier peut être un choix pragmatique, mais avec 10 000 éléments, une base de données peut devenir nécessaire. Pourtant, si l’on avait utilisé une base de données dès le départ pour 10 éléments, on se serait plaint d’une sur-ingénierie
Avec 2 classes, un if/else suffit, mais avec 20 classes, un pattern Factory peut devenir nécessaire ; si on l’avait fait dès le début, cela aurait ressemblé à de l’architecture d’astronaute. Quand on essaie de prévoir ce genre de croissance et qu’on se trompe, on produit du code complexe. Un projet qui continue d’être développé finit systématiquement par devenir plus grand que lui-même
Il y a aussi la clôture de Chesterton. Une chose apparemment stupide dans le code a pu être réellement importante par le passé. Pire encore, elle peut toujours être importante pour un cas limite rare, sans que l’on en voie encore la raison
J’ai reçu plusieurs commentaires toxiques ici et sur reddit à propos d’articles de blog. Dans ces cas-là, j’utilise une méthode consistant à ajouter à l’article, sans jugement, un lien vers le commentaire toxique pour braquer la lumière dessus. La plupart du temps, il ne se passe rien, mais cela remet parfois la discussion sur une voie plus saine
J’en ai moi aussi reçu pas mal. Certains étaient probablement mérités, mais la plupart ne l’étaient sans doute pas. Quelques-uns étaient justes dans une certaine mesure, mais inutiles, voire directement nuisibles à la communauté. Dire une chose vraie de la mauvaise manière, c’est encore dire une chose fausse
Lier des commentaires toxiques sans jugement n’est pas une mauvaise idée. Ce n’est pas toujours possible si le commentaire est marqué comme mort, mais dans tous les cas je ne réponds pas sur le même ton. Je pourrais le faire, mais j’ai appris que l’essence n’est pas un extincteur efficace
Si j’ai tort, j’essaie de le reconnaître immédiatement, au même endroit que celui où l’erreur a été commise. Je déteste particulièrement les excuses privées après une attaque publique
Il y a toutefois une limite. J’ai le sentiment de faire un travail plutôt bon, je le fais depuis longtemps, environ 40 ans, et j’ai beaucoup appris pendant ce temps. J’ai aussi travaillé dans des environnements exigeants qui n’acceptaient pas le travail de faible qualité, ce qui m’a donné l’habitude de produire quelque chose de correct
En général, j’évite de juger publiquement les autres. Ce n’est pas utile, et je n’ai pas toujours raison. Cela peut toutefois être différent si je travaille avec la personne ou si j’utilise ce qu’elle produit. Il m’est arrivé d’être attaqué durement parce que je refuse d’accepter du travail pourri, mais je ne me comporte pas comme Linus Torvalds. Quand c’est possible, je dis de manière respectueuse que ce travail n’est pas acceptable pour moi
Malgré tout, on peut toujours s’améliorer et apprendre du nouveau, parfois dans des endroits totalement inattendus. Rester ouvert à cet apprentissage est fondamentalement une bonne politique. Je deviens juste en me trompant et en apprenant. « Le bon jugement vient de l’expérience, et l’expérience vient du mauvais jugement »
L’un de mes podcasts préférés, well there's your problem sur YouTube, épingle presque toujours les commentaires qui se plaignent du podcast. Ce sont généralement des plaintes du genre « je n’aime pas ce podcast, donc il devrait être un autre podcast », et le commentaire épinglé est à chaque fois proche de l’interprétation la plus stupide possible de l’épisode
Je ne sais pas si cela réduit ce genre de commentaires, mais cela revient à coiffer métaphoriquement d’un bonnet d’âne les personnes qui participent ainsi au débat
Je suis d’accord pour dire que certains ingénieurs ont une mauvaise attitude. Tout le monde peut écrire du mauvais code, et l’idée selon laquelle tout code est mauvais et constitue une dette a aussi une part de vérité
Cet article est intéressant à lire en parallèle de « No more pink mustache ». Dans ce texte, Lyft est décrit comme « cassé à une échelle incroyable », et la cause de la qualité est souvent l’organisation, pas la personne assise sur la chaise :-)
[1] https://rachelbythebay.com/w/2020/02/29/poof/
J’ai lu cet article en 2018 et je suis content de le voir remonter. C’est l’un des textes qui m’a poussé à me poser des questions. S’il est impossible d’éliminer l’absolutisme ou les positions extrêmes, quels filtres peut-on créer lorsqu’on rencontre ce genre de conversations ou de personnes ? J’ai mon propre modèle, mais je suis curieux de savoir quelles stratégies les autres utilisent
Ces personnes cherchent à occuper un territoire émotionnel qui ne leur appartient pas. En général, elles ont déjà calculé qu’elles « peuvent se le permettre », ce qui signifie qu’elles voient l’autre comme faible
Il y a trois options. Abandonner, leur céder ce territoire et continuer à vivre sa vie ; moins l’injustice vous fait perdre le sommeil, mieux c’est. Les affronter de front ; ils sont prêts à se battre, mais leur position étant intrinsèquement irrationnelle, moins on se laisse entraîner dans leur espace mental, plus on « gagne ». Ou venir d’en haut : apporter dans leur espace des preuves sociales montrant qu’ils ont tort. Dans le cas de l’article original, cela correspondrait à des programmeurs productifs qui respectent le travail des autres et ne cherchent pas la petite bête
Quand quelqu’un donne un conseil du type « cela aurait pu être mieux de faire comme ceci », ce n’est pas toujours une attaque contre moi ni une insulte à mes compétences
La personne qui donne des conseils peut être un idiot maladroit dans ses relations, ou tout simplement un parfait idiot. Ce n’est pas grave si une partie du monde n’est pas d’accord avec moi. Le fait que des gens expriment une opinion contraire ou ne soient pas d’accord ne constitue pas une menace pour moi.
C’est un texte étrange. Il sonne comme un tweet, il dit peu de choses, et le titre ne reflète pas le corps du texte, ce qui le fait ressembler à du clickbait.
Je ne suis pas contre l’idée générale, mais il y a aussi l’autre côté. Il faut aussi avoir la capacité à accepter les retours.
La plupart des gens sont capables d’accepter les retours et de les appliquer. Mais certaines personnes donnent des retours de très mauvaise qualité, puis estiment que l’autre n’est pas capable de les accepter.
Ces personnes pensent que leur manière préférée de donner du feedback est la meilleure, que tout le monde devrait ressentir la même chose et que, sinon, c’est l’autre qui doit changer. Elles se trompent, bien sûr. Mais si on le leur dit, elles montrent elles-mêmes pourquoi j’ai écrit « la plupart » dans la première phrase.
1 commentaires
Avis sur Hacker News
Quand on est seul, on peut prioriser ce qui doit être fait, mais en équipe, les décisions de second choix peuvent rester en place pour toujours, ou être laissées telles quelles jusqu’au moment où « le système tombe ». Ensuite, lors du post-mortem, si l’on pointe un ticket ouvert des mois plus tôt pour demander de désamorcer la bombe, c’est perçu comme une « accusation » ou comme quelque chose d’« agressif ». Au final, la solution semble devenir de ne jamais écrire de code de second choix, ce qui rend le codage plus frustrant et anxiogène.
En 2017, on m’a aussi contacté pour corriger du code que j’avais écrit en 2003/2004, et ce code était toujours en production. Revoir le code cassé et les compromis que l’on avait acceptés, puis réaliser que la personne responsable, c’était bien soi, est une expérience assez humiliante ; après cela, mon point de vue sur le code maintenable et la documentation a beaucoup changé.
J’ai vécu cela aussi bien dans de grandes entreprises du S&P 500 que dans des sociétés valorisées entre 100 millions et 1 milliard de dollars, ainsi que dans des startups. Dans ces cas-là, il y avait des ingénieurs logiciel et des managers expérimentés, capables de faire des compromis raisonnables tout en tenant compte des besoins métier, et les ingénieurs interagissaient souvent directement avec les clients.
L’essentiel, c’est l’équilibre, et cet équilibre vient généralement de personnes capables de juger avec mesure. Si l’on ne poursuit que la « perfection », on finit dans un refactoring sans fin et sans sortie de produit ; si l’on ignore la dette technique ou une qualité médiocre, l’activité peut finir par s’effondrer avec le temps. L’endroit où placer le curseur dépend du produit, du secteur, des clients et du business.
Mon moi passé était jeune et naïf, mais productif, et il a abattu beaucoup de travail. Il m’a fallu deux jours pour comprendre le code, mais au fond il était plutôt malin ; si mon moi actuel a tout oublié, c’est peut-être juste que j’ai une mauvaise mémoire.
Mon moi futur corrigera toutes les erreurs. Il sera plus âgé et plus sage, transformera XXX et TBD en code intelligent, implémentera les bonnes idées et aura un temps infini pour réimplémenter les idées moyennes. Avec de meilleurs commentaires, ces trois versions de moi pourraient peut-être ne faire qu’une.
Ce n’est pas seulement une occasion d’apprendre : cela montre aussi une culture ouverte et aide à combattre le syndrome de l’imposteur. L’attitude perfectionniste fait l’inverse : elle se résume à « fais plus d’efforts pour ne pas te tromper », sans rien apprendre, en exigeant seulement davantage d’efforts individuels.
Une fois, j’ai pris sur moi une petite erreur d’un junior qui avait mis la mauvaise version du logiciel dans un rapport. Il aurait suffi de dire au client : « il y a eu une erreur, voici le rapport corrigé ». Mais mon supérieur ne pensait qu’à une chose : « peut-on cacher ça et préserver l’image que nous sommes parfaits ? ». La même personne utilisait les erreurs des autres comme occasions de réclamer des remises, des compensations ou des prestations gratuites.
Ce n’est pas grave. Quand il y aura une raison de les changer, on les nettoiera ; jusque-là, elles restent des exemples de mauvaises pratiques et de meilleures approches possibles.
Ces temps-ci, je réponds : « C’est probablement parce que votre QI est plus élevé que le mien. Comme j’ai un QI plus faible, je dois faire des choses plus bêtes et plus simples. » Parfois, cela fait rougir l’autre personne quand elle réalise à quel point elle vient d’agir comme un petit geek rabaissant les autres sans aucune introspection.
La question n’est pas mauvaise en soi, mais les présupposés « mon idée est tellement simple » et « vous n’avez pas pensé à cette idée évidente et facile » peuvent être agaçants ou insultants. À l’inverse, quand je pose une question à quelqu’un, j’essaie d’éviter « pourquoi simplement », et il peut être préférable de demander quelque chose comme « puis-je comprendre qu’il y a une raison pour laquelle X n’a pas été fait ? », ou simplement de demander gentiment la raison.
Si la question vient d’un manque de contexte, on peut l’éviter en expliquant d’abord pourquoi les solutions les plus évidentes n’ont pas fonctionné, ou en exposant les exigences délicates et les entrées problématiques, avant de décrire ce que l’on a fait. Si le code est déjà commit, l’objectif est de réduire les remarques après coup via des commentaires dans le commit ou la demande de fusion. Parfois, il est aussi utile de ne pas se braquer, d’expliquer que cette méthode a été essayée mais pourquoi elle n’a pas fonctionné, puis de demander sincèrement s’il existe d’autres idées.
Si c’est vraiment une suggestion à laquelle je n’avais pas pensé et qu’elle semble pouvoir résoudre le problème, je dis que c’est une bonne idée et je demande de l’aide pour l’implémenter. Dans ces moments-là, on peut être tenté de répondre au présupposé ou au ton de l’autre, mais j’essaie plutôt d’accepter l’idée et d’avoir un bref moment de gêne.
« Si grug doit choisir entre la complexité et un combat en un contre un contre un tyrannosaure, grug choisit le tyrannosaure. Au moins, grug peut voir le tyrannosaure. »
La deuxième question peut généralement constituer un retour valable. Les compétences et les connaissances des gens ne se recoupent pas toujours. Ce qui est follement complexe pour A ne l’est pas forcément pour B, et l’inverse est aussi possible, sans que ce soit nécessairement parce que l’un est plus intelligent que l’autre. A peut ne pas connaître SQL et B peut ne pas connaître pandas
Si l’on suppose que la stack technique contient déjà à la fois SQL et pandas, il peut parfois être logique de déplacer du code de SQL vers pandas, ou l’inverse. Certaines personnes trouvent le style orienté objet plus facile, d’autres le style fonctionnel. Ce qui est le plus pertinent n’est pas toujours évident, donc la question peut être une bonne question. Si la suggestion est mauvaise, il suffit d’expliquer pourquoi ; si elle est bonne, on peut se demander si cela vaut la peine de le faire maintenant. Si c’est entre les deux, ou si l’on n’a pas le temps, on peut le reconnaître et passer à autre chose
Il devient alors difficile pour l’autre personne de me faire honte ou de me culpabiliser parce que j’ai fait quelque chose de sous-optimal. Je pense que l’objectif de ce genre de remarque est souvent de prendre l’ascendant par la honte. Choisir de ne pas participer au jeu est généralement le coup gagnant
Par exemple, si l’on a 10 éléments à stocker, un simple fichier peut être un choix pragmatique, mais avec 10 000 éléments, une base de données peut devenir nécessaire. Pourtant, si l’on avait utilisé une base de données dès le départ pour 10 éléments, on se serait plaint d’une sur-ingénierie
Avec 2 classes, un if/else suffit, mais avec 20 classes, un pattern Factory peut devenir nécessaire ; si on l’avait fait dès le début, cela aurait ressemblé à de l’architecture d’astronaute. Quand on essaie de prévoir ce genre de croissance et qu’on se trompe, on produit du code complexe. Un projet qui continue d’être développé finit systématiquement par devenir plus grand que lui-même
Lier des commentaires toxiques sans jugement n’est pas une mauvaise idée. Ce n’est pas toujours possible si le commentaire est marqué comme mort, mais dans tous les cas je ne réponds pas sur le même ton. Je pourrais le faire, mais j’ai appris que l’essence n’est pas un extincteur efficace
Si j’ai tort, j’essaie de le reconnaître immédiatement, au même endroit que celui où l’erreur a été commise. Je déteste particulièrement les excuses privées après une attaque publique
Il y a toutefois une limite. J’ai le sentiment de faire un travail plutôt bon, je le fais depuis longtemps, environ 40 ans, et j’ai beaucoup appris pendant ce temps. J’ai aussi travaillé dans des environnements exigeants qui n’acceptaient pas le travail de faible qualité, ce qui m’a donné l’habitude de produire quelque chose de correct
En général, j’évite de juger publiquement les autres. Ce n’est pas utile, et je n’ai pas toujours raison. Cela peut toutefois être différent si je travaille avec la personne ou si j’utilise ce qu’elle produit. Il m’est arrivé d’être attaqué durement parce que je refuse d’accepter du travail pourri, mais je ne me comporte pas comme Linus Torvalds. Quand c’est possible, je dis de manière respectueuse que ce travail n’est pas acceptable pour moi
Malgré tout, on peut toujours s’améliorer et apprendre du nouveau, parfois dans des endroits totalement inattendus. Rester ouvert à cet apprentissage est fondamentalement une bonne politique. Je deviens juste en me trompant et en apprenant. « Le bon jugement vient de l’expérience, et l’expérience vient du mauvais jugement »
Je ne sais pas si cela réduit ce genre de commentaires, mais cela revient à coiffer métaphoriquement d’un bonnet d’âne les personnes qui participent ainsi au débat
Cet article est intéressant à lire en parallèle de « No more pink mustache ». Dans ce texte, Lyft est décrit comme « cassé à une échelle incroyable », et la cause de la qualité est souvent l’organisation, pas la personne assise sur la chaise :-)
[1] https://rachelbythebay.com/w/2020/02/29/poof/
Il y a trois options. Abandonner, leur céder ce territoire et continuer à vivre sa vie ; moins l’injustice vous fait perdre le sommeil, mieux c’est. Les affronter de front ; ils sont prêts à se battre, mais leur position étant intrinsèquement irrationnelle, moins on se laisse entraîner dans leur espace mental, plus on « gagne ». Ou venir d’en haut : apporter dans leur espace des preuves sociales montrant qu’ils ont tort. Dans le cas de l’article original, cela correspondrait à des programmeurs productifs qui respectent le travail des autres et ne cherchent pas la petite bête
La personne qui donne des conseils peut être un idiot maladroit dans ses relations, ou tout simplement un parfait idiot. Ce n’est pas grave si une partie du monde n’est pas d’accord avec moi. Le fait que des gens expriment une opinion contraire ou ne soient pas d’accord ne constitue pas une menace pour moi.
Ces personnes pensent que leur manière préférée de donner du feedback est la meilleure, que tout le monde devrait ressentir la même chose et que, sinon, c’est l’autre qui doit changer. Elles se trompent, bien sûr. Mais si on le leur dit, elles montrent elles-mêmes pourquoi j’ai écrit « la plupart » dans la première phrase.