Devez-vous écrire une bonne documentation et du code propre pour augmenter le «facteur de bus»?

L’un des principaux objectifs des sociétés de développement de logiciels est d’augmenter leur facteur Bus. C’est également ce que préconise un exposé organisé par Google .

Cela signifie que vous devez tout coder et documenter de manière à ce que le projet puisse continuer si vous êtes dépassé demain par un autobus. En d'autres termes, vous devez vous rendre facilement remplaçable par un autre programmeur possédant les mêmes compétences que le vôtre.

Être remplaçable, n'est-ce pas contre l'intérêt d'un développeur? Dans le livre, 48 lois du pouvoir, la Règle 11 stipule que vous devez essayer de garder les gens dépendants de vous afin d’obtenir le pouvoir, ce qui se traduit ensuite par des récompenses monétaires.

En dehors du scénario où vous avez besoin de documentation pour pouvoir poursuivre un projet après 6 mois de pause, il semble exister un conflit d'intérêts évident entre le développeur et l'éditeur de logiciel.

Donc, en tant que programmeur, devriez-vous vraiment écrire une excellente documentation et un code facilement lisible pour tout le monde; ou devriez-vous écrire le code et la documentation de manière à ce que le travail soit fait et que vous puissiez le comprendre vous-même, mais qu'une autre personne puisse avoir du mal à le comprendre?

Vous devez vous efforcer de devenir irremplaçable non pas en écrivant du code, mais en rassemblant plus d'expérience et de connaissances que les autres. L’ancienne méthode fait de vous un développeur que tout le monde essaie d’éviter de travailler avec, car ils craignent et répugnent à maintenir le code que vous avez écrit. De cette manière, vous devenez un membre recherché de l’équipe, que les responsables veulent intégrer à leur équipe.

Dans mon expérience, écrire du code propre, bien documenté (et de préférence auto-documenté) a toujours porté ses fruits. En fait, je saisissais presque toutes les occasions d'aider et d'enseigner aux autres (ainsi que d'apprendre d'eux quand ils savaient quelque chose de mieux) et je ne me sentais presque jamais en danger de me faire remplacer par quelqu'un de moins capable que moi. En fait, cela a généralement aidé toute l’équipe à mieux travailler et à résoudre les problèmes plus rapidement, ce qui est le rêve de tout responsable. Un responsable avisé ne veut pas remplacer les membres d’une bonne équipe.

Si vous manipulez des organisations ou des personnes d'une manière si transparente, il vaut mieux être stupide ou dans un embouteillage qui ne leur laisse pas d'autre choix. Un atelier de développement logiciel bien géré examinerait votre code obscur et la documentation manquante et vous licencierait simplement avant que vous ne fassiez beaucoup de dégâts. S'ils sont mal gérés, ou incapables de faire travailler d'autres développeurs, pourquoi voudriez-vous avoir une sinécure avec eux?

PS Ni M. Greene ni M. Machiavel n’ont accompli grand-chose en dehors de l’écriture de livres qui essayaient de flatter les "hommes durs" de l’époque. Suivez leurs conseils avec un grain de sel.

Si vous êtes irremplaçable, vous ne pouvez pas être promu.

Vous ne voulez pas être irremplaçable. Vous ne voulez pas que les gens se sentent dépendants de vous, vous voulez qu'ils vous apprécient. En règle générale, vous voulez rester loin des gens, qui croient que même la moitié des lois du pouvoir devrait être appliquée aux relations (professionnelles ou personnelles).
Ces règles sont un ensemble d’instructions sur la manière d’établir avec succès une situation gagnant-perdant. Ce que vous voulez, c'est une situation gagnant-gagnant .
Dès que les gens commencent à ressentir, vous essayez de les pousser du côté des perdants dans une situation gagnant-perdant, ils vont riposter. Les tentatives visant à établir des situations gagnant-perdant aboutissent souvent à un résultat perdant-perdant, car vous gaspillez effectivement des ressources pour placer votre partenaire dans une position de perdant, au lieu de les investir dans la réussite globale de votre partenariat.

