4 ms·

I think I'd have nodded and read on a couple years ago when I'd only had thoughtful/well-informed/diversely-experienced developers review my code. I've learned

I think I'd have nodded and read on a couple years ago when I'd only had thoughtful/well-informed/diversely-experienced developers review my code. I've learned since that it's also possible to have your code reviewed by someone without particularly deep understanding (nor awareness of what they lack), who would insist that responding to a critique of (what they think is) a problem is essentially being argumentative because they are certain they've already got the 'correct' answers (in a similar way that a first year philosophy student might think they've already got the answers). > ... they are stuck in an endless loop of making mistakes and refusing to learn from them I am probably overfitting to my own recent experience, but to me, while this could be a legitimate problem with the reviewee, sounds equally plausibly like a red flag on the part of the reviewer: someone who has settled into a set of "correct" answers and now sees other people not adopting their personal outlook on code as a failure to learn. It is not a simple matter to (definitively, non-subjectively) find a 'problem' once the criteria become anything more nebulous than "does it produce the correct result". There's an analogous situation I've noticed in more casual conversations: someone is describing a problem they have or a situation they're in, and the person they're speaking to keeps smugly offering "solutions" that only sound good because they haven't listened closely to the other person, took a superficial glance and assumed the issue was some common one and so offered a facile/common solution—and then don't understand why the other person isn't appreciative.

snapcore 5y ago
Yeah, the person who thinks a mistake is "you aren't writing the code my way" in itself is an ego trap. A lot of programmers get trapped in their viewpoint and think everyone should write code like them because it would make more sense to them if everyone did, when it isn't objectively better.
- sethammons 5y ago
  "Given the choice between my opinion and yours, I'll take mine. Got any data?" -former boss
  - skj 5y ago
    My former boss too! That message was sort of the beginning of the end for the trust I had. Very disappointing.
mkl95 5y ago
> someone who has settled into a set of "correct" answers and now sees other people not adopting their personal outlook on code as a failure to learn. Real example #1: I warn John Doe that his new endpoint will crash in a specific scenario. John Doe dismisses the warning since "it's not likely to happen in the wild". QA call it out soon after it's uploaded to our test environment. The error has a chain effect where it prevents them from testing other stuff. Real example #2: I warn John Doe that we just committed a flaky test to the develop branch, and I submit a PR to fix it. John Doe closes the PR since "for now we must accept tests fail in mysterious ways". Soon after, Doe Johnson who works in another team is blocked by said test. He spends an hour or two coming up with the same solution I did. In both cases we burnt money needlessly, because John Doe is too stubborn to accept our team's code is not perfect.
- hnfong 5y ago
  Sounds pretty bad if they didn't have a reason to not take the fixes. But ... where's the tantrum though?

snapcore 5y ago

Yeah, the person who thinks a mistake is "you aren't writing the code my way" in itself is an ego trap. A lot of programmers get trapped in their viewpoint and think everyone should write code like them because it would make more sense to them if everyone did, when it isn't objectively better.

sethammons 5y ago
"Given the choice between my opinion and yours, I'll take mine. Got any data?" -former boss
- skj 5y ago
  My former boss too! That message was sort of the beginning of the end for the trust I had. Very disappointing.

mkl95 5y ago

> someone who has settled into a set of "correct" answers and now sees other people not adopting their personal outlook on code as a failure to learn. Real example #1: I warn John Doe that his new endpoint will crash in a specific scenario. John Doe dismisses the warning since "it's not likely to happen in the wild". QA call it out soon after it's uploaded to our test environment. The error has a chain effect where it prevents them from testing other stuff. Real example #2: I warn John Doe that we just committed a flaky test to the develop branch, and I submit a PR to fix it. John Doe closes the PR since "for now we must accept tests fail in mysterious ways". Soon after, Doe Johnson who works in another team is blocked by said test. He spends an hour or two coming up with the same solution I did. In both cases we burnt money needlessly, because John Doe is too stubborn to accept our team's code is not perfect.

hnfong 5y ago
Sounds pretty bad if they didn't have a reason to not take the fixes. But ... where's the tantrum though?