Promises, Plans, Goals

I don’t have any New Years Resolutions for 2016.

My New Years Resolutions for 2015 — the first New Years Resolutions I’ve ever made — were:

  1. Publish 24 blog posts
  2. Publish an illustration or drawing each month

The tally at the end of the year was:

  1. 22/24 (no posts in December)
  2. 11/12 (no drawings in December)

So, I failed. I failed to reach the goals I set at the beginning of ‘15. That’s the simplest way of putting it.

Image: Candle

Many people see resolutions as promises made to themselves. I chose deliberately not to. Breaking a promise to yourself is a horrible and harsh thing to do, and definitely not something that anyone would want to become a habit. Making promises only to break them is lying to yourself, and that is never good. Moving forward requires being honest with yourself.

Seeing a resolution as a goal (not a promise) changes things. A goal is something you strive for. Something new you’ve decided to try to do. Per definition you cannot know if you can complete the goal (even when you have a pretty good idea), because you’ve never done it before. A goal cannot be “keep doing what I do”. (Except if what you do gets harder the longer you do it.)

Failing a goal means failing — but nothing more. You have not failed to live up to your word, because your word was “I will try to do this new thing.” You have not failed yourself, because you only promised yourself to try.

I think this is the key to finding a healthy balance for improving yourself: find a steady pace that you can keep. Only increase the pace when you feel it is stable. Always keep going, even when you fall down. Don’t give up. Try not to blame yourself.

I feel that it is often the difference between promises and goals that makes the process of software estimation such a horrible thing: the developers set goals, realistic goals that they believe they will make and will strive to fulfill; but the business people see promises. Or, sometimes, the developers make promises where they should be setting goals.

Estimates, I find, are particularly prone to be misunderstood in this way, simply because of what they are — but that is a topic for a different post.

I didn’t publish the two blog posts (of which one would be illustrated) I had planned on publishing in December. I could have published some: I have some almost-done drafts lying around that could be published with minimal effort. But none of the posts seemed very good. Publishable, yes, but not really meaningful before a major rewrite.

A good goal is measurable, I once read somewhere (and you can find it claimed in many articles across the 'net), and I think that’s a good definition. “Publish 24 blog posts” is a good goal because it lets me constantly gauge if I am writing enough to keep up with my desired rate of two blog posts per month. But this statement of the goal does not capture the reason behind it.

I first made my resolutions because I felt like I had many thoughts on software development that escaped me before I captured them. I wasn’t in a habit of writing, least of all writing about software. But I wanted to get that habit.

My first few posts on the blog, and even a few along the way as I was starting this new habit of writing, were more or less insignificant, but I published them to get going. To keep up steam. To keep writing.

My plan, incarnated as the New Years Resolutions, was to build a habit of writing, and I reckoned that that would take around a year.

As December came I realized that I had nothing that I would feel good about publishing and I would rather focus on celebrating Christmas than stress about writing something. I also realized that I no longer needed the blog posts to be published at a certain rate: at least once a week I write a little something about software development. Most of it isn’t published and much of it is ongoing work on some projects I have brewing that will be published when I have hit on the right formulation.

I realized that I had made it, I had established my habit. I hadn’t reached the stated goals, but the underlying reason for those goals no longer existed.

Plans are what you expect to do going forward, based on the knowledge you have right now. As time passes you gain more knowledge and you may need to revise you plan. The plan is not useless, as it gives you a starting point and tells you what the next step is, and every new revision of the plan will do the same. Long-term plans rarely pan out exactly as originally described. Plans are like estimates in that way: they are not promises, but represent the best idea we have at the moment.

I changed my plan and spent Christmas celebrating Christmas.

When I write more, filling this form will let you know.


Now read this

System Personalities

In Software Is Never Finished and Code Can Always Be Improved I mentioned that you get to know systems better as they grow: You get to know a system as you are building it, and, in the process of doing so, realize what fits and what... Continue →