[devonkim]

The issues I have are that developers tend to be bad at communicating even with each other. Communication as a discipline is a lot about meeting people where they are and this is difficult for basically everyone. The antagonistic attitude that developers seem to develop happen across almost every technical discipline whether it’s engineering or even trades. It may be even worse in trades given so much contact with the general public. If developers had to do customer support for their products as a rule you bet they’d get grumpy. However, I’d also say that interacting with the public probably makes most people in US retail grumpy, too.

What I think I’m trying to say is that developers self-selecting out of things thinking they’re either not good at them or because they don’t like to do them is a bit of a luxury compared to most professions and many on the outside would look at that and feel there’s an attitude of arrogance and entitlement as such.

[frenchman99]

> If developers had to do customer support for their products as a rule you bet they’d get grumpy.

Do you have data to support this?

I would love to do customer support from time to time to better understand the users of the product I work on as a developer. But that request has been denied to me many times, in multiple jobs.

To get people to communicate better, inspire them to do so and have faith in them.

[devonkim]

The data I’m seeing is from studies showing that developers doing peripheral duties and getting interrupted is one of the biggest barriers to productivity and quality among developers rather than training, education, or even raw IQ.

Specialization of roles along with the political realities of corporations means that fiefdoms and exclusions will happen to though.

[frenchman99]

It is perfectly possible to do customer support on a specific schedule so that it doesn't become an interruption though.

[devonkim]

Of course it's possible but the usual workflow of those in customer facing positions tends to be interrupt-driven rather than polled like how developers tend to prefer to work (and there is definitely plenty of study on context-switching productivity loss, stress, etc.). Additionally, the amount of time available for developers to work with customers must be balanced with duties like feature delivery among others. Working across n different customers with m different needs even if time boxed to n hours / week you'll be likely left with customers that feel frustrated and that developers are disengaged when they're just overworked like everyone else.