In 1976 in The Selfish Gene, Richard Dawkins explained that the unit of selection for evolution is not the group or species or individual but the gene. Genes that are best at causing themselves to get replicated are the ones that do get replicated, and so those genes then become predominant.

An organism’s body is a gene’s “survival machine”. Individual organisms die but a gene can survive indefinitely. A gene “uses” an organism to propagate itself from one generation to the next. Since an organism’s design is determined entirely by its DNA, the genes are in charge. The genes are the masters and the organisms are the slaves. Everything an organism does, it’s been programmed to do by its genes in order to propagate those genes.

In The Selfish Gene Dawkins also introduced the idea of a meme. A meme is kind of like a gene but instead of a piece of DNA it’s a behavior or idea. In The Beginning of Infinity David Deutsch uses the idea of a joke as an example of a meme. If a joke is funny, it will make people who hear it want to tell it again, causing the joke to be proliferated. But the joke may not always be retold word-for-word. Some people might remember the idea of the joke but tell it in their own words. Some people might misremember the joke and accidentally tell it a bit differently. Some people may intentionally change the joke in order to try to improve it. Just as a gene will compete with variants of itself, a joke will do the same thing.

The versions of the joke that are best at getting themselves replicated are the ones that become predominant. Note, importantly, that this does not necessarily mean that the best version of the joke will become predominant, just the version that’s best at getting itself replicated. “Survival of the fittest” is a myth. The versions of genes and memes that survive are the ones that are best at getting themselves copied, nothing more.

Before internet memes our culture had many others. Quotes are often memes, for example, like “if it ain’t broke don’t fix it” and “practice makes perfect”. The content of a meme can be true or false, helpful or unhelpful. “Practice makes perfect”, for example, is sometimes refuted with the expression “practice makes permanent”, which is closer to the truth. “Practice makes perfect” didn’t become a meme because it’s true, it became a meme because it has the attractive qualities of being snappy, alliterative and memorable, and superficially seeming wise and true.

Programming principles can also come in the form of memes. “Don’t Repeat Yourself” (DRY) is memorable thanks to its slightly amusing pronounceable acronym and the fact that its advice is useful and approximately true, although only approximately. The refuting advice, “Write Everything Twice” (WET) is cleverly formulated as the antonym to DRY, and has been very successful in replicating itself, despite the fact that its advice (allow duplication up to two times, and only de-duplicate when the number of instances reaches three) is, at least in my opinion, completely nonsensical.

Just as genes don’t obey “survival of the fittest”, memes, including programming memes, don’t obey “survival of the truest”. The programming principles that replicate themselves the most are simply the ones that are the best at getting themselves replicated, not necessarily the ones that are the truest or best. Sometimes an idea proliferates simply because it’s easy to learn and easy to teach, or because repeating the idea makes the repeater feel wise and sophisticated.

Having said that, sometimes a meme is good at causing itself to be replicated precisely because it is true. Newton’s laws of physics, for example, successfully proliferated because they were genuinely useful, and they were useful because they were true—at least true enough for many purposes. Then, later, Einstein’s laws of physics became successful memes because they were an improvement upon Newton’s laws of physics, and succeeded in certain areas where Newton’s laws failed. This phenomenon of memes proliferating precisely because they’re true should give us hope.

We all know people who seem to be slaves to some particular sort of fashion. Some people repeat the political ideas they hear on a certain news channel, for example, or get caught up in a succession of get-rich-quick schemes. These people seem not to have minds of their own. Like genes’ survival machines, these people in a way exist only as a vehicle for memes to replicate themselves. But of course, not everyone has to be a slave to memes. Instead of uncritically accepting memetic ideas, we can examine them with a careful combination of open-mindedness and skepticism and demand a good explanation for why the idea in the meme is supposedly true. In this way, perhaps our false programming memes can wither away and gradually be replaced with ever truer ones.

I’ve been thinking lately about the question of how to decide what’s a good programming practice and what’s not.

One way of looking at this is that it’s all just subjective opinion. Just do whatever works for you. You might call this the “anything goes” principle.

The problem with the Anything Goes Principle is that it doesn’t solve any meaningful problems. At best it works as a way to sometimes get strangers to stop arguing on the internet. It certainly doesn’t solve a debate between two team members in an organization. The Anything Goes Principle is simply a way to agree to disagree, not a way to resolve a disagreement.

Another way to approach the question is what you might call the “consensus principle” or the “best practice principle”. This principle says that whatever the prevailing best practice in the industry is is the right answer. But this method is easily debunked. There have been many instances in history where the consensus view in a certain field is just plain wrong. As the saying goes, “What’s popular is not always right”. The truth can’t be discovered via popularity contest.

Here’s what I think is the real key to recognizing a good programming practice: an explanation which stands up to rigorous criticism and which is sufficiently specific that it couldn’t be used to defend any other principle.

Let’s work with an example. It’s a very uncontroversial principle in programming that, in general, clear and accurate variable names, even if they may be long, are better than short, cryptic variable names. This principle has a strong explanation behind it. Clear variable names are, by definition, self-explanatory. When a name is clear, the reader can learn its meaning directly from the name itself rather than having to infer the meaning by studying the surrounding context. In terms of time and cognitive strain, it’s cheaper to learn the meaning of a variable by simply reading the name than by studying the surrounding context. This explanation is, I think, very hard to refute.

This principle even has an exception that proves the rule. There are times when a one-letter variable name is actually better than a long-and-clear name. The explanation for this is that when the scope of a variable is very small and the original name of the variable is not particularly short, the repetition of the long variable name can actually present enough noise in the code that the long-variable version is harder to understand than the short-variable version.

And by the way I want to note that the argument isn’t that the proponent of this rule personally finds certain code easier to understand. The argument is that a typical programmer would find the code easier to understand, since “a typical programmer” is the likely audience for the code, not specifically the proponent of the rule. So the rule could not be refuted by the argument of “well I personally think short variable names are easy enough to understand”. The argument would have to be “I think short variable names are easy enough for the typical programmer to understand”. It’s the difference between a subjective argument and an objective one.

Here’s an example of a poor explanation. A certain article about service objects claims that “Services are easy and fast to test since they are small Ruby objects that have been separated from their environment.” This explanation is weak partly because it could equally be applied to many other practices. The quality of being small and “separated from their environment” (in other words, loosely coupled from dependencies) is not unique to service objects. Furthermore, the quality of being small isn’t inherent to what a service object supposedly is. I’ve seen plenty of gargantuan service objects. And for that matter, loose coupling isn’t an inherent property of service objects either, and I’ve also seen plenty of service objects with tight coupling to their dependencies. My personal distastes for service objects aside, these explanations for the merits of service objects are objectively bad.

If a certain programming practice can address all the criticism it’s subjected to with specific and objective explanations, then it’s probably a good one. If not, it’s probably a bad one. And while everyone is of course entitled to their own subjective opinion, much of the quality of various programming practices is actually a matter of objectivity. At least that’s what I think.

I enjoy reading nonfiction. Not just programming but also biology, physics, philosophy, mechanical engineering, robotics and other technical topics.

The challenge in technical writing is to convey difficult ideas in ways that are easy to understand. The best technical writing doesn’t make the reader think, “Wow, the writer must be a genius to be able to understand this stuff,” it makes them think, “Wow, I must be a genius to be able to understand this stuff!”

Very few programmers make a serious study of technical writing. I myself, 20+ years into my programming career, have only just begun to do so myself. But I think improving one’s technical writing ability is a highly profitable undertaking for any programmer, even if you never intend to do any technical writing. In a very real sense, programming IS technical writing.

Donald Knuth has said, “Programs are meant to be read by humans and only incidentally for computers to execute.” When we write code, we’re (hopefully) aiming not just for it to fulfill its functional requirements but also for it to be understandable by human readers. In other words, we’re trying to convey difficult ideas in ways that are easy to understand. That’s what I mean when I say that programming is technical writing.

How does one get better at technical writing? One thing that helps is to do a lot of technical reading. In programming, my favorite technical writers are Martin Fowler and Steve McConnell. Outside of that, my favorites include Richard Dawkins (the master in my book), Carl Sagan (a close second), Steven Pinker, David Deutsch, Sean Carroll and Richard Feynman. If you’d like a specific starting point, I’d recommend The Blind Watchmaker by Richard Dawkins.

One last comment, an important one. Good writing is downstream of good thinking. None of the authors I listed above are writers by profession. The programming authors are programmers and the science authors are scientists. These writers are good writers because they’re excellent practitioners, with good ideas worth sharing. It also so happens that these practitioners have learned how to skillfully put their ideas into words. If Richard Dawkins were a clumsy writer, his books would probably still be worth reading on the merit of the ideas they contain. But if Dawkins were an excellent writer but a poor scientist, his books would be junk. Similarly, a programmer must be skilled not only in coding style but in designing and maintaining a software system. Good code is downstream of good thinking.

