GARDER UN PROGRAMME EN TÊTE

Août 2007

Un bon programmeur qui travaille intensément sur son propre code peut le garder en tête de la même manière qu'un mathématicien garde en tête un problème sur lequel il travaille. Les mathématiciens ne répondent pas aux questions en les rédigeant sur papier, comme on le fait à l'école. Ils le font plutôt dans leur tête : ils essaient de comprendre suffisamment bien l'espace d'un problème pour pouvoir s'y déplacer comme on peut se déplacer dans le souvenir de la maison dans laquelle on a grandi. Dans le meilleur des cas, la programmation est la même. Vous gardez tout le programme dans votre tête et vous pouvez le manipuler à volonté.

C'est particulièrement utile au début d'un projet, car au départ, le plus important est de pouvoir changer ce que l'on fait. Pas seulement pour résoudre le problème d'une manière différente, mais pour changer le problème que l'on résout.

Votre code est votre compréhension du problème que vous explorez. C'est donc seulement lorsque vous avez votre code en tête que vous comprenez vraiment le problème.

Il n'est pas facile de mettre un programme dans sa tête. Si vous laissez un projet de côté pendant quelques mois, il peut vous falloir des jours pour vraiment le comprendre à nouveau lorsque vous y revenez. Même lorsque vous travaillez activement sur un programme, il peut vous falloir une demi-heure pour le charger dans votre tête lorsque vous commencez à travailler chaque jour. Et ce, dans le meilleur des cas. Les programmeurs ordinaires qui travaillent dans des conditions de bureau classiques n'entrent jamais dans ce mode. Ou, pour le dire plus dramatiquement, les programmeurs ordinaires qui travaillent dans des conditions de bureau classiques ne comprennent jamais vraiment les problèmes qu'ils résolvent.

Même les meilleurs programmeurs n'ont pas toujours en tête l'intégralité du programme sur lequel ils travaillent. Mais il y a des choses que vous pouvez faire pour y parvenir :

Évitez les distractions. Les distractions sont néfastes pour de nombreux types de travail, mais elles sont particulièrement néfastes pour la programmation, car les programmeurs ont tendance à travailler à la limite des détails qu'ils peuvent gérer.

Le danger d'une distraction ne dépend pas de sa durée, mais de la façon dont elle brouille votre cerveau. Un programmeur peut quitter le bureau et aller chercher un sandwich sans perdre le code qu'il a en tête. Mais une interruption malvenue peut vider votre cerveau en 30 secondes.

Curieusement, les distractions programmées peuvent être pires que celles qui ne sont pas programmées. Si vous savez que vous avez une réunion dans une heure, vous ne commencez même pas à travailler sur quelque chose de difficile.

Travaillez sur de longues périodes. Comme il y a un coût fixe à chaque fois que vous commencez à travailler sur un programme, il est plus efficace de travailler sur quelques longues sessions que sur plusieurs courtes. Il arrivera bien sûr un moment où vous deviendrez stupide parce que vous serez fatigué. Cela varie d'une personne à l'autre. J'ai entendu parler de personnes qui ont piraté pendant 36 heures d'affilée, mais le maximum que j'ai pu gérer est d'environ 18 heures, et je travaille mieux par tranches de 12 heures maximum.

L'optimum n'est pas la limite que vous pouvez supporter physiquement. Il y a un avantage, mais aussi un coût, à interrompre un projet. Parfois, lorsque vous revenez à un problème après une pause, vous découvrez que votre inconscient vous a laissé une réponse en attente.

Utilisez des langages concis. Les langages de programmation plus puissants rendent les programmes plus courts. Et les programmeurs semblent penser les programmes au moins partiellement dans le langage qu'ils utilisent pour les écrire. Plus le langage est concis, plus le programme est court et plus il est facile à charger et à garder en tête.

Vous pouvez amplifier l'effet d'un langage puissant en utilisant un style appelé programmation ascendante, où vous écrivez des programmes sur plusieurs couches, les couches inférieures faisant office de langages de programmation pour celles situées au-dessus. Si vous faites cela correctement, vous n'aurez plus qu'à garder en tête la couche supérieure.

