Build better by optimizing for learning


Compared to construction, where requirements are more often well-defined upfront, software is more ... fluid.

You don't know what the customers want.
You don't know what product to build for them.
You don't know what software architecture is best.

But as time goes on and we keep building, we'll learn these things.

That's why before a project starts, it's anyone's guess how long it will take.

But once you've been working on it for a while, things tend to get more well-defined.

You choose a technology.
You choose a problem to solve.
You get feedback from the users.

So, what we should optimize is learning, and the way to do that is through continuous delivery.

I've written about the importance of fast feedback loops before.

I got the best outcomes from asking my team: "What do we need to build to learn about [what the customers want, which technology is right, how to scale,...]?" and then let them come up with proposals.

Yours,

Taj

The TP Daily Newsletter

Hi, I’m Taj Pelc. I write about technical leadership, business mindset and enterpreneurship. Daily advice on building fantastic tech teams that deliver great products. I'll see you inside.

Read more from The TP Daily Newsletter

I was making a sandwich analogy. The butter makes things run smoothly. The other components are good tech/business alignment, an agile dev process, testing, and automated deployments. To succeed, you can't get just some parts right; you need to get all the parts right. However, one of the most underrated aspects is the developer experience. I'm constantly surprised by how much pain people suffer through just because it's always been this way. Here's what you can do today ... Make it run in a...

Yesterday, I attended the Czech Executive meetup in Brno, which was held in a WWII-era bunker. As the communists had a top-secret base there, I thought creating a little old-school digital business card to share at the networking event might be fun. I generated the code with Claude, uploaded it to GitHub pages, and programmed an NFC tag with the URL so that you can just tap it with your phone. A hacking game in the middle "protects" the links to my website. Eat the red packet, and you're...

Find out how much <the thing you want to do> is worth. This can help in two ways. If it’s internal it helps you to prioritize and focus on doing the most impactful things. If it’s for a client it helps you set a price as a fraction of that value. That’s not always easy, but it’s worth it. Problem is people don’t even try. Here’s what you can do. Break it down into spefic measurable outcomes like increased sales, time saved or reduced costs. Then assign a reasonable estimate to each. Like 10%...