It’s often extremely easy to tell your boss that you wrote thousands of lines of code in a project, and subsequently be praised for your productivity and amazing abilities. However, those lines of code are often full of dependencies, hard to read, and if one library method is changed in the future, the whole mess falls apart. These are only some of the possible problems that we as programmers can run into with convoluted code. Sometimes its more important to write short and concise code; code that although not bigger, is indeed a lot better.

Rich Skrenta summarizes some of these dangers of writing too much code:

Code is bad. It rots. It requires periodic maintenance. It has bugs that need to be found. New features mean old code has to be adapted.

The more code you have, the more places there are for bugs to hide. The longer checkouts or compiles take. The longer it takes a new employee to make sense of your system. If you have to refactor there’s more stuff to move around.

Furthermore, more code often means less flexibility and functionality. This is counter-intuitive, but a lot of times a simple, elegant solution is faster and more general than the plodding mess of code produced by a programmer of lesser talent.

Code is produced by engineers. To make more code requires more engineers. Engineers have n² communication costs, and all that code they add to the system, while expanding its capability, also increases a whole basket of costs.

The real problem with long code is not the code, it’s the coders. After all, we were the ones who wrote the code. Code does not choose to be long, complex, or dependent – we wrote it that way. It’s not that we try to make our code complex, most software developers have really intentions when it comes to what they write. I believe that a lot of our problems come from the competing ideals regarding our ambition to write great code and our ambition to solve the problem presented to us. Often we as programmers can throw some code together that will solve the problem, but we often don’t stop to think about what we are writing. Rather we just write on the fly until the code works on all our test cases, and then its done. We never go back to check if we could reduce the size of the code. We certainly don’t think about the importance of each line as we are writing it. But this is not the right way to think while coding. We should be thinking about each line we are writing; if its really important, or if we can reduce the size of the line.

Wil Shipley provides an really insightful look into what we should be thinking as we write our code:

The fundamental nature of coding is that our task, as programmers, is to recognize that every decision we make is a trade-off. To be a master programmer is to understand the nature of these trade-offs, and be conscious of them in everything we write.

We should always be thinking about what tradeoffs we are making with the code we are writing. It is important that you think about, and question every single line of code that you write. It should be with a heavy heart that you add another line of code to your program. Just remember questions like “Is this line really necessary?”, “Will this cause problems later? For someone else?”, “Could I reduce the size of this line?”, and “Could this line be more readable?”. If you stop and think about things like this, your code will become smaller, better, and sexier.

I have already mentioned this, but its super important to concentrate on the brevity of your code. Keeping everything as short and concise as possible will result in as few problems as possible. From there you can work on the code’s speed, robustness, or flexibility. As long as you start with a good base, you can build upon that base with confidence. Jeff Atwood summarizes some of the advantages to “Coding Small”:

So many aspects of software development can be summarized as small is beautiful:

• The odds of failure for a software project are directly proportional to the size of the project. Slicing a large project into several smaller subprojects is the single most direct way to increase your project’s chances of success.
• The relationship between lines of code and bugs is completely linear. Fewer code means fewer bugs.
• Smaller code avoids TL; DR (Too Long; Didn’t Read) syndrome. The less code there is to read, the higher the odds are that someone will actually read it.
• If you keep your dependencies to a minimum, your code will be simpler and easier to understand.

If you love to code, then I urge you to think about the code you write. No one (I hope) goes to give a speech without thinking about what they are going to say first. The same approach should be taken with your code. Don’t let your ambition for just solving the problem completely take over your code. Think more, code less. I promise you the results will be beautiful.