What Google Taught Me About Scaling Engineering Teams

Re:What Google Taught Me About Scaling Engineering Teams by jrockway on Thursday June 19, 2014 @03:46AM (#7914886)

You have to be careful about who you hire. If you do that well, then opinions, code reviews, one shared repository, and so on, work great. If you hire a bunch of assholes, then they won't work.

I do about 20 code reviews a week; there is never bullying and they are only rarely rubber stamped.

(My favorite code review of my own code this week was where I updated a counter to use atomic.AddInt64 instead of sync.Mutex. But where I was reading the counter, I just read the integer value directly instead of using atomic.LoadInt64. 30 seconds of the reviewers time, and we avoided a potentially difficult-to-track-down bug. No pissing match, no bullying. Just better programs.)

[ Parent | on HN ]

Re:What Google Taught Me About Scaling Engineering Teams by watwut on Thursday June 19, 2014 @05:55AM (#7915387)

Any company over 30 people will have at least one borderline asshole and one asshole is enough to poison the code review if managed wrong.

[ Parent | on HN ]

Re:What Google Taught Me About Scaling Engineering Teams by kabouseng on Thursday June 19, 2014 @08:28AM (#7915693)

20 code reviews a week? How many lines of code for each review?

[ Parent | on HN ]

Re:What Google Taught Me About Scaling Engineering Teams by jrockway on Tuesday June 24, 2014 @01:26AM (#7936304)

I looked in more detail and if I average it out over 2.5 years and only include actual code I care about (not importing OSS packages, which I also review), it's more like one a day.

I was too lazy to calculate a histogram, but let's go with ~100 lines a day.

[ Parent | on HN ]

Re:What Google Taught Me About Scaling Engineering Teams by kabouseng on Wednesday June 25, 2014 @06:01AM (#7943023)

Thanks for the reply.

[ Parent | on HN ]