This is one of those questions that I often ask when I am interviewing a computer programmer job applicant, trying to get a sense for an engineer’s maturity with the craft. (And for the record, I don’t think the question has a “right” answer. Certainly there is no ideal one-sentence response.)
Sometimes I get answers like this:
- “Whatever gets the job done.”
- “Whatever sells.”
- “Whatever solves the customer problem.”
Such answers tell me that an engineer is practical, business-aware, and customer-focused–all useful traits. Pragmatism is usually learned in the economic school of hard knocks, and it’s a critical perspective that should never be forgotten. But I don’t get a warm fuzzy from pure pragmatism; it lacks vision or love of craft.
Another kind of answer focuses on cleverness:
- “I wrote a burst sort once that could beat stdlib qsort. It’s counterintuitive, I know, but the way burst sort works cache…”
- “You wouldn’t believe how much you can say with a 3-line statement in python…”
An engineer with this type of perspective also has praiseworthy qualities–an appreciation for elegance, a desire to achieve. But I find these answers unsatisfying as well. For one thing, the statements are lonely; notice how little they imply about who will build upon or use the finished product. In this vein, I love Martin Fowler’s warning in Refactoring:
“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”
I’ll also include a “miscellaneous” response category, which encompasses stuff like:
- “Good code has to be scalable, make efficient use of resources, optimize for good performance, …”
- “Good code is maintainable and testable.”
- “KISS — keep it simple, stupid.”
All true (the first statement less than the other two, IMO), but all less than fully satisfying.
So what answer would impress me?
Albert Einstein supposedly said, “Make things as simple as possible, but not simpler.” Well, I think good code is quite a complicated subject, and the first thing that would impress me is an acknowledgement that I’ve posed a very difficult question indeed.
Since I’ve already mentioned one of my favorite quotes about simplicity, I think I’ll mention the other here, as well. Oliver Wendell Holmes: “I would not give a fig for the simplicity this side of complexity, but I would give my life for the simplicity on the other side of complexity.”
Holmes was talking, I believe, about wrestling with a difficult, multifaceted problem, and distilling it down to its essence only after all its dimensions are fully understood.
I’m going to post a few observations on what I think constitutes good code in coming days. These will be glimpses of zen that I’ve occasionally stumbled upon on the “other side of complexity” as I’ve wrestled with the craft through my career.
I’ll be curious to know what you think, as well.
(Read more posts in my “What is ‘Good Code’?” series…)
5 thoughts on “What Is “Good Code”?”
Just ran across a tweet by @trev_harmon. It dovetails so nicely with the Martin Fowler quote that I just had to repeat it: Dear communicators: I don’t care if you understand complex thoughts or concepts, but rather if I do after listening to you. #simplify