Oh and paying attention to what you're doing and how long it took, and making sure not to waste unnecessary time on nice-to-haves or unnecessary research rather than critical functionality. This is particularly important if you're working alone; I find reviewing my source control checkins and my PivotalTracker progress very helpful in this respect.
Then again I ended a great relationship for work so perhaps I'm not the best exemplar of priorities.
Today I've managed to get Hadoop set up in pseudo-distributed mode in 1.5 hours on a fresh VM I just installed, while reading a tutorial in the background waiting for stuff to download and install. Tomorrow I'll think more about how I want to convert my crawler prototype from C# over to Ruby on the cluster and read a bit more about how this all works while I wait for code to compile or packages to run at the day job.
Even the 15min I spend eating while at the client are used to think, read and plan my next step or how I will implement something. Same for the drive to/from work. Yup I talk to myself. There's a lot of time in the day when you're supposedly busy that you can get constructive work done.
In the evening I'll start working on getting my first test job to run. At the end of every day it looks like I've made little progress, but at the end of the week I'm certain to be happy with my progress (something I learned from David Burns' "Feeling Good" is to actually test your hypotheses; if you feel you didn't accomplish much, actually test it by listing what you did and you'll be probably be pleasantly surprised).
Good point on capturing and reviewing progress. I'm always trying to get better at that.
Reminds me of a saying from my former CEO, "it's not about the time left in the game, but the number of swings at the bat you get."
I think it would be really interesting for the productivity obsessed to maybe even see a mockup of the task lists you would generate to get a sense of how detailed of a list was good.