Every now and then I have a discussion or lecture with my roommate Chris, on some aspect of software engineer, architecture, process management, or programming in general. His specialization is psychology, so while this exercise can be cathartic, it’s largely pointless. I’ve decided that it might be more effective to write these things down and post them.

Today, prompted by a discussion on what I should name some new object, Chris asked:

Isn’t all coding about being too clever?

I think that is a conception that many laypeople and beginning programmers have — that we should try to be clever. Seasoned engineers will know that being clever can be one of the worst sins.

Here was my response, paraphrased:

The goal is to write the minimal code that (a) gets the job done, (b) doesn’t break, and (c) is understandable and maintainable by other people.

“Clever” often meets the first requirement, can sometimes meet the second, and always fails miserably at the third — which is actually the most important one. All things equal, I’d often rather have a broken system that I can understand than a rat’s nest of code that happens to work.

That said, sometimes you do come across clever code that meets all of those requirements. These are small masterpieces and works of art and should be regarded as such.