“Oh, so that’s all. That’s really easy.”
“Really? That’s all it does?”
“So where’s the hard part? I understood that straight away when I looked at it.”
Sometimes these questions are even asked of me, which is flattering ;) The flippant answer, of course, is “So that any idiot can come along and understand it.” Disappointing though it might be, this answer is also quite correct.
If you only ever take one piece of advice from this blog, take this one: Code yourself out of your job.
Coding yourself out of a job doesn’t mean you’re going to get fired when you’re done. Coding yourself out of a job means that you don’t end up responsible for the same chunk of a project forever, always fixing bugs in it because it’s too complicated, too involved or just plain scary for newcomers.
There’s an art to having someone look at your code and understand it at a glance. It’s a subtle display of skill, the result of which being that the person reading your code doesn’t even realise that you got inside their head before they ever arrived, understood what they’d be thinking when they looked at it and gave them subtle cues as to which parts of the code were the ones they were looking for.
There’s also a corresponding amount of confidence required in order to be able to choose a less optimal solution in terms of performance for the sake of comprehension. Why confidence? Because as part of having your code look simple, you have to be willing to have someone stroll along after the fact and ask within two seconds of looking at your solution, “Why did you choose this way? This other way’s almost twice as fast…” That, my friends, is the whole point: they understood it within two seconds of looking at it.
One “I don’t understand” question about a piece of code and unless it’s a really, really fast and effective algorithm and the alternatives are awful, it’s already cost more in real terms than its fast performance has saved.
Obviously in heavily-hit code paths this would not a good choice, but if I have a method that only gets executed a few times per second then I honestly don’t care whether it takes 0.01s or 0.001s to execute. If there’s no other real difference between the two then of course I’m going to pick the faster one, but if the screamingly-fast one is horrendously complicated and I’m going to be the one who’ll have to come back to it every time it needs modifying, then I’ll take the merely-quite-fast one, thank you very much.
At the point where someone asks why you made a sub-optimal performance decision, you have to be sufficiently confident in your own ability to explain to them that yes, you could have done it another way, but then it’d take longer for every single person who came after you to understand what was going on, you’d have to field more questions about it, and that it actually didn’t matter. You also have to be sufficiently confident in yourself to evaluate their solution and confess on occasion, “Actually, I really do like your solution and it’s better than mine. Let’s do it your way instead.”
In a nutshell, the optimal solution is not necessarily the fastest, but the most effective in terms of the long-term maintenance of the application.
Of course, the really smart ones amongst us can write code that’s simple, obvious and extremely fast. And we’re all that good, right? ;)
 Especially when that idiot might be yourself six months later…
 Unless you work for an unwise company, in which case you might consider leaving very soon anyway.
 Be correct about this, though. If it matters, do it better.