By Dave Rael January 25, 2016

When Should You Improve?

Resolutions for the New Year seldom have the lasting impact they intend to. Unpacking the reasons for this is difficult. The human psyche is so complex it can be hard to determine all the reasons for why we fall short.

The problem with taking the New Year as an opportunity to change our habits is that, by fetishizing the time period in this way, the period’s sacrosanct status may serve to hamper our efforts to change. If we let the first flush of the New Year go by without making the changes we promised ourselves we’d make, we may begin to feel absolved of taking action as January turns into February and February turns into March.

Putting It Off Until Tomorrow

Mexican businessman playing video games at homeThe phenomenon of the annual purging of our old, bad habits and the attempt to replace them with something new is tainted with the Fatal Tomorrow Fallacy. Don’t worry if you’ve never heard that term before; I just made it up.

The Fatal Tomorrow Fallacy is the idea that you have a magical time tomorrow, next week, next month, which is the right time to fix what’s broken. It is an insidious evil because waiting to take action on something of value has several adverse consequences.

Waiting until the New Year to fix a problem is a form of procrastination. In choosing what to do with your time today, you are subject to opportunity cost. Unfortunately, you can’t get everything done today in the way you’d like. Choices must be made and priorities materialized. Choosing actions that will improve your life and have lasting impacts for many tomorrows to come are great choices for what to do today. Waiting to make those changes in favor of something seemingly urgent today makes for a less-than-optimal tomorrow.

Suspending a thread with an idea for improvement to another time also incurs the overhead of context switching.  If something is on your mind today, there is a cost associated with saving it to durable storage (in your mind or in some sort of external brain) and reconstituting your context later.

Using a magic date for an improvement can mean you’ll be trying to concentrate several changes into the same time frame.  This is a recipe for failure.  I’ve certainly experience taking on too many things at the same time, leading to coming up short on most or all of them.

Finally, we should consider our mortality.  There is no guarantee your existence will have another tomorrow.  If there is a tomorrow, there is no guarantee we will have the same capabilities and capacities we have today.  Accidents can strike at any time.  Something left undone today may remain undone permanently.

Arbitrary Milestones

Depositphotos_77665216_m-2015Why is January the best time to fix something or upgrade the way you operate?

Marking the beginning of the year at a given point is arbitrary. Even if it wasn’t, limiting yourself to moving into new habits can happen at other times.

The .NET Rocks! podcast is a great show that has been creating awesome content for a long time. I’m not sure if there is another podcast with such longevity. I recommend giving it a listen, even if you don’t use .NET. Richard Campbell and Carl Franklin are simply awesome.

When they reached 1000 episodes, they had a special retrospective show to mark the occasion.

The conversations they had leading up to the milestone were fun. There was a sentiment expressed that 1000 was not worthy of celebration for geeks, but that it should be 1024 instead because software geeks love references to all things binary and a kilobyte is often regarded as 1024 bytes.

Really, this shows the arbitrary nature of the selection of noteworthy spots. One of those numbers is as good as another.

Today is as good as the first day of January for making something better. It’s not the date that makes a given moment significant. Rather, it’s your choice to act that makes the day important. . Making this choice won’t remove all potential excuses, but it will destroy the tomorrow fallacy and solidify your choice of direction.

There is not any more magic in a date on the calendar than there is in an episode number. 1024 episodes over the course of decades is a monumental accomplishment, but so is 1023.

Planting Trees

Often cited as a Chinese proverb, a bit of wisdom states:

“The best time to plant a tree was 20 years ago. The second best time is now.”

Trying to use the boundary between years as the line of demarcation for acting to improve oneself is fraught with peril. The looming of a date on the calendar that seems like a nice place for a fresh beginning is, more than anything, an excuse for doing nothing.

Waiting is also a way to limit the benefit of your improvement.

The core tenet of Extreme Programming is the idea that if a practice is beneficial, you should take it to the extreme and do it all the time.  In the same way, if you have decided on a way to improve, your best course of action is to take advantage of the benefits of your new practice immediately.

The idea that “I’ll start my diet Monday after enjoying cake Sunday” is really just a lack of commitment to the awareness that making different choices is in your best interests.

If something is better, it’s better now.

