Attributing the speed of a developer to that developer alone is a myth. Put a very fast developer into a slow codebase, and they’ll code slow. The only time these two factors meet is a fast developer in a codebase and an environment they can excel in. The biggest speed boost available to coders is the codebase they work in. Having a codebase that is well maintained and easy to make changes is a worthwhile pursuit. It allows for everyone working in it to work faster despite their current ability level.

What kind of elements in a codebase cause a developer to slow down? If I have to edit behaviour in four places before it is “live” to the customer is one obvious case. The inverse of this is also true. Clumsy abstractions make it difficult to get features out. Continuous Delivery is another major factor to the speed a developer works in. So what defines a codebase to be 10x versus 0.1x besides the nebulous and controversial “clean code”.

Readability & Simplicity: The Foundation of a Scalable Codebase

The mark of an exceptional coder is that the code is easy to understand. Often people expect the opposite. A smarter coders code is so exceptional no one else can understand it. The mark of “genius” is actually “extreme simplicity” not “overt complexity”.

Readers also understand the original intention of the code. Clear, descriptive names for variables, functions, and classes aide coding intention. Readability includes consistent naming patterns that match domain logic. The expert programmer prefers explicit over implicit logic. The expert coder makes it obvious what the code models assumptions are.

Expert coders also understand the need for abstraction or DRY concepts. They understand code duplication is necessary in this process. Sticking to single responsibility principle while offering library functions.

Maintainability: Code That Can Evolve Without Breaking

Maintainable code is easy to debug and find errors. Proper error handling involves clear meaningful error messages. Structured logging and monitoring allows for regular tracking of errors within production. Unit and integration tests to catch error edge cases before reaching production. Acceptance tests ensure the code is workable before every release.

What does developing faster actually look like? Code that can change when presented with a new idea is the mark of a very good codebase. These codebases enable consistent and dependable addition of features. It’s not enough to push a new feature that works 85% of the time. The reality is even a 15% “not working” is a significant bug to the end user, especially given enough traffic.

XKCD - 1012

Wrong Superhero - The Villain is The Hero

The problem with the hero-complex in code is often the villain is the hero. In codebases, the developer who best knows how to fix a bug is the same person that created it. Just like in the etomologist fighting the ant instead of the entomologist. What you wanted was an all-knowing developer that can ship anything. What you got was a developer that creates his own bugs and fixes them.

I don’t deny there are orders of magnitude more effective developers than others. They create bigger and better projects in shorter periods of time. They generate the “shareholder value” our company needs. However, this type of developer exists a lot less in the wild than we realize. Developers should focus on the code, and making it better. This is better than comparing their relative skill-set to other, more skilled developers.

Conclusion: The Competitive Advantage of a 10x Codebase

The advantage of a 10x codebase is it aides developers in creating solutions. Do not let your competitors win this battle.