I’ve sometimes come across software developers who, at least on the surface, seem determined to make things outrageously complicated. So much so that it feels like a hallmark: the more obscure it is, the more I prove how good I am. I suppose that may be what they’re getting at.
Still, when we write a new piece of code, the question we should ask ourselves is: “Will we understand this ourselves some time from now?” If the answer is yes, the next question should be: “Will others understand it—the people who inherit this work, for better or worse?”
I always say that if the first goal of good software is to solve a problem and be useful to someone, the second is to write code so that others can easily take over what we do. It’s naive to think that the more convoluted we make our work, the more technical esteem we’ll earn.
Experience has taught me one clear, irrefutable thing: the best solutions—the ones that have surprised me most—have clearly been the simplest. Anyone can deliberately make something complicated, but few, very few, can find the simplest way or solution.
This should be one of the principles guiding our day-to-day work: always try to find the simplest solution to any problem, whether in programming, design, and so on.
This principle won’t just improve our products and make our future work easier when we need to modify an application again. Over time, you realize that the constant habit of looking for ways to simplify things actually reprograms your mind, so simple solutions start coming to you naturally.
I wholeheartedly recommend reading (and rereading) Code Simplicity, Max Kanat-Alexander’s book. A software engineer at Google, he reflects on ideas that can do a great deal to improve the quality of our work. His blog also has some very interesting posts.