5 ms·

One particularly prominent special case of this is when one engineer makes a snap judgment about another engineer's work that it's "overcomplicated". Oftentime

by gyulai 5y ago

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.

alkonaut 5y ago
> 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.
- gyulai 5y ago
  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.
  - maccard 5y ago
    > 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.
maccard 5y ago
> 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.

by gyulai 5y ago

alkonaut 5y ago

> 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.

gyulai 5y ago
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.
- maccard 5y ago
  > 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.

maccard 5y ago

> 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.