Apprendre comment devenir un bon programmeur

C’est le rôle du programmeur de faire le travail difficile et de discerner l’impossible. Du point de vue de la plupart des développeurs en activité, quelque chose est impossible si on ne peut pas le développer à partir d’un simple système ou si on ne peut pas l’estimer. Selon cette définition, ce qui est appelé « recherche » est impossible. Un gros volume de travail simple est difficile, mais pas nécessairement impossible.

La distinction n’est pas simple, car on peut très bien vous demander de faire ce qui est pratiquement impossible, d’un point de vue scientifique ou de génie logiciel. Cela devient alors votre travail d’aider l’entrepreneur à trouver une solution raisonnable, qui est simplement difficile et qui répond à la plupart de ses attentes. Une solution est simplement difficile quand elle peut être planifiée avec confiance et que les risques sont compris.

Il est impossible de satisfaire une exigence vague, telle que « Construire un système qui calculera le style et la couleur de cheveux les plus attrayants pour une personne ». Si l’exigence peut être plus poussée, elle deviendra plus difficile, comme « Construire un système qui calcule un style et une couleur de cheveux attrayants pour une personne et lui permettre une prévisualisation et d’apporter des modifications, pour obtenir la satisfaction du client, basée sur le style original, tel que nous gagnions beaucoup d’argent ». S’il n’y a pas de définition précise du succès, vous ne réussirez pas.

L’intégration d’un langage de programmation dans un système suscite une fascination presque érotique chez un programmeur. C’est l’un des actes les plus créatifs qui puissent être réalisés. Cela rend le système énormément puissant. Cela vous permet d'exercer vos compétences les plus créatives et prométhéennes. Ce qui fera du système votre ami.

Les meilleurs éditeurs de texte du monde ont tous des langages intégrés. Ils sont utilisables dans la mesure où le public ciblé peut maîtriser le langage. Bien sûr, l’utilisation du langage peut être rendue optionnelle, comme dans les éditeurs de texte, afin que les initiés puissent l’utiliser et les autres n’aient pas à le faire.

De nombreux autres programmeurs et moi-même sommes tombés dans le piège de la création de langages intégrés pour des objectifs spécifiques. Je suis tombé dedans deux fois. Il existe déjà beaucoup de langages conçus spécifiquement pour être des langages intégrés. Vous devriez y réfléchir sérieusement avant d’en créer un nouveau.

La véritable question à se poser avant de rendre un langage intégrable est : est-ce que ça va dans le sens ou contre la culture de mon public ? Si votre public cible est exclusivement composé de non-programmeurs, en quoi cela l’aidera-t-il ? Si votre public cible est exclusivement composé de programmeurs, peut-être préférerait-il une interface de programmation d’application (API) ? Et quel langage utiliser ? Les programmeurs ne veulent pas apprendre un nouveau langage peu utilisé, mais si cela correspond à leur culture, ils n'auront pas à passer beaucoup de temps à l'apprendre. C’est une joie de créer un nouveau langage. Mais nous ne devrions pas laisser cela nous rendre aveugles aux besoins de l'utilisateur. À moins que vous n’ayez des idées et des besoins vraiment originaux, pourquoi ne pas utiliser un langage existant, afin de pouvoir tirer parti de la familiarité que les utilisateurs ont déjà avec lui ?

Le programmeur solitaire qui aime son travail (un bidouilleur) peut choisir le meilleur langage pour la tâche. La plupart des programmeurs qui travaillent ont très peu de contrôle sur le langage qu’ils vont utiliser. Généralement, ce problème est dicté par des chefs qui prennent une décision politique plutôt qu’une décision technologique et qui n’ont pas le courage pour promouvoir un outil non conventionnel même lorsqu’ils savent, souvent avec une connaissance de première main, que l’outil le moins accepté est le meilleur. Dans d’autres cas, le bénéfice très réel de l’unité au sein de l’équipe et dans une certaine mesure d’une communauté plus large, prévaut sur le choix d’une personne. Les managers sont souvent motivés par le besoin de pouvoir engager des programmeurs expérimentés dans un langage donné. Nul doute qu’ils servent ce qu’ils perçoivent comme étant les meilleurs intérêts du projet ou de la compagnie et ils doivent être respectés pour cela. Cependant, je crois personnellement que c’est la pratique courante la plus inutile et la plus erronée que vous êtes susceptible de rencontrer.

