Helpful and interesting. However, you can tell this was written by an engineer. The acronym CL is used about a hundred times. There is not a single page where the first usage of the acronym explains the full term.
How to do a code review
231–240 of 376 posts
Re: How to do a code review
#232Earlier quoted context omitted.
Why the scare quotes around "positive"? I have lots of positive thoughts when doing code reviews. I don't write them into comments all that often, but sometimes I do. "Oh I didn't know about this API, nice find!" "Ah, nice approach, this is a big improvement." "Thanks for improving the test coverage!" Maybe this seems like unactionable "noise", but it isn't, it encourages future actions of the kind being positively r…
Depends how it's come across. If your not careful it can come across as patronising.
Personally I try to make them often, but I also try to be thoughtful about making them as to not come off patronizing like you mentioned.
Though I’ve never felt like a positive comment ever made me feel patronized in any situation, I think a good way to not come off patronizing is to to make the comment more personal than general, ie:
“This is a cool way to use the rest operator (or whatever thing), Ima steal this”.
Obviously it needs to be an authentic comment, but I think it’s a significant difference vs
“Great use of the rest operator!”
When the interpretation on the other end might be “oh so this person is surprised I know these basic language constructs”.
I learn things from doing code reviews all the time, and I like letting my coworkers know that I feel like I’ve gotten better at my job as a result of reviewing their contributions.
I think it’d be a shame if I didn’t let them know.
Re: How to do a code review
#233Here's the part that resonated with me most: A particular type of complexity is over-engineering, where developers have made the code more generic than it needs to be, or added functionality that isn’t presently needed by the system. Reviewers should be especially vigilant about over-engineering. Encourage developers to solve the problem they know needs to be solved now, not the problem that the developer speculates…
Re: How to do a code review
#234Re: How to do a code review
#235As 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.
(Disclosure: I'm a Googler.)
Re: How to do a code review
#236Earlier quoted context omitted.
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/
If you live in CA, you're good to do it: https://codes.findlaw.com/ca/labor-code/lab-sect-96.html as long as you do it on your time, using your own resources, and do not compete with your workplace. The fact that google (or other employers) do not go out of their way to tell you this is, of course, understandable.
Google's IARC process (where they officially sign over their claim to a given invention) is really, truly unusual. They absolute are going out of their way to be accommodating. Even their (super liberal) open-source process was practically unheard of when they started it. The fact that Chris DiBona runs that office is probably (definitely, absolutely) a factor.
Also, I would exercise extreme caution when using the section 2870 argument with a random employer; there's nothing in there that says you can't be fired if you try it, even (and especially) if you win.
Re: How to do a code review
#237I feel embarrassed to even ask... what does CL stand for?
Re: How to do a code review
#238Earlier quoted context omitted.
Forgive me, I don't understand your last sentence. It sounds contradictory vs "they got a lot more productive".
They got fewer returns/defects when they stopped rushing.
Re: How to do a code review
#239Earlier quoted context omitted.
Forgive me, I don't understand your last sentence. It sounds contradictory vs "they got a lot more productive".
What would happen is the shop would start thrashing with people switching from one task to another trying to hurry one unit through production. You eat the setup time for each production task for exactly one unit.
Re: How to do a code review
#240As 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
Since I wrote it on my own time, I had my pick of going the IARC route vs going the Google open-source route, and I picked open-source with a Google copyright because it was simpler (though I fully intend to go with IARC on another project just to try it out).
It's on my own github instead of Google's because (again) it was simpler. Since it contains zero Google-specific anything and wasn't made on company time, they didn't care which I picked at the time. In retrospect it probably would have been cooler to publish it under their name instead of mine, but aw well.