On the other hand, I'm reminded of this passage from HPMoR:
"But Father had once told her that the trouble with passing up opportunities was that it was habit-forming. If you told yourself you were waiting for a better opportunity next time, why, next time you'd probably tell yourself the same thing. Father had said that most people spent their whole lives waiting for an opportunity that was good enough, and then they died. Father had said that while seizing opportunities would mean that all sorts of things went wrong, it wasn't nearly as bad as being a hopeless lump. Father had said that after she got into the habit of seizing opportunities, then it was time to start being picky about them."
Or, in context: You can't skip directly to writing quality code. First, you have to get used to writing code, and to do that, you have to write a lot of it. You have to get used to getting things done. Only after you have a good grasp of getting things done, of seeing a project to completion, should you start worrying about code quality.
I have a lot of unfinished projects, and a lot of smaller projects that I have finished. I'm sure all of us do. But once, I decided not to worry so much and just start writing, and I started and shipped an incredibly ambitious project. It wasn't my best code, but it taught me a lot about not sitting at a blank screen trying to plan everything to be perfect before starting.
Totally agree, and this applies to almost every creative endeavor I can think of. If you want to write a book, throw words on a page. If you want to start a company, launch an MVP and iterate fast. All things being equal, doing is better than not doing, and doing well is better than doing poorly.
If you're interested in this topic w.r.t software engineering, check out Michael Lopp's article in The Magazine about Stables and Volatiles[1]. Really good piece on how companies are composed of and need both Volatiles like The Kid who move fast and innovate, and Stables who clean up the mess and move the company towards profitability.
Another term I like to use is analysis paralysis - basically spending all of your time preparing to do something, but getting bogged down in the preparation instead of the actual goal.
"But Father had once told her that the trouble with passing up opportunities was that it was habit-forming. If you told yourself you were waiting for a better opportunity next time, why, next time you'd probably tell yourself the same thing. Father had said that most people spent their whole lives waiting for an opportunity that was good enough, and then they died. Father had said that while seizing opportunities would mean that all sorts of things went wrong, it wasn't nearly as bad as being a hopeless lump. Father had said that after she got into the habit of seizing opportunities, then it was time to start being picky about them."
Or, in context: You can't skip directly to writing quality code. First, you have to get used to writing code, and to do that, you have to write a lot of it. You have to get used to getting things done. Only after you have a good grasp of getting things done, of seeing a project to completion, should you start worrying about code quality.
I have a lot of unfinished projects, and a lot of smaller projects that I have finished. I'm sure all of us do. But once, I decided not to worry so much and just start writing, and I started and shipped an incredibly ambitious project. It wasn't my best code, but it taught me a lot about not sitting at a blank screen trying to plan everything to be perfect before starting.