Here’s how I think about software development:

All code is an assumption until it meets its real-life context: its user, real-world data, the situation it’ll be used in.

The goal in a startup should be to prove all your core assumptions as quickly as possible. Whereas in an agency setting, say, or perhaps even in a larger company, there’s a defined deliverable, code in a startup is never done: you’re constantly iterating on it to get closer and closer to the right fit for its context.

You could spend months or years meticulously developing the perfect codebase before release, but the truth is, no matter how many automated tests you run, no matter how much QA you’ve built in, you won’t know if it really works until a real user uses it. That’s true of websites, applications, back-end server demons, you name it. If you’ve spent all that time writing code and it’s not the right thing - well, then you’ve probably wasted a ton of time and money.

Before the internet era, that was the only way software could be written. A company would work hard on a release, which might even then be shrink-wrapped and sent to stores. These days, we’re constantly connected, and software (whether it’s on the web or not) can be continually updated. Some of the best platforms I’ve worked on have released multiple times a day. The internet gives developers superpowers.

The right thing to do, then, is to write the simplest, smallest thing you can, get it out there, learn from how people are using it, and iterate quickly. This iterative feedback loop is at the heart of agile development, but it’s also just good common sense: you always want to shorten feedback loops as far as you can. The question is always: what’s the shortest distance to proving or disproving your assumption?

Otherwise you’ll end up chasing perfection in silence. In the worst case, your product might not even get released: the context will likely change during a long development process, which means you’ll need to continually adjust the code until you get there. Then the world changes again, and you have to adjust again, and so on and so on and so on. The world will always change - that’s a given - so it’s better to release early and often.

Every software developer in a startup needs to have an inherent comfort with imperfection and a mindset of “failing fast”.

That’s true of every aspect of startups, of course. The core proposition, the underlying business models, the culture, the team - all of those things need to be tested early and iterated upon until you find the right thing. The best startups deeply ingrain these learning loops so that everyone is iterating quickly. The worst just spin their wheels forever.

To do that effectively, you have to let go of your ego. Yes, you’re smart: your insights and past experience will inform how you react to new information. But you can’t operate in a vacuum. Even the smartest people in the world need to approach problems with a growth mindset and let the people they’re trying to build for be the ultimate arbiter on whether they’re building the right thing. Nobody can sit in an enclosed room and come up with the right thing all or most of the time. Whether you’re in the C-suite, an individual contributor, or an intern, you’ve got to figure out how to test your ideas in the real world as quickly as possible.

And then learn, grow, and repeat.