Mais bien entendu, les choses ne sont jamais unidimensionnelles. Même si un langage de base est retenu et hors de votre contrôle, il arrive souvent que des outils et d'autres programmes puissent et doivent être écrits dans un autre langage. Si un langage doit être intégré (et vous devriez toujours y penser), le choix de celui-ci dépendra beaucoup de la culture des utilisateurs. Vous devez en tirer avantage pour servir votre entreprise ou votre projet en utilisant le meilleur langage pour le travail et le rendre ainsi plus intéressant.

Les langages de programmation devraient vraiment s'appeler « notations », car leur apprentissage n’est pas du tout aussi difficile que l’apprentissage d’un langage naturel. Pour les débutants et autres outsiders, « apprendre un nouveau langage » semble être une tâche ardue. Mais après en avoir trois à votre actif, il ne vous reste plus qu’à vous familiariser avec les bibliothèques disponibles. On a tendance à penser qu’un grand système comportant des composants écrits en trois ou quatre langages est un grand désordre. Mais je soutiens qu’un tel système est plus puissant qu’un système écrit dans un seul langage et cela pour plusieurs raisons :

• il y a nécessairement un couplage lâche entre les composants écrits dans des notations différentes (bien que les interfaces ne soient peut-être pas propres) ;
• vous pouvez facilement évoluer vers un nouveau langage ou une nouvelle plate-forme en réécrivant chaque composant individuellement ;
• un langage peut ne pas convenir à la globalité du système. Avoir plusieurs langages pour vos modules vous permet de sélectionner le bon outil pour le travail.

Certains de ces effets peuvent être seulement psychologiques, mais la psychologie compte. Finalement, les coûts de la tyrannie des langages dépassent les avantages qu’elle procure.

La pression de la date de mise sur le marché est la pression pour livrer rapidement un bon produit. C’est bien, parce que cela reflète une réalité financière et reste sain dans une certaine mesure. La pression du calendrier est la pression exercée pour livrer quelque chose plus rapidement que ce qui peut l’être, c'est ravageur, malsain et trop commun.

La pression du calendrier existe pour plusieurs raisons. Les personnes qui confient les tâches aux programmeurs n’apprécient pas vraiment notre solide éthique de travail et le plaisir que procure le fait d’être un programmeur. Peut-être parce qu’ils projettent leur propre comportement sur nous, ils pensent que demander quelque chose plus tôt nous obligera à travailler plus pour le livrer plus tôt. C’est probablement vrai, mais l’effet est très faible et les dégâts sont très importants. De plus, ils n’ont aucune visibilité sur ce qu’il faut vraiment pour produire un logiciel. Ne pouvant pas le voir et ne pouvant pas le créer eux-mêmes, la seule chose qu’ils peuvent faire est de voir la pression de la date de mise sur le marché et d'attirer l'attention des programmeurs sur ce sujet.

La clef pour lutter contre la pression du calendrier est de la transformer en une pression de date de mise sur le marché. La façon de le faire est de donner une visibilité sur la relation entre la main-d'œuvre disponible et le produit. Produire une estimation honnête, détaillée et surtout compréhensible de tout le travail nécessaire est le meilleur moyen de le faire. Il présente l’avantage supplémentaire de permettre de prendre de bonnes décisions concernant les compromis possibles en matière de fonctionnalité.

L'idée clef que l'estimation doit préciser est que le travail est un fluide presque incompressible. Vous ne pouvez pas en produire plus dans un intervalle de temps que vous ne pouvez remplir un récipient au-delà de son volume. En un sens, un programmeur ne devrait jamais dire « non », mais plutôt dire « qu’allez-vous abandonner pour obtenir ce que vous voulez ? » L’obtention d’estimations claires aura pour effet d’augmenter le respect des programmeurs. C'est comme ça que les autres professionnels se comportent. Le travail acharné des programmeurs sera visible. Fixer un calendrier irréaliste sera également douloureusement évident pour tout le monde. Les programmeurs ne peuvent pas être trompés. C'est irrespectueux et démoralisant de leur demander de faire quelque chose d'irréaliste. La programmation extrême amplifie cela et construit un processus autour de cela. J'espère que tous les lecteurs auront la chance de l'utiliser.

C’est votre devoir de comprendre les utilisateurs et d’aider votre supérieur à les comprendre. Parce qu’ils ne sont pas aussi intimement impliqués que vous dans la création de votre produit, les utilisateurs se comportent un peu différemment :

