Beat Procrastination with Science

Another day and another poor soul on Hacker News grieving about losing the day to procrastination. I’ve been there, done that. Too many times to count. And I’ve heard the story retold in many variations. But the one thing that struck me about this particular story was that the author says, “I’ve still no clue why humans procastrinate (sic).”

Now that strikes me as strange because it’s not like procrastination is some deep mystery of the universe. There are people who actually study procrastination and why humans do it (and by extension, how to fight it). They’re called scientists, more accurately, neuroscientists and psychologists. What’s even better is that someone else has gone and done the work of curating much of the available research in the area and tried to offer a coherent, scientific strategy for beating procrastination. That article (and the references) are a veritable treasure trove of information, but here’s the quick start version to get you up and fighting procrastination right now.

Essentially beating procrastination comes down to three steps:

1. Increase your expectancy of success

Do this by starting properly on small tasks that you can finish easily. This helps to build success spirals where one victory gives you the mental boost to make it to the next. Join groups (like Toastmasters) and create situations that will improve your chance of success. Visualize your goals but be honest about your current situation so that you can plan a realistic strategy to what you want.

2. Increase value

Engage in tasks that are meaningful to you and provide you with ample opportunities for entering a state of flow. Reduce errands and other short, distracting tasks so that you can focus on the things that really matter to you.

3. Control impulsiveness

Set clear and frequent goals. Measure repeatedly and correct course accordingly. Acknowledge that humans are creatures of habits and set ones that are biased towards putting you in a favorable position to get work done.

In conclusion

The breadth and depth of human knowledge can be very surprising, especially when it comes to knowledge about yourselves. If you ever catching yourself saying “I don’t know why I do this” consider the possibility that someone else does know (and has published about it). Science and rationalities can be powerful allies when we are our own worst enemies.

Sunday Selection 2011-12-11

Around the Internet

More shell, less egg It’s alway a joy to see two masters at the top of their craft engaged in a respectful, but determined duel. This is a short commentary on Donald Knuth and Doug McIlroy’s approaches to literate programming. Worth reading even if you’re not a big fan of literate programming.

Selective use of technology I firmly believe that science and technology is a good thing and that our world is better because of them. However I also understand that technology cannot do everything for us. In particular there are a lot of decisions it cannot make for us (yet). I also tend to get a lot of my best work when I am least partially disconnected and can hold at bay the full force of the Internet. All things in moderation.

Why sugar makes us sleepy (and protein wakes us up) As much as many of us would like to live as if we disembodied brains surviving on anything that barely resembled food, that is definitely not the case. Since we are stuck with our flesh-and-blood physical bodies for the foreseeable future, it is a good idea to figure out how it all works and make the most of it.

From the Bookshelf

Do the Work While I’m not entrely a fan of Steven Pressfield’s use of vaguely “spiritual” ideas and terms, this book is still worth reading for everyone. It’s especially useful if you have that big project you’ve been thinking about but never got around to actually starting. At $1.99 for the Kindle edition, it’s a steal.


What we actually know about software development Despite the importance of software development, most developers are acutely unaware of the scientific studies in the area and rely mostly on anecdote. Luckily there is an increasing amount of research in software development (not to be confused with computer science) and it’s worth knowing what we actually know about the field and what is myth.

Getting to Work

There is a danger to doing what you love as part of your day job. For a few weeks I’ve been working on a programming project. The project should have been very interesting and motivating. It involved combining programming languages (which I love and have been learning about for years) and networks (which I don’t know that well, but have a growing interest in). This should have been an ideal project – a project with just the right combination of personal skill and challenge. It was a project with definite goals, with people who supported me and wanted me to succeed and were willing to give me regular feedback. And yet it was so hard to actually get myself to do the work.

The Motivation Problem

I think the problem is that for most of my life programming was something I did on the side. In school, programming and computers were never the main course of study. In fact, more than once my parents had to tear me away from the computer. In college I decided to be an Electrical Engineer because I wanted to know how the machine worked from the lowest level up. Though that was an interesting and very fulfilling learning experience I realized at the end of four years that I would rather use computers to do something interesting rather than improve the machine itself. Though I did do a good bit of programming in college, most of my classes did not involve programming as the focus.

