One particularly prominent special case of this is when one engineer makes a snap judgment about another engineer's work that it's "overcomplicated". Oftentimes this means that the person making the judgment hasn't thought deeply enough about the problem to be able to see all the complexities in the problem that justify all the complexities in the solution.
I feel like, at this point in my career, and in the specific context where I work, this has now become the bottleneck to my career progress.
The problem is: It works as a self-fulfilling prophecy based on the fallacies of social proof and fundamental attribution error. People reach for the snap judgment "this is overcomplicated" because they expect me to just be the kind of person who just overcomplicates things. And they feel easily justified in that judgment given that other people also tend to make that judgment about me. This means they budget even less time for trying to understand the complexities in the problems I solve before reaching for the easy judgment of "this is overcomplicated".
So: The guy who always overcomplicates things, thus draining the company's cognitive resource needlessly and just generally being a nuisance, ends up looking much the same from the outside as the guy who could just be a company's strongest engineering asset. He could be the guy to put the company ahead of the competition, always understanding the engineering problems more deeply and solving them more thoroughly than others, including the competition, in a way that the competition can't easily replicate. -- ...if only the people tasked with passing judgment could overcome biased and lazy decision-making.
> Oftentimes this means that the person making the judgment hasn't thought deeply enough about the problem to be able to see all the complexities in the problem that justify all the complexities in the solution.
This is often the case, but even more often I think my annoyance with the overcomplexity of the code isn't that the code solves the problem in a too complex way, but that the code solves a much too complex problem.
Most of my job as a developer is fighting complexity. Doing it in code is an uphill battle. If you have to solve complex problems with non-complex code, you are fighting a losing battle. The struggle to keep complexity out of the code happens in the dialogue with stakeholders (Project managers, customers, team etc).
Now, there are of course cases where the conclusion after the complexity debate might have been that "yes, the requirement is for the program behavior to really be this complex, meaning the complexity of the code is required". But this is extremely rare. The reason I get annoyed when seeing complex code is because through the decades I have learned that almost invariably, someone took a complex requirement at face value and implemented a complex solution to the requirement.
I'm often reminded of the saying by H. L. Mencken "Explanations exist; they have existed for all time; there is always a well-known solution to every human problem — neat, plausible, and wrong."
Now, I do agree that 80% of all engineering problems that one comes across in practice are amenable to the kind of problem solving tactic where instead of solving problem X, you instead look for opportunities to solve adjacent problem Y which is of lesser complexity.
But sometimes, problem X is just really the problem you actually have and actually need to solve. And you need to add to that the fact that I specifically seek out these situations, because craftsmanship ranks high among my personal values.
To give you a bit of context: Using data from the stack overflow developer survey, I rank in the 87th percentile among developers in terms of years of my life that I've been coding, 70th percentile in terms of years of coding professionally when I don't count my Ph.D. as "professional" coding. The Ph.D. puts me in the 97th percentile of educational attainment, and happens to be from a top-5-ranked university. I spend 50% of my time at work doing boring mundane things like implementing ETLs, which I've done professionally since I was 15 years old (I'm now 37), and I don't even complain about that.
With the other 50% of my time, I try to get my psychological needs around craftsmanship met, and seek out the toughest engineering problems we have in the company where I work. And then those are precisely the sorts of situations, where I have 20-somethings who are my bosses tell me that I always overcomplicate things. This feels extremely humiliating to me, and is a huge lost opportunity for the company.
> Now, I do agree that 80% of all engineering problems that one comes across in practice are amenable to the kind of problem solving tactic where instead of solving problem X, you instead look for opportunities to solve adjacent problem Y which is of lesser complexity.
The problem with these "overcomplicators" is that they see those 80% of problems as the 20% (and in my experience it's more like a 95/5 split).
> To give you a bit of context: ...
If I gave one of my coworkers (or reports) feedback that they had overcomplicated a solution and their response was to drop they're in the 97th percentile of programmers with a PhD from a top-5 ranked university, I don't thikn that would dissuade me in any way, in fact probably the opposite. It's an ad-hominem defense; defending _you_ rather than the decisions you've made.
> With the other 50% of my time ... seek out the toughest engineering problems... where I have 20-somethings who are my bosses tell me that I always overcomplicate things.
With all due respect, they might have a point. If everywhere you go smells, maybe it's time to check your shoes.
> If everywhere you go smells, maybe it's time to check your shoes.
...well it could also be the fundamental attribution error I mentioned earlier.
The very way this thread is unfolding reflects my initial point: From the outside it looks the same.
Telling which is which really requires looking at the specific situation, and thinking about it very deeply, and resisting reasoning from an ad-hominem basis, resisting fundamental attribution error, risisting superficial analogies, like your shoe-analogy, or "I've been in lots of situations with engineers who overcomplicate things and usually it's because they actually do overcomplicate things, so I'm just going to treat it like it always is the case that the actually do overcomplicate things".
Regarding the paragraph about percentiles: I did not write that to suggest that I'm always right, and others are always wrong. I wrote it because I think it's natural that 90th-percentile engineers would seek out 90th-percentile problems to tackle. And it's precisely that point where reasoning from "usually..." becomes invalid reasoning.
In fact the seatbelt example is the perfect example, because if you show somebody a seatbelt mechanism, their initial reaction is indeed likely to be "This is overcomplicated. Why not just use a fixed rope?"
> it could also be the fundamental attribution error I mentioned earlier.
It absolutely could be, you're right. On the balance of probabilities if it's _consistently_ happening to you, maybe it's not as simple as "I'm smarter than everyone else in the room".
> "This is overcomplicated. Why not just use a fixed rope?"
The answer to that is clearly demonstrable, and the analogy holds true. If you are an engineer designing a solution to a problem, you should be able to articulate _why_ this solution is necessary, and what problems it solves. If you're consistently being told that it's over engineered, and aren't able to refute that (as you're implying that this is humiliating for you), then maybe the solution is unwarranted.
Reducing the "overcomplication" problem to a "communication" problem doesn't help, because it suffers from the same shortcoming where these Dunning-Kruger-esque paradoxes are concerned.
All too often the pattern is the judge saying or thinking something like this: Since the subject matter is amenable to proof, and since I, the judge, am such a smart fellow that I would certainly be able to follow any proof presented to me with little effort, my reasoning now works as follows: Step 1: I expend little effort when passing judgment. For example, I shall feel free to pass judgment by declaring something to be "overcomplicated" if it comes from a person about whom I hold the opinion that he tends to overcomplicate stuff (fallacy). Step 2: The burden of proof to dissuade me from that judgment then falls on the enginneer. When he presents that proof, I shall then expend only little effort in trying to follow it, and if I can't, then it surely must be due to the fact that, on top of overcomplicating his engineering solutions, this particular engineer is also a bad communicator. Note that on top of piling on one piece of fallacious reasoning on top of another, this pattern now also starts to take on the flavour of special pleading. Step 3: I am then no longer under any professional or moral obligation to listen to pretty much anything that person has to say. And I will not let this stop me from using my influence to prevent this person from having a career in the company where I work.
> Oftentimes this means that the person making the judgment hasn't thought deeply enough about the problem to be able to see all the complexities in the problem that justify all the complexities in the solution.
While this is true, oftentimes it's true that the person who solved that problem solved it through a lens of their own knowledge (blindspots included). Some of the biggest, most difficult to use messes have come from the "expert" developers who solve a whole bunch of problems that are tangentially related with one solution that is 50% neat and 50% duct tape because they _didn't_ think about the complications when they designed it.
I feel like, at this point in my career, and in the specific context where I work, this has now become the bottleneck to my career progress.
The problem is: It works as a self-fulfilling prophecy based on the fallacies of social proof and fundamental attribution error. People reach for the snap judgment "this is overcomplicated" because they expect me to just be the kind of person who just overcomplicates things. And they feel easily justified in that judgment given that other people also tend to make that judgment about me. This means they budget even less time for trying to understand the complexities in the problems I solve before reaching for the easy judgment of "this is overcomplicated".
So: The guy who always overcomplicates things, thus draining the company's cognitive resource needlessly and just generally being a nuisance, ends up looking much the same from the outside as the guy who could just be a company's strongest engineering asset. He could be the guy to put the company ahead of the competition, always understanding the engineering problems more deeply and solving them more thoroughly than others, including the competition, in a way that the competition can't easily replicate. -- ...if only the people tasked with passing judgment could overcome biased and lazy decision-making.