Code was quite unreadable in the old days
Well, if you know me or read this blog since some time, you should know that I consider code readability even more important than correctness. This is because a bug-free code does not exist, thus, soon or later someone will have to fix it in the smallest time possible.
Nevertheless there are at least two situations where is needed that your code is difficult to understand.
You Want To Be Indispensable
It may be because you are a contractor and you want that for the company is easier to ask changes to you instead of trying to manage them internally. Or, if you are an employee, you may be afraid that someone else can take your position, and the company can decide to fire you.
No matter the reason, writing unreadable and poorly commented programs is a good way to make the understanding of your code really hard and time consuming for everyone, except you. With these premises, the company best choice is to don't give your code to anyone else.
You Hate Your Colleagues
This is a sort of revenge. Do your mates have a better salary than you, bombastic titles in their business cards, and the boss always praises them? The only way you can punish them is by forcing them to understand your terrible code.
This can be done in a large scale by including a refactoring session each time you add a new feature or fix a bug in an understandable file. Of course, your main goal is to mess things. This is also called refuctoring1.
They have to feel the pain each time they are requested to change something you touched.
There aren't many, just a couple. First: your colleagues may hate you and consider you a bad programmer. If you are writing unreadable code just to annoy them, this should not bother you too much.
Second: the code will be difficult to understand for you too. So, after a couple of months it will be painful for you too to manage you own code. If you are an hourly contractor, this can be a good thing since every change will take longer.
I personally don't see any other reason to write poorly readable code. And also the above two are quite questionable. Always remember that, with a good VCS, it's easy to detect who introduced the mess in the code and, at some point, someone may decide that is better to restart a project from scratch instead of having only one developer able to manage it.
Image by Arnold Reinhold taken from Wikimedia Commons licensed under the Creative Commons Attribution-Share Alike 2.5 Generic license.
This post has been updated after its initial publication. Last change made on 2016/11/06.