Hacker News new | past | comments | ask | show | jobs | submit login

  > The fact, for example, she dismisses PRs or code reviews because made by
  > white males. Or the blog post on her first deliverable, rewritten by a
  > white male.

I really feel like you are injecting your own issues into this. For example, here is an excerpt that you're referring to:

  > However, it soon became apparent that this promising start would not last
  > for long. For my first few pull requests, I was getting feedback from
  > literally dozens of engineers (all of whom were male) on other teams,
  > nitpicking the code I had written. One PR actually had over 200 comments
  > from 24 different individuals.
First off, nowhere does she reference the race of the engineers that were commenting on the PRs. The fact that you jump into this talking about white males this and white males that, seems like you are bringing your own baggage with you into this discussion.

Secondly, it seems more like her issue was that she felt like she was getting dogpiled on via the PR. 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. It especially seems not very inclusive to make a new hire feel like she is immediately on the defensive. 200 comments seems excessive. (Granted we can't see the content so it may not have been all unjustified, but still).

Here is the other excerpt that you reference:

  > The post was submitted for editorial review. It was decided that the tone
  > of what I had written was too personal and didn't reflect the voice of the
  > company. The reviewer insisted that any mention of the abuse vector that
  > this feature was closing be removed. In the midst of my discussions with
  > the editorial team, trying to reach a compromise, a (male) engineer from
  > another team completely rewrote the blog post and published it without
  > talking to me.
Again, there is a lack of reference to whether or not the male is white or not. We can assume that he is probably white, but there isn't even a hint as to his actual race.

Also, like the previous excerpt the gender of the person is referenced to drive home the whole 'inclusiveness' angle. The real issue here isn't that the offender is male, but that he apparently went around her while her content was tied up in editorial review. That seems like a total dick move, IMHO.

To be fair, it's possible that to also blame the managerial systems in place for allowing this too. How was this person able to publish the blog post while a "competing" version of the post was held up in editorial review (though presumably not fully rejected)? Was this a mistake due to poor communication?




> 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."


It 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.


Even 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.


> 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.

I've actually found myself in precisely this scenario. Last time it happened, it was because I was called upon to help try to talk some sense into a somewhat stubborn junior engineer who couldn't grasp that they were making sub-optimal and potentially dangerous decisions.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: