Live data from Hacker News

How to do a code review

google.github.io

21–30 of 376 posts

Re: How to do a code review

#21
post #5

Earlier quoted context omitted.

It refers to "changelist". Google uses a Perforce-like VCS internally, and they kept the Perforce terminology: https://www.perforce.com/perforce/doc.051/manuals/p4guide/07...

aka "Pull Request" in Github parlance.

aka "Merge Request" in Gitlab vernacular (which makes more sense than "pull request" in my opinion).

Re: How to do a code review

#22

This is great advice and isn't followed often enough, especially when reviewing code written by people new to an organization/team: > If you see something nice in the CL, tell the developer, especially when they addressed one of your comments in a great way. Code reviews often just focus on mistakes, but they should offer encouragement and appreciation for good practices, as well. It’s sometimes even more valuable, i…

> I've seen cases where people got hundreds of comments (many of them minor, nitpicky) from more experienced developers and were discouraged by the sheer number of them. That most new developers naturally suffer from imposter syndrome is not helped at all by 100% critical code reviews.

This, combined with a large portion of developers lacking social empathy, poor communication skills, and (unfortunately) a desire to appear to the the smartest person in the room, can lead to severe demotivation and stress for both experienced and new team members.

Re: How to do a code review

#23

CL? Is that perforce? Hopefully it works better than the real perforce. A really tough and confusing versioning tool.

> CL: Stands for “changelist,” which means one self-contained change that has been submitted to version control or which is undergoing code review. Other organizations often call this a “change” or a “patch.”

source: https://google.github.io/eng-practices/

Re: How to do a code review

#24
post #16
post #6

As a side note, their github hosts 1600 repos. Just wanted to say thank you, google.

I would wager that a vast majority of them are personal projects. If you work at Google and want to do some open source project on the side, the code is owned by Google and is under Github.com/google. See: https://news.ycombinator.com/item?id=15592968

Here I am just wishing my company would even allow me to post the source of a project I've worked on with any license and apparently Google isn't worth praise for hosting all such projects with an Apache license by default and a review process if you'd like to try to keep copyright.

https://opensource.google.com/docs/iarc/

Re: How to do a code review

#25

This is great advice and isn't followed often enough, especially when reviewing code written by people new to an organization/team: > If you see something nice in the CL, tell the developer, especially when they addressed one of your comments in a great way. Code reviews often just focus on mistakes, but they should offer encouragement and appreciation for good practices, as well. It’s sometimes even more valuable, i…

Why is it that people feel so discouraged by loads of review, especially early on? I always had a good bit of imposter syndrome early on, but never considered quitting. I always assumed that you have a lot to learn, that it’s expected you’re going to suck at some level.

Re: How to do a code review

#26

Earlier quoted context omitted.

aka "Pull Request" in Github parlance.

aka "Merge Request" in Gitlab vernacular (which makes more sense than "pull request" in my opinion).

A Perforce changelist is more like a git commit than a GitHub pull request.

Re: How to do a code review

#27

In the "What Is Not An Emergency?" section: > It is the end of the day on a Friday and it would just be great to get this CL in before the developer leaves for the weekend. I laughed out loud because it reminded me of so many times I have seen it happen and then someone had to fix in the weekend. Who shares the same experience?

Some places I've worked explicitly won't push/deploy/similar on Friday.

Re: How to do a code review

#29

In the "What Is Not An Emergency?" section: > It is the end of the day on a Friday and it would just be great to get this CL in before the developer leaves for the weekend. I laughed out loud because it reminded me of so many times I have seen it happen and then someone had to fix in the weekend. Who shares the same experience?

Some places I've worked explicitly won't push/deploy/similar on Friday.

That's a good policy. We currently don't deploy on Friday afternoons.
Post reply on HN