• Tobias Coetzee

Conspicuous Cleverness


One of the biggest problems with code maintainability is developers trying to write super clever code. A phenomenon I like to refer to as ‘conspicuous cleverness’. This usually leads to code that causes lots of issues and huge headaches later down the line.

Why would one developer do such a thing to his fellow developers?


Signalling Theory

I was listening to a Freakonomics Radio podcast this past week and one of the economic theories they referred to was Signalling Theory. It is where you buy a Prius not just because you care for the environment, but because you want to make sure everybody else knows it, i.e. using the Prius to signal that you care for the environment.

In the same way, I think some developers try to write super clever code just to signal to their peers and managers, ‘conspicuous cleverness’. Instead of waving a big golden flag they are actually waving a big red flag saying ‘Unmaintainable code, this way comes’.


Altruistic Code

Most of the time this super clever code is written for the now, not for the future. When you write code, always think about how easy this code is going to be to maintain in the future. Write altruistic code. Care about the future developer who is going to have to maintain your code.

If you wrote super clever code then future developers aren’t going to look at your code and go ‘Wow, this code is awesome and super complicated, I love it’. They are going to look at it and go ‘#$@@!$$#, what is this?’. Write the type of code you would check in with your physical address attached to it knowing an axe wielding psychopath is going to maintain it later.

I have to add that I think the worst kind of super clever code is where a developer has learned something new and is forcing its use in a project (refer back to my code generation post for an example).


Make friends, not enemies

You will impress your peers and managers more by writing clean, easy to maintain code. Remember the first thing you need to accomplish is solve the problem at hand. After solving the problem you can look at improving the code from a performance and cleanliness point of view. I’m not saying finish an entire project and then go and refactor, that will be crazier than an axe wielding psychopath.


Solve the problem, test, refactor, test, repeat. This is the infinite loop your development should be stuck in.


Don’t start off with ‘how clever can I design this code’, it is like putting the cart in front of the horse or the class before the namespace, classic race condition. Write the kind of code that will make you friends. I will have some future posts on how to write the kind of code that makes you friends.


Share some of your advice on writing maintainable code, what should other developers look out for and not do. Also, subscribe to my blog and you won’t miss any future posts.

0 views

© 2023 by Design for Life.

Proudly created with Wix.com

  • White LinkedIn Icon
  • White Twitter Icon
  • White YouTube Icon