Consistent > Idiomatic

Idiomatic code refers to code that follows the general conventions and best practices of a particular programming language. It is code that is written in a way that is considered “natural” or “typical” for that language.

As a direct consequence of my previous point, I believe that consistent code is better than idiomatic code. Being consistent does not preclude being idiomatic or vice versa. However, the two may sometimes be at odds due to project specifics which might make keeping a strictly idiomatic codebase a nightmare.

Years ago, when I joined my first big Java team, I had gathered many preconceptions on how Java projects should be built based on best practices outlined by books like Design Patterns and Effective Java. Little did I know, I would soon be thrown into a completely new massive project where many “non-idiomatic” decisions were made to keep the code easy to follow and understand by everyone.

While I objected at the beginning, I quickly realized that those decisions were the best ones for the project’s long-term viability. After a few days, I completely eased into the team’s conventions and could onboard others with the same ease a few months later. Had we stuck with all the “by-the-book” principles, we wouldn’t have been able to scale it to become the market success it is until today.

This does not mean that knowing the principles isn’t important. For the same reason I often page through Design Patterns and Effective Java for some forgotten wisdom, I regard Go’s foundational principles and focus on keeping code idiomatic. And yet, one of the skills that makes a great engineer is knowing when to forgo the principles in the name of pragmatism.