Hacker News Reader

Comment by vbtemp | Hacker News Reader

I enthusiastically believed this in the past, but then I started observing the reverse: Code reviews became gatekeeping for junior developers... In other words, junior developers were using it as opportunities to assert power (via obstruction). Of course this was idiosyncratic to the company and team.

I've become less positive toward code reviews over the years as well - the low-hanging fruit of style checking, linting, and related stuff has been automated away. Moreover, people are busy and when they do code reviews, they are mostly looking for easy stuff to pick at. What ends up getting avoided is the far more important algorithm, design and architecture reviews that really require a much bigger cognitive load.

View on HN

I feel code review is overrated. It makes refactoring and small fixes take like 2h longer. I atleast fill up my parallel tasking slots too fast with small things if they linger in review. So either I don't do them or get less done.

Code review might be good for a subset of code, like retrofitting bugfixes to release branches or babysitting a team of beginners.

Code reviews turn into a formality when everyone is submitting great code. This is a good thing.

BUT: I just joined a team with domain experts who do not have a software engineering background. As I go through the code, there's lots of copy & paste, incorrect error handling, inconsistent (and confusing) variable names...

These developers really can benefit from coaching in a review. The team then benefits because the code is easier to read, robust, and maintainable.

(The codebase is impressive for people who have minimal software background. I've seen much worse from people who should know better.)

“Moreover, people are busy and when they do code reviews, they are mostly looking for easy stuff to pick at. L

That’s a real problem. Almost nobody has the time to really understand the code they are reading and how it fits in.

Conversely if you do attempt to do a deeper dive into the design and architecture choices my experience has been you end up getting push back and overruled -- because people are busy and don't want to miss a deadline with code that "works"/ passes whatever the minimum bar was set to hurl it into production.

I completely agree. The irony for me has been how immensely helpful toolchains (PRs, awesome unit test harnesses, powerful CI systems, etc etc) actually kind of make things worse and support everyone missing the forest for the trees.

Everything has become dislocated from reality. "Issues" and "tickets" does not capture actual work to do. Unit tests and CI do not capture whether something is truly functional. Peer-reviews do not mean a given commit is stronger than otherwise... At the end of the day there's just no replacement for good judgment and experience, despite all the fancy tools that want to try to "gamify" it.

Reply on news.ycombinator.com