Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

She was right, and as a senior engineer she was in a mentor role.

I don't think that directly communicating a relevant fact - that trans is not a gender - to someone contributing to a survey intended to collect data about marginalized people is the same as expecting her peers to walk on egg shells. That's just asking them to get their facts straight.

Where you see an instance of her co-workers being accused of attacking her, I see her lines of communication being shut down from above. A simple one-on-one conversation probably could have resolved that situation very easily, but GH management seems in this case to have insulated that person from learning from their mistake. Not the kind of effort I would expect from an organization that's truly trying to be "inclusive.



To play devil's advocate:

------------------------------

> As a senior engineer she was in a mentor role.

Being in a mentor role does not mean you have to right to mentor. Assuming you have a superior position, and deciding to use it to explain something obvious to someone else as "educating" them is not a good social interaction for the other person, and may make them feel trapped and uncomfortable. The author never said the junior developer expressed interest in mentorship, merely that "this teammate seemed to be benefiting from it." Not willing engaged, but "benefiting." Without context, it is imaginable that said mentoree didn't want these interactions or this relationship and the author never identified this social cue.

> I don't think that directly communicating a relevant fact - that trans is not a gender - to someone contributing to a survey intended to collect data about marginalized people is the same as expecting her peers to walk on egg shells. That's just asking them to get their facts straight.

The article starts by complaining about "drive-by issue comments", then described opening what might be considered a drive-by issue. That could be construed as contradictory. Moreover, said issue may be construed as a (company-)public dressing-down. A developer came though and, in a public manner observable by all their peers, informed another that they were not being sensitive enough. It's reasonable, I think, to be upset in that context.

> A simple one-on-one conversation probably could have resolved that situation very easily, but GH management seems in this case to have insulated that person from learning from their mistake

The author could have initiated such a conversation herself in lieu of the issue.

------------------------------

My point is that a lot of things are a matter of perception, and one person's is seldom the whole story. Caroline clearly had a bad go of it at GitHub, that isn't deniable. But individuals' perceptions are fickle things, and it is seldom the case that any one tells the whole story.


> Being in a mentor role does not mean you have to right to mentor.

Exactly. For what we know, the junior could have actively complained to the manager (wrongly or rightly) about her mentoring. OTOH the junior dev might have appreciated it. We can't say for sure.

Some people (myself included) prefer to get a general direction and then later to come back for further questions. Too much information in a short amount of time can be overwhelming, I need some time to absorb and read it up in the internet. A few keywords might be good enough to get someone going and figure it out themselves.

"learn at her own pace, without any pressure from you." This really sounds as if the manager had the junior dev's best interest in mind. I don't see how the manager said this to get back at Caroline, as was kind of implied in the article.


> Some people (myself included) prefer to get a general direction and then later to come back for further questions. Too much information in a short amount of time can be overwhelming, I need some time to absorb and read it up in the internet. A few keywords might be good enough to get someone going and figure it out themselves.

I'm in a senior role on my team, and this is exactly how I'd describe the support I try to give my teammates when they ask (and hopefully, they'd agree). Unless someone is going down the significantly wrong path, I'll generally leave them alone until they ask for assistance. Sometimes, they ask for a direction, sometimes they ask for the type of "pair programming" described in the post (screensharing via video calls), but how much or little they get is up to them, and they drive.

In this case, you're right that we don't know the context of the story from the more junior developer's perspective, and it's completely plausible that they weren't happy with the mentorship they were receiving, but also didn't feel comfortable giving that feedback themselves, all of which is a shame.


You are absolutely right.

What makes me a bit skeptical here is that Coraline just writes 'this teammate seemed to be benefiting from it'. But doesn't mention that the junior dev appreciated it or thanked her for her help. Didn't the junior complain about the missing mentoring after the intervention of the manager?

But who knows, probably I am reading way too much into these few sentences...


I'm in a senior role on my team, and this is exactly how I'd describe the support I try to give my teammates when they ask

I think this level of support is a fairly widespread target for the first interaction on a topic. We're (generally speaking) working among fellow talented professionals within a small-enough window of related disciplines and skill levels. The reasonable assumption is that someone requesting help needs just enough new information to establish connective tissue in their own mental understanding of a problem to become self-sufficient again (even if that means doing more research, learning, digging, etc... on their own). Topics that require a "brain dump" from someone with the institutional knowledge is a sign of technical debt and that information belongs in internal documentation.


> The article starts by complaining about "drive-by issue comments", then described opening what might be considered a drive-by issue. That could be construed as contradictory.

The article is reasonably clear that "drive-by issues" are ones where people leave comments uninvited, and it's also explicit that Caroline was specifically asked to review the survey in question. So it's hard to read that as contradictory.


> Caroline was specifically asked to review the survey in question.

Yes and no. From the article:

> One day a notification came to me that a repo for the open source developer survey had been created and that the survey questions were in progress. My director followed up with me to make sure that I was aware of the survey and asked me to review the questions. I worked my way through, and stopped short at one particular question...

She got a notification of the repository, was asked by someone (not the person working on it) to review the questions, and decided that these two interactions separately constituted an invitation to give public feedback.

Then, her primary feedback was in the form of creating an issue about a specific question, with a terse description. (If you look at the repository in question [0], it appears her feedback came in the form of opening two similarly-terse issues about back-to-back questions with no further comments on the survey for 10 days.)

It's easy to imagine viewing that as a negative interaction from the other side.

I'm not saying it was handled well, or that it wasn't possible to resolve it in another way, but, yeah, I can imagine getting a little upset about that sort of thing happening in the author's shoes.

0. https://github.com/github/open-source-survey/


oh for fuck's sake, these were factual corrections


Right on! Perfectly stated.


> She was right, and as a senior engineer she was in a mentor role.

Apparently not?




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

Search: