Smart Code sucks, write Dumb Code instead
“Smart Code” are the lines of code that try and save you or your users time and effort by doing more work than is expected.
As a hypothetical example, imagine an Article class that has a method named publish(), and it works like this: First it autocorrects any spelling mistakes, and then sets the status to "published". This ensues writers always appear professional. Cool, right?
Not so fast. Imagine you’re the one writing an article for other developers. After hours you’re happy with it, and you click publish. Suddenly the published version shows all the camelCase variable names you wrote with spaces and in a different case. What a pain! You quickly go back to the editor, fix the errors, and hit publish again. But it autocorrects it again! Mildly fuming, you hit unpublish, and spend the next three months building your own blogging platform.
“Dumb Code” on the other hand are the lines of code that do exactly what you expect them to do, nothing more.
If our publish() method, was Dumb Code it would simply set the status to "published". Nothing more.
This example may seem obvious, but I see issues just like this all the time in my own codebases and in others. Whether we write it to flex our computer science knowledge, save time, save lines, impress our colleagues, or to accommodate that future unspec’d feature that’s just sure to be needed, we’re addicted to writing Smart Code.
But here’s the thing, Smart Code by definition is unusual code. It’s doing things that were unexpected, or in an unexpected way. This can make it hard to read, to understand, to maintain, and to optimize. It’s also a safe haven for ill-intentioned bugs to hide out.
You don’t need to write Smart Code to prove yourself. Writing and promoting Dumb Code can show far more wisdom.
In another example, how about when viewing articles — should we filter out any articles that have empty bodies? Surly the writer doesn’t actually want their unfinished article to be visible by accident? (We’ll get back to this).
The solution is not just about just having pure functions with no side effects. It’s also not about creating more work for you, or your users. It’s all about providing control.
To write Dumb Code, you have to provide control
Dumb code does the exact amount of work that you’d expect it to do.
If I flick the light switch, it won’t try and adjust the brightness and color to match the room — the light will instantly just turn on, or off. It’s boring, it makes no assumptions, and most importantly I never have to worry about it (Hey Google, you might want to listen in).
So how do you stop being so damn smart?
Live up to your naming
To write Dumb Code, start by thinking about the name you’re giving your class or function. If the name is publish, then what would you expect it to do? Would you expect it to autocorrect your work? Remember, the only rule you need for writing clean code is to always be referencing a mental model.
If the function was instead called autocorrectAndPublish, what would you expect it to do? I’d argue you may still have a terrible user experience because the control provided just isn’t granular enough, but it would be Dumb Code because it does exactly what is expected.
Don’t make assumptions
Being able to realize when you truly know something, and when you’re just assuming something because it’s logical is an incredibly underrated skill to have (in coding and in life). While coding, if you can notice the times when you’re slightly unsure of what to set a value, or whether or not to call some function, it likely indicates you’re about to make an assumption.
In times like this, you might also think you can infer the value, or figure it out by doing some automated work — but the thing is, you’ll be wrong. Not always, but there will be times where your assumptions won’t be valid, and you’ll be wrong. This will not only produce an annoying UX, but can also cause some of the sneakiest bugs you’ll ever have to deal with.
Think about a company signup form. We may think it’s a good idea to ask for their web address, so we can scrape their website, determine their industry, and then show relevant content as soon as they enter like magic (it lowers the barrier to entry, and there’s never an initial empty state!) But now imagine what happens if they mistype their address, don’t want to provide one, or just input a fake address to trial your app.
Stop creating work for yourself and just dumb it down.
Prevent problems, rather than intelligently fixing them
So you’ve stopped making assumptions in your code — but now you have people complaining because you didn’t assume how to fix their mistakes — and they make a ton of mistakes.
Let’s go back to the example of adding logic to filter out articles that have an empty unfinished body text. You say, ok I know this is just an assumption that people will want this, so I won’t filter them out. But what if they do want that? How do you fix this without making assumptions?
You don’t fix it, you prevent it. You can provide control at the root cause of the issue.
In this case it might be a confirmation box that appears when you go to publish a blank article, or publishing is prevented altogether until some body text exists. That’s Dumb Code, and it prevents you from having to write Smart Code.
Dumb Code doesn’t make assumptions, it doesn’t do more work than it’s expected to, and it puts control in the hands of the user. Dumb Code just does exactly what you think it does.