Si vous faites cela avec vos employeurs, ils essaieront de vous imposer des mesures, afin de réduire votre monopole du savoir. Généralement, ce sont des directives ridicules sur la façon dont vous devez faire votre travail et transformeront ainsi votre vie professionnelle en un enfer vivant. De plus, ils vous appelleront à 3 heures du soir lorsque quelque chose se brise, car vous êtes la seule personne à pouvoir le réparer. Vouloir exploiter des situations telles que l’effet de levier risque de se retourner contre vous et de vous causer plus de problèmes.

Les cimetières sont pleins d'hommes indispensables.
- Gaulle, Charles De

Alors coupez la merde et faites votre travail correctement. Si ce n'est pas pour autre chose, alors pour vous, car vous êtes probablement la pauvre âme, qui doit apporter des modifications au code dans 2 ans.

Les réponses négatives ne sont pas trop surprenantes, étant donné le nombre de programmeurs meilleurs que la moyenne que ce site attire. Les personnes talentueuses n'ont généralement pas besoin de recourir à ce type de tactiques de sécurité par obfuscation. Mais je travaillais chez un équipementier automobile du Fortune 500 avec quelques développeurs peu talentueux qui s'étaient taillés des fiefs pour eux-mêmes, qu'ils gardaient avec zèle en créant de nombreux documents pour les interfaces épouvantables qu'ils avaient conçues.

Tout le travail d'un type consistait à gérer le code d'un module reliant deux sous-systèmes entièrement distincts, permettant ainsi aux modules de chaque système de communiquer via un UART. En gros, il s’agissait de la programmation série 101. Au lieu de simplement créer une interface générale ressemblant à ceci:

  int sendData (int targetModule, void * data, size_t byteCount);
  int recvData (int sourceModule, void * data, size_t maxBytes);

il a créé des codes d'opération distincts pour chaque message que deux modules communicants pourraient vouloir s'envoyer l'un à l'autre. Ce qui voulait dire que son module devait connaître chaque message et devait être mis à jour chaque fois qu'un message était ajouté ou modifié. Parlez d'intimité inappropriée!

Le problème, c’est que ce gars a gardé un document Word répertoriant tous les opcodes / messages et l’a mis à jour avec diligence au besoin. C'est devenu tout son travail . Quelques fois par semaine, il envoyait une nouvelle révision à tous les malheureux qui l'avaient laissé sur son chemin critique. Et cela a été considéré comme «professionnel», car la direction aimait voir de la documentation. Kinda me fait pleurer pour l'industrie automobile.

Je suppose que mon propos est le suivant: parfois, rédiger une documentation peut en fait protéger des programmeurs médiocres. Les gestionnaires ne peuvent souvent pas faire la différence entre une bonne conception et une mauvaise, et beaucoup sont obligés de prendre des décisions techniques avec des informations limitées. C'est incroyablement stressant pour eux. Voir un document Word avec des dizaines de tableaux bien formatés peut être très réconfortant, même si ce qu'il décrit est une idée fondamentalement mauvaise.

Être remplaçable, n'est-ce pas contre l'intérêt d'un développeur?

Je déteste te le dire, mais tout le monde est remplaçable. Bien sûr, il peut parfois être un léger défi de vous remplacer (si vous êtes expérimenté et assez brillant), mais il est impossible de trouver des années lumière.

