Depends on the record you're looking at. If you look at the temperature records from ice cores you can see that the entire 21st century has so far been within the historical range at this point in the cycle.
However the 21st century has been an outlier in that temperatures have suddenly (for some reason :) failed to correlate with the amount of CO2 in the atmosphere.
It's funny whenever I hear someone say "We only hire people who went to X" I always just assume that person is insecure about their own abilities. Hiring based on credentials doesn't require you to be good at the job yourself.
Want cognitively diverse teams? It’s not as simple as hiring more female technologists.
I'm sorry, is the author implying that men and women approach engineering problems differently (i.e. they think differently)? Is there any evidence of this? I thought "essentialism" was anathema in contemporary diversity circles.
Eighty percent of Etsy customers are female, but the company itself used to be known in startup circles as engineer-centric and something of a dude-fest
So the fact that eighty percent of Etsy users were women despite having an all-male engineering team apparently means that you have to hire more women engineers to attract female users? Again I'd love to see evidence that once a core of female engineers were hired significant changes where made to the site that could only have come from a "woman's intuition" (natch). It seems to me that having a female dominated user base in spite of an all male engineering team disproves the assertion that you need hire women to achieve "cognitive diversity".
This is all suggesting that developers have a say in product design. I assume developers at Etsy do...
In that case, I find developers and product managers (including myself) are sometimes way too bias to give valuable feedback to product decisions. On the other hand, the big advantage I could see would be if the developers are constantly having conversations with their friends about the usability and design of the site. In this case, I could see an advantage.
I'm sorry, is the author implying that men and
women approach engineering problems differently
(i.e. they think differently)? Is there any evidence
of this?
I don't think it's controversial to believe that one's best chance at achieving "cognitive diversity" comes from having a variety of genders/backgrounds/ages/etc/whatever on your team.
That's not incompatible with rejecting the belief that one gender/race/whatever is "better" at something.
I would think it's controversial when applied to engineering. This implies that the basic tools of software development are somehow viewed/used differently by people of various genders/ethnicities/etc... solely because of this "diversity" which I think most people would disagree with. And if one were to argue that being asian/female/poor somehow effects how you develop software I would love to know how those differences manifest in day-to-day software development.
It's not really a question of believing one gender/etc... is better at something here it seems to be a question of not believing it as the author seems to think "cognitive diversity" can be achieved simply by adding women to your dev team.
While 2+2 will remain 4 under every gender, race and social status, it is important to realize that there are insights that aren't taught out of a textbook. If all you are doing is building objective software with the basic tools of software development, you are no better than a code monkey.
Etsy needed women because their customers were women. They needed engineers that would help them understand or uncover the point of views of their customers. At the end of the day you are serving people, not machines, and it makes more sense to optimize for the needs of customer, instead of assuming every programmer with git experience make a good engineer for Etsy.
I would think it's controversial when applied to
engineering. This implies that the basic tools of
software development are somehow viewed/used
differently by people of various genders/ethnicities/etc
We're probably operating with different definitions of "software engineering."
I understand software engineering to encompass much more than just using "the basic tools of software development." Within that scope, you're definitely right: I don't think one gender can use Eclipse (or vim, or whatever) better.
I'm thinking of a broader definition of software engineering that involves understanding problems and choosing from many viable solutions, each with their own trade-offs in terms of implementation difficulty and end-user experience. There are a lot of people who feel that process, and our industry as a whole, would benefit from having a greater variety of perspectives.
the author seems to think "cognitive diversity" can be achieved
simply by adding women to your dev team.
Unfortunately, when approaching an issue like this you cannot do so without adopting a sexist viewpoint yourself. To begin to analyze workers in terms of sex or gender to begin with, itself is sexist, the same way that affirmative action is racist.
It's fine and good that companies want to hire more female engineers. But this article is lame, which you should have picked up on when the author used the word "rockstar"
I hate being referred to as a rockstar developer as a male. I couldn't agree more. I want more engineers, not tokens. If I can work with competent people, I am happy. Even if it's an all male or all female workplace.
Sexism/racism et al. can exist outside of institutions no?
"Hate crimes" for instance clearly do not involve
any recognizable institutions yet clearly involve an -ism of some kind. Nor do -isms only exist at the society level. For instance it would be possible for a female owned company to not hire men (female hiring bias/sexism) which would run counter to larger societal biases.
> "Hate crimes" for instance clearly do not involve any recognizable institutions yet clearly involve an -ism of some kind.
Only in the sense that they 'reproduce' the broader -ism. The individual act is one of discrimination, the sum of all acts collectively is an *-ism.
> For instance it would be possible for a female owned company to not hire men (female hiring bias/sexism) which would run counter to larger societal biases.
Studies and discussion on this topic are scoped specifically at the societal level for a reason.
> I thought "essentialism" was anathema in contemporary diversity circles.
You are absolutely right that essentialism is not generally accepted any more, but you're mistaking essentialism a bit. Essentialism is not 'women do things differently than men,' essentialism is 'Women are x.'
As an example, certain feminists don't believe that trans women are women, because they are not born with sexual organs that are the essence of 'woman.'
In contrast, population thinking would assert some number of a portion of a population has some trait, but it's not required, or 'essential.' Saying that 'many women have vaginas' is not an essentialist statement, it's a population-ist one.
Therefore, "many women approach problems differently than many men" is not essentialst. "All women _must_ approach problems differently than men" is essentialist.
But the author is stating that "woman are x" by stating they bring more "cognitive diversity" to a team. In order for this to be true, woman in fact "must" approach problems differently than men or there would be no diversity benefit (whatever that may be in this case).
If it's not a rigorous philosophical work, people will not be very precise with their qualifiers.
For example, in the previous sentence, I said 'people' and not 'most people.' Especially in the social sciences, people assume you're discussing populations, and words like 'most' impede clarity more than aid it.
That said, I don't know the author, and they may be a gender essentialist; they do still exist.
Great, another guilt ridden diatribe against John Scalzi from John Scalzi. I've never read someone who is more obsessed about being a "privileged white male" than he is. I wish he would take his own advice or at least the first part of it. I'm not going bother arguing with him because really what's the point, this self-flagellation obviously gets him off and as usual it's all about him. Is "self-hating narcissist" a thing?
Self-flagellation? I went back to make sure I didn't miss anything but it looks like a post about understanding your privilege and how your success relates to it. It's a post about understanding the depth of experience that other people live with, experiences he has not had because of that privilege.
It seems that a trend is developing of labeling earnest introspection as "self-flagellation." See my comment at https://news.ycombinator.com/item?id=5375270 for an identical situation on a different subject. I don't want to make assumptions, but are people really that hostile to the idea of openly questioning oneself?
(I'm speaking specifically of the HN community, obviously the answer for the general public is a resounding "yes")
Acknowledging that you were born with certain advantages, and that said advantages make you blind to the difficulties that people who are not like you face, is a weird thing to call "self-flagellation". Or narcissism for that matter. Like it is literally the opposite of narcissism.
I forget which awesome person said it, but the correct response to realizing you have privilege is not to feel guilty or self-hating. It's to feel responsible. You've been given immense advantages; you should use them to help others who have been less fortunate. So no, I doubt John Scalzi hates himself very much.
There's nothing self-flagellating about Scalzi's post. And I say this as somebody who is not particularly fond of the language of privilege. But also, if you've never read anyone more obsessed with privilege than Scalzi, you've managed to live in a pretty politics-free bubble.
I went from hg -> git in the last couple of years. I'd say they are "almost identical". The key difference is a slightly different mindset on merging and branching IMHO. It can be non-trivial for some of my more hard headed dev brethren to change their way of thinking once they've chosen a method and gotten in the correct mindset.
I went from using mercurial to git and I still have lots of respect for mercurial. I wouldn't mind the switch at all if I needed to work with a team who used mercurial, but personally I still just prefer git.
Yup, that's me in a nutshell. I used svk first and then moved on to mercurial.
Then I had to learn git. I like the model for lightweight branches in git (bookmarks in mercurial) but the step backwards in UI is still irritating. I'm used to it at this point but teaching it to others is a constant source of pain ("git checkout -t/-b"!)
Ugh, no, I fought my way through git first, and I didn't think hg was the same when I encountered it, I thought hg was nigh-unusable after I thrashed at it for a week.
I work for an agency that often picks up work from large agencies or in-house teams and most of the time I find myself using either Subversion or Mercurial. We use Mercurial for our own projects, but one client uses Git, which I use at home and prefer it to Mercurial.
It's a situation I imagine a lot of development agencies find themselves in.
The last company I worked at had a least a half dozen different dev teams working on more or less unrelated projects, all doing their own thing. While each team all used the same tools internally, the different teams used different tools and each team handled its own vcs hosting. I can imagine a company like that might want to get everybody on the same page, without forcing one team to give up their favorite tool.
I'm not aware of any, but I suppose this means you can use your preferred tools even if the rest of your team disagrees.
For my home projects, I used Mercurial for a year since I preferred its command-line tools to Git. When workable GUI tools for Git appeared (starting with Github for Windows), I migrated to Git.
Also, a small bravo to Fogcreek for using a screen grab from Windows. Windows is so uncool that we need some Windows screen shot affirmative action.
Agreed about the horrible tools. Unfortunately, this is an extremely difficult market to break into. Most academics want free and open source tools and don't care how many research assistants or post-docs they have to torture to use them. Compounding the problem is that the market is so small any commercial product is going to have to be very expensive (>$1000.00) to make it worth while re: development and support costs. For instance something like BrainVoyager (http://www.brainvoyager.com/) which is a commercial competitor the tools you listed starts at $4,000 which is a pretty good chunk of any equipment budget on a grant.
Closed-source tools are also problematic for research purposes, since at some point in your career you will almost certainly want to run an analysis that they can't perform.
BrainVoyager's approaches are from the ice age and not flexible enough to handle modern protocols. Only a moron could defend using it for research. It's tranlational at best (a toy you give those clinicians that can't even figure out SPM). But it does make pretty pictures.
I'm a clinician and it admittedly took me ages to figure out SPM. I still hate it, and think it is terrible to work with but useful. The state of the software is actively hampering contributions from clinicians. The problem is, as you have pointed out, that if BrainVoyager is the alternative, that's no alternative at all.
