A great programmer sees software as a craft, honing a perfect solution from a sea of binary logic. Good software is beautiful outside and in, and even on a large scale is simple enough that there are no obvious bugs. They produce software that is precise and clean down to the last detail, continually improving quality.
But it’s easy to fall into the trap where quality beats everything. The software cannot ship until every bug is fixed, every scenario is covered, even the heat death of the universe. And the software still hasn’t left your machine.
Until your code is in front of your users it’s an untested hypothesis about what they want and what they can use. And hypotheses, no matter how precise, have a habit of not surviving contact with reality.
Test early, test often
So start with a smaller hypothesis. Remember that for most of what we do, Newton’s laws of motion are good enough, and simple enough. Unless you’re building something that depends on very precise timings and/or very high speeds, you don’t need to handle relativity.
So ship it.
Build it. Test it. Ship it.
Prove your hypothesis meets the real world, and use it. Define your MVP. Cut it to the bone. And ship it.
Make sure you’re building the right thing: ship it.
Every project has a bug zero: no-one can use something that doesn’t exist, and isn’t live.
Fix that bug first, because every other bug depends on it. Either the bug is important enough for them to complain and tell you want they want. Or it’s never used, so remove the functionality.