Pour être vraiment un produit de valeur pour votre employeur (non seulement l'employeur actuel, mais tout employeur), vous devez démontrer votre capacité à écrire un code aussi facile à comprendre pour quiconque le lira (peu de temps pour travailler avec lui) et documenter. le code (n'importe qui peut obtenir une vue d'ensemble de haut niveau de vos systèmes sans creuser dans le code).

Être réellement bon en documentation de code est une qualité difficile à obtenir de nos jours, alors cela seul aidera à vous différencier des autres.

Un code propre et bien documenté mérite également d’être mis sur un CV (du moins, des résultats tangibles, c’est-à-dire "nous avons été en mesure de recruter de nnouveaux développeurs avec un minimum de montée en puissance et une assistance minimale grâce à ma documentation"). vous-même "irremplaçable" n'est pas.

Être remplaçable, n'est-ce pas contre l'intérêt d'un développeur?

Cela dépend des intérêts de ce développeur. Si vous êtes un homme qui veut rester dans le même emploi pendant toute sa carrière, soyez absolument indispensable pour une entreprise qui récompense l'incompétence et gagne beaucoup d'argent, alors oui, absolument.

Mais que se passe-t-il lorsque l'entreprise se bloque, probablement parce qu'elle a embauché trop de personnes de ce type? Où vas-tu aller ensuite? Qu'en est-il lorsqu'ils vous demandent pourquoi vous avez occupé le même emploi pendant 15 ans? Etc.

Maintenant, voyons les choses différemment: combien de développeurs ont perdu leur emploi en écrivant du code que tout le monde peut lire?

La seule probabilité que cela se produise est si l'entreprise est en difficulté et rend les personnes licenciées. Si cela se produit, vous feriez mieux de sortir et vous serez très bien préparé pour les prochaines interviews. De plus, votre conscience sera complètement libre - vous ne laisserez pas de code inexplicable que vous avez écrit pour votre propre gain.

Je ne sais pas quel genre de personne vous êtes, mais cela sert mieux mes intérêts.

Personnellement, je pense qu'une de mes plus grandes forces réside dans l'automatisation de mon propre travail. Que pensez-vous qu'une entreprise a tendance à penser lorsque je suis devenu excédentaire par rapport à mes propres besoins? Pensent-ils "ok, nous allons nous débarrasser de lui maintenant" ou pensent-ils "pourquoi ne le transfère-t-il pas dans un autre rôle et le laissons-t-il à nouveau"?

Être remplaçable, n'est-ce pas contre l'intérêt d'un développeur?

Vous avez raison, mais je pense que vous avez mal compris le sens de «remplaçable». Je pourrais trouver un millier de développeurs qui écrivent du code mouvementé, des documents non documentés qui peuvent rapidement se transformer en désordre intenable.

Développeurs qui produisent non seulement des programmes stables, mais aussi du code épuré, une documentation informative et assurent la continuité du projet, ce qui est non seulement irremplaçable, mais aussi inestimable .

Je vais aborder cette question sous un angle différent, car il existe déjà plusieurs excellentes réponses.

Pensez à ce qui se passe lorsque vous jouez à de petits jeux en essayant de vous rendre "irremplaçable" tout en empêchant les autres d'apprendre le fonctionnement de votre code. Vous restez dans le même travail en maintenant vos propres dégâts aussi longtemps que l'entreprise vous tolère. Et c’est le meilleur des scénarios. Le pire des scénarios, c’est que d’autres ingénieurs et cadres de votre entreprise, plus talentueux et plus éthiques, voient l’encombrement que vos mauvaises pratiques imposent à l’entreprise et ils décident de réagir, en vous licenciant et en le réécrivant. tout à partir de zéro. C'est fait. En fait, c'est une chose assez commune à se produire.

Maintenant, considérons ce qui se passe lorsque vous écrivez un bon code et une bonne documentation. Vous créez un composant ou un système qui fonctionne bien et qui, après un certain temps de fonctionnement, corrige les bogues et fonctionne sans problème. Il faut peu d'effort pour le maintenir. Vous pouvez ensuite passer à des projets plus grands et meilleurs, avec une solide victoire à votre actif. Les gens vous reconnaîtront pour avoir fait du bon travail et commenceront à respecter votre opinion. Vous aurez la possibilité de progresser dans la chaîne alimentaire et de prendre des décisions plus significatives, ou d'effectuer un travail plus important et impactant, ou de gérer des projets à un niveau supérieur. Votre carrière va s'améliorer, vous serez promu, vous gagnerez plus d'argent, vous serez reconnu et approuvé par vos pairs, vous ajouterez de plus en plus de succès dans des projets de plus en plus importants.

Quel itinéraire préféreriez-vous?

Si vous êtes le seul point d'échec, votre client (ou votre employeur) tentera probablement de vous remplacer. il y a toujours un point où il est moins coûteux de remplacer un logiciel que de le maintenir, même si cela semble essentiel. Il y a une raison pour laquelle l'informatique est l'une des professions les plus externalisables.

En revanche, être remplaçable vous procure plusieurs avantages inestimables:

• pouvoir prendre des vacances
• ne pas être sur appel
• liberté de partir et de travailler sur un projet nouveau et intéressant

Si vous ne passez pas 5 minutes à rédiger une documentation rapide, vous passerez une heure à la relire et à l'expliquer aux personnes qui souhaitent utiliser votre code.

Pire encore pourrait passer des jours à chercher un nouvel emploi parce que votre patron a découvert que vous n’écriviez pas de code maintenable.

Une excellente documentation finira par devenir obsolète en refactorisation / évolutions, et sa mise à jour prend beaucoup de temps.

Code propre + test unitaire> excellente documentation

La réponse à ta question est oui". Oui, vous devriez écrire une bonne documentation et du code propre. Le fait de vouloir délibérément faire autrement montre un manque d'intégrité, ce qui, même s'il est de plus en plus répandu dans le monde des affaires, n'est soudainement pas une "bonne" chose.

Personne n'est irremplaçable. Les personnes qui fabriquent une situation dans laquelle elles se pensent ont tendance à découvrir qu'elles ne le sont pas. Construire une co-dépendance pour vous-même est contre-productif car cela vous limite également, pas seulement à votre employeur.

L’un des principaux objectifs des sociétés de développement de logiciels est d’augmenter leur facteur de bus.

Fausse prémisse. Les principaux objectifs d'une entreprise de développement de logiciels (de tous ceux dans lesquels j'ai travaillé) sont de produire le meilleur logiciel possible et de gagner de l'argent, pas nécessairement dans cet ordre. Réduire le "facteur autobus" n'est qu'un moyen d'éviter de perdre de l'argent.

