loading...
Cover image for How to be a Better Husband & Why it Makes Daily Standups Foolish

How to be a Better Husband & Why it Makes Daily Standups Foolish

bootcode profile image Robin Palotai ・4 min read

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.

Alt Text

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.

Alt Text

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 window.blur or 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.

I'm not going into further details about those (adding a privacy policy, now that we have a great one, or cleaning some spooky skeletons around session handling). But you can see how a small task snowballs into a set of changes that just makes sense to do while you are there in the context.

Alt Text

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.

What are the takeaways?

(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.

(Attribution: Hungarian folklore pattern from an artist on Meska, the Hungarian Etsy; Header image from The gender wars of household chores)

Posted on by:

bootcode profile

Robin Palotai

@bootcode

Developer, Ex-TL at Google. I teach how to be an effective SWE.

Discussion

markdown guide