Comment by toast0 | Hacker News Reader

Comment by toast0 | Hacker News Reader

Tests and code reviews aren't right or wrong, but take this opportunity to form your own opinion of how you would like to work, and be sure to ask about it when you are interviewing for your next job.

Just as some would run screaming from a place without mandatory code reviews, others would run screaming from a place with mandatory code reviews.

You should be able to get close to real answers about these practices during interviews, there may be some bias towards aspiring to have tests and code reviews, but asking for details should filter out aspirations from actualities.

On the other hand, 12 hour work days, with weekends is clearly bad, and it may be hard to tell who is saying the things you want to hear, only because you want to hear it.

Having a good reason to not be in the office crazy hours is something to mention in interviews "i've heard [industry] can be crazy, but i've got a strict schedule because of X, that won't be a problem right?" Bonus points if you can come up with something plausible, true, with positive connotations and something they wouldn't get in trouble for asking about.

> others would run screaming from a place with mandatory code reviews.

Why would a peer looking over your code be so terrible?

I don't mind occasional code reviews, but I would not want to work somewhere where they're mandatory.

In my experience, mandatory code reviews lead to diffusion of responsibility; because everything is reviewed, changers take less care, even when reviewers treat at least some reviews as perfunctory, leading to preventable errors that weren't caught in review (although I've heard code reviews are supposed to catch preventable errors like this). If changers take more individual responsibility in their change, or a review is a special occasion, demanding and receiving a thorough and thoughtful review, the results seem better from what I've seen by observing groups I work in, and others I'm exposed to.

Mandatory reviews lead to excess communication, and the delays that cause. Stopping to get a review takes wall clock time, as well as the reviewer's time, and causes interruptions (or if done in batches to preserve reviewer's attention, takes a lot more wall clock time). This really breaks the glorious cycle of fast iteration. In my experience, 60 seconds of results from production is worth more than most review feedback.

In case of changes related to production issues, that means any event requiring a change needs two people to respond. Some events may require consensus, but others have clear solutions.

OTOH, it really depends on the cost to make changes, and the cost of making mistakes. In an environment where changes are expensive, and making mistakes is expensive, maybe mandatory reviews and extensive testing and actually having a specification make sense. Thankfully for me and the stakeholders involved, I don't work in such an environment.

Sometimes code reviews can feel like being a carpenter and having to ask your coworkers their opinions after each nail you drive whether you did it right. And then having to spend time judging your coworkers' nail-driving skills rather than putting up the wall you've been given a deadline to build.

I've learned to accept code reviews as worthwhile overall, but there are definitely trade-offs.

A lot depends on how the code review is done. Where I'm currently working we have to do code reviews for an external auditing process and the whole thing has become farcical. It's not at all unusual to be asked to review thousands of lines of code that another developer has spent months working on for a part of the system you're totally unfamiliar with. When I started there and asked the lead developer on guidance for what to look out for, he admitted to just looking for potential null references and rogue code seeking to intentionally damage the system.

Reply on news.ycombinator.com