Hacker News new | ask | show | jobs
by golemotron 3151 days ago
> One of the easiest ways to gauge social sensitivity is to show someone photos of people’s eyes and ask him or her to describe what the people are thinking or feeling — an exam known as the Reading the Mind in the Eyes test. People on the more successful teams in Woolley’s experiment scored above average on the Reading the Mind in the Eyes test.

What isn't mentioned is that the 'Mind in the Eyes' test is used to assess autism and spectrum conditions.

If that kind of empathy is necessary for good teamwork then the neuro-diverse are at a disadvantage in that type of work and systematically excluded from companies that do all of their work in teams. Companies that take this seriously could assess where teamwork is important - and where it isn't - and hire appropriately.

1 comments

Where do you think teamwork is not important? Such circumstances are vanishingly rare at best, mostly debatable, and will get rarer as humanity's ambition increasingly exceeds the capabilities of individuals. Meanwhile, having the ability to work with others will always be better than not.
Writing novels has always been a primarily-solo activity. I don't see demand for those dropping off drastically.

The guy who re-plumbled my house was working there alone pretty much all the time. That seems to be a common way of working in many trades, and plumbers don't seem desperate for work.

A fair number of bits of heavily-used software started out as one person's project (many of the successful ones do eventually morph into community projects, but titles like "benevolant dictator for life" show that community doesn't necessarily mean a flat "team" setup). Lots of programming languages fall in this category. Sublime Text. Indy games (and, not so very long ago, the majority of games). Building software as a solo endeavour does seem to be somewhat out of fashion right now, but that doesn't necessarily mean it can't work.

So it's okay to discriminate against people with disabilities?

There are many areas where individual work shines. Legal research, accounting, auto repair. I think the same is true in software.

What's your definition of teamwork? If it is that in order to complete a large task (e.g. building an iPhone) that it is beneficial to work together with others, it's obvious, because even the best engineer in the world doesn't live long enough to fix everything currently.

If however you are saying that there exist many tasks for which you actually work together to come up for a solution for a known problem, I doubt that.

Case in point: Perelman.

To make it more concrete: if one is using cloud services, is one working together with that could service people? Is that teamwork? I don't think so. Yet, it is cooperation.

In jobs where you need to hold a heavy object in place such that someone else can put a nail somewhere is only teamwork, because of technological limitations. Robots that can do this already exist, but they are too expensive. As such, I also don't count those classes of work as teamwork.

Taking the above into consideration, what remains of your "teamwork"?

Perhaps "teamwork" is not the best term, if it invites such a narrow interpretation. But even for mere "cooperation" as you put it, empathy is needed. In your cloud service example, if a client ever needs tech support, at least the support person is trying to read the client's mind, or they're not doing their job. Even in the case of holding up heavy objects, don't underestimate the value of sensitivity to the other person's needs; I've been on both sides of screwups in that area.

GP asked about hiring at companies, so solo projects are either not germane, or an illusion. Are you the only dev on a project that serves larger business goals? You're on a team! You need to understand how your work fits in with others' efforts, and either adjust or explain how others should adjust instead, most likely both. Oh, and don't forget to document everything, another empathy-heavy task. I think we all know this; it's just another way of discovering the meme that devs who understand the business go farther.

Part of the point I was trying to make is that those "large projects" you were talking about are going to become more common and more important, out-competing smaller teams that are almost by definition less capable in terms of feature output. If a solo dev outcompetes a team, it's because they were better at empathizing with customers. If that's not exactly teamwork, it doesn't avoid the problem, either.