> if your code doesn't work on more or less the first try, your design is probably wrong

Or you're tired. Or you're just not as focused as you could be. Or you have a deadline. Or you're trying something new. Or you're not fluent in the language yet. Or you're fluent in the language but not the framework. Or you're fluent in the language and framework but not the design pattern (if you use those).

Or a whole host of other things.

I'm not saying spot-checking the design isn't a good idea, but saying that it's the design more often than the code just doesn't match up with my experience.

The entire idea is to increase the probability that you are correct. So if you're coding tired, you're decreasing that probability. If you're using a framework you're not familiar with, you're decreasing that probability. This is why I mentioned that it was in trading technology: they only get paid to be right.

How do you define "the first try"? Surely you're bound to have various trivial issues?

Something along the lines of after fixing obvious stupid things like those trivial issues.

I remember once my code worked on the first try. I found it difficult to believe.

One time in uni, I had no access to a computer and wrote an entire b-tree implementation on paper for a course, typed it in and it worked.

Based on a true story

In principle TDD is the opposite of this.

Out of curiosity, did you use any debugging on paper for your code?

I can't recall, honestly

I've found it to happen very often the past few years

Did this comment really deserve a downvote? Upvoting accordingly!

Maybe not, but this one certainly does.