Technical debt from the developer perspective

Technical debt is a common metaphor in software development, taking shortcuts will allow us to ship code faster, but in the long term makes the code harder to change and extend. There are many many articles on cold rational reasons why you should always go for the clean slow proper programming and avoid all those sneaky ways to accumulate technical debt.

We won't go on showing fancy graphs of how it accumulates and how it impossible to add new features. We won't allude to your better side, that you should know better. Also probably you won't be going away here nodding and promising yourself that you'll wake up tomorrow and write clean respectable code.  We will take a look at how those spaghetti shortcuts come in from a few different perspectives.

Now they might not all be applicable or relevant for your use-case but in general, they might help explain how its current state came to be. Who? you might ask. The one project everyone at your company avoids, whose mere mention destroys even the happiest of office moods. I personally like to refer to it as Hastur! Him Who Is Not to be Named!

Back to reality, this is just the first of the series of posts that look into different aspects of the Technical dept. Check out the article that looks at the topic from a business management standpoint, which might make it easier for you to get your management on board towards reducing technical debt.

Technical debt as a habit of procrastination

Do you know what the previous section and most technological debt articles remind me of? Articles about weight loss and procrastination. All three share the same mental process: "Prioritizing short-term satisfaction that hurts your long-term goals". Also, the bad ones talk about rational reasons. Like I need you to tell me that never exercising is bad! And good ones focus on ways we sabotage ourselves every day.

Eating a jar of Nutella won't make you overweight. Finishing work early on a Friday so that you can finish a new game in one weekend won't make you a bad employee. Rushing the last two days before a deadline won't make your code an unmaintainable mess. Trust me I did all three repeatedly during the great stay-at-home of 2020!

The habit of always choosing the shortcut leads to technical debt

Now, do any of those daily or even weekly, and you are in for a bad time. The problem is not in the single act, but in the habit that might develop from it. Try reflecting on your last workweek and finding patterns. Cases where you felt obliged to rush something or avoid documenting something, or proofreading comments. Such patterns might give you some insights into what triggers you to choose the easy way out. Knowing them is the first step in avoiding or preparing for such situations in the future.  If you'd like to really dig deep into optimizing personal and workspace habits, I wholeheartedly suggest the Atomic Habits book. It's a very good starting point for analyzing all the little things that you do without thinking about them every day.

Now sadly, as most blog posts, this won't be a complete guide on how to solve procrastination or shortcuts in code. But we will leave this topic with a video on procrastination. Watch it, and then try watching it again and replacing the word "procrastination" with "quick and dirty code."