• les utilisateurs prennent généralement des décisions brèves ;
• ils ont leur propre travail. Ils penseront principalement à de petites améliorations dans votre produit, pas à de grandes ;
• les utilisateurs ne peuvent pas avoir une vision qui représente l’ensemble des utilisateurs de votre produit.

Il est de votre devoir de leur donner ce qu'ils veulent vraiment, pas ce qu'ils disent vouloir. Il vaut toutefois mieux leur proposer et leur faire accepter que votre proposition est ce qu'ils veulent vraiment avant de commencer, mais ils peuvent ne pas avoir la vision pour faire cela. Votre confiance dans vos propres idées à ce sujet devrait varier. Vous devez vous protéger à la fois de l'arrogance et de la fausse modestie pour savoir ce que le client veut vraiment. Les programmeurs sont formés pour concevoir et créer. Les spécialistes du marché sont formés pour comprendre ce que veulent les gens. Ces deux types de personnes ou deux modes de pensée chez une même personne, travaillant ensemble en harmonie, offrent les meilleures chances de formuler la vision correcte.

Plus vous passerez de temps avec les utilisateurs, plus vous serez en mesure de comprendre ce qui réussira réellement. Vous devriez essayer d’éprouver vos idées avec eux autant que vous le pouvez. Vous devriez manger et boire avec eux si vous le pouvez.

Dans son ouvrage « Guy Kawasaki Rules » (les règles de Guy Kawasaky), l’auteur a souligné l’importance de regarder ce que font vos utilisateurs en plus de les écouter.

Je pense que les entrepreneurs et les consultants ont souvent beaucoup de difficultés pour clarifier ce que leurs clients veulent vraiment. Si vous avez l’intention d’être consultant, je vous suggère de choisir vos clients en fonction de leur lucidité et de leur portefeuille.

Pour être promu à un rôle, jouez ce rôle en premier.

Pour être promu à un titre, déterminez ce qui est attendu de ce titre et faites-le.

Pour obtenir une augmentation de salaire, négociez armés d'informations.

Si vous sentez que vous êtes en retard pour une promotion, parlez-en à votre patron. Demandez-lui explicitement ce que vous devez faire pour être promu et essayez de le faire. Cela semble banal, mais souvent, votre perception de ce que vous devez faire sera très différente de celle de votre patron. De plus, cela va mettre votre patron devant le fait accompli.

La plupart des programmeurs ont probablement un sens exagéré de leurs capacités relatives à certains égards. Après tout, nous ne pouvons pas tous être dans le top 10 ! Cependant, j'ai vu certaines personnes qui ont été sérieusement non appréciées à leur juste valeur. On ne peut pas s'attendre à ce que l'évaluation de chacun corresponde parfaitement à la réalité à tout moment, mais je pense que les gens sont généralement assez justes, avec une mise en garde : vous ne pouvez pas être appréciés sans qu’il y ait de visibilité dans votre travail. Parfois, en raison d'événements fortuits ou d'habitudes personnelles, une personne ne sera pas remarquée. Travailler beaucoup à la maison ou être géographiquement séparé de votre équipe et de votre chef rend la tâche particulièrement difficile.

Nietschze exagérait quand il a dit : « Ce qui ne me détruit pas me rend plus fort ».

Votre plus grande responsabilité est envers votre équipe. Vous devriez bien en connaître chaque membre. Vous devriez tenter d'obtenir le maximum de votre équipe, mais ne pas la surcharger. Vous devriez généralement parler à tous les membres de la façon dont ils sont sollicités. S'ils y adhèrent, ils seront bien motivés. Dans chaque projet, essayez de les mettre à profit d’une manière qu’ils suggèrent et d’une manière qui, selon vous, leur sera bénéfique. Ne les sollicitez pas en leur donnant plus de travail, mais en leur donnant une nouvelle compétence ou, mieux encore, un nouveau rôle à jouer dans l'équipe.

Vous devez permettre aux personnes (y compris vous-même) d’échouer de temps en temps et de prévoir certains échecs dans votre programme. S'il n'y a jamais d'échec, il ne peut y avoir de sens de l'aventure. S'il n'y a pas d'échecs occasionnels, c'est que vous ne faites pas assez d'essais. Quand quelqu'un échoue, vous devriez être aussi gentil que possible avec lui sans pour autant le traiter comme s'il avait réussi.

