As a public open source (yep, open source can be private) programmer (currently x86_64 assembly), and I am very aware of this pitfall.
It is very important to move forward in code, because you cannot predict how will actually end up a complex program: you need to have all the (sane) features in to actually know. Since code is all about trade-offs, there is "no perfect".
You have to be carefull at avoiding falling into a mental spinning loop about this.
Once you have a reasonable minimum of usable features in, publish it. It help breaking such mental loop.
For instance, currently writing a printf implementation, and printf specs are already brain damaged by themselves, so I am not looking for perfection, far from it. I did set myself a minimal set of features (full format decoding, hexadecimal and byte strings) before publishing it. Until it does not require the complexity of a compiler, does a good enough job, I'll be happy.
Sometimes it is not about perfectionism, but a question of resourses required to achieve something reasonably working: you have a montain to deal with just to get something minimaly working, and you are given a spoon... when you are lucky.
As I said in my post, I did not release it yet, and it will be very incomplete. But I am not alone, and some did assembly written printf like functions (gogol).
The actual real way to work around the inappropriate complexity of that function is to remove it and switch to a brutal "put string" with string conversion functions (with space allocated on the stack). In the end it would be not that much more work in most cases, then in the end I may not even use my assembly code, but lower some printf function usage to what I said.
Isn't assembly programming already a form of perfectionism in itself. Compilers do the job well enough 99.9% of the times. If you are in the 0.1% where writing assembly is justified, you are probably also expected to put many, many times more effort on details most programmers don't care or even don't know about.
Yes, I think it's even less than 0.1%. Assembly should mostly be written as a target for a compiler backend or to inline a hotspot only when it is proven that the compiler can't do it for you. Very few are in either of these two situations outside of artificial environments like a class.
Just to be independent from those grotesquely and absurdely massive and complex compilers(gcc|clang/llvm), justify the additional amount of work for myself.
Not to mention that from the perspective of the life cycle of tons of system software components out there, the actual coding is not that much.
I'm guessing it's referring to the "corporate open source" ecosystem where Google and similar companies make code public but everything else is closed. There is no collaboration, no public roadmaps, no influence given to the community and such. Not sure it's a vital distinction, for me both are as public/private as the other, but that's the only meaning I could try to extract from that...
It is very important to move forward in code, because you cannot predict how will actually end up a complex program: you need to have all the (sane) features in to actually know. Since code is all about trade-offs, there is "no perfect".
You have to be carefull at avoiding falling into a mental spinning loop about this.
Once you have a reasonable minimum of usable features in, publish it. It help breaking such mental loop.
For instance, currently writing a printf implementation, and printf specs are already brain damaged by themselves, so I am not looking for perfection, far from it. I did set myself a minimal set of features (full format decoding, hexadecimal and byte strings) before publishing it. Until it does not require the complexity of a compiler, does a good enough job, I'll be happy.
Sometimes it is not about perfectionism, but a question of resourses required to achieve something reasonably working: you have a montain to deal with just to get something minimaly working, and you are given a spoon... when you are lucky.