Continuez à réécrire votre programme. Réécrire un programme donne souvent une conception plus propre. Mais même si ce n'était pas le cas, cela aurait des avantages : vous devez comprendre un programme dans son intégralité pour le réécrire, il n'y a donc pas de meilleur moyen de vous le faire comprendre.

Écrivez du code lisible. Tous les programmeurs savent qu'il est bon d'écrire du code lisible. Mais vous êtes vous-même le lecteur le plus important. Surtout au début ; un prototype est une conversation avec vous-même. Et lorsque vous écrivez pour vous-même, vous avez d'autres priorités. Si vous écrivez pour d'autres personnes, vous ne voudrez peut-être pas créer un code trop dense. Certaines parties d'un programme peuvent être plus faciles à lire si vous étalez les choses, comme un manuel d'introduction. En revanche, si vous écrivez du code pour qu'il soit facile à recharger dans votre tête, il peut être préférable d'opter pour la concision.

Travaillez en petits groupes. Lorsque vous manipulez un programme dans votre tête, votre vision a tendance à s'arrêter aux limites du code que vous possédez. Vous ne comprenez pas aussi bien les autres parties et, plus important encore, vous ne pouvez pas prendre de libertés avec elles. Ainsi, plus le nombre de programmeurs est réduit, plus un projet peut muter complètement. S'il n'y a qu'un seul programmeur, comme c'est souvent le cas au début, vous pouvez procéder à des refontes complètes.

Ne laissez pas plusieurs personnes éditer le même morceau de code. Vous ne comprendrez jamais le code des autres aussi bien que le vôtre. Peu importe à quel point vous l'avez lu, vous l'avez seulement lu, vous ne l'avez pas écrit. Ainsi, si un morceau de code est écrit par plusieurs auteurs, aucun d'entre eux ne le comprendra aussi bien qu'un seul auteur.

Et bien sûr, vous ne pouvez pas repenser en toute sécurité quelque chose sur lequel d'autres personnes travaillent. Il ne s'agit pas seulement de demander la permission. Vous ne vous autorisez même pas à penser à de telles choses. Repenser un code avec plusieurs auteurs, c'est comme changer les lois ; repenser un code que vous contrôlez seul, c'est comme voir l'autre interprétation d'une image ambiguë.

Si vous souhaitez confier à plusieurs personnes le travail sur un projet, divisez-le en plusieurs parties et attribuez chacune d'elles à une seule personne.

Commencez petit. Un programme devient plus facile à retenir dans votre tête à mesure que vous vous familiarisez avec lui. Vous pouvez commencer à traiter les parties comme des boîtes noires une fois que vous êtes sûr de les avoir entièrement explorées. Mais lorsque vous commencez à travailler sur un projet, vous êtes obligé de tout voir. Si vous commencez avec un problème trop important, vous ne pourrez peut-être jamais vraiment l'englober. Donc, si vous devez écrire un programme important et complexe, la meilleure façon de commencer n'est peut-être pas d'écrire une spécification pour celui-ci, mais d'écrire un prototype qui résout un sous-ensemble du problème. Quels que soient les avantages de la planification, ils sont souvent contrebalancés par les avantages de pouvoir garder un programme dans votre tête.

Il est frappant de constater à quel point les programmeurs parviennent souvent à atteindre les huit points par accident. Quelqu'un a une idée pour un nouveau projet, mais comme il n'est pas officiellement approuvé, il doit le faire en dehors des heures de travail, ce qui s'avère plus productif car il n'y a pas de distractions. Poussé par son enthousiasme pour le nouveau projet, il y travaille pendant de nombreuses heures d'affilée. Comme il ne s'agit au départ que d'une expérience, au lieu d'un langage de « production », il utilise un simple langage de « script », qui est en fait beaucoup plus puissant. Il réécrit entièrement le programme plusieurs fois, ce qui ne serait pas justifiable pour un projet officiel, mais c'est un travail d'amour et il veut qu'il soit parfait. Et comme personne d'autre que lui ne le verra, il omet tous les commentaires, sauf ceux qu'il s'adresse à lui-même. Il travaille en petit groupe par nécessité, parce qu'il n'a encore parlé de son idée à personne d'autre, ou parce qu'elle semble si peu prometteuse que personne d'autre n'est autorisé à y travailler. Même s'il y a un groupe, il ne peut pas y avoir plusieurs personnes qui éditent le même code, car il évolue trop vite pour que cela soit possible. Et le projet commence petit parce que l'idée est petite au départ ; il a juste un hack cool qu'il veut essayer.

