Your approach is totally valid if you're faster at producing bad code than clean code that scales well. I actually have allowed my ability to write bad code to atrophy, so it's extremely time-consuming for me to attempt it. And bad code has a way of biting you unexpectedly and costing even more time down the road, so the idea of attempting it is not appealing to me.

The idea I'm trying to get across is that it's possible to get to a point where it's not faster to write bad code first (so there _is_ no waste in going straight to good code), but the path to get there as a developer is to deliberately choose to always write good code.

It's kind of like the argument for Typescript: it's a huge time sink that will make your code and your ability to meet deadlines suffer in the short term, but longer term it has benefits that make it worthwhile.