Hacker News Reader

Comment by eacapeisfutuile | Hacker News Reader

Isn’t it a bit ironic with how much code everyone depends on that can freely be altered by some unknown party, while so much time goes into code reviews to verify internal changes at most companies.

View on HN

you can have ten comments about the name of a variable, but no one bats an eye at a new npm package introduced. Also, devs that wrote code that Google depends on can't pass the leetcode gate check to get a job there.

Our industry is a laughingstock.

The last sentence is an overreach to me, but I have experienced much of the same bike-shedding during code reviews. 95% of them are useless. Read that twice; I am not joking, sadly. I am not against code reviews, but in my experience(!), the reviewers are not incentivized to do a thorough job. Seriously, if you deliver a new feature vs do a deep, difficult code reviews, which one benefits you more? To repeat: I don't like it; I am only pointing out the perverse incentives to rush during code reviews.

One more thing that I don't see enough people talking about here: Writing good software is as much about human relationships (trust!) as it is about the computer code itself. When you have a deeply trusted, highly competent teammate, it is normal to put less effort into the review. And to be clear, I am talking about the 99% scenarios of writing the same old CRUD corporate code that no one gets excited about here. Please don't reply to this post with something like, "Well, I work on Dragon at SpaceX and all branches have 2x code coverage and the QA team has 600 years of combined experience... Yada..."

One 1 hour doing code review is not really stolen from doing feature work really is it? For the vast majority its stolen from playing video games or some other non-work.

That is very subjective, and far from what I’ve seen.

That heavily depends on the individual developer and the organization in question.

In general, the most highly skilled developers who are most capable of doing a thorough code review are also the ones who are most likely to be genuinely over capacity as is.

I'm not sure about your experience, but companies which have strong code review practices also have strong controls on the third party code. In terms of review granularity, it makes more sense to be critical of maintenance/readability for code you actually own and maintain. Third party code has a lower bar and should, although I also believe it needs to be reviewed

Yeah I think this is the common case. I think we usually trust that dependency A took a look at their dependency B and C before releasing a new version of A. And even if properly reviewing our bump of A, how often do we check out changes in B and C

Edit: yes for FAANG-ish companies this is usually a bit different, for this reason. And licenses..

>while so much time goes into code reviews to verify internal changes at most companies

Maybe at FAANGs, but I work at a massive company and code review is non-existent.

I think this almost the default even outside of FAANG, of course there’s companies not applying it.

Some might say RMS was right all along.

I would actually say that he is completely wrong in this case. Open source created this problem.

And you think proprietary code doesn't have this problem?

Can you prove it? Where's the evidence? ;)

Lack of proof in any direction is approaching the core issue here.

The problem niver would have been fixed in proprietary software. And it's unlikely the problem would have been considered anything more than a 0.5s startup delay in some situations if xz were proprietary; it would have been reported as a performance issue to the malicious maintainer, who would have treated it as such and improved the startup time.

> while so much time goes into code reviews to verify internal changes at most companies

Very easy claim to make. Difficult to verify.

Yes, this is anecdotal, but I think there’s a fair share invested into it (from my experience)

And he was in the project for just 2 years.

Reply on news.ycombinator.com