[zxcvbn4038]

I have not been a junior developer for a long time, but I occasionally get treated like one. One day after joining a new employer I raised my first or second pull request - and one of the longer term members of the team reviewed it and really let me have it! In every single line he found problems with my style, approach, everything - and he wasn’t really polite about any of it either. So I wrote back that it was actually his change from the previous day with all “dev” changed to “qa”. No response but the change was approved.

[distantaidenn]

It's their ego. I'm now at the CTO level, but I still code as a hobby (daily) and will contribute as necessary to a product with coding. A couple years ago, during a stretch with a previous client, I wrote a bit of code. With my second PR, one of the code reviewers tore my code to shreds. It was 90% styling and 10% theory. As for the styling, sure, it was fair enough. I was new to their culture and it was trivial changes -- 5 minutes of work.

The last 10% was simply a theory issue. The reviewer wanted things his way, which would have taken an inordinate amount of time for the feature. I told him that it was unnecessary, and would increase dev time. I was thinking about the entire product process, while he was focusing on how the code should look -- which was purely arbitrary.

He wouldn't waver, and delayed my PR. It eventually was escalated to the head of engineering, who sided with me. It was a trivial feature, and my code was tested and worked -- it just wasn't the reviewer's way of doing things.

Anyway, it got merged as is. But, I can only wonder about how a junior dev may have handled it. Wasting hours of time to conform to a particular senior engineer's arbitrary "way" of doing things -- correctness be damned. As for my own code reviews, I follow a simple process: 1. Can I parse it in 10 seconds? 2. Does it fit the specs? 3. Is it tested? 4. Is it extensible?

[st4lz]

You describe something that I experience in almost any organisation. I am not a CS grad, I've seen many projects in different technologies through the years and also have more business-oriented mindset as for software engineer. The amount of arbitrary requirements in code, especially in languages with no clear code styles (like Python) and specifically with people who don't expose themselves to different technologies (work in the same company for years or so) is a major productivity and motivation killer.

What are the useful techniques to deal with such people? Many times, it is just easier to comply to their vague requirements rather than engage in prolonged discussions, as they usually don't have the ability or will to look at things from the other side. I consider escalation to a higher management the last resort.

Does anyone produced some successful strategies to deal with that?

[antihero]

If they were actually competent the styling changes would have been caught/fixed with automation. If they can’t set up linting and formatting as part of their CI…well I don’t think they have any right to call themselves senior.

[mandelbrotwurst]

Yeah, I tend to take the position that the only appropriate way to request code style adjustments is via automation.

[tidenly]

I still work on a team the person who mentored me four years ago. He's a great guy, but sometimes in front of other engineers he'll still treat me like I'm a junior - and start explaining some incredibly simple concept to me like an idiot. Sometimes things I obviously knew before even joining, like how HTTP verbs work.

It's just a quirk of his without malice I think, but it does get to me depending on who its in front of. I think he just wanted to be seen as the teacher.

[jen20]

Whenever I encounter someone attempting to be condescending while talking about “HTTP Verbs” I pull open the RFC for HTTP and demonstrate that the word “verb” literally does not appear in the document.

[tjrDL6MjB2Zwwa]

so what?

[watwut]

Oh yeaaaah. This one sounds like extreme tho. But yes, practically, I eventually grew to consider most of the "how to behave on code review" social advice article to be naive and wishful thinking.

Fairly often, you gotta show confidence and show boundaries.