Antisocial Coding: My Year at GitHub • Hacker News Board

Re: Antisocial Coding: My Year at GitHub

#361

Post by ubernostrum » Thu, Jul 06, 2017, 7:01 AM UTC

kybernetikos wrote: post #344

eqdw wrote: post #258

Earlier quoted context omitted.

Word games. "Best people" can mean the best team. I mean like honestly, if you don't care _in principle_ about the quality of your staff, how are you deciding who to hire?

Nowhere do I say that I don't care at all about the quality of my staff. In fact I'm often told my hiring process is pretty rigorous. What I am claiming is that work is generally done by teams and optimising for high performing and highly capable teams is not the same as optimising for high performing and highly capable individuals (my understanding of what most people mean by 'meritocracy'). It's not merely word gam…

Don't just look to companies for examples -- look to sports.

There are professional sports franchises who go out and just throw money at "the best" players in their leagues. And the track record of doing that is pretty mixed; it turns out that just hiring a bunch of top individuals easily loses to putting together a group of players who are each objectively "worse" but whose play as a team is superior.

Re: Antisocial Coding: My Year at GitHub

#362

Post by LordHumungous » Thu, Jul 06, 2017, 7:15 AM UTC

> My team was 5 women and one man: two of us trans, three women of color

Keep in mind that her team helps writes her performance reviews.

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

Oh no people were reviewing a new engineer's code. (male employees. you know what that means)

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

Translation: I wrote a ranty screed and my employer, which unlike me understands the importance of polite communication and cares about its public image, declined to publish it verbatim.

> But pair programming simply didn't happen at GitHub. I would occasionally get another engineer to share a screen to walk me through a particularly hairy subsystem, but actual pairing was extremely rare and I missed it.

Gee I wonder why nobody wanted to pair program with you.

> When I talked to my manager about how she was progressing, I was told to stop the formal mentoring and allow this person to "learn at her own pace, without any pressure from you."

Translation: Your mentee is complaining about you being a huge asshole.

> She told me that the data scientist who had written the survey questions was very upset and had gone to her manager to complain about me.

Guessing this wasn't the first incident.

> This was the first instance of what came to be referred to as my "non-empathetic communication style".

Lol.

> My manager accused me of shutting down the conversation by making it personal.

You would never do such a thing.

> My overall review was a "Does Not Meet Expectations."

Surprise! Your coworkers hate you.

> The same day that I had this review, I got some devastating personal news. I have bipolar depression and was already in a bad place mentally

Aaand here come the excuses.

> she said she felt like I was trying to manipulate her by sharing my feelings in the hopes of influencing the PIP.

You weren't though, right? Right?

> GitHub has made some very public commitments to turning its culture around, but I feel now that these statements are just PR.

Yes this has everything to do with Github's culture and nothing to do with your performance as an employee.

Re: Antisocial Coding: My Year at GitHub

#363

Post by LordHumungous » Thu, Jul 06, 2017, 7:18 AM UTC

tyingq wrote: post #8

I've seen this a few times. People with a naturally terse way of communicating eventually end up offending someone with the power to retaliate.

Gotta throw in some emojis yo

Re: Antisocial Coding: My Year at GitHub

#364

Post by LordHumungous » Thu, Jul 06, 2017, 7:19 AM UTC

quanticle wrote: post #357

LordHumungous wrote: post #356

>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. This is common practice for new devs, at least where I work.

Oh god, that sounds horrible. As a new dev, I already know that I don't know anything. I don't need hundreds of people pointing out every little flaw in my code.

Not hundreds, more like 5-6. It's nothing personal, it's to help the new dev learn the company way of doing things.

Re: Antisocial Coding: My Year at GitHub

#365

Post by [deleted] » Thu, Jul 06, 2017, 7:21 AM UTC

sethrin wrote: post #6

Am I reading this correctly? Fired for lack of empathetic communication? Is that really a thing?

[deleted]

Re: Antisocial Coding: My Year at GitHub

#366

Post by Sorreah » Thu, Jul 06, 2017, 7:22 AM UTC

nice_byte wrote: post #358

ohthehugemanate wrote: post #75

Earlier quoted context omitted.

Meritocracy is actually a very damaging thing, the way we tend to implement it in tech. Without concrete and public metrics of "merit", it becomes a buzzword for reinforcing the biases (conscious or not) of the evaluators. Particularly in tech, those biases tend to favor white, upper middle class, males. This kind of bias is demonstrated over and over in studies, even (and in some cases, especially) among people who…

> Without concrete and public metrics of "merit", But there are such metrics. For example: * "I implemented feature X, which increased CTR by Y% thus increasing revenue by Z" * "New compression scheme reduces bandwidth usage by this much, allowing team B to implement their new feature without worrying about badnwidth usage too much" * "Team C, who uses our library, needed urgent help investigating a performance issue…

A bug might be as simple as a single character fix on a printed string, or as complex as performance isn't as good as we expected, so profile and rewrite parts of the entire application to get acceptable performance. Both count as a single unit in your "bugs fixed" metric. Or do we have meetings to play poker and assign points for bugs?

Unless you're fixing tens of thousands of bugs I don't think you're going to have a good sample size to judge the output of 2 people based on just how many bugs they've closed.

This can also be gamed ie. pick up easier bugs to appear more productive, open bugs for small issues you notice yourself and fix, and this has the byproduct that real work never gets done.