Essayez de faire en sorte que chaque membre de l’équipe adhère et soit bien motivé. Demandez explicitement à chacun d’entre eux ce dont il a besoin pour être bien motivé s’il ne l’est pas. Vous devrez peut-être laisser certains développeurs insatisfaits, mais vous devriez savoir ce que tout le monde désire.

Vous ne pouvez pas renoncer à quelqu'un qui ne porte pas intentionnellement sa charge de travail à cause d’un moral bas ou de l'insatisfaction et le laisser simplement démotivé. Vous devez essayer de motiver vos équipiers et les rendre productifs. Tant que vous avez la patience, continuez ainsi. Lorsque votre patience est épuisée, virez-les. Vous ne pouvez pas permettre à quelqu'un qui travaille intentionnellement en dessous de son niveau de rester dans l'équipe, car ce n'est pas juste pour l'équipe.

Dites clairement aux membres forts de votre équipe que vous pensez qu’ils sont forts en le disant en public. Les louanges devraient être publiques et les critiques privées.

Les membres forts de l'équipe auront naturellement des tâches plus difficiles que les membres faibles. C’est parfaitement naturel et personne ne sera dérangé par ça tant que tout le monde travaille dur.

C’est un fait singulier, qui ne se reflète pas dans les salaires, qu’un bon programmeur est plus productif que 10 mauvais programmeurs. Cela crée une situation étrange. Il sera souvent vrai que vous pourriez aller plus vite si vos programmeurs faibles se dérobaient. Si vous agissiez ainsi, vous feriez davantage de progrès à court terme. Cependant, votre tribu perdrait certains avantages importants, à savoir la formation des membres les plus faibles, la diffusion des connaissances tribales et la capacité de se remettre de la perte des membres les plus puissants. Les forts doivent être souples à cet égard et examiner la question sous tous les angles.

Vous pouvez souvent confier aux membres les plus forts de l’équipe des tâches difficiles, mais soigneusement délimitées.

Vous établissez un équilibre entre vos besoins personnels et ceux de l’équipe pour choisir l’aspect du projet à traiter. Vous devriez faire ce pour quoi vous êtes le meilleur, mais essayez de trouver un moyen de vous développer, non pas en prenant plus de travail, mais en exerçant une nouvelle compétence. Les compétences en leadership et en communication sont plus importantes que les compétences techniques. Si vous êtes très fort, prenez la tâche la plus difficile ou la plus risquée et le plus tôt possible dans le projet afin de réduire les risques.

Pour tirer le meilleur parti de vos coéquipiers, développez un bon esprit d'équipe et essayez de garder chaque individu à la fois stimulé et engagé personnellement.

Pour développer l’esprit d’équipe, il est bon d’utiliser des objets insignifiants comme des vêtements et des fêtes avec un logo, mais pas autant que le respect personnel. Si tout le monde respecte les autres, personne ne voudra laisser tomber quelqu'un. L'esprit d'équipe est créé lorsque les gens font des sacrifices pour l'équipe et pensent en termes de bien de l'équipe avant leur bien personnel. En tant que dirigeant, vous ne pouvez pas demander plus que ce que vous vous donnez à cet égard.

L’une des clefs du leadership d'équipe est de faciliter le consensus afin que tout le monde ait son mot à dire. Cela signifie parfois de permettre à vos coéquipiers de se tromper. Autrement dit, si cela ne nuit pas trop au projet, vous devez laisser une partie de votre équipe agir à sa manière, sur la base d’un consensus, même si vous croyez avec une grande certitude que ce n’est pas la bonne chose à faire. Lorsque cela se produit, n'acceptez pas, désapprouvez ouvertement et acceptez le consensus. Ne semblez pas blessé ou si vous y êtes forcé, déclarez simplement que vous n'êtes pas d'accord, mais pensez que le consensus de l'équipe est plus important. Cela fera souvent revenir en arrière les personnes qui ne sont pas de votre avis. N'insistez pas pour que ceux qui font marche arrière réalisent leur plan initial.

Si une personne refuse de donner son consentement une fois que vous avez discuté des problèmes de toutes les parties concernées, indiquez simplement que vous devez prendre une décision et quelle est votre décision. S'il existe un moyen de juger si votre décision sera mauvaise ou s'il est démontré ultérieurement qu'elle est fausse, changez-la le plus rapidement possible et reconnaissez les personnes qui avaient raison.

