3 ms·

> based on nonexistent science and personal feelings But his memo had extensive sourcing, including many scientific studies. Are you saying that those studies

by Sacho 9y ago

> based on nonexistent science and personal feelings But his memo had extensive sourcing, including many scientific studies. Are you saying that those studies are nonsense? > It is not "political correctness" that gets someone fired for failing to test a change before deploying it in production and breaking the site; it is a lack of critical thinking skills. This is opposite the blameless culture laid out as best practices by the leaders in tech, so I don't know why you would assert it as a good reason to fire someone. I too, like you, think words matter and think we should be able to take people's beliefs into account when choosing to associate with them. I'd like to note that our opinion is pretty controversial - it's actually illegal to do this for several wide ranges of people's beliefs, when it comes to employment! So perhaps there is a middle ground between "words don't matter" and "we must support all opinions", and in watering down the argument to these two simplistic extremes we're ignoring the complex reality evident before us.

geofft 9y ago
> But his memo had extensive sourcing, including many scientific studies. Are you saying that those studies are nonsense? "Extensive" seems like a stretch. Here are the scientific (i.e., non-Wikipedia, non-media) citations: - women are more interested in people than things (DOI 10.1111/j.1751-9004.2010.00320.x) - women score on average .4 sigma higher on "neuroticism" than men (DOI 10.1037/0022-3514.94.1.168) - the average woman is more interested in work-life balance than the average man (DOI 0.1080/03069880600769118) - moralizing issues is sometimes bad (DOI 10.1111/1467-9280.00139) - the concept of "microaggressions" lacks scientific backing (DOI 10.1177/1745691616659391) Of those, only the last one is directly relevant to his policy proposals. (And it seems to be one researcher's position paper, anyway, but I'm happy to grant for the moment that it holds the weight of scientific consensus.) The rest are all interesting scientific facts but the connection to his policy proposals is incredibly unclear. I said it's based on personal feelings because the idea that software engineering involves caring about things more than people, that neuroticism (in the psychological sense) makes one less suited for software engineering, and that advancement in tech requires giving up work-life balance. As many others have argued (e.g., https://medium.com/@yonatanzunger/so-about-this-googlers-manifesto-1e3773ed1788 https://medium.com/@yonatanzunger/so-about-this-googlers-man... ), these are opinions of an extremely junior engineer who has confused "software engineering" with "writing lines of code". If we're going to take the logic in this article seriously, we should much more readily take seriously 'aphyr's (absurdist) suggestion that men perform better on technical tasks in societies where they're not allowed to own property: https://twitter.com/aphyr/status/894211417561341952 https://twitter.com/aphyr/status/894211417561341952 That one has a solid scientific citation and direct relevance to the policy proposal it's making! > This is opposite the blameless culture laid out as best practices by the leaders in tech The blameless postmortem relies on the fact that you trust everyone to be making the best decisions they can under the circumstances and you trust them all to be well-informed and qualified, and that sometimes mistakes happen anyway and the identity of the person who makes it is basically chance. Take GitLab's recent incident: if a company's practices don't involve testing backups, and someone is responding to an urgent production problem and deletes the wrong directory, it's not a sign that the person who got paged is particularly incompetent. There is incompetence, but it's a property of the entire team: backups should exist and be tested, runbooks should be clearer, production hosts should be more visible, etc. But as a consequence, in order for the blameless postmortem to work, you have to actually trust your engineers to be competent. A person who writes a manifesto like this is also the sort of person who's going to read a half-complete answer on StackOverflow that offers a simplistic but enticing explanation, and conclude that it is 100% relevant to their problem despite evidence to the contrary, questioning relevant internal docs along the way. Someone who does that isn't someone you want responding to production incidents. You don't want to blame them - because you don't want to risk them causing problems in the first place. Such a person is a mishire. The fact that certain people are rejected in the interview process (including false negatives!) does not violate the blameless culture. Once you conclude that someone was a false positive hire, you should promptly let them go with a generous severance.
- toomuchtodo 9y ago
  > Such a person is a mishire. The fact that certain people are rejected in the interview process (including false negatives!) does not violate the blameless culture. Once you conclude that someone was a false positive hire, you should promptly let them go with a generous severance. You might just have a terrible organization or managers with no or poor experience. ¯\_(ツ)_/¯
  - geofft 9y ago
    Let's be clear, I'm not advocating for the rejection of promising junior candidates with the intellectual curiosity to learn how to do things. I think more companies need to hire such people, and I've strongly advocated for hiring them at my jobs (with mixed results). But that doesn't imply that an organization or manager's job is to teach everyone everything. There exist non-junior roles, and very often there are people who are mishires for a senior role but great hires for a junior one, or mishires for a certain company but great hires for another one, etc. Sometimes what you're looking for is a senior engineer, and saying "This person isn't senior, they're not right for this role" isn't a failing of management or of the organization. Damore was a senior engineer (L5) at Google, which is definitely not a junior role (it's the first level where they don't expect you to be getting promoted within 1-2 years, IIRC). (Let's also be clear, everything I've said about dealing with mishires promptly also applies to mishires in management or mis-promotions into management. There are a lot of people in management who have no business there, and should get either a promotion to a highly-ranked IC role or a generous severance so they can find one elsewhere, before they do more harm to their team.)

