Taking Responsibility For Your Code

When you start a new project from scratch, you have a lot of freedom. Adding lines is almost as simple as typing it out and compiling.

As you add more code, however, it starts to constrain itself. You can’t easily add a few lines here because the code over there interacts with it poorly. Eventually, your code starts to rot and smells awful, but you have to work in it. It’s just not as fun nor easy anymore.

The state of your code base is the result of decisions made in the past. Sometimes developers have taken shortcuts to “get things done”, and then they have to suffer by working in stinky, smelly code that makes it difficult to do The Right Thing(tm). Unfortunately, these developers don’t take responsibility for their situation, and they keep doing what got them there in the first place. A colleague of mine says that they get into a state of learned helplessness.

As a result, it becomes easier to accept the state of the code base, to go with the flow, and to forget to be proud of your craft.

Soon, you are taking shortcuts as the normal course of events in large part because the shortcut looks like the main path. The path to creating legacy code (definition: code that doesn’t have tests) looks a lot less tangled than the path of TDD and SOLID principles. The real deception is that doing so creates the barriers, the gnarled weeds and growth, and you need more discipline and more patience to cut through it in order to get back to the right path, if you even bother at all.

Today’s shortcut results in problems with delivering results in a timely manner tomorrow.

The good news is that code is malleable. Even if the current state is bad, it’s possible to improve it, even if just a little.

Each day, you have an opportunity to improve the code for the people following behind you as well as for yourself as you traverse the path through the code again. And each day, despite the cause of the stench, you have the opportunity to use your skills as a software engineer, skills such as refactoring and TDD, to change the code from the stinky state it is in to a better, lemony-fresh state.

The alternative is to wallow in poor quality code, slowing your ability to deliver, and oftentimes adding to the problems that got you here in the first place.

Take responsibility for the quality of your code. It’s possible to have a better code base. Make it happen.