Lately, I spent more time struggling with furniture and drawers than writing code. This is what happens when you move house and have a baby while AI agents are taking the world by storm.

While fighting with a rocking chair, I recalled the Ikea effect: a psychological bias that makes us prefer stuff that we built ourselves even if the quality is not great. I guess that really affects coders!

However, I figured that Ikea effect is not the only connections between assembling furniture and programming. Indeed I found many analogies. And the fact that I spent time thinking about these probably explains why it took me longer that expected to assemble drawers.

Better to be organized

If you have a large number of pieces to assemble, having them already organized in a neat way allows for easier management and reduces chanche for error.

Likewise having your code organized instead of a messy thousand lines script makes everything more manageable.

Read the instructions first

When building a wardrobe, reading and following carefully the instructions can be the difference to eventually having it done and having to drive back to the store asking for help.

As the famous programming adage goes “spending 8 hours writing code can save you 10 minutes of reading the documentation”.

Fine-tune when everything is done

It took me a little too long to get this piece of wisdom so it’s better to write it down. Tightening the bolts on one side before having set the other side screws everything up.

In programming, but even more in ML, this translates into focusing on the fine tuning when you have something in a working condition. It is pretty useless to have the model with the perfect hyperparameters when you haven’t started yet to implement the application.

Time estimation is hard

Little drama time

At home

Me: How much would it take to assemble that couch?

Myself: It seems big, I would say 4 hours!

It took less than 2 hours.

Me: What about that drawer for the diaper station?

Myself: It looks a little bit more complicated because of all that small pieces, but in 8 hours it should be done

After 3 full evenings and a Saturday I gave up and asked my wife to help me. Even with her precious help it took the full Sunday to have it done.

At work

PM: How much time do you need for this feature?

Me: We would need a week to have it ready!

It took actually one day of focused work.

PM: It looks great! Could you only add this small thing?

Me: Oh yes, you’ll have it by the end of the day (thinking Claude Code would handle it in no time)!

At the end of the week, I am still trying to find a solution.

Working in two is better

The previous situation contained also this one, but it’s so important I want to highlight it.

Ikea goes as far as placing a sketch of two people working together on the instructions manul.

In software engineering the fact that to make good stuff sometimes you need to work with a mate is formalized in the definition “pair programming”.

Remove labels/print statement as soon as possible

On some of the components usually there is some kind of label maybe with a barcode. If you don’t take it out immediately when you are done assembling, it would be impossible to take it off without leaving patches of paper and glue on the furniture later on.

I believe this is the equivalent of a print statement in a script (I know, I know it’s better to use real logging!). If you don’t clean it up immediately you will never do it and as a result your program (and its output) will be messier.

Right tools make everything easier

You could mount a full drawer with the kit provided, but it will take less time and curse words if you have your set of professional tools.

As a coder you could write everything in notepad, but for sure it makes your life easier to work in an IDE (and with Claude Code).

Most of the time, when you think something is wrong, it’s your fault

More times than I would like to admit I found myself questioning the ability of who wrote the manual or the engineer that thought those two pieces could fit together only to find out some hours later that I messed up.

And of course this happens not so rarely when you find a bug and you have looked at all your lines of code. “For sure there must be an error in that famous dependency, let me fill a bug report.”. Than you figure out you were passing the wrong filepath.