Re:Doing a Job (1982)
by journalctl on Saturday November 02, 2019 @11:29AM
(#21428206)
I think code reviews on teams without architects are awkward. Someone naturally might step up to take on that role, but if there’s no clear decision maker for hard technical choices, then it’s just a bunch of awkward, passive suggestions. And with no clear leadership, it’s hard to resolve disputes. People need to be empowered to do their jobs, but I’ve noticed that on a lot of dev teams that empowerment isn’t explicit. So you end up with the strongest personality being the one that makes important technical decisions or architecture decisions, regardless of whether or not they’re qualified. Personally, I’m not a fan of this approach.
I worked in a place where QA was cyclical - there would be too many errors, so they would add another layer of checks. Then someone would think, well, people are being too careless because they think the next layer will catch what they miss, so let's remove a step.
Re:Doing a Job (1982)
by lonelappde on Saturday November 02, 2019 @02:13PM
(#21429121)
That's because your code shop is not doing engineering.
I feel that the code reviews I’ve been a part of were not as effective as they could have been. I think there is social awkwardness at criticizing design or conceptual aspects, and a multitasking aspect that means the reviewer is in a hurry and mostly checks conformity to the style guide. Very little checking out of branches and manual testing happened, so we had more regressions than expected.
Is this the norm? What practices have you seen that lead to better results?