Il y a une qualité de l'écriture qu'on appelle la "transparence". Je reconstitue de mémoire ce que j'en ai lu dans un livre de Peter Elbow, dans un passage que je n'arrive pas à retrouver. Un texte est transparent lorsque, à sa lecture, on retire immédiatement un sens, sans remarquer son style. Une phrase déclarative simple est facilement transparente: j'écris "Le chat regarde par la fenêtre," le lecteur comprend que le chat regarde par la fenêtre. Toutes les phrases déclaratives simples ne sont évidemment pas transparentes.
Je m'interroge sur l'application de cette notion au code. Lorsqu'on lit un code transparent, on le lit comme une simple description d'un processus qui sera déroulé lors de l'exécution, et on ne remarque rien de particulier dans la forme même de ce code.
Paradoxalement, l'écriture transparente demande de beaucoup travailler le style.
Laurent a binômé lors de la dernière session du dojo avec Christophe pour nous présenter en mode "programmation collective" un nouveau kata -- résoudre un problème de labyrinthe de deux façons, l'une itérative et l'autre récursive. Plusieurs d'entre nous avait regardé ledit kata, peu avaient les deux solutions de prêtes. Pour ma part, la version récursive, sans être triviale, m'avait paru venir assez naturellement, alors que je n'avais aucune idée de comment aborder la version itérative. Il n'en fallait pas plus pour piquer ma curiosité et souhaiter en apprendre plus sur cette question.
Je me suis accroché. Jusqu'au moment où je n'ai plus pu. Un moment magique où tout avant s'enchaînait logiquement, où le chemin à suivre était clair. Une charnière faisant basculer mes certitudes dans une interrogation perplexe -- pourquoi cet algorithme ? Pourquoi cette ligne en plus ? Je voyais le but à atteindre, et pouvais tant bien que mal revenir à quelques étapes préliminaires qu'il fallait achever avant d'obtenir la pleine solution. L'enchaînement logique que constituait ce moment charnière me restait pourtant inaccessible. Nous en étions alors au passage du cas trivial en une itération à celui, nettement moins, en deux itérations.
Blocage psychologique ? Manque d'endurance dans mon attention ? Je ne sais. Ce qui est sûr, c'est que rapidement je me suis retrouvé face à de vieux démons réveillés, ceux rencontrés dans les cours de mathématiques post-lycéennes. Ceux où j'aimais aller, où pugnace je bataillais pour comprendre l'enchaînement des lignes écrites au tableau, où la plupart du temps pourtant je devais entourer un point d'interrogation en marge et aux deux-tiers de la démonstration recopiée -- promesse hâtivement formulée d'un retour à ma copie qui, une fois effectué, ne laisserait plus plâner aucun mystère ; crainte sourde d'une sanction si le mystère demeurait jusqu'au prochain examen. Cette peur mêlée à la bonne volonté de comprendre ce qui se passe a longtemps été pour moi une source de frustration -- jusqu'au jour où j'ai compris qu'il n'y avait pas de honte à dire qu'on ne comprend pas, que la responsabilité de compréhension incombe autant à l'émetteur qu'au destinataire. Stella Baruk pose comme thèse que l'échec scolaire en mathématique est avant tout un échec de l'enseignement à communiquer un savoir à des élèves pourtant capables de le comprendre. Sans avoir eu à réellement subir le sentiment d'échec scolaire en mathématiques, je regrette de ne pas avoir lu les écrits de Stella Baruk à une époque où je redoutais de voir mes questions sur une démonstration mathématique répondues par un "C'est pourtant simple..."
La même problématique s'est présentée de façon nettement moins iconoclaste en cours d'écriture théâtrale, quelques années plus tard. Le progrès de chacun s'y mesurait en sa capacité à communiquer une histoire, sans susciter pour autant de contre-sens en ce qui concerne les motivations des protagonistes. Dans un tel cadre, il vient clairement qu'un texte, un dialogue, un scénario peut être "intelligent" sans pour autant "fonctionner". La responsabilité qui est laissée au public de comprendre ce qui est à comprendre est contre-balancée par celle qu'a l'auteur de communiquer efficacement ce qui, justement, est à comprendre.
J'en suis toujours à creuser où sont les aspects performatifs de l'activité de programmation. Si notre travail est de communiquer des idées, un savoir, des formes, des expérience ou une théorie, peut-être qu'une part de réponse se situe dans la nécessité pour le codeur/auteur de s'accorder avec son lectorat/public sur ce qui "fonctionne" dans son discours.
I wrote some code
Threw it away
Rewrote it again
In front of other people
It was clever code
They frowned at it
I have been training at the Dojo for several weeks now. Time for feedback, commencing with why I really enjoy our Dojo sessions: because it's just like the opposite of what most of us have at work.
At work,
- Discussions are mainly about content, not form.
- As long as it just "works" everybody is OK.
- As much as possible we try to deal with issues alone.
- It's not well seen to voluntarily uncover whole zones of our own ignorance.
- Every one has a his/her very personnal idea about what's the best.
- Very few people see and are interested in the code I write.
- A lot of war stories you ear are about a code you'll never see.
- The code I write is useful, if not beautiful.
- Those who must evaluate my work don't know much about coding.
At the Dojo you can have just the contrary.
My purpose here is to try and formulate some rules or principles that seem to emerge from our activity. Or maybe it's just the way I see them, other people interested or involved in the Dojo will tell if it's the case, or just what they think of it.
The First Rule
One important rule about the Dojo is : At the Dojo one can't discuss a form without code, and one can't show code without tests. It is a design training place, where it is acknowledged that "the code is the design" and that code without tests simply doesn't exist.
Finding a Master
The master can't be a master of every forms. I feel quite at ease with recursive functions and list processing e.g. but I think I don't know how to create even a simple web app. Fortunately, while it's the first time they really deal with "tail-recursion" some practionners here have done professional web apps for years !
Come Without Your Relics
Of course, you know how to do it. You know how and why this code is better than that one. You've done it already. The point is to do it right now, explain it to us, and share what you learned.
Leaning Again
In order to learn again something, we just have to forget it. But it's not easy to forget something when you're alone. It's easier when we give our full attention to someone who just tries to learn it for the first time. We can learn from others mistakes as well as from ours if we listen carefully.
Slow Down
Learning something should force you to slow down. You can go faster because you learned some tricks, but you cannot go faster and learn at the same time. It's OK, we're not in a hurry. We could do that for years. Some of us certainly will. What kind of deadline will we miss if we spend four more weeks on this subject rather than on four different subjects ? More precisely, when we reach the next plateau, is it because we went through the previous one, or is it just because we were flying over it ?
Throwing Yourself In
At some time someone begins to master a subject and wants to approach another one. Those threatened by boredom should throw themselves first into a presentation. The goal is to get back to a good motivation level, ie. an acceptable level of difficulty.
Subjecting To A Master
If it seems difficult to you, look for other practitionners who can judge your code and could easily show something new about it to you. Ask again until the matter contains absolutely no more difficulty to you.
Mastering A Subject
If it seems easy to you, offer to explain it to other who find it difficult. Explain it again as long as they find it difficult.
This way, what seemed difficult will turn easy and vice-versa. In both cases, you'll learn.