by Sacho 9y ago

geofft 9y ago

> But his memo had extensive sourcing, including many scientific studies. Are you saying that those studies are nonsense? "Extensive" seems like a stretch. Here are the scientific (i.e., non-Wikipedia, non-media) citations: - women are more interested in people than things (DOI 10.1111/j.1751-9004.2010.00320.x) - women score on average .4 sigma higher on "neuroticism" than men (DOI 10.1037/0022-3514.94.1.168) - the average woman is more interested in work-life balance than the average man (DOI 0.1080/03069880600769118) - moralizing issues is sometimes bad (DOI 10.1111/1467-9280.00139) - the concept of "microaggressions" lacks scientific backing (DOI 10.1177/1745691616659391) Of those, only the last one is directly relevant to his policy proposals. (And it seems to be one researcher's position paper, anyway, but I'm happy to grant for the moment that it holds the weight of scientific consensus.) The rest are all interesting scientific facts but the connection to his policy proposals is incredibly unclear. I said it's based on personal feelings because the idea that software engineering involves caring about things more than people, that neuroticism (in the psychological sense) makes one less suited for software engineering, and that advancement in tech requires giving up work-life balance. As many others have argued (e.g., https://medium.com/@yonatanzunger/so-about-this-googlers-manifesto-1e3773ed1788 https://medium.com/@yonatanzunger/so-about-this-googlers-man... ), these are opinions of an extremely junior engineer who has confused "software engineering" with "writing lines of code". If we're going to take the logic in this article seriously, we should much more readily take seriously 'aphyr's (absurdist) suggestion that men perform better on technical tasks in societies where they're not allowed to own property: https://twitter.com/aphyr/status/894211417561341952 https://twitter.com/aphyr/status/894211417561341952 That one has a solid scientific citation and direct relevance to the policy proposal it's making! > This is opposite the blameless culture laid out as best practices by the leaders in tech The blameless postmortem relies on the fact that you trust everyone to be making the best decisions they can under the circumstances and you trust them all to be well-informed and qualified, and that sometimes mistakes happen anyway and the identity of the person who makes it is basically chance. Take GitLab's recent incident: if a company's practices don't involve testing backups, and someone is responding to an urgent production problem and deletes the wrong directory, it's not a sign that the person who got paged is particularly incompetent. There is incompetence, but it's a property of the entire team: backups should exist and be tested, runbooks should be clearer, production hosts should be more visible, etc. But as a consequence, in order for the blameless postmortem to work, you have to actually trust your engineers to be competent. A person who writes a manifesto like this is also the sort of person who's going to read a half-complete answer on StackOverflow that offers a simplistic but enticing explanation, and conclude that it is 100% relevant to their problem despite evidence to the contrary, questioning relevant internal docs along the way. Someone who does that isn't someone you want responding to production incidents. You don't want to blame them - because you don't want to risk them causing problems in the first place. Such a person is a mishire. The fact that certain people are rejected in the interview process (including false negatives!) does not violate the blameless culture. Once you conclude that someone was a false positive hire, you should promptly let them go with a generous severance.

toomuchtodo 9y ago
> Such a person is a mishire. The fact that certain people are rejected in the interview process (including false negatives!) does not violate the blameless culture. Once you conclude that someone was a false positive hire, you should promptly let them go with a generous severance. You might just have a terrible organization or managers with no or poor experience. ¯\_(ツ)_/¯
- geofft 9y ago
  Let's be clear, I'm not advocating for the rejection of promising junior candidates with the intellectual curiosity to learn how to do things. I think more companies need to hire such people, and I've strongly advocated for hiring them at my jobs (with mixed results). But that doesn't imply that an organization or manager's job is to teach everyone everything. There exist non-junior roles, and very often there are people who are mishires for a senior role but great hires for a junior one, or mishires for a certain company but great hires for another one, etc. Sometimes what you're looking for is a senior engineer, and saying "This person isn't senior, they're not right for this role" isn't a failing of management or of the organization. Damore was a senior engineer (L5) at Google, which is definitely not a junior role (it's the first level where they don't expect you to be getting promoted within 1-2 years, IIRC). (Let's also be clear, everything I've said about dealing with mishires promptly also applies to mishires in management or mis-promotions into management. There are a lot of people in management who have no business there, and should get either a promotion to a highly-ranked IC role or a generous severance so they can find one elsewhere, before they do more harm to their team.)