Um. That kind of thinking is pretty close to my own from some years back. Not any more, but who knows, I may change my way of thinking again ;) In the moment I'm just reserving my judgement regarding skills of other developers. And only make judgements regarding particular pieces of code, mostly trying to find positive things in it, rather than negative ones.
Out of curiosity, a personal question. In terms of years of active software development, what's your level of experience? Is it say, 20 years of building code for moneys? Two times less than than? Two times more? You don't have to answer.
There's nothing bad about being a terrible coder who manages to put together a basic product. There are plenty of terrible musicians who still release albums for example. But it takes wisdom and maturity to understand ones own limitations.
If I owned 50% of a company, and a guy who had measurably increased my wealth by improving the product and hence the value of the company, gave me some advice like this I would listen very carefully. I would not "cut off my own nose to spite my face" or "throw the baby out with the bathwater".
Interesting. Well, my current way of thinking is that there are no terrible coders, it is just that mature and experienced engineers are slightly less prone to making terrible and difficult to correct mistakes. Like using an obscure language or something, just because they feel that way and without considering the implications ;)
There are, apparently, those who cannot implement FizzBuzz. Perhaps it's incorrect to call them "coders". But beyond that, you have a spectrum of skill. Do they become competent before they become coders in your books?
I disagree, somewhat :-) There are people whose contribution is horrible but it's rarely confined to the quality of their code. It's more about being able to lead the company in directions that are ultimately wasteful in some way or other and not being able to change direction when the time is right. That leadership may be expressed in code, but the code is as much or more a symptom than the root cause.
With basic QA practices in place (peer review, coding standards, designs grokked by teams not individuals etc.) a single person usually can't muck up the codebase very badly. He or she can still poison a whole project or company.
Well, my understanding is that developer's experience changes the shape of the probability distribution of excellent/horrible contributions. But it is always a distribution. And that it is difficult to accurately distinguish between excellent/horrible contributions without hindsight.
I find that as I get more experienced, I'm more aware of how much of this huge discipline I don't know, and how many mistakes I've made in the past, and I'm much less likely to call myself a "good coder".
When I was younger and slapping shit together any old how, I thought I knew it all.
Out of curiosity, a personal question. In terms of years of active software development, what's your level of experience? Is it say, 20 years of building code for moneys? Two times less than than? Two times more? You don't have to answer.