When a software system has defects, usability issues, or other problems that hinder operation, but with known workarounds such that it can still run, the problems are often treated as lower priorities than other urgent matters.

Sometimes this is the correct assessment and the lights must remain on. Sometimes we do have urgent matters that need to be addressed first. When we can “limp along,” we usually do just that.

Urgent matters get addressed, and workarounds stay in place.

Usually, things that seem urgent might be less impactful than we think, though, and, in the long term, suffering through interminable workarounds is a hindrance to progress.

This hurts the value we provide over the long term. Udi Dahan stated this eloquently on Twitter:

Udi Dahan @UdiDahan

Insight: today's burning issues were bred by us being too busy with yesterday's burning issues to deal with the important but not urgent stuff.

4:42 AM – 22 Dec 2015

Days pass as we suffer sub-optimal, but still operational workarounds. Days turn to week, weeks turn to months… you get the idea.

Debt as Future Burden

Ward CunninghamBusinessman go up a escalator introduced the popular metaphor technical debt. This term represents the costly shortcomings on quality appearing in software systems over time. Debt arises due to both entropy and conscious decisions to compromise in order to meet schedules and deal with other constraints.

It captures what we know to be true in the real world – taking on debt leads to a burden in the future that will interfere with progress on the issues of tomorrow. Limping along with sub-optimal workarounds in your system is like racking up credit card debt and making only the minimum payments.

Paying down your technical debt is often a hard sell in current work environments where so many people want to complete projects as quickly as possible and move onto the next. It’s even possible some of these people cut corners knowing their quick fixes will slow things down in the future. More often, however, it’s just not understood that quality matters and making compromises today constitutes taking on a technical debt that will hinder future progress.

It’s not controversial among programmers to assert that “technical debt slows down a project more than anything else”. Fixing the problems that will make you slow in the future should be a priority today.

When and Why

The advice here to improve now rather than later might seem to contradict Robert Whitcomb’s admonition to stop improving yourself.

I don’t think it does, though.

Robert’s caution was to avoid the trap of “continuous improvement” and ride the ebbs and flows of the flow cycle. Make sure you incorporate downtime into your routine, prioritize your life, interweave it with your work, and enjoy the things that light you up.

The point of “stop improving yourself” is not to literally stop improving your life, your project, your product, your environment, and your productivity. The point is that you already have a lot to be proud of and guilt over not accomplishing some goal is counterproductive.

It is also an emphasis on something easily forgotten among the hard-charging productivity jockeys that are probably a majority of the Simple Programmer audience: downtime matters and you need it.  It’s important to waste time well, in addition to maximizing the benefits of productive time. The example set by John Sonmez of relentless dedication is paralleled by very few, and even he recognizes the value of some downtime.

Similarly, the point of The 4-Hour Workweek is not to literally limit your time working to an extremely small number, but to make the most of your time by investing it in the activities with the largest returns, as per the Pareto principle.

Making the most of the time you spend working is the best way of which I am aware to make sure you can accomplish what you want and still have time for the things that matter.

When you identify a way you can make your life better, the best thing you can do is act on it. Make it a way of life.

search for itThis can include fixing bugs you have been working around in a sub-optimal way.  It can mean taking better care of your body, the hardware that supports the software that is your mind.

Keep in mind the pitfalls of the Fatal Tomorrow Fallacy.  Limping along today means more urgent problems tomorrow to interfere with delivering what you need to get done.

In our personal lives, as well as our professional lives, addressing what can be improved is best done now. Magical dates are not magical.

What are your thoughts on using the New Year as a crutch to avoid things that would be better addressed sooner? What changes do you need to make that you can address now?  How will having read this piece change your strategy for tackling what you need to do? Leave a comment below!

About the author

Dave Rael

Dave Rael is a dedicated father and husband and a seasoned software professional. He specializes in building distributed systems and understanding problem domains, especially via Domain-Driven Design and Behavior-Driven Development. Outside work, he's usually playing with kids, playing basketball, lifting weights, coaching youth sports, and enjoying dirty jokes. He blogs at optimizedprogrammer.com about writing software and getting the most out of life and is the host of the Developer on Fire podcast at developeronfire.com, where he extracts inspiring stories from successful software geeks.