Using the Problem to Solve the Problem

Programmers have a technique called TDD - Test Driven Development. The idea is to start from the end: before writing the code, you write a test that defines what the code should do. That test fails - obviously, the code doesn’t exist yet. Then you write the minimum code to make the test pass. Done, next test.

I use this every day at work. But I only recently realized I use the same thing for almost everything.

I had to cut a piece of ceiling material at a tricky angle. One of those where you look and don’t even know where to start measuring.

I tried everything. Measured, drew, measured again. No matter what I did, the angle came out wrong. The shape I wanted was right there in front of me, just look at the hole in the wall. But translating that into a cut mark on the wood wasn’t working.

Then the idea came: if the hole has the shape I want, use it as a template.

I took some cardboard, fit it into the hole and kept cutting until it fit right. With the template, I just traced it onto the wood. Perfect fit.

When I decided to power my house with solar energy, I knew nothing. The most experience I had was with those old calculators that worked without batteries.

But I had a goal: take my house off the power grid.

I bought a 100W panel, a charge controller and an inverter. Made a light turn on. It worked.

And then I realized my goal was too open. “Power the house with solar energy” didn’t tell me how many watts I needed, how many batteries, what the investment size was. The experiment showed me I needed to refine the goal.

I went to measure equipment consumption, do the math, make a new plan. And run new experiments.

Today I already know my next step is to have batteries for 3 days without sun. I know how many ampere-hours I need, how much each battery costs. Execution now is just saving money and installing.

At work it’s the same thing. When I need to fix a bug, I don’t start reading code trying to understand what’s wrong. I write a test that reproduces the problem. When the test fails the right way, I know I understood the problem. Then it’s just making it pass.

Sometimes the first test ends up in the trash. It was exploratory, it served to familiarize me with the context. It’s the cardboard of code.

It’s easy to fixate on the symptom and forget the objective. A screw stripped - how do I fix it? But the problem isn’t the stripped screw, it’s securing the piece. Throw that screw away and use another one.

It gets easier when you let the problem show you the way.