Ce qui est encore plus frappant, c'est le nombre de projets officiellement approuvés qui réussissent à faire les huit choses de travers . En fait, si vous regardez la façon dont les logiciels sont écrits dans la plupart des organisations, c'est presque comme si elles essayaient délibérément de faire les choses de travers. Dans un sens, c'est le cas. L'une des qualités qui définissent les organisations depuis qu'elles existent est de traiter les individus comme des pièces interchangeables. Cela fonctionne bien pour des tâches plus parallélisables, comme la guerre. Pendant la majeure partie de l'histoire, on pouvait compter sur une armée de soldats professionnels bien entraînés pour vaincre une armée de guerriers individuels, aussi vaillants soient-ils. Mais avoir des idées n'est pas très parallélisable. Et c'est ce que sont les programmes : des idées.

Il n'est pas seulement vrai que les organisations n'aiment pas l'idée de dépendre du génie individuel, c'est une tautologie. Cela fait partie de la définition d'une organisation. De notre conception actuelle d'une organisation, du moins.

Peut-être pourrions-nous définir un nouveau type d'organisation qui combinerait les efforts des individus sans exiger qu'ils soient interchangeables. On peut soutenir qu'un marché est une telle forme d'organisation, même s'il serait peut-être plus exact de décrire un marché comme un cas dégénéré, comme ce que l'on obtient par défaut lorsque l'organisation n'est pas possible.

La meilleure solution serait probablement de faire quelque chose de différent, comme faire en sorte que les parties de programmation d'une organisation fonctionnent différemment des autres. Peut-être que la solution optimale serait que les grandes entreprises n'essaient même pas de développer des idées en interne, mais simplement de les acheter . Mais quelle que soit la solution, la première étape consiste à se rendre compte qu'il y a un problème. Il y a une contradiction dans l'expression même de « société de logiciels ». Les deux mots vont dans des directions opposées. Tout bon programmeur dans une grande organisation sera en désaccord avec cela, car les organisations sont conçues pour empêcher ce que les programmeurs s'efforcent de faire.

Les bons programmeurs parviennent à accomplir beaucoup de choses, mais cela nécessite souvent un acte de rébellion contre les entreprises qui les emploient. Peut-être serait-il utile que davantage de gens comprennent que le comportement des programmeurs est déterminé par les exigences du travail qu'ils accomplissent. Ce n'est pas parce qu'ils sont irresponsables qu'ils travaillent pendant de longues périodes pendant lesquelles ils oublient toutes leurs autres obligations, se plongent directement dans la programmation au lieu d'écrire d'abord des spécifications et réécrivent du code qui fonctionne déjà. Ce n'est pas parce qu'ils sont hostiles qu'ils préfèrent travailler seuls ou grogner après les gens qui passent la tête par la porte pour leur dire bonjour. Cette collection apparemment aléatoire d'habitudes ennuyeuses n'a qu'une seule explication : le pouvoir de garder un programme dans sa tête.

Que cette compréhension puisse ou non aider les grandes entreprises, elle peut certainement aider leurs concurrents. Le point faible des grandes entreprises est qu'elles ne laissent pas les programmeurs individuels faire du bon travail. Donc, si vous êtes une petite start-up, c'est l'endroit idéal pour les attaquer. Attaquez-vous au genre de problèmes qui doivent être résolus par un seul grand cerveau.

Merci à Sam Altman, David Greenspan, Aaron Iba, Jessica Livingston, Robert Morris, Peter Norvig, Lisa Randall, Emmett Shear, Sergei Tsarev et Stephen Wolfram pour avoir lu les brouillons de cet article.