4 ms·

> Remember: reading your mind is part of every team member’s job. That’s how they stay proactive! > Did someone on your team do something differently than how

> Remember: reading your mind is part of every team member’s job. That’s how they stay proactive! > Did someone on your team do something differently than how you would do it? Reprimand them! They might tell you that it works just fine, and that their way is just as good. But it’s not your way, so it’s not right. An important question to me: what is a reasonable level of code-style guidelines for a manager / lead code-reviewer to enforce? I was in a position where all my code had to be reviewed and approved by this guy before it would be merged. It felt like I had to read his mind in order to get it correct and get it merged. I would spend as much time tweaking things stylistically to appease him as writing actual code. So how do you determine what's an appropriate level of strictness and what isn't? Obviously a consistent code-style in a codebase helps make it more readable, yet obviously it's also possible to be too pedantic. I have trouble knowing where the line is. In my case, I don't know if the guy reviewing my code was the problem, or if I was the problem for being annoyed by it.

cjcenizal 11y ago
I currently have the role of the lead reviewer you describe and I often worry I'm focusing too much on minor details. Fortunately my coworkers are comfortable pushing back. I think if you're able to have an objective discussion and agree on your goals, and whether a suggested change meets them better than the existing code, you'll be able to get work done together without one of you feeling like you're being a problem. The reviewer also has to be prepared to let go of a suggestion if the change won't have an actual impact.
- freditup 11y ago
  It's a tough issue. Having every line of code be exactly 100% consistent isn't a bad thing, in fact, it's a good thing. But, I question if it's worth the time, effort and frustration to do this. I feel it could be better spent on more pragmatic things, like code correctness. And then of course, there's the minor changes that don't actually bring any improvement at all. It's tough though, because I feel that pushing back against these things, at least in the short term, just eats more time, is more of an effort, and causes tension.

cjcenizal 11y ago

I currently have the role of the lead reviewer you describe and I often worry I'm focusing too much on minor details. Fortunately my coworkers are comfortable pushing back. I think if you're able to have an objective discussion and agree on your goals, and whether a suggested change meets them better than the existing code, you'll be able to get work done together without one of you feeling like you're being a problem. The reviewer also has to be prepared to let go of a suggestion if the change won't have an actual impact.

freditup 11y ago
It's a tough issue. Having every line of code be exactly 100% consistent isn't a bad thing, in fact, it's a good thing. But, I question if it's worth the time, effort and frustration to do this. I feel it could be better spent on more pragmatic things, like code correctness. And then of course, there's the minor changes that don't actually bring any improvement at all. It's tough though, because I feel that pushing back against these things, at least in the short term, just eats more time, is more of an effort, and causes tension.