Given two solutions to a problem, the one with less code is usually better.
Plite of the Programmer
Our job as programmers is to deliver value to customers. We deliver value by identifying needs, translating them into requirements, and writing code to meet those requirements. The difficulty of the task is compounded by the fact that requirements are constantly, unpredictably changing. Even after we finally ship, the story isn’t over. Code is a living thing that must be maintained, usually well beyond anyone's expectations.
Over the lifetime of a product, we will edit code 10x more than we write code, and we will read code 10x more than we edit it. Each token we add to our code may be read over 100 times. Every token we save could save up to 100 token-thoughts and 10 future edits. The key to our productivity is writing less code.
Why Count Tokens?
Tokens are the smallest meaningful element in code. Tokens are a more objective measure of code size since lines can have any number of tokens. Measuring tokens also ignores white-space and comments. Last, measuring tokens doesn't penalize using clear names. ‘Occupations’ is just as good a name under the token metrics as ‘occus’ or other hard to understand abbreviations.
Don't abbreviate words. Saving keystrokes only saves writing the code. It doesn't save edits or reading. Abriviations make reading harder. Since reading code dominates our time, abbreviations are a losing proposition. Only use shortened words if the shortened version is used at least as commonly in speech.
Measuring tokens is a simple, effective metric that lets us make decisions quickly and get on with solving problems and delivering value.
Why ‘Write Less Code’?
It's a simple concept with depth. Amateurs and masters both can apply and learn from it. A more accurate metric might be refactorability. We spend most of our time refactoring code, not writing it. Refactorability is the code-quality metric. It can be broken down into code size, clarity, and structure. Of the three, size is the only one that can be objectively measured, and while clarity and structure are important, both are usually improved by reducing code size. Refactorability is not something a novice will understand. ‘Write less code’ is an excellent guiding principle for all programmers.
How to Write Less Code
All other good coding practices essentially reduce code size. Two of the most important, and most often violated coding practices for reducing code-size are DRY and ZEN.
DRY
Don't. Repeat. Yourself. Don't you dare repeat yourself ;). The most problematic artifacts I've seen, both from novice and expert programmers, is code repetition. The big problem with repetition is it compounds the complexity of refactoring. Not only do we have to fix two or more things instead of one, but we have to understand how they all interact. Plus it bloats the code-base making it hard to understand.
DRY is a subtle art. The first, obvious level is ‘don't copy-paste your code,’ but as we level-up, we start to realize anything gzip might compress potentially violates DRY. The ultimate measure is, as always, refactorability. How many code-points need to change for a common refactor? Is there a way to reduce repetition to reduce the complexity of refactorability?
ZEN
Build it with Zero Extra Nuts (more commonly known as YAGNI). Because it is impossible to
predict future requirements, adding anything to our code that isn't strictly necessary to meet current requirements is not only a waste of time now, but it will haunt us for at least 10x future edits and 100x future reads.
It is fun to add cool features, but the master knows the only thing that matters is delivering value to the customer.
Write Less Code - Formalized
My hypothesis, and my experience, comes down to this:
- Given two different functions, modules or programs
- that both meet or exceed the problem's requirements, both correctness and performance
- the one with less tokens is always better
- as long as it doesn't sacrifice clarity.
The Practice of Writing Less Code
As with everything in life, writing less code is a practice. There is no point where we will master it. There is always another layer of deeper understanding. We are always learning how to make our code DRYer and more ZEN. We must constantly be looking for ways to meet requirements with less code.
