Applying household ideas to software development

Posted by Sjoerd Job on July 11, 2016, 6:29 p.m.

A not-so-favourite part of my life consists of doing household chores. (I must still learn to enjoy it).

However, even though I might not like it, I still think that there are lessons that can be applied to software development.

None of these are new, but I still think they are worth while to document them again, in my own words.

Hate it? Do it often!

When I don't clear the living room floor for several days, I find it quite difficult to start clearing it. It is such a huge mess that I have no clue where to start. Should I start with the Play Mobil, or with the Duplo? With all the left-overs from arts-and-crafts?

It took me a while to learn that by clearing the floor multiple times a day, it was more simple. The mess is less, and it is easier to know where to start.

The same goes for programming: for example, refactoring is best done often, instead of letting the mess accumulate and trying to do a "year of refactoring". (Not that I hate refactoring, I love it!)

Hate it? Automate!

In programming, doing things more frequently results quite often in someone automating it. In the household that is not always the case.

However, there are still some things that can be automated. An excellent example is doing the dishes. This is another chore I do not really enjoy (because again: not doing it often, no clue where to start). But a few years ago we got a dishwasher. And it made the household much more pleasurable.

Finding an example from the world of software development is not hard: testing, deployment, need I go on?

Hate it? Share the load! Love it? Share the load!

As I told you, I'm not really a fan of doing household chores. One of the things I do love to do is DIY-like tasks, like assembling IKEA products we bought, (re-)doing the electric wiring, and other tasks commonly thought of as "man"-tasks.

My wife is much the same: she also loves assembling IKEA products. Sometimes we even get in a fight over it, because I want to do it, while pragmatically speaking, she has more opportunity for it.

And the "woman"-tasks? They still need to be done, and they are as much my responsibility as they are hers. (I'm ashamed to admit I should be helping her more than I am now. She deserves it!)

Again, the same goes for software development: there are no "junior"-only tasks, just as much as there are no "senior"-only tasks. Sure, I can imagine a task is complex enough that you'd prefer to have a senior do it, but perhaps the junior will surprise you. Maybe by showing the task was not as complex as you thought, or by showing that they are improving.

If the junior finds out it was indeed too complex, they can ask the senior for guidance, and learn on the spot. Or collaborate with another junior to get the job done.

Likewise, don't assume that just because a task is simple, you should not "waste" the senior on it. A senior might enjoy to do a simple task instead of having yet another complex task. Or, they recognize that the task might be a frequent one, and find a way to automate it so that next time the customer/product owner can do it without getting the development team involved.

If a (senior) programmer is too arrogant to do "chores", maybe it is time to put them on a personal improvement plan. If a (senior) programmer is too arrogant to let somebody else try doing a complex task: personal improvement plan.

Hate it? Try better tools!

When I was younger, I sometimes mowed the lawn at home. We had a manual lawnmower which you had to push around, and the action of the rolling wheels drove the blades doing the cutting. I did not mind myself, but I can easily understand somebody getting back-trouble, and thus hating it.

Eventually we got an electric lawnmower, where the blades were driven by an electric motor instead of a mechanical action. This was such a blast! It made it a lot easier. As a bonus, the grass was collected in a bin attached to the machine, making it a lot easier to clean it up as well.

An equivalent would be switching from using a simple text editor like Windows Notepad to a more advanced tool like Vim, Emacs, or if you fancy, an IDE (Integrated Development Environment). Or maybe using a Makefile instead of a complicated shell script.

Never stop experimenting!

Recently I was taking the clothes off the clothes line. As normal I had the basket for the clothes on the right, and the basket for the clothes peg on the left. During the task, I felt I made some awkward moves with my hands. After some thinking, I deduced it was because I was constantly crossing my arms when dropping the clothes and pegs in the appropriate basket. By moving the peg-basket to the right, I felt that the movement became much more natural. Nowadays I always place the peg basket on the right. I'm not only more comfortable now, but also slightly faster.

Likewise, you should pay attention to moments where you feel discomfort, even a slight discomfort. Think about what is causing it. Maybe you need to move the keyboard a bit, or the monitor should be higher. Maybe remap your shortcuts so that your most used actions are at the "home row". Maybe create a shortcut for running the unit tests, or learn another refactoring technique.

Sometimes you know what the problem is, but don't know a solution: ask a colleague, a friend, or a stranger on the internet.

Get to work!

Sometimes, no matter how much you dislike it, you have to get up and do the chores. You can't keep on postponing, because others (and actually, you yourself as well) desire to see results. Demand, even. The same goes for the household as programming. Just as carrots don't cook themselves, a code-base can't grow new features without the help of a programmer.

Take your time!

Sometimes a bit of procrastination is precisely what the doctor ordered. When the job is too complex, don't start without first preparing something of a plan.

Especially in creative jobs, finding the plan can feel a lot like procrastination. Instead of starting, you first let the problem simmer a bit while answering Stack Overflow posts, doing a bit of therapeutic refactoring, and browsing comics. You feel like you're not doing anything useful. But after a while you finally get the plan formed, and solve the problem in a few hours or days.

If instead you had forced yourself to "work", it would have turned out that you dug yourself a massive hole. Instead of having your picture frame nicely mounted to the wall, you accidentally drilled through a gas line. If you had procrastinated a bit, you might have remembered to check.

A final note

Alternatively, this could be read as "applying Software Development advice to the household".

Have more tips and tricks? Let me know!