I wrote it a bit tongue in cheek, but honestly, I've recently started to consider writing the first solution as a pure learning exercise. I.e. when writing a new module/feature, I lean towards getting a solution implemented quickly, fully expecting to immediately scrap most (or all) of it, and write it again. Most of the time, this happens way before the code goes into review phase, so nobody knows I've actually written something twice.

In my experience, most of the insights cluster in two places: just as you start writing your solution, and just as you think you're done with it. So you want to get through the whole process quickly, just to learn the things you need to write a proper solution.

Related, from a different HN thread - https://news.ycombinator.com/item?id=27692710 - "action produces information".

> so nobody knows I've actually written something twice.

that's not really what a rewrite is. A rewrite is when something has already been in production, and the engineer re-do the same feature set, but refactored or rewritten in a different (possibly better, but not guaranteed) form. This rewrite takes up the time that would've been spent on something else.

If you were doing a "rewrite" during implementation, but still delivered on time, that's not a rewrite - that's just good engineering, doing exploratory coding! If you couldn't deliver on time because of the rewrite, then i guess you can call it a rewrite.

I don't think this is what people mean by a rewrite here. I expect any code that makes it to review to undergo some kind of refactoring. Sometimes it's going to be refactored as part of the review. And if throwing away your first draft works for you to create better software, that's fine! I still consider this as some kind of refactoring.

Throwing away a whole repository that was tested and running in production or on some dev environment, is something different in my point of view. And I think that's what people mean by "rewrite".