So, how do we manage anticipating too early to change vs. reacting too late to change?

Consider software development like we’re driving a stick shift. As we start, we’re in first gear: coding away at a steady pace. The more we code, the less efficient we become. At some point, we have to shift up a gear.

Shifting up a gear, in programming terms, is cleaning up our code: taking a step back to refactor, abstract, or implement a pattern. It means taking the time to consider how to change our habits at a particular point in the development process. Doing this does not mean we’ve made a mistake. It’s natural and necessary.

We have to shift in code just as we have to when we’re driving. Still, if we do it too soon, we’ll spend a lot of time trying to regain our speed. Do it too late (or not at all), and our code will burn out. Knowing when to shift is essential. It keeps the development process running as efficiently as possible. We don’t shift just to shift; we have to do it when it’s right. We have to find our programming cadence.

There is no set number of gears in software development. We can choose to have just 5 or 500 gears in our programming cadence. This depends on the complexity and scale of the project as well as our own willingness to shift gears. For more complex projects, allowing ourselves more gears means we can shift a lot more often. It means that if we shift a little too early, it won’t take us too long to get back to speed. A little too late, and we haven’t experienced too much burnout. For smaller ones, just a few gear shifts will do.

In the end, software complexity is necessary. It’s the debt paid for more functionality. The key is to know when complexity feels right and when complexity feels wrong. Listen to your sixth sense when it tells you that, this time, complexity makes things worse on everyone. It’s why what we do is much more art than it is science.

Complexity is one of those things we get better at understanding after years of being in the business. Veteran programmers are really good at managing it. Collectively, we need to pass this kind of wisdom onto future generations of passionate programmers. In the next chapter, we’ll look at how we can become not just better programmers but better teachers.