Clear is better than clever

Ability to make complex things simple is what sets apart a great programmer from an average one. So why do most programmer interviews at companies such as Google focus on writing performant code instead?<p>Most professional programmers only occasionally need to look into performance issues, but need to take complex things and simplify them with every line of code they write. And yet most programming interviews don’t evaluate this ability. I think this should change.

The concept of clarity is why I don’t like the consequence of SOLID, where you have lots of tiny classes.<p>It’s easier to understand complex functions and a simple class structure than the other way around. Because jumping between multiple files&#x2F;classes incurs a high understandability cost, whereas complex functions fit on your screen typically.<p>And reading some more about it, I found this good article: <a href="http:&#x2F;&#x2F;qualityisspeed.blogspot.com&#x2F;2014&#x2F;08&#x2F;why-i-dont-teach-solid.html?m=1" rel="nofollow">http:&#x2F;&#x2F;qualityisspeed.blogspot.com&#x2F;2014&#x2F;08&#x2F;why-i-dont-teach-...</a>

The issue is that in Go speak, &quot;clever&quot; means any programming language technique that was invented after the 1970&#x27;s. We are fortunate that the creators of Go felt comfortable with structured programming, or otherwise they might have felt that function calls with their compiler maintained stacks and local variables were &quot;clever&quot; and that we should all use goto statements since those are much clearer as to what is actually happening.

The difficulty of giving examples to illustrate what &quot;clarity&quot; means really shows in this article.<p>For the most part I evaluate software clarity by how many times I had to hit &quot;goto definition&quot; to see what was actually happening. But this takes us away from what the author was attempting to say. In my opinion, 95% of clarity comes down to writing good abstractions, and it is next to impossible to articulate what a good abstraction is.<p>It&#x27;s like describing the taste of salt.

There was that recent post about innovation being a limited resource. Clever is a limited resource. Save your clever for good, insightful architecture, or for when you really need the algorithmic chops. Don&#x27;t expend it just to impress your coworkers.

I think one reason why people like to write supposedly <i>clever</i> code especially on the realm of software development is due to lots of these developers want to get acknowledgement of what they produce. And hearing someone say &quot;Oh, this is a very clever implementation&quot; sort of fix that inherent need to be recognized. I haven&#x27;t heard (particularly in corporate environments) where a praise in the line of - &quot;wow, this was a very clear and simple implementation&quot; trump what managers and people deem as superior when the term clever was attached to it.<p>I&#x27;ve challenged far quite a lot of implementations where understanding a piece of functionality has required for the developer to jump between more than 23 files across 8 different projects in implementing a very domain specific functionality. Splitting code into single independent parts introduces simplicity, only and if only you are reading that part by itself, but when you layer it overall to get the functionality it delivers and it becomes a web of tangled mess of code, then that clever solution was not really clever after all.

Debugging code is more difficult than writing it. If you write the cleverest code you can, you are, by definition, not smart enough to debug it.<p>&#x2F;shamelessly stolen from somewhere I&#x27;m too lazy to look up.

My rule of thumb has always been &quot;the amount of comments I leave is directly proportional to how clever my code is&quot;.<p>Code that is trivial really needs no elaboration, but occasionally I feel like I gotta go crazy with a bunch of hashmaps of lambdas and all that jazz, and I don&#x27;t think that there&#x27;s inherently anything wrong with that.<p>However, when I do that, I make sure I document it like crazy with comments, so that when I have to look at the code two weeks later, I at least can figure out what I was doing.

Have to really disagree with the &quot;comp&quot; function example. No need to have &quot;else&quot; statements. The one with early returns and only &quot;ifs&quot; is succinct and good.<p>Also what is up with comparator function being used this way for most articles nowadays? If I am not mistaken &quot;return a-b&quot; is the much better solution and don&#x27;t say that it is considered too clever :)

I agree with the sentiment of the article, though I don&#x27;t really like the example given. To me, using a switch statement instead of if-else-if is not any clearer.

