pull down to refresh
Interesting take.
When I make a paper public, one of the most stress-inducing things is when someone finds a problem with it. Even if I know I can fix it, it still causes that little lump in your chest when you find out. Isn't it like that with finding bugs?
On the other hand, as I get older and wiser, I realize that I agree with the medium-rare steak analogy. If I try too hard to make the paper airtight prior to releasing it, I've wasted a bunch of time because there are always problems I can't foresee. Better to release it once the essence is there, and let the public / referees find all the nuanced issues that you can go back and fix later.
In a way, this is even a safer way to get published, because referees always look for something to criticize no matter what. If you work too hard to squash all the bugs prior to shipping, they just end up finding harder to squash bugs.
Isn't it like that with finding bugs?
Yes, it's very unpleasant, but unpleasantness is one of the better fuels for motivation and motivation fuels things getting done.
If we want to get things done, we should inject this kind of unpleasantness into the process as frequently as we can stand.
IME quality emerges more naturally from quantity than anywhere else. At least in part it's due to more contact with this unpleasantness.
I always say that the hardest part of programming, once the skills are there, is maintaining/finding motivation. There's no motivation like someone else suffering from a problem you created. Otherwise we tend to exhaust ourselves imagining everything that can go wrong, and there's no end to things that can go wrong.
I think things are best shipped when they are rare to medium-rare - cooked well enough that no one is going to get sick from consuming them, but not so well cooked that you ruin the essence. Cooking is also a one-way process - I can cook a rare steak to make it well, but can't reverse the process. We can go backwards on a feature, but it's ~100x harder to motivate.