I love reading the book Code Complete, by Steve McConnell. The following comes from it.
…
Communication with other people is the motivation behind the quest for the Holy Grail of self-documenting code.

The computer doesn’t care whether your code is readable. It’s better at reading binary machine instructions than it is at reading high-level-language statements. You write readable code because it helps other people to read your code. Readability has a positive effect on all these aspects of a program:
– Comprehensibility
– REviewability
– Error rate
– Debugging
– Modifiability
– Development time – a consequence of all of the above
– External quality – a consequence of all the above

Reable code deosn’t take any longer to write than confusing code does, at not in the long run. It’s easier to be sure your code work if you can easily read what you wrote. That should be a sufficient reason to write readable code. But code is also read during reviews. It’s read when you or someone else fixes an arror. It’s read when the code is modified. It’s read when someone tries to use part of your code in a similar program.
…
You should go to the effort of writing good code, which you can do once, rather than the effort of reading bad code, which you’d have to do again and again.

The idea of writing unreadable code because you’re the only person working on a project sets a dangerous precedent. Habits affect all your work, you can’t turn them on and off at will, so be sure that what you’re doing is something you want to become an habit. A professional programmer writes readable code, period.

…
If you think you don’t need to make your code readable because no one else ever looks at it, make sure you’re not confusinf cause and effect.