Building Software Is Learning - by Thorsten Ball

SubscribeSign in

Building Software Is Learning<br>An internal note to the Amp team on feedback and shipping faster

Thorsten Ball<br>Jun 02, 2026

Share

A few weeks ago I shared the following as an internal message with the Amp team. I showed it to a friend while talking about feedback loops and he told me to post this publicly. So here we go. Unedited, straight up copy & pasted from our Slack.

You know what’s rare?<br>person a: “we need this feature”<br>person b: “yes, let me build it”<br>...<br>person b: “done.”<br>person a: “fantastic, exactly what I wanted.”That’s basically NEVER what happens. At least not when you’re building something new. It might happen when you fix a bug or when you port something that already exists in another app to a new language or framework, ... Or when you’re building after a spec.

But when there’s no spec, and when you’re building something new?

Here’s how that works:<br>person a: “we need this feature”<br>person b: “yes, let me build it”<br>[...]<br>person b: “done.”<br>person a: “hmm, actually, that’s not what I meant. what I meant is: [...]”Or this:<br>person a: “we need this feature”<br>person b: “yes, let me build it”<br>[...]<br>person b: “you know what... There’s 3 ways to do this, actually, and I’m not sure what the best way to do this is?”<br>person a: “ah, I see, I think given that we want to ship this tomorrow, let’s go with way 1”Or:<br>person a: “we need this feature”<br>person b: “yes, let me build it”<br>[...]<br>person b: “done.”<br>person a: “Don’t like it”Now why does that happen, again and again and again?

Because building new software is learning! If you’re building something new and you don’t yet fully know how exactly it’s supposed to work, you will learn what exactly it is that you’re building as you’re doing it. Let me repeat: building new software is learning.

So far, so good, right? But here’s the very important bit, the one bit I want you to take with you into this week: there is no way in hell, absolutely zero chance, that you can build something new and avoid bumping into “that’s not what I meant”, or “now that I’m working on it I’m not actually sure”, or “hmm, now that I use it, I don’t like it”. Because the only way you could avoid that would be to fully specify what you want up front and, well, guess what programming is? It’s fully specifying what you want. You can’t avoid it, because you can’t define it yet, because building software is learning!

Now that was the bad news. Here’s the good ones. You can reduce the time the ... from the examples above takes — the time between the confident “yes, let me build this” and the humbled “oh, I see”.

And that, in turns out, is the most important thing you can do when you’re building something new: reducing the time it takes you to go from “let me try something” to getting your ass whooped by reality.

If someone says “we need this feature”, don’t go “yes, let me build it” and hack on something for 4 weeks only for the other person to ultimately go “that’s not what I meant.” No. Instead, embrace that we need to learn, that we need to try and play around with this idea as fast as possible, in a way that lets us learn. To embrace that idea means that you try to figure out “what is it they mean” as fast as possible, with the minimal effort required, so you can LEARN what it is you’re building.

Instead of going away for 4 weeks and hacking on something, you instead can do stuff like this:<br>... build a prototype, in 1hr, and show it to them, and they go “no, that’s not what I meant, you should change this part here”

... write down a spec of how you’d approach it, in 30min, and show it to them, and they go “no that’s not what I meant”

... cut up the thing in multiple things and ship one every day, so that every day what you built hits reality and you get to learn, because on day 2 someone says “know what, we should change...”

... reduce the scope, figure out what the things are that we’re already sure about and skip those, and instead focus on the bits that we don’t know yet — that’s where we need to learn. don’t add 5 ways to login, if all we need to learn right now is 1.

... fake a demo video, show that around, get input on that - Quinn’s done it many times

... write the news post that explains the idea — why waste effort building something for a week if the idea can be captured in 3 paragraphs?

... write the example code that would go into the README, show that around, does that look like a good API? People don’t need an SDK built if they dislike the API in the readme.

...

There’s more options that I didn’t list here. And you don’t have to pick only one. In fact, for something big, you should probably do a few of these things. Or you vary them, or combine them, or ...

What exactly you do doesn’t matter as much as constantly asking: how can I get feedback on what I’m trying to build as soon as possible? And “feedback” here is used in the widest sense possible. Feedback comes in all shapes and sizes:...