Rewrites, infrastructure, code reviewers, mentoring. No earned dollars, no "features" shipped, good luck measuring "saved engineering hours".

There are no objective measures of productivity in the majority of cases for tech workers.

Re: Antisocial Coding: My Year at GitHub

#367

Post by Jare » Thu, Jul 06, 2017, 7:25 AM UTC

problems wrote: post #256

Jare wrote: post #237

Earlier quoted context omitted.

If the idea sounds great and is arguably great on all accounts, but in practice proves to not work, time and time again, perhaps the idea needs to be parked until the environment is fixed. Otherwise, arguing about it becomes a distraction while, in its corrupted form, the idea actively damages the things it should be improving. So you just say "don't do >" and, rather than expand and qualify the statement with a para…

> So you just say "don't do >" and, rather than expand and qualify the statement with a paragraph like the above, you just move on to the actual topic you want to focus on. That's a terrible plan because it blanket dismisses a rational and widely accepted idea without explaining why or even forcing you to think about it. How about you at least take the courtesy to explain why you're dismissing something that at face…

Ok so apparently my attempt to offer an alternative pov for people who I believed did not grasp the original, is getting me some downvotes. Let me just link to what she has said about meritocracy in the context of her Code of Conduct:

http://contributor-covenant.org/

"Marginalized people also suffer some of the unintended consequences of dogmatic insistence on meritocratic principles of governance. Studies have shown that organizational cultures that value meritocracy often result in greater inequality. People with "merit" are often excused for their bad behavior in public spaces based on the value of their technical contributions. Meritocracy also naively assumes a level playing field, in which everyone has access to the same resources, free time, and common life experiences to draw upon. These factors and more make contributing to open source a daunting prospect for many people, especially women and other underrepresented people. (For more critical analysis of meritocracy, refer to this entry on the Geek Feminism wiki.)

An easy way to begin addressing this problem is to be overt in our openness, welcoming all people to contribute, and pledging in return to value them as human beings and to foster an atmosphere of kindness, cooperation, and understanding."

AFAIK the word "merit" doesn't appear at all in the actual Code of Conduct.

Re: Antisocial Coding: My Year at GitHub

#368

Post by azinman2 » Thu, Jul 06, 2017, 7:32 AM UTC

TheLilHipster wrote: post #299

myko wrote: post #79

Earlier quoted context omitted.

Wow. That particular maintainer is really off the deep end - here is their writeup on the incident (which is pretty fucked up reading IMO): http://meh.schizofreni.co/random/lulz/2016/01/08/tales-from-...

Eh, it's only brass if you don't get "lulz" humor/culture.

The blog post only further confirms what a self-righteous jerk ‘meh’ is... it’s clearly not a joke but some strange mini-achievement in “freedom” and upsetting the “cucks” (meanwhile getting an F in human decency).

Re: Antisocial Coding: My Year at GitHub

#369

Post by mercutio2 » Thu, Jul 06, 2017, 7:32 AM UTC

bartread wrote: post #355

thehardsphere wrote: post #208

Earlier quoted context omitted.

That's addressed later by her boss: > I brought up the fact that we had been actively working on improving that over the past several months and that I had been tracking well against the goals we agreed to, but she said that the review period was only through January so that progress didn't count. So, the "tracking well" was in a 4 month span not in the review period. Here's another question: Why were weekly one-on-o…

This sort of bugged me as well. Why was the review done in April but the review period ended in January? Whilst the article is (as I've pointed out elsewhere) only one side of the story, GitHub isn't that big a company, so how crap do your management processes have to be that you only get around to reviewing somebody 3 months after the review period ended? It doesn't sound like the scheduling of the review was a surp…

Do you work at a big company? If you do, take a look at your last review, comparing when you received it to the period it technically applies to.

In my experience, both as a manager and an individual contributor, the periods will be offset by 2-4 months. The delivery of the review, while it feels like the start of something to the recipient, is the end of what's often a long and stressful period of planning, writing, and distributing reviews that lead to raises, bonuses, and promotions.

So nothing seems odd about that timeline to me, unless her manager failed to explain "this is a review that applies to the period before you made marked improvement".

Re: Antisocial Coding: My Year at GitHub

#370

Post by HelloNurse » Thu, Jul 06, 2017, 7:35 AM UTC

rjbwork wrote: post #84

mattbillenstein wrote: post #47

If you're ever put on a PIP, get out -- it's a sign someone in the company doesn't want you there. I've never heard of a PIP working out and both the company and employee being happy -- maybe you only hear about the bad cases, but a PIP often seems to me like a cover your ass plan on the part of the company. They want to get rid of a person, but they're afraid of getting sued, so a PIP is a way to document why a pers…

Guy on my team at my last company was - he was non-technical, but was in charge of looking at raw data and finding discrepancies and things we could write code to fix on an ongoing basis as he was a domain expert. He had a rough time with technical topics, and so part of his PIP, as I understand it, was to become basically proficient in using SQL to query, and understand the basics of RDBMS. He did so, and was remove…

This was a valuable employee that the company actually wanted to improve, which is unrelated to the PIP as excuse to fire people discussed here. There's a world of difference between a review that says "he's weak at technical tasks: inferior and unfit" and a review that says "he's weak at technical tasks, it would be nice if he learned to do them"