Clever code is bad. Don't write clever code.

“Wait! Isn’t code supposed to be smart? Programming IS hard! We have to be smart!” 

Nope.

Code is supposed to be simple. And programming is no place for being a smart-ass. Let me explain.

What is clever code

Clever code is code that when you read it your face goes like this:

Or like this:

Or like this:

Clever code is code that should be instantly and effortlessly understood  – but it’s not.

It can exist in many forms. It can be that one liner that does too much.

return i > 0 ? i << 2 : ~(i << 2) + 1;

“WTF?”  (Apparently, this multiplies it by 4 and makes it positive – who knows. Got it from here.)

It can also be that super over designed set of classes that is so abstract that you spend an hour navigating the inheritance hierarchy and still have no idea what’s going on.

“But that code looks pretty simple to me! What’s the problem?”

Yes, code cleverness is subjective, a matter of opinion. What is hard for me to understand might be easy to you. And that’s my point with this article:

We don’t write code for ourselves, we write for others (and the other might be future-you)!

Clever code is bad because if it’s not understandable it’s not maintainable.

It’s bad because debugging it will take energy that could be applied to higher value activities such as building new features, improving tests, automating tasks or trying new technologies and tools that will deliver value to your customer.

And it’s bad because it makes coding look harder than it is. It makes people feel that they don’t know stuff and causes friction where we should be making things easier, smoother.

Level up as a developer

Caring about the consequences of clever code and avoiding them is one of the things that makes you a senior developer, not the number of tricks or obscure language constructs, or your ability to write a whole program with one line of code.

It’s common for beginners to write clever code. Not the absolute beginners – they are still learning the language – but those who are already fluent and learning new tricks. Those folks are proud and want to show off all their skills.

We should learn new tricks but also learn when to use them. And more important: learn the fact that being capable of doing something, doesn’t mean that we should. The same way you don’t wear shorts to a wedding and you don’t wear a suit to the beach, there’s a time and a place for everything.

One sure way that I can spot a beginner is by the clever code one produces. It shows that the person doesn’t quite get that software development is a social activity and that there’s no place for ego.

A big part of the transition from beginner to senior dev is this understanding that our purpose is to build value to the organisation that employs us and that code is only a tool and should be treated as such.

So, if you want to become a senior dev or a technical leader, you must master and teach less experienced folks how to keep the codebase clever code free.

“Okay, got it. What should I do now?”

It’s hard not to let some clever code slip into the codebase every once in a while. After all, it’s not always evident that some code is clever – it might be simple to you, right?

That’s why we need to watch ourselves all the time. Here’s a few ideas that will help:

Use the common way of doing stuff

Usually, there is more than one way of doing something. Use the oldest, most boring, obvious way, that any beginner would understand. No magic, no frameworks, no anything that would require extra knowledge or brain cycles to understand. Instead of doing:

while (*d++ = *s++);

Do this:

strcpy(destination, source);

Don’t try to save space on your hard drive or screen

It doesn’t matter if you end up with more code and bigger files: storage is cheap, people’s effort and time are expensive.

Extract methods, use meaningful names – use as many words as you need to make your intent come across. Use spaces, line breaks, format accordingly. Turn this:

(people != null) && (people.get(name).getAge() >= 18) ? people2.add(people.get(name)) : people3.add(people.get(name));

Into this:

Person person = allPeople.personNamed(name);

if (person.isAllowedToDrink()) {    
    listOfDrinkingPeople.add(person);
} else {
    listOfNotDrinkingPeople.add(person);
}

Objects with behaviour help a lot as well.

Get feedback

Pair programming is great for this. Ask your colleague: “Do you understand this?” “Or is it better this way?” Look if they are making one those faces.

Watch your own reaction for feedback: if you make a face reading some code you’ve written, change it!

Do code reviews – have the team reading the code and giving feedback to one another.

What’s next?

Now you know what clever code is, why it is bad and how not to write it. Now you must go one step further and learn about the biggest design mistake and 4 strategies to avoid it.