Lessons from a life of startups, coding, countryside, and kids
This is a pretty familiar concept to (good) software developers but perhaps not to everyone. A bad software developer will look at a piece of code, think it is inefficient in someway, and procede to “fix” it. But without actually measuring the performance you have no idea whether the performance really was unacceptable and by how much you have improved it (if at all). Good software developers go through a measure-change-measure cycle to ensure problematic area are identified and actually fixed.
I am not a metrics-driven guy by nature. I don’t particularly like dealing with numbers and I don’t naturally track every minute detail of my life but even I have started tracking a lot more areas of my life recently. Last month we started using YNAB to track our finances and budget. I’ve also bought a FitBit Zip which allows me to track my steps each day. As a freelance developer I’m currently billing by the hour and I use Freckle to track my billable time but I also wanted better insights into my non-billable time so I’m using RescueTime. Like many people, I’ve tracked my weight for a while (FitBit now but also WeightBot) — good news: it’s not going up, bad news is it’s not going down either. If you’re a programmer, The Healthy Programmer book takes a very familiar approach to “debugging” your health.
Even just this week I started timing my swims: On Tuesday I did 1mile in 49mins (better than my previous guesses of 50-55mins) but today I did it in 46:30. It only changed because I could check my watch and force myself to swim faster and rest less (I was aiming for 45mins, eventually closer to 30mins). Without timing my swim I wouldn’t have had the motivation to beat my previous time; or even if I’d beaten it, I’d have felt no achievement because I wouldn’t have known that I’d done better than Tuesday. Lesson learnt: measure it if you want to change it.
I’m going to write more about the individual areas and tools in subsequent blog posts