[ericelliott]

There are a few first principles from which we can design code.

The first is: Requirements change.

For many reasons. User needs change. Business processes change. Technology evolves.

If you're going to keep up, you must design code that is easy to change.

Code that is easy to change tends to be code that can work with lots of different code.

Code that can work with lots of different code tends to lean towards the general end of the spectrum, rather than being too specific.

Designing code that is modular does not mean that you need to over-engineer, and it doesn't even mean that it needs to be used more than once.

It should mean that the code has locality: The ability to understand the full effect of the code without also understanding the full context of the code around it or the full history and future life of every external variable it uses.

It may sound to new developers like I'm talking about something complicated, but it's the opposite:

Code that can be easily adapted to future use-cases tends to be more simple. It tends to know the least about it's environment. It tends to do only one thing, but do it so well as to be perhaps the optimal solution.

What follows from the first principle is perhaps the most important principle in software development. Remember this and you'll find yourself needing to do a small fraction of the work you once did to produce the same value:

A small change in requirements should lead to only a small change in implementation.