Here is a suggestion on how to identify what to measure:

1. What is causing you pain?
2. What causes the pain to occur?

Step 1 is all about prioritization. Pain is bad. If something is causing you pain, you want to stop it. You need to stop it. So pick the thing/item/problem that is causing you the most pain. This is what you need to improve or fix.

Step 2 is looking at what is causing the pain to occur in the first place. Once you know the factors that are contributing to the pain, you can try to change them. If you are doing the right thing, the factors contribute less, and the pain should go down.

For example: Let us say I want to write more python code. My day job doesn’t involve much python, so I feel like I’m being left behind because all of the cool kids on reddit are talking about the fun they are having writing python code.

The pain: Not being able to write in the language I want to. The cause: Day job doesn’t use python.

Addressing the cause will affect the “pain”. If you get a different job (e.g. one that involves writing python code) then you have solved both problems.

But what if you can’t just switch jobs? Then you try experimenting with writing python code for your own personal use. Try writing it to solve scripting problems on your PC at work. If that makes you feel better, then you are moving in the right direction. If you try writing open source code in python in your after work hours, but it winds up stressing you out, then you are moving in the wrong direction. (Or you’ve identified that there might be a different problem than what you originally though there was!)

By tackling the sources of your pains, and applying small changes there, you can get a measure of where your efforts are going. Sometimes these measures are going to be cold hard numbers, and sometimes they are just going to be “feelings”. But either way, they are indicators of how you should change your processes and habits in order to become more successful.

What you can measure, you can manage.

I just watched a new video from Giles where he talks about how you can improve your programming productivity. Its a really good short video that hits the nail on the head. If you want to make a change, guessing about what to fix won’t cut it. You need to measure what you are doing, and then adjust accordingly.

The quote at the top was in the video, and I have to say I don’t think I had ever heard it before. But as soon as I heard it I knew it was 100% correct. Think about it: everyone who is in charge of things in you life (bosses, teachers, parents, etc.) track what you do to some extent. When you step out of line, they know about it and are able to let you know. Why? Because they are “measuring” you progress via grades, work done, chores completed, etc.

So if it works for them, why can’t it work for you? Track the things that are important to you, and see if you can make a positive change.

I’ve been hemming and hawing lately about tracking things like my programming projects or seeing if my neighborhood association really is increasing the house values. The time for action is now.

My first step: Putting widget on this blog to track my BitBucket RSS feed. If I’m going to work on a project out in the open why not let everyone know about it? This way if I’m not being productive, it will be pretty visible.

(As a side note, this is something that Giles has mentioned before that I really believe in: If you are a programmer, you should have some project out in the public eye. Open source is a good thing. Contributing to open source is a great thing. Being known as a programmer who contributes to open source software is the best thing.)

My next step: Start treating time tracking on my projects as a first class citizen. I’m starting a new sprint tomorrow: I’m going to track my time better. Also, I’m going to add some tasks to my Satellite Tracking project so I can make sure I’m on task when I’m working on it.

Thanks Giles, that video was a good kick in the ass.

One that I really liked was Joel’s idea of not posting comments on a blog, rather write your response on your own blog. Its a great way of generating content and forcing you to think about the topic (similar to the idea of “you don’t really understand something unless you can teach it to someone else”). I think its a really great idea, and it seems to have stirred up a lot of debate.

And finally, the other great idea: Do it fucking now.

I’ve found the key is to have a small easy-to-achieve goal. Something trivial. Implement a small helper function. Wash the dishes in the sink. go for a small walk (instead of sitting watching TV). Do one small blog post.

Accomplishing one thing, no matter how tiny is a small victory. And usually I wind up thinking “Well, it was easy to wash those dishes, I should wipe off the counter too, that will only take a second”. Before I know it, I usually accomplished a quite a few small things, and that usually adds up to a big thing.

So the next time you are lacking motivation, just think of one or two small things you can knock out quickly and easily. (You do have a to-do list, right?) I’ll bet that getting a few things done will help motivate you to tackle the bigger jobs.

And speaking of bigger jobs, I’m off to try and write a few methods to try and make a class or two spring to life.

Success comes in cans, failure comes in can’ts.

So, if you are interested in GTD and are running on a Mac, go get Voodoo Pad and try it out. It rocks.

That is very good advice. I started writing a game a while back (like over a year ago), but I just kinda stopped for some reason. Recently I’ve been thinking of new projects I *could* start doing, and in one case I actually started slinging some code. When I read the post that advised the guy to just finish the project with an engine (and not re-write it from scratch), that hit me like I thunderbolt.

It doesn’t matter how “good” something is if you never ship it out the door. Sometime you’ve just got to cut your losses and implement those features in the next release. To borrow a phrase from Xzibit, sometimes you’ve got to be a Mack truck: Go the distance and deliver the goods.

His point is basically that people are held back by a fear of failure, yet if you do not fail then you are not really pushing/challenging yourself enough. Failure is what happens when you find the limits of your abilities.

That’ s a pretty deep thought, and I had to stop and think about it a while. I’ve come to learn that you can always learn something from your failures, but I’ve always thought that the lesson was limited to “what not to do next time”. The idea that Wil presents is more like negative logic: “I did not fail this time, so next time I should try harder/different and find out where my limit is.”

Its pretty clear this can be applied to many things in life, but probably should be used with some common sense (i.e. don’t try to see a sunspot with your naked eye just to see if you fail or not). Its definitely something to think about. Why let a fear of something that could be good hold you back from doing what you want?

And having said that I’m going to stop worrying about my next programming project and if it is designed well enough, or if I’ve thought about everything. Instead of worrying about all of the little details (its a personal project) and not doing anything while I agonize over the small stuff, I’m going to hit the publish button and then start slinging some code.

Having a To Do list (or several small ones in my case) doesn’t do you any good if you are not moving towards an objective. That’s the whole reason for the lists, to help you get things done.

So make sure you have a clear goal in mind when you are making your To Do lists. The more focused on your goal your tasks are, the faster you will get there. Knocking out list items and making progress towards your goal can be addictive. Get started today!

Upon further reflection, I think I have found the reason why it did not work. For me GTD is about a To Do list that is generated based on very small tasks that need doing in the near future (i.e. the next things for me to do). As a result of this, I never fully implemented the calendar part of the GTD system. The calendar/tickler works by “remembering” things for you that will happen in the future. Since I was only concerned about the near future, I’ve never really done anything with the calendar.

School is built around calendars. Everything, every lesson, every test, is scheduled on a calendar. Combining this information with the topics being covered in the class can yield a To Do list that is several weeks out.

Most people probably know this as a syllabus. One day I’ll learn to look at it.