Lost

I wasted the whole day. I thought the problem was somewhere else in the code, so I spent the entire day there tiring to figure out why it wasn’t working. But the problem was in some other completely different part of the code.

You’d think after thirty years of heavy coding that wouldn’t happen to someone with as much experience as I have. But it does.

It probably happens way less than when I was younger, but it still happens.

And that’s why the way we often try to estimate the amount of work is hopeless (but fixable).

My problem yesterday was that I was working on a large disconnected group of changes, all at the same time. Bouncing back and forth between them. The latest thing I was doing was not working, but the real problem was something I did a few days before to some other part of the code.

I was bouncing, not because of time -- it isn’t really more efficient -- but really because it was boring, and there were some deep technical problems that I haven’t yet figured out how to properly handle. So, I’d work on it a bit, jump to something easier, get that done, and then return. But this week, I have a couple of those tricky problems all at the same time, so it got a little messy.

It didn’t help that I was having an ‘off day’. Kinda down in my mood; kinda slow in my thinking. If you’ve been coding hard for a long time, sometimes your brain just needs a break. You hit this level of mental tiredness, often described as burnout. So, you need to take a bit of a breather; pace yourself.

That is, not every day is a “heavy coding” day. Somedays you just want to do boring, stupid, or trivial things. It’s because of that that I often keep two different to-do lists. One for the hard stuff and one for the boring stuff.

So, what does this have to do with estimations?

Well, if the work you are going to do spans a longer period of time, and you are still at the stage in your career where you really do need to focus on only one thing at a time, then there are going to be lost days in the middle of your effort.

So, you can’t just say it will take X days. Some of those days -- and you don’t know which ones -- will get messed up by life, moods, exhaustion, and other things. It’s not going to take exactly X days. In fact, you don’t have any idea how many days it will take.

But all is not lost. You can often know that if it went really well, it might take Y days. And if it goes really badly it could take as long as Z days. So, honestly, the work will take between Y and Z days, you’ll know afterward.

That is, estimates for intellectual work should not be a fixed period of time, instead, they should always be best and worse cases. A range. Two values.

If you get into the habit of thinking of them as ranges, then collecting them together and converting them into scheduling becomes a whole lot easier.