3 ms·
> I've never worked anywhere that I felt the need to start critiquing the code of people from other teams who were working on systems that I might not even have
by Shank 9y ago
> I've never worked anywhere that I felt the need to start critiquing the code of people from other teams who were working on systems that I might not even have experience with.
This is probably a side effect of how GitHub evolved. Watching some of their earlier talks and comparing that with how they function now, the introduction of managers was a recent addition. It probably didn't change how past engineers operate in the company, e.g., "chime in if your comments are relevant, even if you aren't necessarily requested to chime in."
- nostrademons 9y agoIt was common in early Google as well...I knew someone fairly high up that used to leave drive-by code reviews for people on other teams. It wasn't done much by the time I joined in 2009, and became explicitly taboo by 2010 or so. I think it's actually because when you're in a young fast-growing company, the success of the company is literally everyone's responsibility. You have both the means (because the company hasn't yet ossified into management structures and the codebase is small enough that most people can be familiar with all of it) and the incentive (because a large portion of your compensation is in stock options that are only worth something if you succeed) to materially affect the company's prospects. And many people who join in that environment don't get the memo about when it becomes inappropriate for a new, larger structure.
- phlakaton 9y agoEven at a larger size, though, it can still work – but the need for effective communication and diplomacy is even greater. You also want to be sensitive that you probably do not have all the context you might need when reviewing another project's code, so humility is important. When I do this, it's usually in the form of clarifying questions, suggestions, or requests.