Earlier quoted context omitted.
Your comment reminds me of the exercise where a class was split into two cohorts, one was tasked with producing just one clay pot (I can't remember the thing now), while the other cohort was tasked with making one per day or something similar. Put simply, one group put all of its energy into producing just one, and the other group just turned out pot after pot after pot. At the end, so the story goes, the group that…
The pot challenge is one group is they get graded just on number of pots made vs. the other on a single pot they can submit. The group trying to perfect one pot ends up making worse quality pots than the quantity group because the quantity group ends up getting way more practice. That anecdote gives me lots of hope. I hope it's accurate! :)
If you just write a huge amount of code rather than examining what's good or bad about code you wrote, you'd probably end up writing the same bad code over and over again. Seeing where improvements can be made is sometimes really not obvious and can feel like you're going backwards. For example, learning where functional programming applies instead of writing a class for everything. You need to be able to understand why something is better for simple repetition to work.