24 March 2015

There is a common theme among motivational and inspirational media encouraging “Big Hairy Audacious Goals.”  It is not my intent to argue that this is bad – in fact, it’s great.  I think most of us, myself included, suffer from thinking too small.  Big goals are your friend in determining the direction of your life.  You may feel misled, at this point, by my title.  I’m not arguing at all that you should not pursue great and awesome things.  I intend to present how I think you should approach those things.

TofG 191

Goals that are large and exciting are great.  When Bill Gates and Paul Allen, in the 1980s decided they had a goal of creating the software that enabled getting a personal computer in every home, they were dealing in the realm of what could not be viewed as anything other than impossible.  It is only slightly exaggerating to say that what they were able to accomplish was miraculous.  It is one of the great achievements of human history.  It could be argued that it was inevitable and would have happened without Microsoft.  It has been argued that the world would have been better off without “the Evil Empire.”  Despite these potential objections, the fact remains that a ludicrous goal was attained and we should all marvel.  Again – giant goals are great.  I don’t think, though, that they just started from that vision and measured their progress against that each day and said “Yep, we’re 0.00000000000001% of the way there.”  That is a demoralizing approach.  That is the path to unfinished projects (and the Dark Side).  In order to make progress against large goals, there need to be milestones along the way.  We need smaller goals that support the larger goals.  This is the point – giant goals are great for direction and identifying the right small goals – microgoals are THE way forward for daily progress and effort and sanity.

An example I have heard to illustrate the value of microgoals is that of writing a book.  Having a goal of “write today” or make progress on book” is lacking in meaning and it’s hard to say whether it was done or not.  Something like “write 500 words” or “complete chapter 3” is a concrete and reachable goal and you know when you are done.  Writing a book is too big a task to have meaningful progress in a day.  It is no different with writing software.

When implementing a large feature that takes many weeks to complete, imagine what your daily progress reports might reveal (if you are doing daily progress reports – if not, I suggest using something like iDoneThis or Teamreporter to track what you are accomplishing, ideally with your team, but individually works too).  If you are working on the big feature and each day you have a progress report saying “Made progress on Big Feature,” your progress reports have limited value (perhaps no value).  If instead, you have broken your large task down into smaller tasks, you can have a meaningful progress report showing items you have completed.  It feels a lot better to have a list of things completed rather than a nebulous list of meaningless “progress.”  I’m not saying progress is bad, just that it doesn’t communicate much.  Feeling better might seem like a small thing, but the encouragement that comes from knocking things out rather than looking at the same task day after day has a significant impact to motivation and productivity.

Think about this – it’s nothing new to say that you should not be working on code for a long time without committing to source control.  Jeff Atwood addressed the topic in 2008, which was late to the party.  If you are committing something to source control, you should be doing it every day.  When something is ready to commit, you are making a statement that you have completed something and that it has been tested and implemented to your satisfaction in solving some piece of whatever it is you are trying to do.  Source control systems (decent ones anyway) require a message with your commit.  This is because you should be describing why you made changes every time you have completed changes.  Right here you have a completed task.  Every commit to source control is a cause for celebration – it is the completion of something you needed to do, a check in the proverbial box.  In addition to being a great demarcation for what you have accomplished, commits to source control are awesome for tracking because they enable effortless tracking via automation.  The ideal size for goals for a day is that you should be able to accomplish many of them in a day.  I often have daily reports with IDoneThis showing 10-20 items (some personal in addition to technical and business activities).

It is a worn cliché that the optimal approach to eating an elephant is to do so one bite at a time.  There is a good reason for this – large goals are best approached by decomposition and attacking the component pieces one at a time.  This is not any different for software than it is for the ingestion of large creatures.  Small goals with frequent accomplishment (in support of larger goals) is the Optimized Programmer way of operating.  Every completion of every small task is an achievement worthy of celebration.

blog comments powered by Disqus