11–20 of 376 posts
Would help if they mention what a "CL" is somewhere before using it ubiquitously
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...
As a side note, their github hosts 1600 repos. Just wanted to say thank you, google.
> 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, in terms of mentoring, to tell a developer what they did right than to tell them what they did wrong.
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.
Now if teams pay careful attention to this statement, the Code Review Guidelines can be shortened by an order of a magnitude! ;-)
As a side note, their github hosts 1600 repos. Just wanted to say thank you, google.
Wow, that is really a huge number of repos. I wonder how many are just forks though.
Here are the statistics just in case anyone else is interested:
1,519 Sources
38 Forks
18 Archived
6 Mirrors
--------------
1,581 Total
As a side note, their github hosts 1600 repos. Just wanted to say thank you, google.
"Technical facts and data overrule opinions and personal preferences." So true, so true! Now if teams pay careful attention to this statement, the Code Review Guidelines can be shortened by an order of a magnitude! ;-)
> 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?
CL? Is that perforce? Hopefully it works better than the real perforce. A really tough and confusing versioning tool.
"Technical facts and data overrule opinions and personal preferences." So true, so true! Now if teams pay careful attention to this statement, the Code Review Guidelines can be shortened by an order of a magnitude! ;-)
For example: I’ve seen cases where there’s disagreement as to which of two technical paths to pursue, where one side (not liking the way consensus is currently leaning) demands a data driven proof that one of the choices is best. Ordinarily this would be fine, but in this case, it would take no less work/time to gather said data than to entirely implement both solutions and directly compare them.