I've got more work to do this weekend than I want to do. Possibly more work than I have time to do, at least if I get too distracted by nice weather and errands. So I'm going to take a few minutes to blog about time management!
I have two goals here:
I had a list of tasks today:
I was actually expecting things to take 3x longer than predicted. That usually seems like a good approximation, although it's not great that the math works out that way.
Task 1 actually took 50 minutes, or about 3 times as long (hooray, right on schedule). Why? Part of it was an OpenCV method returning weird things (either an empty transformation matrix or a wonky one) for reasons I still don't fully understand. A second part was a bug I actually introduced where I was shortening some array I'd already shortened. I didn't discover this bug until it was already part of my web/twisted/c++ pipeline. And the third part was that I was testing my code inefficiently by making it load some files it didn't need and take 5 seconds instead of <1s. In summary: Something perplexing, something totally my fault, something inefficient.
Task 2 also actually took 50 minutes, or 20 minutes more than expected. I spent about 6 minutes planning out what I'd do. It was a more straightforward task than the previous one, and time went towards things like collecting test cases and looking up various documentation. I think I was just overly optimistic with my time estimate and didn't count the actual number of mini-tasks I'd need to do. I expected it to go smoothly, and it did.
Task 3 took four times as long as I anticipated, coming in at a whopping 80 minutes. The main reason was that I looked at the code I was planning to plug straight into some bigger pipeline, and I discovered it was the mutant, bloated beast that had evolved out of something else. So about 40 minutes went to just restructuring the code and cleaning out the stuff I didn't need. Then I spent about 10 minutes making sure it ran on my remote machine and 25 minutes actually plugging it into the pipeline. There we go, my estimate for "plug this into that" was about 25 minutes! I had just lost track of some details until I took a closer look.
I have two goals here:
Goal 1: Not get needlessly overwhelmed by large projects
I have a tendency to think about scheduling like this: "I need to do LARGE PROJECT X, which consists of several pretty large pieces A, B, and C... But I don't really know how long each will take so I'll just try to do A in the first half of the day and B later that day... and C the next day... But in actuality, part A has all these secret little traps or yaks to shave so parts B and C get put off and/or condensed." Perhaps there is a better way to plan out projects such that I can have more confidence in the schedule I've set forth.Goal 2: Be better at predicting how long things will take
Timing and productivity are the things that make me most anxious in my life right now. I think I'm reasonably okay at predicting how long things will take, but I think I could be a whole lot better about it and thus feel a lot more in control of my schedule and my productivity.Mindful scheduling experiment of the evening
I had a list of tasks today:
- fix face alignment (ETA: 15 minutes)
- change collection flow output (ETA: 30 minutes)
- hook up 3D face code to pipeline (ETA: 20 minutes)
I was actually expecting things to take 3x longer than predicted. That usually seems like a good approximation, although it's not great that the math works out that way.
Task 1 actually took 50 minutes, or about 3 times as long (hooray, right on schedule). Why? Part of it was an OpenCV method returning weird things (either an empty transformation matrix or a wonky one) for reasons I still don't fully understand. A second part was a bug I actually introduced where I was shortening some array I'd already shortened. I didn't discover this bug until it was already part of my web/twisted/c++ pipeline. And the third part was that I was testing my code inefficiently by making it load some files it didn't need and take 5 seconds instead of <1s. In summary: Something perplexing, something totally my fault, something inefficient.
Task 2 also actually took 50 minutes, or 20 minutes more than expected. I spent about 6 minutes planning out what I'd do. It was a more straightforward task than the previous one, and time went towards things like collecting test cases and looking up various documentation. I think I was just overly optimistic with my time estimate and didn't count the actual number of mini-tasks I'd need to do. I expected it to go smoothly, and it did.
Task 3 took four times as long as I anticipated, coming in at a whopping 80 minutes. The main reason was that I looked at the code I was planning to plug straight into some bigger pipeline, and I discovered it was the mutant, bloated beast that had evolved out of something else. So about 40 minutes went to just restructuring the code and cleaning out the stuff I didn't need. Then I spent about 10 minutes making sure it ran on my remote machine and 25 minutes actually plugging it into the pipeline. There we go, my estimate for "plug this into that" was about 25 minutes! I had just lost track of some details until I took a closer look.
Reflection
That was a lot of different tasks and many different reasons for underestimating the time they'd take. Some of the bigger patterns might be:- Perplexing things will take a long, long time as I let my brain try to wrap around them. And that should be okay, as long as I don't get stuck in an infinite loop.
- Reminder to stop writing bugs.
- I could look for ways to be more efficient with my testing.
- It seems like don't want to give myself too long of a time estimate, because something that should take 15 minutes is way easier to start on than something that will take 1 hour.
Comments
Post a Comment