Towards an Aesthetics of Coding

There goes another great article from Fowler…

I do have to say, I admire his way of thinking. As I have perceived him, he is not dogmatic. Rather, he is pragmatic, but not of the boring kind. He is pragmatic-passionate; that is, he believes what he believes through introspection, experience, and intuition. He seems able to change his views, but whatever he defends, he defends well, not out of pretension, instead, out of perceiving what he believes is right.

Clearly, though, since his view is subjective, and so is mine, we may not agree on some things. But I would like to focus on what we agree with, and from that derive what I believe might be the ideal shape and attitude of coding. First, I totally agree with him regarding the use of diagrams. Thanks, and finally! Diagrams should be used more as a tool, much akin a ruler or a throwable sketch, to understand instead of dictating how our code should look like.

I believe this attitude towards diagrams is derived from its frustrations. Sometimes, we would like to think of the design and implementation processes as separate, which is why we use the architect metaphor to identify those who are in charge of solely designing. However, metaphors have an inflection point where they no longer hold up; that’s why they are not definitions. In this case, architecture deals with the real world, while programming deals a little bit with that (hardware), and deals with ambiguity (software) too.

So, we have an intersection here: programming has to be efficient and precise, and also reflect a personality. For the former attributes, well, there are just a few ways to get things right in programming, and a lot of ways to get things wrong. You cannot write nonsense, but it is also true that there is not just one way to write solutions that get things right; this isn’t mathematics in its purest form. The programmer must decide what names and procedures to use; this justifies the latter property.

Being language the means of programming, it is natural to see how its development is much more alike to writing; poetry, more precisely. But, again, this is just a metaphor; no one writes novels by first designing and then implementing them. More accurately, this process is a mixture of both, much like what Fowler has described both in content, and mainly in intention; there is passion and articulation. I would even dare to say that, when conceiving literate programming (programming as an essay), maybe Donald Knuth intermingled this artistic sense with his pure mathematical side.

It seems then that coding has that passionate and articulate side. Nevertheless, different from writing a novel where we can be baroque and abuse platitudes, revelation in code displays itself through minimalism. From this, I hope you can see that the aesthetics of coding is of the almost-average kind. In simplicity, we fall back to patterns, and as Fowler does, the use and implementation of these patterns stem from intuition.

If we were to hear programming, it would sound like a minimal Philip Glass composition, where sounds repeat themselves endlessly until a slightly-off key, or a different timing, is tuned. In a world of repetition and perfection, this kink amidst the purity of order is a speck of humanity. If we were to see programming as a person incarnate, such individual would be healthy, with a speck of uncontrollable passion and ingenuity.

Fowler, M. (May, 2004) Is Design Dead? Retrieved from: https://martinfowler.com/articles/designDead.html