by Leon Rosenshein

Hey, That's Pretty Clever

snark code quality tech debt

A dungeon master with unruly hair and d20.
The Dungeon Master of Engineering has been on Twitter for just over 4 years now. There have been lots of snarky (but accurate) tweets about life as a developer. Recently there was a whole thread contrasting the viewpoint of someone new to tech with a tech veteran. Some are whimsical, some are political, and some are learnings about things developers deal with every day. There are lots of really good learnings in there when you look at them.

One of my favorites is

New to tech: 
That's really clever, ship it. 


Tech Veteran: 
That's really clever, fix it.

I really like that one. Because I used to do clever things. Call things and rely on their side effects to save a few lines of code. Use Duff’s Device because it’s interesting and maybe faster even if the speed wasn’t needed, but Speed is Life. Or simple things like reuse a variable that wasn’t needed anymore to save a little stack space. Or in C++ use a , as a sequence point instead of just making a new statement.

Clever is nice. Clever is fun. Clever makes you feel smart. And we all like that. It’s great. Until it’s not.

Because the failure mode of clever is jerk. This is true when speaking or writing. Not just writing comments like tweets, but also when writing code.

Clever code often works at first. It might work for though a couple of requirement changes and refactors. And it might even work after that. But it’s value goes down fast. The code was written once. And it will be read many times. Now, every time someone needs to read the code to understand what it does, whether to extend it, refactor it, fix a bug, or just avoid adding a bug, that person will need to figure out what happens in the bit of clever code. That takes time. That takes effort. That increases cognitive load. Which makes everything harder.

And no one wants that. Software engineering, the balancing of conflicting goals and requirements to solve a user’s problems, is hard enough. There’s no good reason to make things harder on ourselves when we don’t have to.

I will acknowledge that sometimes you have to. If you’re writing an embedded controller and need to save every byte. If you’re working on the inner loop of a complex, time consuming rendering loop and your profiling has told you that this is the function that’s blowing your time budget. If you’ve found something new and novel in the domain that means your clever solution is actually the right one in this domain’s context. But those times are relatively rare.

So when you run across clever code, code with a slightly more verbose or slower implementation, code that can be written in a more maintainable way, consider fixing it. Make it less clever. You’ll be thanked by your peers and by future you. They’ll think you’re pretty smart for not subjecting them to clever code.

And that’s the best kind of thanks.