Code is written and read by humans, therefore it should be clear and concise.<p>Cleverness should be used in constrained situations like performance (fast inverse square root [1] comes to mind), and comments explaining the cleverness is important.<p>I should note [1] did a terrible job at commenting.<p>[1] <a href="https:&#x2F;&#x2F;en.m.wikipedia.org&#x2F;wiki&#x2F;Fast_inverse_square_root" rel="nofollow">https:&#x2F;&#x2F;en.m.wikipedia.org&#x2F;wiki&#x2F;Fast_inverse_square_root</a>

&gt; Here we have a comp function that takes two ints and returns an int;<p>Ah, &quot;comp&quot;utation. &quot;comp&quot;lex numbers? &quot;comp&quot;licated function? &quot;comp&quot;onent? &quot;comp&quot;anion numbers, is that a thing? &quot;comp&quot;rehensive example?<p>Saving three characters of typing is more important than being clear?

All these quotes remind me of another quote that I like:<p>Simple and dirty beats complex and clean any day. - Learn C the Hard Way

If you have only a final “else” instead of a bare “return” in a function that returns a value, you are making it <i>worse</i>. Now when I read the code, my first instinct is “seems to be a bug, undefined behavior” and I have to read more carefully.<p>This is a terrible example and a code change I would never approve. The clarity-over-cleverness goal is good but not with these kinds of cases.

Creating anything is a craft and creating software programs is no different. While everyone should strive to learn how to write programs well so the intent isn’t obfuscated, it ultimately boils down to two factors: programmer’s experience and talent. Most programs, like most works of art, will be utter crap and nonsense, as most artists are - with rare notable differences. This is why I heavily support frameworks and prescriptive style of programming, or “opinionated” systems as some would call them. They are usually invented by people much smarter than the average Joe and ultimately generate better long term results. It would benefit our productivity much more if we invested efforts into translating these brilliant minds into compiler features so the compiler checks for style as well, not just “spelling”. We need Grammarly for code.

