The ByteBaker

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.

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.

…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.