yeah, if you're going to talk bad about anyone's code, start with your own. not even the things you wrote a few months ago, but like even today, writing xml schemas for a rest api, the whole time i'm thinking about all the ways the decisions i'm making are going to come back and bite me in the ass. not because i'm inexperienced but because i've written and worked with schemas and specs for interprocess communication before and know that any changes to the schema will require edits to multiple codebases and the time and effort to make some of those changes can be frightening.
i guess this is what fred brooks calls "the second system effect." it'll probably turn out that there's some other more terrible problem with the current system that i'm not even seeing because i'm overly concerned about the communication protocol on top and not the databases underneath or concurrency off to the side somewhere.
how many systems of some particular type does one have to build before not writing shit on the first pass? because, like, yes, the code freely available to anyone with a quick `apt-get source` is often of much higher quality than some things hidden in multinational corporations' private repos. so everyone can have some idea of what good code looks like now, but i am personally finding creating much more difficult than verifying and fear that it's going to take a lot of time to narrow that gap.
is it really necessary to work on like 8 processors before doing what someone like ivan godard does? maybe just 4 or 5 projects (which translates into about a decade, mind you) is enough before the "i'm fucking shit up" jitters pass for any particular type of system?