Loi 11 Apprenez à garder les gens dépendants de vous.

Qu'est-ce que cela signifie pour vous?

Voulez-vous que les gens dépendent de vous parce que vous les avez minés de telle manière qu'ils ne peuvent aller de l'avant qu'avec votre aide? Ou voulez-vous que les gens dépendent de vous parce que vous êtes intelligent et perspicace, fiable, digne de confiance et capable d'aider les autres à mieux faire leur travail? Voulez-vous gâcher vos collègues sans votre aide, ou voulez-vous qu'ils vous apprécient de les avoir bien rendus?

C'est ton appel.

(en supposant le code de production)

J'ai tendance à aller un peu plus loin. J'ai écrit sur la façon de faire des programmes "idiot proof", mais je ne le qualifie pas toujours: j'écris beaucoup de code que d'autres personnes ne verront pas ou avec lequel ils ne travailleront pas (du moins, c'est ce à quoi on s'attend quand il est écrit). jeJe suis l'idiot dont j'essaie de me défendre dans ce cas. C'est une bonne chose que votre programme détecte des problèmes pour vous, et le problème a été tellement simplifié qu'il est assez évident qu'il y a une erreur et son origine. En réalité, les détails d'implémentation sont évidents lorsque vous écrivez un programme (sauf si vous l'implémentez prématurément), mais ils doivent être résumés et résistants aux erreurs pour les clients (même lorsque la localité du module existe). La raison en est que les programmes deviennent très complexes. Parfois, vous pouvez séparer les problèmes, mais pas tout le temps. Si vous maintenez vos composants très stricts, simples, bien encapsulés et à l'abri des puzzles, ils ont tendance à bien s'adapter et la plupart des défauts sont détectés avant leur expédition. Il est plus facile de réutiliser, et vous avez plus de confiance et plus de facilité à réutiliser les programmes. ces programmes complexes que vous écrivez deviennent plus complexes (même pour vous) après un certain temps d'absence du programme. Lorsque vous le lisez en 6 mois, la compréhension et le débogage peuvent prendre un temps absurde par rapport à la version idiot proof. Si un composant introduit un changement radical, il peut rester indétectable pendant longtemps sinon. Les programmes sont complexes. vous ne pouvez pas échapper à cette réalité, mais vous pouvez le rendre infaillible, ce qui vous facilitera grandement la vie lorsque quelque chose ne va pas ou s'il doit être réutilisé ou modifié. Par conséquent, l'approche imbécile signifie que votre logiciel peut être compris, réutilisé ou mis à jour par vos juniors ou les personnes les plus récentes de l'équipe (et pas seulement par quelqu'un d'aussi bon / expérimenté que vous). Le remplacement est une préoccupation distincte: si les gens aiment travailler avec vos programmes, vous faites du bon travail - ne ' Ne vous inquiétez pas du remplacement. Bien sûr, je pourrais imaginer des scénarios dans lesquels des programmes inintelligibles pourraient sauver votre travail, mais écrire un bon programme que d’autres peuvent utiliser et maintenir est clairement le moindre mal (regardez les réponses des autres). Si je me surprends à écrire quelque chose qui n'est pas idiot, j'essaie de résoudre ce problème.

En dehors du scénario où vous avez besoin de documentation pour pouvoir poursuivre un projet après 6 mois de pause, il semble exister un conflit d'intérêts évident entre le développeur et l'éditeur de logiciel.

Vous ne savez vraiment pas à quoi vous pensiez lorsque vous revisitez des implémentations en veille. Lorsque vous êtes vraiment expérimenté, le problème est plus simple car vous pouvez vous fier davantage aux méthodologies établies ou aux approches que vous utilisez. Cela suppose toutefois que ces méthodologies sont invariantes. Même si la documentation peut être laxiste, vous devez toujours être défensif dans vos implémentations (par exemple, vous savez mieux que de passer NULL dans ce scénario - testez cette condition).

Donc, en tant que programmeur, devriez-vous vraiment écrire une excellente documentation et un code facilement lisible pour tout le monde; ou devriez-vous écrire le code et la documentation de manière à ce que le travail soit fait et que vous puissiez le comprendre vous-même, mais qu'une autre personne puisse avoir du mal à le comprendre?

Je recommande l'approche imbécile, qui est encore plus claire et plus résistante aux erreurs que l'approche par facteur de bus. Ecrivez vos programmes et votre documentation de manière à ce qu'ils soient facilement compris par quelqu'un de l'extérieur du projet. C'est bon pour vous aussi. Cela augmentera votre valeur pour votre entreprise et votre équipe, ils ne voudront pas vous remplacer.

Vous avez fondamentalement mal compris le jeu. Le jeu ne consiste pas à continuer à faire comme avant, à être responsable de tout le code que vous avez écrit car personne d'autre ne le comprend. Le jeu consiste à terminer un projet et à passer au suivant, en laissant derrière lui le code que quelqu'un d'autre peut facilement comprendre et avec lequel travailler en votre absence, afin que vous puissiez faire de nouvelles choses et assumer plus de responsabilités. Votre prémisse ne fonctionne que si vous êtes heureux de devoir faire la même chose encore et encore, sans possibilité d'apprendre ni de vous améliorer.

Je vous ferai également remarquer que si vous n'avez pas souvent l'occasion d'examiner ce code, vous aurez également de la difficulté à le comprendre dans six mois si vous le dissimulez délibérément.

Je documente le petit code que j'écris, non pas pour que les autres puissent le lire, mais pour que je puisse le lire dans 3 mois! Il s'agit de faciliter la maintenance. Si vous êtes responsable du code que vous avez écrit et que vous ne pouvez pas corriger les bogues qui apparaîtront plus tard dans la ligne, vous voudrez qu'il soit bien documenté ... Il est peu important que vous soyez remplaçable si vous n'êtes pas capable. faire votre travail!

Tous les informaticiens "irremplaçables" avec lesquels j'ai eu la malchance d'interagir ont été remplacés, en grande partie parce qu'ils essayaient de tenir en otage les ressources de leurs employeurs. Lorsque des personnes qui me font rapport me disent que leur temps est trop précieux pour "gaspiller" de la documentation, je les remplace dès que possible.

Il semblerait que si un futur employé considère que les 48 lois du pouvoir sont éthiquement ou moralement acceptables, il serait préférable de s'en passer.

Si vous voulez VRAIMENT être irremplaçable (ce que vous voudrez peut-être reconsidérer après avoir lu toutes les réponses ...), pourquoi ne pas documenter le code?

Il existe un guide vraiment brillant sur la façon d'écrire du code non maintenable que vous devriez absolument lire: http://thc.org/root/phun/unmaintain.html

Prendre plaisir! (J'ai certainement fait ...)