But now I’m in graduate school and programming is supposed to be part of the job description. Yes, I know that large areas of computer science are essentially mathematics and you can get away with writing very little code, but that’s not where my interests lie. For me, programming is no longer just something I do for the fun of it. It’s something I do because my grades depend on it and because I’m getting paid for it. It has become work and that has been fairly disastrous to my ability to get things done.

As knowledge about our psychology improves one of the interesting facts that has come up is that intrinsic motivation is a much stronger force than any form of external motivation. In a specific sense that means I need to have an internal reason for doing my work. In a more general sense I need to have an autotelic personality: to “have a purpose in and not apart from itself”. The good news is that I’m in a line of work that favors autotelics. The bad news is that it seems to be all too easy to lose the sense of self-motivation, to feel like that the only reason I’m working is because I’m expected to and I’ll get something definite out of it.

However one more piece of good news is that starting is often the hardest part, especially for something you think you should want to do, but can’t muster the motivation for it. I’ve noticed that once I’ve started and am making progress it’s easy to keep going. The trick is to both start and end in the right way.

Start and Stop

Whenever I start out reading and thinking too much about my problem I sabotage myself. I tell myself the problem is too hard, there’s too much other stuff I need to know first, surely someone else has already solved the problem and I can just use their code. Down that path lies madness (and not getting anything done). Though I’m all for thinking before pumping out code, for starters I like to just jump in and get going.

Diving in and hacking away helps produce the feeling that I’m making progress. Whatever I do at this phase is pretty basic: code cleanup, documentation, minor refactoring, maybe fixing a small bug. The point isn’t to get productive immediately, it’s to load the working context of the program into my brain, to get minor victories that help get past the resistance to start. Once I’m past the initial hump I can pause and think deeply about the core of the problem. Since I’ve already loaded up the problem in my head that also becomes easier.

I’ve learned the hard way that stopping probably is just as important. The key is momentum. During each coding session I build up a certain amount of momentum as I build up a mental model of the problem and the solution. Unfortunately I have to re-acquire that momentum every time I start again. I want to pick the proper stopping points so that the re-acquisition is quick and smooth.

I make sure that I always leave code in a relatively clean state: everything has been committed, there is some amount of documentation and most importantly I’ve identified what I need to do next. That way the next time I sit down with the code I can look up the README or the TODO file and pick off the next thing on the list. If the last commit was broken the next thing is usually something to fix. If the last commit was good I can add a new feature. I use a version control system that makes it easy to roll back changes and commits so I don’t hesitate to put in a “checkpoint” commit, even if it’s broken. The less time and effort I have to spend in deciding what to do next the better a chance I have at actually getting something worthwhile done.

This isn’t about computers

…or computer science or programming. This is about getting work done, work that I love. But sometimes love isn’t enough to get me out of the browser and into the text editor. Habit is often stronger (and less demanding) than will power. The good thing about habits is that they can be both formed and broken. I’m starting to learn that the key isn’t to beat yourself up for being a slacker, but rather engineering your life so that getting stuff done is on the path of least resistance.

And now it’s time to get back to my project.

Sunday Selection 2012-12-04

Around the Internet

How I went from writing 2000 words a day to 10,000 words a day Writing is no easy business and writing a lot on a regular basis is even harder still. It’s good to know that there you don’t need some special gift to become super-productive, you just need to carve out the time and work to the patterns that let you get the most out of the day.

Eleven equations Computer Science geeks should know There’s not much consensus when it comes to how much mathematics computer scientists and programmers need to know. Personally I would say that if you are a computer scientist you need a fairly strong mathematics background (something I’m still working on, I’ll admit). Even if you’re just a programmer I think having some mathematical familiarity will make you a better thinker and give you a better bag of tricks to call upon.

Clay Johnson’s Information Diet Though I love social networks, both the technology powering them and the interesting interactions they produce, too much of anything is a bad thing. I’ve been considering going on an information diet (or perhaps more correctly an information consumption diet) so that I could more of that time into creating instead of consuming.


How Github uses Github to build Github I firmly believe that good tools and workflows can make your job easier and your production better. I also think Zach Holman is really cool. While this focuses on Github it’s easily applicable to any group of developers (or creators in general) working together to produce awesome stuff.