Demandez à votre équipe, en tant que groupe et individuellement, ce qui pourrait, selon elle, créer l’esprit d’équipe et créer une équipe efficace.

Félicitez fréquemment plutôt que généreusement. Reconnaissez tout particulièrement ceux qui ne sont pas d’accord avec vous quand ils sont louables. Félicitez en public et critiquez en privé, à une exception près : parfois, l’évolution ou la correction d'une faute ne peuvent être félicitées sans attirer l'attention embarrassante sur la faute d'origine, de sorte que l’évolution devrait être félicitée en privé.

C'est amusant de diviser un projet logiciel en tâches qui seront exécutées par des individus. Cela devrait être fait au plus tôt. Parfois, les responsables aiment penser qu’une estimation peut être faite sans tenir compte des personnes qui effectueront le travail. Ceci est impossible tant la productivité des individus varie. Les personnes ayant des connaissances particulières sur un composant changent également constamment et peuvent avoir un effet sur l'ordre de grandeur des performances.

Tout comme un compositeur considère le timbre de l'instrument qui jouera un rôle ou l'entraîneur d'une équipe sportive considère les forces de chaque joueur, le chef d'équipe expérimenté ne sera généralement pas en mesure de séparer la division du projet en tâches, des membres de l'équipe auxquelles elles seront affectées. Cela fait partie de la raison pour laquelle une équipe performante ne doit pas être divisée.

Cela présente un certain danger, car les gens s'ennuieront en misant sur leurs forces, sans jamais améliorer leurs faiblesses ni acquérir de nouvelles compétences. Cependant, la spécialisation est un outil de productivité très utile quand elle n’est pas trop utilisée.

Parfois, il n’est pas possible d’éviter des tâches fastidieuses essentielles au succès de l’entreprise ou du projet. Ces tâches peuvent vraiment nuire au moral de ceux qui doivent les accomplir. La meilleure technique, pour y remédier, consiste à invoquer ou à promouvoir la vertu de la paresse de Larry Wall, programmeur. Essayez de trouver un moyen de charger votre ordinateur de la tâche ou d'aider vos coéquipiers à le faire. Travailler pendant une semaine sur un programme pour effectuer une tâche qui prendra une semaine à la main a le grand avantage d’être plus éducatif et parfois plus reproductible.

Si tout le reste échoue, présentez des excuses à ceux qui doivent faire la tâche ennuyeuse, mais ne leur permettez en aucun cas de le faire seul. Au minimum, affectez une équipe de deux personnes pour effectuer le travail et promouvoir un travail d'équipe sain afin d'accomplir la tâche.

Pour obtenir le soutien pour un projet, créez et communiquez une vision qui démontre une réelle valeur pour l’organisation dans son ensemble. Essayez de laisser les autres partager votre vision. Cela leur donne une raison de vous soutenir et vous fait profiter de leurs idées. Recrutez individuellement des soutiens clefs pour votre projet. Dans la mesure du possible, montrez, ne dites pas. Si possible, construisez un prototype ou une maquette pour illustrer vos idées. Un prototype est toujours puissant, mais dans le logiciel, il est de loin supérieur à toute description écrite.

La graine d'un arbre contient l'idée de l'adulte, mais ne réalise pas complètement la forme et la puissance de l'adulte. L'embryon grandit. Il devient plus grand. Il ressemble plus à l'adulte et a plus d'usages. Finalement, il porte des fruits. Plus tard, il meurt et son corps nourrit d'autres organismes.

Nous avons le luxe de traiter un logiciel comme ça. Un pont n'est pas comme ça; il n'y a jamais de pont « bébé », mais simplement un pont inachevé. Les ponts sont beaucoup plus simples que les logiciels.

Il est bon de penser que les logiciels sont en croissance, car ils nous permettent de faire des progrès utiles avant d’avoir une image mentale parfaite. Nous pouvons obtenir les retours des utilisateurs et les utiliser pour corriger la croissance. L’élagage des membres faibles est une chose utile.

Le programmeur doit concevoir un système fini pouvant être livré et utilisé. Mais le programmeur avancé doit faire plus. Il doit concevoir un chemin de croissance qui se termine dans le système fini. C'est votre travail de prendre le germe d'une idée et de construire un chemin qui la transpose le plus facilement possible en un artefact utile.