We all know the metaphor of technical debt. I want to share some weaknesses of the technical debt metaphor, plus a different metaphor which I think is better.

In real life, debt is not inherently bad. If you have debt, all it means in most cases is that you took out a loan. Loans are a good thing. Loans are what makes it possible to buy things like cars and houses that almost nobody has the money for up front. Business loans can allow business to make investments to grow faster, pay back the loan, and end up with a net benefit that wouldn’t have been possible without the loan.

Debt in real life is also avoidable. You don’t have to get a car loan or mortgage if you don’t want to. You don’t have to get a credit card. You could theoretically pay for everything with cash your whole life.

In software, what we call “technical debt” is not avoidable. It’s going to happen no matter what.

Managers sometimes talk about “strategic technical debt”, where debt is consciously taken on in order to meet a short-term timeline. The thing is, there’s never a plan to pay the debt back. Indeed it rarely does get paid back. Usually the next move is to take on yet more technical debt. It’s like a payday loan cycle, where each payday loan is used to pay the interest from the last payday loan, with less and less of each paycheck ultimately going into your own pocket. Yet the “strategic technical debt” myth persists, partly because the metaphor is so easy to grasp (and miscomprehend).

I prefer to think of a software system as a collection of blades.

A dull blade is never preferable to a sharp one. Sometimes it may be better to just cut with the dull blade instead of taking the time to sharpen the blade before cutting, but it’s clear that that’s a compromise. No one would talk about “strategic dull blades” the way they talk about strategic technical debt.

Unlike debt which you can simply choose not to take on, blades unavoidably get dull with use. Having technical debt makes it sound like you did something wrong. But you don’t have to do anything wrong in order to end up with bad code. Often, bad code is simply the result of entropy. The blade metaphor makes it clear that dullness is normal and unavoidable.

The blade metaphor also has built-in suggestions about how to address the problem. When is it time to sharpen a dull blade? Right before you use it (or right after). It obviously wouldn’t be a very smart investment to just go randomly sharpening saws in the shed. When you pick up a saw and notice that it’s hard to cut with, that can tell you that it would be worth the investment to sharpen it at least a little before trying to cut more with it. If there’s a blade that never gets used, you can afford not to sharpen it, since a dull blade that’s not being used is not hurting anything.

Lastly, the blade metaphor makes clear the benefit of being in a good state. What exactly is the benefit of not having technical debt? That you don’t have to pay technical interest? The benefit is not so clear. The benefit of having sharp blades is obvious: you can cut faster. Unlike being debt-free which is simply the absence of a bad thing, you’re in possession of something good.

As an industry I wish we would do away with the technical debt metaphor and adopt the blade metaphor instead. I think this metaphor would help managers understand the nature of the issue more accurately. Instead of pressuring us to take on “strategic technical debt”, maybe they’ll see the virtues of helping us keep our blades sharp.

Anti-productivity sentiment

In my career I’ve noticed that a lot of developers have a distaste for the idea of “productivity”. They view it as some sort of toxic, unhealthy obsession. (It always has to be an “obsession”, by the way. One can never just have an interest in productivity.)

Productivity is often associated with working harder and longer, sacrificing oneself for a soulless corporation.

In a lot of ways I actually agree with these people. Having an unhealthy obsession with anything is obviously unhealthy, by definition. And I think working long and hard for its own sake, for no meaningful reward, is a waste of precious time.

But I think sometimes these anti-productivity people are so blinded by their natural aversion to “productivity culture” that they miss out on some good and worthwhile ideas, ideas they would actually like if they opened their minds to them.

“Productivity” is a pretty ambiguous word. It could have a lot of different interpretations. I’d like to share my personal interpretation of productivity which I happen to quite like. Maybe you’d like to adopt it for yourself.

My version of productivity

For me, productivity isn’t about obsessively tracking every minute of the day or working so hard you burn yourself out.

The central idea of productivity for me is decreasing the ratio of effort to value. This could mean working less to create the same value or it could mean working the same to create more value. Or anywhere in between. Each person can decide for themselves where they’d like to set the dial.

I value a calm, healthy mind and body. People obviously do better work when they’re relaxed and even-keeled than when they’re harried and stressed.

Productivity for me is about realizing that our time on this planet is limited and precious, and that we shouldn’t be needlessly wasteful with our time but rather protect it and spend it thoughtfully.