There’s some worthwhile stuff here about how perverse incentives lead to pathological outcomes in large organizations, but…
> Here's the pressure if you're in the 10% of people that aren't crud at their jobs - you're surrounded by people that are crud.
> In professional settings, approximately all of my time goes into solving problems introduced by people that are just indescribably bad.
Jesus. If this is really the case, consider that your organization might be abnormally bad and that you should leave.
I’ve worked with a few incompetent engineers, but never have I ever worked somewhere where 90% of ICs are so bad that they’re actively making the product worse and burning all of the other 10%’s time on trying to undo the 90%’s work. Of course it’s also not true when an organization claims that everyone there is a “10x ninja rockstar”. Most people I’ve worked with are smart but human. If I worked somewhere where 90% of my peer engineers were as bad as OP’s are, I’d leave ASAP by any means necessary.
The alternate hypothesis, of course, is that I’m part of the 90% but don’t know it!
The thing is, there isn't one singular measure of value in terms of how the product can be "bad" or "good". I've very often seen less experienced engineers make stuff that helps a specific customer (good), but makes the app just a little less organized and understandable in the long run (bad). I often have to step in and fix the damage done that might not be visible at first glance for a lot of my coworkers. I wouldn't say it's 90%, but maybe 60%.
The thing is, it's not like said engineer didn't actually deliver a useful thing to a customer, so it's not like he did objectively universally bad. But they might not realize that if everybody worked like this, a few years down the line, our entire product would be beyond saving.
> but makes the app just a little less organized and understandable in the long run (bad)
This sounds like normal code-rot; code is changed to achieve some particular goal, but budget isn't allocated for the requisite refactoring. I personally prefer that refactoring opportunities are seized whenever they appear; managers with budgets don't usually agree, for understandable reasons. Eventually you end up with a hairball that can't be refactored, and has to be rewritten.
Whether a change should be made at all, whether to go ahead and refactor there and then, or how long to postpone the refactoring, are all business decisions that have to be taken by the person that manages the budget.
It all depends on your personal standards. This is a much more measured take than what I wrote above, and probably more accurate. Of course, Sturgeon's Law is obviously not literally true in every domain. 90% of people can successfully fry an egg, etc.
60% feels about right - they can get stuff done but I have to intervene because the damage they are causing is just beyond their ability to recognize (and I'm sure I do this too, for harder problems).
> Here's the pressure if you're in the 10% of people that aren't crud at their jobs - you're surrounded by people that are crud.
> In professional settings, approximately all of my time goes into solving problems introduced by people that are just indescribably bad.
Jesus. If this is really the case, consider that your organization might be abnormally bad and that you should leave.
I’ve worked with a few incompetent engineers, but never have I ever worked somewhere where 90% of ICs are so bad that they’re actively making the product worse and burning all of the other 10%’s time on trying to undo the 90%’s work. Of course it’s also not true when an organization claims that everyone there is a “10x ninja rockstar”. Most people I’ve worked with are smart but human. If I worked somewhere where 90% of my peer engineers were as bad as OP’s are, I’d leave ASAP by any means necessary.
The alternate hypothesis, of course, is that I’m part of the 90% but don’t know it!