> Separating out the support process (to automation, to contractors, etc.) makes it easy to forget you’re not writing code to serve robots, you’re writing code to serve people.
On the other hand, support duty means you're regularly interacting with people who have problems with your product, and they will commonly be either in a bad mood (due to stuff not working) or just run-of-the-mill assholes (because that's the people who tend to complain). That doesn't necessarily endear them to you, especially when you're not high on socialisation in the first place.
usually when i complain, i am really polite and friendly (even when frustrated about the issue).. this way you usually get most done, and you'll get friendliness back :)
i encourage everyone to be like that.. when this does not help you can always 'scale up' your dissatisfaction in subsequent calls :)
I've found that having to support users has made me a better user myself, making sure that I provide sufficient context and information to aid in debugging, and always being polite and understanding that regardless of how frustrating a problem is, venting on the poor person trying to help you will never help (not that I was an asshole before).
I suppose that falls into the general "walk a mile in their shoes" wisdom.
Maybe. Who's at fault when the problem was inadequate resources to get the job done?
The front-line implementor grunts in engineering whose rushed code is directly at fault? Middle management who wanted to keep their jobs and so didn't bark back? Upper management under pressure who found out too late that they'd over-promised?
Distant, disconnected ownership focused on the bottom line? Consumers in price-driven marketplaces? Economic theorists designing stock markets which aggressively sever any sense of local responsibility and turn publicly held companies into uncaring machines? Whatever or whoever created this cruel hard world?
Who among all those needs to have their noses rubbed in it when end-users suffer?
There are always inadequate resources to get the job done. But if you take pride in your work and the finished product, then you owe it to yourself to talk to your end users directly, regardless of whether you're the front-line implementor, middle management or upper management.
You may be misreading this thread/my comment though. The person receiving the angry support call is indeed unlikely to the one at fault for the customer's issue. However, the post you were replying to was making the point that it's good for the people who actually build the product to experience what it's like to support that product's users.
On the other hand, support duty means you're regularly interacting with people who have problems with your product, and they will commonly be either in a bad mood (due to stuff not working) or just run-of-the-mill assholes (because that's the people who tend to complain). That doesn't necessarily endear them to you, especially when you're not high on socialisation in the first place.