TENIR UN PROGRAMME DANS SA TÊTE

Août 2007

Un bon programmeur travaillant intensément sur son propre code peut le garder en tête de la même manière qu'un mathématicien garde un problème sur lequel il travaille. Les mathématiciens ne répondent pas aux questions en les résolvant sur papier comme on l'enseigne aux écoliers. Ils font davantage dans leur tête : ils essaient de comprendre un espace problème suffisamment bien pour pouvoir s'y déplacer comme on peut se déplacer dans la mémoire de la maison où l'on a grandi. Au mieux, la programmation est la même chose. Vous gardez le programme entier dans votre tête et vous pouvez le manipuler à volonté.

Cela est particulièrement précieux au début d'un projet, car initialement la chose la plus importante est de pouvoir changer ce que vous faites. Pas seulement pour résoudre le problème d'une manière différente, mais pour changer le problème que vous résolvez.

Votre code est votre compréhension du problème que vous explorez. Donc ce n'est que lorsque vous avez votre code dans votre tête que vous comprenez vraiment le problème.

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

Même les meilleurs programmeurs n'ont pas toujours tout le programme sur lequel ils travaillent chargé dans leur tête. Mais il y a des choses que vous pouvez faire pour aider :

Évitez les distractions. Les distractions sont mauvaises pour de nombreux types de travail, mais surtout mauvaises pour la programmation, car les programmeurs ont tendance à opérer à 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 dans sa tête. Mais le mauvais type d'interruption peut vous effacer le cerveau en 30 secondes.

Étrangement, les distractions programmées peuvent être pires que les imprévues. 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 en longues séances. Puisqu'il y a un coût fixe chaque fois que vous commencez à travailler sur un programme, il est plus efficace de travailler en quelques longues séances plutôt que de nombreuses courtes. Il viendra bien sûr un moment où vous deviendrez stupide parce que vous êtes fatigué. Cela varie d'une personne à l'autre. J'ai entendu parler de gens qui ont piraté pendant 36 heures d'affilée, mais le plus que j'ai jamais pu faire est d'environ 18, et je travaille mieux par tranches de 12 heures maximum.

L'optimum n'est pas la limite que vous pouvez physiquement endurer. Il y a un avantage ainsi qu'un coût à diviser un projet. Parfois, lorsque vous revenez à un problème après un repos, vous trouvez que votre esprit inconscient a laissé une réponse en attente pour vous.

Utilisez des langages concis. Les langages de programmation plus puissants rendent les programmes plus courts. Et les programmeurs semblent penser aux programmes au moins partiellement dans la langue qu'ils utilisent pour les écrire. Plus le langage est concis, plus le programme est court, et plus il est facile de le charger et de le 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 en plusieurs couches, les couches inférieures servant de langages de programmation pour celles au-dessus. Si vous faites cela correctement, vous n'avez qu'à garder la couche supérieure dans votre tête.

Réécrivez votre programme. Réécrire un programme donne souvent une conception plus propre. Mais cela aurait des avantages même si ce n'était pas le cas : vous devez comprendre complètement un programme pour le réécrire, donc il n'y a pas de meilleure façon de le charger dans votre tête.

Écrivez un code facile à relire. Tous les programmeurs savent qu'il est bon d'écrire un code lisible. Mais vous-même êtes le lecteur le plus important. Surtout au début ; un prototype est une conversation avec vous-même. Et quand 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 rendre le code trop dense. Certaines parties d'un programme peuvent être plus faciles à lire si vous les étalez, comme un manuel d'introduction. Alors que si vous écrivez du code pour le charger facilement dans votre tête, il peut être préférable d'aller pour la concision.

Travaillez en petits groupes. Lorsque vous manipulez un programme dans votre tête, votre vision a tendance à s'arrêter au bord du code que vous possédez. Les autres parties, vous ne les comprenez pas aussi bien et, plus important encore, vous ne pouvez pas vous permettre d'y apporter des libertés. Donc plus le nombre de programmeurs est petit, 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 faire des redesigns englobants.

N'ayez pas plusieurs personnes qui éditent le même morceau de code. Vous ne comprenez jamais le code des autres aussi bien que le vôtre. Peu importe à quel point vous l'avez lu attentivement, vous l'avez seulement lu, pas écrit. Donc si un morceau de code est écrit par plusieurs auteurs, aucun d'entre eux ne le comprend aussi bien qu'un seul auteur le ferait.

Et bien sûr, vous ne pouvez pas redessiner en toute sécurité quelque chose sur lequel d'autres personnes travaillent. Ce n'est pas seulement que vous devriez demander la permission. Vous ne vous laissez même pas penser à de telles choses. Redessiner un code avec plusieurs auteurs est comme changer des lois ; redessiner un code dont vous êtes le seul maître est comme voir l'autre interprétation d'une image ambiguë.

