How to beat procrastination with Self Imposed Deadlines

“Procrastination attracts us because of hyperbolic time discounting: the immediate (guilty) rewards are disproportionally more compelling than the greater delayed cost. Procrastination is the reward itself.

An MIT professor found that when he allowed his students to give themselves their own homework deadlines, they would artificially restrict themselves to counter procrastination. However, they did not set deadlines for optimal effectiveness. I am personally a huge procrastinator and it’s always a pull between rational logic (giving yourself the most time by choosing end dates as the deadline), and your past experience saying you will put it off so force yourself to start early.”

At the same time, while it is inefficient to start late, but one should not try to start earlier than necessary. The task will occupy your mind longer and especially if you don’t like to do the work, it will stress you longer. The task does not become more difficult if you put it off until you need to do it. It just gets longer, because you will allow interruptions (there’s still time, so…).

Bigman2003 on SlashDot quotes this from his personal experience

” I manage a small programming team, and one of my jobs is to set up deadlines. The nature of where we work means that we don’t really HAVE deadlines at all (gubment) but we need to make progress. So, I impose deadlines on my team. Usually they are fairly aggressive, but we always meet them. Two days before the last deadline, my team was all working frantically trying to get things done. One of the guys asked, “Why the hell did you make the deadline so early? Why not just push it out two more months?”

My answer was the same as always: “If I had pushed this deadline out two months, we’d be going through this same exact crunch time, just two months later.” It’s just a fact, if we have six months to do a job, we’ll finish in exactly six months. If we’re given 12 months to do the same job, we’ll finish in exactly 12 months.”

I have observed two things. If the imposed deadline is shorter than the time actually needed to do the job, then the job will appear to be finished (i.e., people will say they are done), but there will be many things missing. Later, people will say “Oh, we were all under a tight deadline, so I guess we must have forgotten to do that”.

More interestingly, if the deadline is longer than the time actually needed to do the job, I have observed that the job is done early. But (and this is an important but), all of the functionality is actually there.

To perform this experiment for yourself, I suggest that you take several small problems (small bugs are good for this). Try to find problems that will take from 1/2 a day to a day. Assign deadlines ranging from 2 hours to 3 days. Record the amount of time it actually takes to do the work. Then do code reviews of all the work.

I think you will find the experiment very instructive.

I have found that when there is always work in the queue, there is no point to setting deadlines. Instead it is better merely to estimate the work (so that you can make predictions). It is also counter productive to measure the amount of time each task takes (otherwise people will cut corners in order to meet some kind of unreasonable expectation, sometimes self imposed). Instead, just keep a rolling average of how close your estimates are to reality (i.e., we’ve gone 10 days and we’ve finished 11 days of estimated work, therefore we are going at 1.1x our estimated rate). This gives you predictability without the negative side effects of measuring too closely. IMPORTANT: Don’t complain or cheer if the work rate is different than the estimated rate. This is to be expected. The information is only to allow you to communicate progress with management.

In every case that I have implemented this (and obviously this isn’t my idea — it’s standard practice in many shops), productivity, quality and predictability have all improved. It’s worth a try

Another reader winknerd suggests the following tips for a geek on how to beat procrastination

When I want to beat procrastination I cut down the task in smaller sub-tasks with their own deadline.

For example, if it is 1 January and I have to write a paper until 31 December, then I will try to estimate how long the paper should be and of what parts it should be composed. If I find that I need to write about 10000 words and that the paper should be divided in 6 parts, then I will try to estimate how long each part ought to be. Suppose I find out that 1000 words should go in part 1, 3000 in part 2, 1000 in part 3, 2000 in part 4, 2500 in part 5, and 500 words in part 6.

Then I will attempt to guess the requirements that should be met before writing each part, for example part 2 may require some extensive research before I sit down typing, and part 4 may need to wait until the results of a computer simulation are available. The research may require some reading on my part, so I will have to know how many books I must read and how long or difficult these books are.

If I can calculate the prerequisites for writing the different parts, then I assign deadlines to the completion of each part. I continue breaking the subtasks into smaller and smaller tasks, until I can create weekly or daily schedules. Then I use my PDA, timesheet software, or a personal wiki for tracking my progress.

Another important technique for cutting down procrastination is to minimise startup time/costs. If I need to power up my laptop before typing my essay, then I just leave the laptop open at all times.

Finally, for people who have to spend their days in multiple locations within each day, it is imperative to maximise your mobility. For example, I want to learn some Python, but I have little formal time for investing in it. What I did was to load PythonCE on my HTC Universal [wikipedia.org] PDA (which, by the way, has a QWERTY keyboard and broadband Internet access), so while I commute to work and university I spend the time reading Python tutorials over the Internet and typing programs into the Python interpreter. The fact that this runs on an always-on PDA (with an extended 8h battery and nearly always-on Internet connectivity, too) means that it is very easy to start from where I left even between days (there is no frequent shutdown-bootup cycle in PDAs).

Another example I can give for increased mobility is with e-mail: I was using a POP email server which made life difficult when I couldn’t access my mail which was stored on my home’s hard disk because I was away from home. What I did was to switch to using my own IMAP server. Combined with RoundCube Webmail software, this really created an environment where I can access my email, including my drafts, from anywhere in the world and with any IMAP client I have in hand.

Other tips for mobility that I know from experience is using laptops with cellular Internet access such as Flybook [flybook.biz], and using Web-based tools on your own Web server instead of desktop applications (sometimes I had to write my own Web tools in PHP) so that you are not tied to one particular machine. Use of SSH/VNC with an always-on broadband connection at home is also useful if you need to access your home PC when you travel (assuming you do leave your PC open 24/7 as in my case).

Of course, in actual practice, procrastination still occurs and the planning isn’t always reflective of reality, and sometimes you just need to accept this fact and stop worrying too much (especially if you are a Type A [wikipedia.org] personality).”

Alex Smith was gonna post this yesterday, but …

Dear visitor, if you enjoyed reading this post, you may want to subscribe to my RSS feed. Thanks for visiting!