This put me in mind of a passage from the (excellent) 1982 book <i>Inside the Soviet Army</i>, by the Soviet defector Vladimir Rezun (which can be read in English in its entirety here: <a href="http:&#x2F;&#x2F;militera.lib.ru&#x2F;research&#x2F;suvorov12&#x2F;index.html" rel="nofollow">http:&#x2F;&#x2F;militera.lib.ru&#x2F;research&#x2F;suvorov12&#x2F;index.html</a>), which explained why ammunition for Soviet weapons hadn&#x27;t been standardized across a common set of calibers:<p><i>The calibre of the standard Soviet infantry weapon is 7.62mm. In 1930, a 7.62mm `TT&#x27; pistol was brought into service, in addition to the existing rifles and machine-guns of this calibre. Although their calibre is the same, the rounds for this pistol cannot, of course, be used in either rifles or machine-guns.</i><p><i>In wartime, when everything is collapsing, when whole Armies and Groups of Armies find themselves encircled, when Guderian and his tank Army are charging around behind your own lines, when one division is fighting to the death for a small patch of ground, and others are taking to their heels at the first shot, when deafened switchboard operators, who have not slept for several nights, have to shout someone else&#x27;s incomprehensible orders into telephones-in this sort of situation absolutely anything can happen. Imagine that, at a moment such as this, a division receives ten truckloads of 7.62mm cartridges. Suddenly, to his horror, the commander realises that the consignment consists entirely of pistol ammunition. There is nothing for his division&#x27;s thousands of rifles and machine-guns and a quite unbelievable amount of ammunition for the few hundred pistols with which his officers are armed.</i><p><i>I do not know whether such a situation actually arose during the war, but once it was over the `TT&#x27; pistol-though not at all a bad weapon-was quickly withdrawn from service. The designers were told to produce a pistol with a different calibre. Since then Soviet pistols have all been of 9mm calibre. Why standardise calibres if this could result in fatally dangerous misunderstanding?</i><p><i>Ever since then, each time an entirely new type of projectile has been introduced, it has been given a new calibre...</i><p><i>[West Germany and France] have excellent 120mm mortars and both are working on the development of new 120mm tank guns... [W]hat happens if, tomorrow, middle-aged reservists and students from drama academies have to be mobilised to defend freedom? What then? Every time 120mm shells are needed, one will have to explain that you don&#x27;t need the type which are used by recoilless guns or those which are fired by mortars, but shells for tank guns. But be careful-there are 120mm shells for rifled tank guns and different 120mm shells for smoothbore tank guns. The guns are different and their shells are different. What happens if a drama student makes a mistake?</i><p><i>The Soviet analysts sit and scratch their heads as they try to understand why it is that Western calibres never alter.</i><p>(This specific chapter can be read here: <a href="http:&#x2F;&#x2F;militera.lib.ru&#x2F;research&#x2F;suvorov12&#x2F;06.html" rel="nofollow">http:&#x2F;&#x2F;militera.lib.ru&#x2F;research&#x2F;suvorov12&#x2F;06.html</a>)

If it&#x27;s both clear and conventional, gcc should be able to make it clever. If it can&#x27;t, I&#x27;d rather pay a human to profile it, than to make it clever.<p>There are too many developers who are &quot;super good at writing clever code&quot;, and not enough who are comfortable with profiling and analytics.

Nice. I said exactly this for the same reason yesterday. In that case it was a thread about Lisp. Here&#x27;s the comment:<p>&gt; Even the open source Common Lisp compilers, written by arguably the lispiest of Lispers, don’t have a lot of “cleverness”.<p>To which I replied my agreement:<p>&gt; Don&#x27;t write clever. Write clear.<p>Its a sentiment that you find attached to Lisp programming style fairly often, although ironically there is a whole lot of barely readable Lisp code out there.<p>Personally, I think the code is (nearly) worthless crap if someone with skill has to spend as much time parsing it as the writer did writing it.<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=20376344" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=20376344</a>

That switch case transformation in the end is just syntactic sugar for the equivalent if-else-if chain so I am not sure it is actually an improvement.<p>That said, I still agree with the basic idea. An if-else-if chain is easier to reason about than if-return, and representing information with enum or algebraic data type can be more robust than using a combination of booleans.

This is a strange read as a fiction writer. This lesson is learned quite early in prose writing- explicitly due to the fact that written works must be read. Maybe because of this, I&#x27;ve never felt the need to write &#x27;cleverly&#x27; in my programming either. Can other prose writers corroborate?

&gt; The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague. <a href="https:&#x2F;&#x2F;wikiquote.org&#x2F;wiki&#x2F;Edsger_W._Dijkstra" rel="nofollow">https:&#x2F;&#x2F;wikiquote.org&#x2F;wiki&#x2F;Edsger_W._Dijkstra</a><p>&gt; Everyone knows that debugging is twice as hard as writing a program in the first place. So if you&#x27;re as clever as you can be when you write it, how will you ever debug it? <a href="https:&#x2F;&#x2F;wikiquote.org&#x2F;wiki&#x2F;Brian_Kernighan" rel="nofollow">https:&#x2F;&#x2F;wikiquote.org&#x2F;wiki&#x2F;Brian_Kernighan</a>

I wonder though, isn&#x27;t it even more clever to be simple (which is also clearer)?

I often cite this quote : Everyone knows that debugging is twice as hard as writing a program in the first place. So if you&#x27;re as clever as you can be when you write it, how will you ever debug it? (B. Kernighan)

Often I only need clever for performance reasons.<p>I write a filter&#x2F;map, which is slow in some languages, but looks readable and if I need better perf I rewrite it with a for loop.

brevity is the soul of wit and the veil of clarity.

I think clever stuff should be behind clear APIs.

Two men enter a bar. One is taller than the other. Which one is taller? -1.

&gt; If software cannot be maintained, then it will be rewritten; and that could be the last time your company invests in Go.<p>Maybe on to something there, golang code bases I&#x27;ve seen are a complete mess because of how &quot;simple&quot; the language is. Hopefully more people start realizing this and moving on to better languages.

&lt;subjective thing&gt; is better than &lt;subjective thing&gt;.<p>Oh thanks, that was so useful.