Pour ce faire, vous devez visualiser le résultat final et le communiquer de manière à ce que l'équipe d'ingénieurs puisse s'enthousiasmer. Mais vous devez également communiquer aux programmeurs un chemin qui va de l’endroit où ils se trouvent à l’endroit où ils veulent être, sans grands sauts. L'arbre doit rester en vie tout le temps ; il ne peut pas être mort à un moment donné et ressusciter plus tard.

Cette approche est capturée dans le développement en spirale. Les jalons qui ne sont jamais trop éloignés sont utilisés pour marquer les progrès le long du chemin. Dans l'environnement extrêmement concurrentiel des entreprises, il est préférable que les jalons puissent être livrés et rapportent de l'argent le plus tôt possible, même s'ils sont loin d'un livrable bien conçu. L’un des travaux du programmeur consiste à trouver un équilibre entre les avantages immédiats et futurs, en choisissant judicieusement une trajectoire de croissance exprimée en étapes.

Le programmeur avancé assume la triple responsabilité de développer des logiciels, des équipes et des personnes.

Un lecteur, Rob Hafernik, a envoyé ce commentaire sur cette section que je ne saurais mieux faire que de citer intégralement :

« Je pense que vous sous-insistez sur l'importance ici. Ce ne sont pas que des systèmes, mais des algorithmes, des interfaces utilisateur, des modèles de données, etc. Lorsque vous travaillez sur un grand système, il est absolument essentiel de progresser de manière mesurable vers les objectifs intermédiaires. Rien n’est aussi grave que l’horreur particulière de s’attaquer à la fin et de découvrir que tout cela ne va tout simplement pas marcher (regardez la récente débâcle du système de nouvelles des électeurs). J'irais même plus loin et le qualifierais de loi de la nature : aucun système grand et complexe ne peut être mis en œuvre à partir de zéro, il ne peut qu’évoluer d'un système simple à un système complexe en une série d'étapes intentionnelles. »

A quoi on ne peut que répondre « Fiat lux ! »

Pour bien communiquer, il faut reconnaître à quel point c'est difficile. C'est une compétence en soi. Cela est rendu plus difficile par le fait que les personnes avec lesquelles vous devez communiquer sont imparfaites. Elles ne feront pas d'effort pour vous comprendre. Elles parlent mal et écrivent mal. Elles sont souvent surchargées de travail ou dérangées et, tout du moins, concentrées sur leur propre travail plutôt que sur les problèmes plus vastes auxquels vous pourriez vous attaquer. L'un des avantages de prendre des cours, de pratiquer l'écriture et la prise de parole en public ainsi que l'écoute est que si vous devenez bon, vous pouvez plus facilement voir où sont les problèmes et comment les corriger.

Le programmeur est un animal social dont la survie dépend de la communication avec son équipe. Le programmeur avancé est un animal social dont la satisfaction dépend de la communication avec des personnes extérieures à son équipe.

Le programmeur met de l'ordre dans le chaos. Une façon intéressante de faire cela est de lancer une proposition quelconque en dehors de l’équipe. Cela peut être fait dans un format papier blanc ou simplement verbalement. Ce leadership présente l’énorme avantage de fixer les termes du débat. Cela vous expose également à la critique et, pire encore, au rejet et à la négligence. Le programmeur avancé doit être prêt à accepter cela, car il a un pouvoir unique et donc une responsabilité unique. Les entrepreneurs qui ne sont pas des programmeurs ont besoin que ceux-ci fassent preuve de leadership à certains égards. Les programmeurs sont la partie du pont entre les idées et la réalité.

