Why Senior Devs Write Dumb Code and How to Spot a Junior From A Mile Away

One of my all time favorite quotes is from Brian Goetz, a smart dude in the Java world who is one of the authors of Java Concurrency in Practice, among other things. The quote appears in an interview that Oracle published under the title, “Write Dumb Code”. Goetz was asked how to write code that performs well. Here is what he had to say:

Often, the way to write fast code in Java applications is to write dumb code — code that is straightforward, clean, and follows the most obvious object-oriented principles.

The rest of the ~1000 words is devoted to explaining why trying to optimize code and trying to be clever is a common programmer mistake — a rookie mistake, if you will.

Senior dev code

If, like me, you were once a Junior Dev, you may remember your first experience looking at a Senior Dev’s code and thinking, “I can write that. Why aren’t I a senior?”

Yet I tried to write code like that for a long time, and I couldn’t.

What was so mystifying about “Senior Dev” code was not that I didn’t understand it, but that I could understand it immediately, it was fundamentally dumb, and it seemed like there had to be more to it. “Where’s the rest?” I remember thinking. “How does this do all of that?”

Since then I’ve learned all the names of all the principles and qualities of code that make it dumb: YAGNI, Single Responsibility Principle, DRY, Single Level of Abstraction Principle, low coupling, etc. And I’ve become a “Senior Dev” as well. (I actually hate the term “Senior Dev” and refer to myself only as a “software engineer” but that’s a story for another time.)

The greatest lessons I’ve learned are that writing dumb code is actually hard, and that it pays exponential dividends to do so.

How to Spot a Junior Dev a mile away

In Refactoring: Improving the Design of Existing Code, Kent Beck says:

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

You can always spot a Junior Dev when you come across code full of clever one-liners, murky abstractions, and/or gobs of language features. I’d say the latter is the most common one. It’s like the code is trying to say, “Look at me! My creator really knows the language! I use default interface synchronized thread-local JavaBean copy constructors with custom generic unchecked exceptions and cross-functional security-hardened JAXB Lombok code generation!”

Yes, I’m spouting nonsense because nonsense is often what code can turn into in the hands of someone who is thinking exclusively about the computer side of things, rather than the human one.

Code is about communication with other humans and giving instructions to a computer, but it is now much more of the former than the latter. The compiler takes care of translating what programmers write into machine language. Often, there are several layers of this translation, such as when Java is compiled to ByteCode, which is read in by the Java Virtual Machine at runtime, where it is ultimately translated down to just zeroes and ones.

But code is human language. It has to communicate the who, what, when, where, how, and why of a task, as well as instruct the computer. It has to make sense five years from now after the company has been acquired and a new team who has never seen this code before has to crack it open and make an enhancement or fix a bug.

Yes, writing dumb code is hard. I feel like I’m getting the hang of it more and more as time goes on. I feel gratified when I get comments like “Clean code!” in code reviews. I know that the best thing I can do for my team, and the future maintainers of the code, is to write dumb code.

For fun, I’ll leave you with one last thought from Dave Carhart: