Dumb by the pattern

If you can’t explain something in simple terms, you don’t understand it

Richard Feynman

We all love readable code

In the community of software developers, it is a common mantra that code should be as readable to humans as possible. Certainly, some communities in software, and hence some programming languages, tend to give more relevance to readability than others, but it is generally accepted that when code maintenance matters, meaning when we expect us coming back to it for whatever reason, like to fix a bug, or to refactor it, then code readability matters as well.

It is interesting to note how readability can be a concern even when designing new programming language features. As an example, this piece by Stuart W. Marks taken out of the Java community, in this case as part of the so-called Amber Project: Local Variable Type Inference: Style Guidelines.

It is also said that developers spend around 10 more times reading code than writing it. Though I am not aware of experimental evidence for this 10 to 1 ratio in particular, at least as a rough indicator it sounds pretty right. So, making code easier to read could turn our daily experience reading it a bit more comfortable, who would say not to that?

Coding by the pattern

Once encouraged to write code easier to read, we need to puzzle out how to do it in practice. Rather candidly, one would suggest that to be readable, software code should be self-explanatory. This way, other developers, however stranger to the context within the application was developed, would be able to follow every feature as if they were reading a tale for little children, thanks to it being implemented in a way that explains itself by showing off its intent with terms that show their meaning explicitly.

Although, what we see in practice is that, when achieved, readability in code comes through making it look similar to the code developers are already used to reading. This is actually a broader practice: we structure our applications the same way, we apply the same naming rules, and we implement the same solutions as much as it is possible to make them fit our context.

OK, so we are not that original, but our software works, so what?

Some of those models that we follow are special since the community (?) granted them the badge of being called a pattern.

Patterns were invented and posed as the rightest way of fulfilling some basic and common tasks in software. That is why they can be implemented in any kind of application and, roughly speaking, with every programming language. Patterns free us of having to design and implement everything from scratch, of re-inventing the wheel once and again. Hence patterns enable us to spend our time on what is truly specific to the application we are dealing with. And, as they were invented by very smart people, using them we are putting some of that smartness in our code for free too.

Seen that way, it is not surprising that patterns get so popular. And, needless to say, coding by the pattern is not bad from the point of view of delivering outcome either, in the same way, that it is great to win the lottery jackpot: you get the money because you hit the combination, not because you had foreseen it, but your pockets are full anyway. Similarly, our software may not be that original, but it looks a bit smarter, and it works.

So, what is the matter with coding by the pattern? Why I am apparently complaining about it? In these times we are living in, I could say because who decides what method deserves to be a pattern? Or, who picked the books we are advised to read? Likely all pattern inventors were white, straight males, right?

No matter how interesting that conversation might be, this post is not that ambitious. Today I am just wondering how we, as a community, are dealing with patterns, rules of thumb, and the rest of those right ways to do stuff.

Conformity

And, in my honest opinion, our community is too hooked to seeking out patterns. Instead of being the starting point of enlightening conversations, once elevated to the category of pattern, principle, or methodology, good ideas are mostly impeding open discussions to happen. Even manifestos, which are the highest example of conscience shakers we may imagine, are twisted and bent until they become rules to follow.

Conformity means to model your own attitudes, beliefs, and behaviour to match the group’s expectations.

A Definition of Conformity

And to follow the rules means to conform with what is commonly accepted. The recurrent complaint about how the Agile Manifesto has become a recipe book, or the adoption of micro-services boosted just because trend builders said so (and now the path back to monoliths may be the new hype) are two examples of it.

Surely there are plenty of examples of successful applications that succeeded thanks to the following piece by piece what others already proved that works. As it is pretty easy to find true examples of totally conventional applications that failed miserably too even though doing it all by the book.

The fact that software gets unsurprisingly boring, though unfortunate for those who like reading code, is not relevant either. The awful consequence of implementing the same solutions once and again is that we are preventing ourselves from exploring potentially better solutions just because they may not match the pattern.

This shrinking of the solution space is not the only casualty here. As a consequence of the lack of training, in the course of time, our brain becomes less and less capable of coming up with fresh, good ideas. And of recognizing bad ideas, and of elaborating why. Conformity not only shrinks our ability to invent solutions that fit our context best, a context nobody knows better than we do. In a word, conformity turns us dumber.

Needless to say, by the way, conformity makes us cheaper too, because coders by the pattern are way easier to replace: conformity makes developers expendable.

A way to upskill ourselves

Above I considered code readability as an example of what happens when developers surrender to familiarity instead of thinking their own way first: they think they are writing readable code, but they are blindly producing code that conforms with code written by others. It should not be surprising that their code turns out to be not as readable as they think. Unfortunately, this tells us about something even worse:

If the implementation is hard to explain, it is a bad idea.

The Zen of Python

What the Zen of Python reminds us here wasn’t new. Richard Feynman, the American physicist and 1965 Noble Prize in Physics, referred to the same sentiment in the quote than opens this blog post. According to what he later explained, Feynman came up with it after meeting one colleague who complained about the hard time he had trying to explain some difficult concepts of Physics to his students.

Feynman was famous for his brilliant ability to explain tough ideas in ways people could (and still can) follow. With that statement, he summarized his own experience: that the process of making an idea comprehensible to others will bring us to unveil any concealed misconceptions that we were unaware we had. Misconceptions, or even mistakes, that, once addressed, would make our own knowledge deeper than it was at the beginning.

Helping others comprehend helps us comprehend better. We may call it a happy side effect. If we translate this to software, it would mean that writing meaningful code (which, by the way, goes farther than mere readability) will not only yield a more comprehensible application but also, thanks to the upskilling side effect that Feynman showed us, it will also turn us better code writers.

Conclusion

I am not saying that we should put originality first as if our aim as coders was L’Art Pour l’Art, but that it is putting our understanding first what really will make us reach our best as developers, as well as the best solution possible for our current project.

Patterns are not bad, they are just not enough. It is never the pattern alone what yields the value we are wanting to import to our code. Trying to copy the positive results of a given experience without putting it in context is a mistake. It is the pattern in its context what really makes sense, and it is our job to map what makes patterns work and our own context to see if they fit.

Title image credits: from the film “Being John Malkovich” (1999) directed by Spike Jonze. I love all the works by Spike Jonze, in particular his music videos. I love this film for the concept the plot explores. I strongly recommend watching this film, just because life can be better though weirder.