Si vous voulez mettre plusieurs personnes au travail sur un projet, divisez-le en composants et donnez-en un à chacune.

Commencez petit. Un programme devient plus facile à garder en tête à mesure que vous vous familiarisez avec lui. Vous pouvez commencer à traiter des parties comme des boîtes noires une fois que vous êtes sûr d'avoir complètement exploré. Mais lorsque vous commencez à travailler sur un projet, vous êtes obligé de tout voir. Si vous commencez avec un problème trop gros, vous ne pourrez peut-être jamais vraiment l'englober. Donc si vous devez écrire un programme grand et complexe, la meilleure façon de commencer peut ne pas être d'écrire une spécification pour lui, 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 compensés par les avantages de pouvoir garder un programme dans sa tête.

Il est frappant de constater à quel point les programmeurs réussissent à toucher 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 ce n'est initialement qu'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 complètement le programme plusieurs fois ; cela ne se justifierait pas pour un projet officiel, mais c'est un travail d'amour et il veut qu'il soit parfait. Et comme personne d'autre ne le verra à part lui, il n'omet que les notes à soi-même. Il travaille dans un petit groupe par la force des choses, car il n'en a encore parlé à personne d'autre, ou l'idée semble si peu prometteuse que personne d'autre n'est autorisé à y travailler. Même s'il y a un groupe, ils ne pourraient pas avoir plusieurs personnes qui éditent le même code, car il change trop rapidement pour que cela soit possible. Et le projet commence petit parce que l'idée est petite au début ; il veut juste essayer un truc cool.

Encore plus frappant est le nombre de projets officiellement approuvés qui réussissent à faire les huit choses de travers. En fait, si l'on regarde la façon dont les logiciels sont écrits dans la plupart des organisations, on dirait presque qu'ils essaient délibérément de faire les choses de travers. En un sens, c'est le cas. L'une des qualités définissantes des organisations depuis qu'il en existe 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, une armée bien entraînée de soldats professionnels pouvait compter sur le fait de battre une armée de guerriers individuels, quelle que soit leur bravoure. 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. C'est une partie de la définition d'une organisation de ne pas le faire. De notre concept actuel d'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 pourrait dire qu'un marché est une telle forme d'organisation, bien qu'il soit plus exact de le décrire comme un cas dégénéré - comme ce que l'on obtient par défaut lorsque l'organisation n'est pas possible.

Probablement la meilleure solution sera une sorte de bidouillage, comme faire fonctionner les parties de programmation d'une organisation différemment du reste. Peut-être que la solution optimale est que les grandes entreprises n'essaient même pas de développer des idées en interne, mais se contentent de les acheter. Mais quoi qu'il en soit, la première étape est de réaliser qu'il y a un problème. Il y a une contradiction dans l'expression même "entreprise de logiciels". Les deux mots tirent dans des directions opposées. Tout bon programmeur dans une grande organisation sera en désaccord avec elle, car les organisations sont conçues pour empêcher ce que les programmeurs s'efforcent d'atteindre.

Les bons programmeurs réussissent quand même à faire beaucoup. Mais cela nécessite souvent pratiquement un acte de rébellion contre les organisations qui les emploient. Peut-être que ce sera plus facile si plus de gens comprennent que la façon dont les programmeurs se comportent est dictée par les exigences du travail qu'ils font. Ce n'est pas parce qu'ils sont irresponsables qu'ils travaillent en longues séances pendant lesquelles ils se moquent de toutes leurs autres obligations, qu'ils se plongent directement dans la programmation au lieu d'écrire d'abord des spécifications, et qu'ils réécrivent du code qui fonctionne déjà. Ce n'est pas parce qu'ils sont antipathiques qu'ils préfèrent travailler seuls ou gronder les gens qui passent la tête pour dire bonjour. Cette collection apparemment aléatoire d'habitudes agaçantes a une seule explication : la puissance de tenir un programme dans sa tête.

Que cette compréhension puisse ou non aider les grandes organisations, elle peut certainement aider leurs concurrents. Le point le plus faible des grandes entreprises est qu'elles ne laissent pas les programmeurs individuels faire un travail exceptionnel. Donc si vous êtes une petite startup, c'est là qu'il faut les attaquer. Prenez le genre de problèmes qui doivent être résolus dans un seul gros cerveau.

Merci à Sam Altman, David Greenspan, Aaron Iba, Jessica Livingston, Robert Morris, Peter Norvig, Lisa Randall, Emmett Shear, Sergei Tsarev et Stephen Wolfram d'avoir lu des versions préliminaires de ce texte.