To the day I remember my turn in a daily standup 10 years ago, feeling quite foolish. As per the book, I should have said something like "Yesterday I fixed the indexer bug and updated the user documentation, and today I'm going to add batch support to the load pipeline."
But in reality, I said "Yesterday I was working on the indexer bug, and I will continue so today.", for the third day in a row.
So was I really working on the indexer bug all that time? Or was I just slacking? How does this relate to becoming a better husband? You will find out after a short detour.
While I don't agree on all of the points delivered in The gender wars of household chores, it is an enlightening read with a practical takeaway.
I'll summarize below, but maybe you want to read it yourself first. If inpatient, jump to the "...when I decide to take care of a simple chore.." part. The header image of this article is taken from that part as well.
(Waiting here for you to return.)
The illustration depicts that usually, when a husband is asked to fill the washing machine, he does so and that's it. In contrast, the wife would pick up all sorts of accidental chores on the way there, like refilling soap, putting away toys lying accross the floor, etc. What started out as a single chore became a bunch of loosely related tasks due to it made sense to batch them.
Now you might suspect how this relates to programming.
Ideally, we are expected to come up with a plan, estimate the time it would take, and execute precisely. But let me tell about my day yesterday (even if it was not a Monday).
While sipping the last drops of coffee in the morning, I drew a small dependency graph of recent tasks, and concluded that working on indexing (again) is the most important. As I reached for the keyboard, an email popped in carrying a UI bug report from a user. As a usability bug trumps backend improvements, I started on it.
(Technical detail): The bug was about some input element acting up after the user tabs away from the browser and back. Indeed, when tabbing, first the element loses focus, then the window, finally they get it back in reverse order. But from the user's perspective, there was no focusing happening, so the action specified in
onfocus didn't make sense.
Fine, I started adding a UI test to replicate the behavior. But as it turns out, creating a new tab using
puppeteer doesn't trigger the
focus events. Ok, this is not my fight, so added this test to the list of manual tests.
To fix the bug, I began to add some complicated logic about detecting this focusing situation. But it became nasty quickly, so I took a step back. I started fixing focus, since we used focus in the first place. But I could just change the element to react to
click instead of focus. That avoided lots of trouble and made the code simpler.
While trying to run the integration tests, I stumbled upon some caching issue in the build system. I couldn't let that lie around, so took some time to devise a fix.
Time to push a release then! But it would nag the users to reload the UI, and I wanted to do some other UI updates. So it made sense to do those and do a batched release.
So was I slacking back then? Maybe. Probably. But more likely I was stumbling into a cascade of unforeseen issues, reporting other bugs I encountered to be revisited later, running the tests and fixing the test runner, etc.
(Read the free sample of my in-progress book Programming without Anxiety for more tips.)
Unscheduled - or even unnoticed - tasks slow down completion of the original goal. But performing them while in the right mental context pays off on the long run. That said, if you are not in the right context, rather file a bug report about them for later.
When hitting an unexpected task, take a step back and ask: Is there any alternative solution? Is this the right time for this fight? Otherwise, you can be down the rabbit hole quickly.