Because form is restrictive, the idea bursts forth more intensely
I promise, we’ll talk about programming.
But first, let’s lose ourselves in this work by the Expressionist painter Franz Marc (The Fox, 1913). It’s interesting to note how much the artist’s style solidified in just a few years, with the introduction of a strict formalism that draws on Futurism. Compare this painting to his early works—the contrast is striking.
Formalism is constraint: why would anyone want to impose constraints on themselves?
Charles Baudelaire provides the answer: “Because form is restrictive, the idea springs forth more intensely!” In other words, creativity arises from constraint, which serves as a starting point when facing a blank page. Create the framework to break free from it. This is true of painting, music, and art in general. And it makes sense for software development.
Kata, a space for experimentation
Developers often practice code kata. The term isn’t innocently borrowed from martial arts—it reflects values embraced by software artisans.
Kata are codified exercises that are performed over and over again. The beauty of it is that the highest-ranking practitioner (black belt, nth dan) practices the same kata as the beginner, humbly acknowledging that one never stops learning.
Thus, going through kata one after another as if checking off boxes would make no sense. On the contrary, one must return to them periodically, first and foremost because it is an opportunity to observe the progress made since the last time.
But sometimes the opposite happens: you trip over your own feet without seeing it coming and fail at a kata that’s supposed to be simple. It might be a little frustrating, but that’s where you learn, because you return to the essence of things.
This is especially true of Test-Driven Development: come on, let’s not bother checking that the test fails—it’s obvious, so let’s move on. The one thing not to do—except that you have to have done it to know not to do it 😁
But the key point—and this is where we come back to our friend Franz—is that reworking a kata is often an opportunity to experiment with something new, to take risks, to work under constraints, and to have a little fun.
Ideas for constraints for your kata
Here are a few approaches I’m fond of:
- Coding using only the keyboard, without touching the trackpad or mouse: a good way to familiarize yourself with your IDE;
- Varying the paradigms (functional/object-oriented), using the Tennis kata as an example;
- Varying the implementations (for loops, reduce, recursion): the ATM and Diamond katas lend themselves particularly well to this;
- Going deeper into a kata: the Fraction kata for defensive programming, RPN for error handling with monads, or even FizzBuzz for exploring functors (OK, an exploration that might go a bit too far);
- Optimizing performance: The Game of Life lends itself well to this;
- And more generally, refactoring a previous implementation of a kata.
The value of these explorations is that the knowledge you gain can then be applied in your daily work when writing production code: it’s not just for intellectual pleasure.