Je ne maîtrise pas bien la communication, mais ce que j’essaie actuellement, c’est de la considérer comme une approche à quatre volets : une fois la mise de mes idées en ordre, une préparation parfaite, je m'essaie à l'oral, je donne un papier blanc aux gens (sur papier réel, ainsi qu'électroniquement) pour leur faire une démonstration, puis je répète patiemment ce processus. Je pense que bien souvent nous ne sommes pas assez patients dans ce type de communication difficile. Vous ne devriez pas être découragé si vos idées ne sont pas immédiatement acceptées. Si vous avez investi de l'énergie dans leur préparation, personne ne vous le reprochera.

Vous devrez souvent dire aux gens des choses qui les rendront mal à l'aise. Rappelez-vous que vous faites cela pour une raison. Même si rien ne peut être fait pour résoudre le problème, dites-leur le plus tôt possible pour qu'ils soient bien informés.

La meilleure façon de parler d'un problème à quelqu'un est de proposer une solution en même temps. Le deuxième meilleur moyen est de faire appel à eux pour aider à résoudre le problème. S'il existe un danger que vous ne soyez pas cru, vous devriez trouver des personnes ou rassembler des preuves qui étayent vos propos.

L’une des choses les plus désagréables et les plus courantes que vous aurez à dire est : « Le planning devra être revu ». Le programmeur consciencieux déteste dire cela, mais il doit le dire le plus tôt possible. Il n’y a rien de pire que de remettre une action à plus tard quand le planning glisse, même si la seule action consiste à informer tout le monde. Ce faisant, il vaut mieux le faire en équipe, au moins spirituellement, si ce n'est pas fait physiquement. Vous voudrez connaître l'opinion de votre équipe sur votre position et les solutions possibles et l’équipe devra faire face aux conséquences avec vous.

Le mot mythe signifie parfois fiction. Mais il a une connotation plus profonde. Cela signifie également une histoire de signification religieuse qui explique l'univers et la relation de l'humanité avec lui. Les managers ont tendance à oublier ce qu'ils ont appris en tant que programmeurs et à croire à certains mythes. Il serait aussi impoli et infructueux d'essayer de les convaincre que ces mythes sont faux, que d'essayer de désillusionner une personne profondément dévote de ses propres croyances . Pour cette raison, vous devriez reconnaître ces croyances comme des mythes :

• plus de documentation est toujours mieux. (Ils le veulent, mais ils ne veulent pas que vous passiez du temps dessus.) ;
• des ressources peuvent être ajoutées à un projet en retard pour l'accélérer. (Le coût de la communication avec les nouvelles personnes est presque toujours plus élevé qu'utile.) ;
• il est possible d'estimer le développement de logiciels de manière fiable. (Ce n'est même pas théoriquement possible.) ;
• la productivité des programmeurs peut être mesurée à l'aide de métriques simples, telles que des lignes de code. (Si être succinct est le pouvoir, les lignes de code sont mauvaises, pas bonnes.).

Si vous avez une opportunité, vous pouvez essayer d'expliquer ces choses, mais ne vous sentez pas mal si vous ne réussissez pas et n'endommagez pas votre réputation en confrontant ces mythes de manière belliqueuse. Chacun de ces mythes renforce l'idée du responsable selon laquelle il contrôle réellement ce qui se passe. La vérité est que les gestionnaires facilitent s’ils sont bons et gênent s’ils sont mauvais.

Il y a souvent de brèves périodes de grand chaos organisationnel, telles que des relâches, des rachats, des introductions en bourse, des licenciements, de nouvelles embauches, etc. Cela dérange tout le monde, mais peut-être un peu moins le programmeur dont l'estime personnelle est fondée sur la capacité plutôt que sur la position. Le chaos organisationnel est une excellente occasion pour les programmeurs d'exercer leur pouvoir magique. Je l'ai gardé pour la fin, car c'est un secret tribal profond. Si vous n'êtes pas programmeur, arrêtez de lire maintenant.

Les ingénieurs ont le pouvoir de créer et de maintenir.

Les non-ingénieurs peuvent diriger du personnel, mais dans une entreprise de logiciels classique, rien ne peut être créé et maintenu sans les ingénieurs, tout comme les ingénieurs ne peuvent généralement pas vendre un produit ou gérer efficacement une entreprise. Ce pouvoir résiste à presque tous les problèmes liés au chaos temporaire de l’organisation. Quand vous en avez, vous devriez ignorer complètement le chaos et continuer comme si de rien n'était. Vous pouvez bien sûr vous faire virer, mais si cela se produit, vous pourrez probablement obtenir un nouvel emploi grâce au pouvoir magique. Plus généralement, une personne stressée qui n'a pas le pouvoir magique entrera dans votre cercle et vous dira de faire quelque chose de stupide. Si vous êtes vraiment sûr que c'est stupide, il est préférable de sourire et de hocher la tête jusqu'à ce qu'elle s'en aille, puis de continuer à faire ce que vous savez être le meilleur pour la société.

Si vous êtes un dirigeant, dites à votre personnel de faire la même chose et dites-leur d'ignorer ce que quelqu'un d'autre leur dit. Cette ligne de conduite est ce qu'il y a de mieux pour vous personnellement et pour votre entreprise ou votre projet.