3 ms·
If you think of rigorous code reviews as brutal, you're seeing it the wrong way. Reviews are about the code, not the people that write it, and the process of r
by a-dub 8y ago
If you think of rigorous code reviews as brutal, you're seeing it the wrong way. Reviews are about the code, not the people that write it, and the process of reviewing means teaming up to make sure it will be the best it can be.
If its really sloppy, bend your boss' ear and see if they agree. If so, develop a plan of action with your boss to get things up to standard for everyone.
If it's sloppy and terrible and no one wants to change, find a new job.
- barry0079 8y agoI wouldn't suggest going straight behind your team's back to your boss to "Tell". That seems like a quick way to get them all to resent you. I'd try a candid discussion first before this.
- a-dub 8y agoMaybe you're right. ... but I think "telling" is also the wrong way to look at it. It's not about who's right and who's wrong or who's the best or who should get dinged or whatever will get people's backs up and invoke pride and resentment among equals. There's a reason why there's a boss, they're there to set direction where their role in doing so is clearly defined to everyone. I suppose every team is different though.
- Haydos585x2 8y agoI think most people will immediately get their back up if a team member was going straight to their boss anytime something the team member disagreed with was pushed to git. Something like a style guide might help clarify points. There's also no guarantee that what OP feels about the code is correct. They might like one way but wasn't present for discussions or doesn't understand the work completely. If they're running straight to a manager every time it's only going to end poorly.
- b0bby_tabl3s 8y agoI think it's fair to say that there are different reviewing styles and environments, as alluded to in the OP. IMO reviews SHOULD be about the code, but pride tends to make it about the person regardless of which end you're on.