Jan, Senior Software Engineer at Mozilla, on Clean Code

Last week, I shared a post giving the answer to the question “What is clean code?” by five of the most respected software engineers in the industry. I concluded the article by saying:

I’ve also planned for the coming days to ask this question to some developers I respect in order to share their answers with you, with my comments.

Well for today’s article, I have the privilege to share with you the answer by Jan Keromnes, who is a senior software engineer at Mozilla. If you’re not aware, Mozilla is one of the hottest companies for which to work for as a developer, together with other big names such as Google, Facebook and Amazon. The selection process to get in is incredibly competitive, which means that only the best software engineers make it. And those who know Jan are actually not surprised at all that he’s one of the few who’s made it (and quickly became “senior”, on top of that).

As soon as I met him at the beginning of our Master’s degree, I was struck by his genuine passion for computer science. It was obvious to all that he had a desire not only to master his craft, but also to help other students do the same. Sadly for me, since I didn’t care at that time about software craftsmanship (I explain why in this post), I didn’t make the most of our time together to work with him and learn from him (oh, to be able to use a time machine!). But it’s never too late, so here am I, presenting to you his take on what clean code is:

So Jan, what is clean code for you?

I think code should be as concise as possible, but not more. Clean code should go straight to the point, in not too many lines. No need to design a complex hierarchy of abstract classes if what you’re trying to do fits in a simple for-loop. (Really, it’s ok to copy/paste a block of code, especially if factoring it out actually results in more complexity, or in a giant “util”-module). Concise code is quicker to read, yet it should remain dead simple and extremely transparent. Short variable names, acronyms, and clever hacks actually make your code harder to read and to maintain, even if you’re saving a few bytes of source code.

Now that I’ve worked as a developer for a few months, I understand how pragmatic and wise Jan’s approach is. Many imagine that a developer’s day is mostly spent writing new lines of code. Well actually, we could argue that a typical developer spends more time reading than writing code. And since this is the case, one of the most important aspects of code’s cleanliness is its readability.

We could say that the same goes for prose. My favourite books are those where I feel that the writer’s point could not have been expressed more clearly, either by subtracting or adding words (see Camus’ The Stranger for a perfect example). And text, like code, can either be too concise or too verbose. Too concise, and we struggle to get the author’s intent because of a lack of information. Too verbose, and we lose the author’s main point in a sea of rambles. So clean code aims to strike the right balance.

Another pragmatic point I appreciate in Jan’s definition is that we should be willing to break what are considered “rules” or “best practices” if this can make the code more readable. For instance, a famous rule introduced by Dave Thomas (one of the giants giving his definition in my previous post) is called DRY, for: Don’t Repeat Yourself. According to this principle, duplicated code (and hence copy and paste) is a great evil to be avoided at all cost. Well, this is mostly good advice, but as Jan says, we need to be flexible and use our judgment well (as with most “rules”).

Finally, another theme that I see in Jan’s answer is transparency. For code (or prose) to be transparent means that the author’s intent is clear and unmistakable upon first reading (the opposite of cryptic). We all hate reading text messages or emails where a sentence could be meaning two opposite things (one positive, one negative). The same goes for code. And sometimes, by trying too hard to be clever, the author can mislead his readers. As Jan says, it’s fine sometimes to take what can seem as a “simple” road, without using a sexy new feature of the language or framework used or some complex abstractions. As a junior developer, I often feel the urge to use these “clever hacks” that I read about in blogs written by the “cool kids” in the industry. But I need to restrain myself in order to focus on readability and simplicity.

The journey to become a clean coder is very similar to the journey to become a clear prose writer. At first, we only know the most basic words. Then, as we learn more complex words, we like to use them a lot, even when they’re not the most appropriate. Finally, as we mature, we know when to use which words depending on the context in order to be best understood.

Thank you Jan for these great principles, on which I’ll keep meditating a while until I’ve internalized them. I can’t wait to interview other developers to learn from them as I’ve learnt from you :).

Originally published at www.samuelpath.com on March 6, 2017.