Absolutely agreed. In a previous job, I was hired as a developer for a small company and also took most of the service/support calls. It gives a huge amount o

Absolutely agreed. In a previous job, I was hired as a developer for a small company and also took most of the service/support calls. It gives a huge amount of insight into how people use the software/hardware, where they get stuck most frequently and also where any bugs lie. We made most of the changes to the software as a direct result of customer feedback, targetted to the areas which generated the most calls because they caused the most problems for the user. Simple usability/workflow improvements significantly reduced the call volume and made the customers much happier with the software. It also meant that in cases where bugs were found, we could triage them directly on the call or shortly after and in many cases have a tested software update for them during the same working day. When someone runs their business with your product, they greatly appreciate the effort you make to keep their business running smoothly. I learned a lot about our customers' businesses by talking to them, even visted a few in person, and that all helped to make our software serve them better. I had a few surprised callers when they realised that the tech support and the developers were one and the same; they often expected the tech support to be stupid/less well informed/script-following automatons, and were surprised when we could help them in great detail. Very few of them expected that suggestions for improvement would actually be acted upon, let alone implemented and delivered within a short timeframe. In a small company, with customer numbers in the small hundreds, this led to direct personal working relationships between the end users/customers and the developers, which I found very satisfying. Were we shielded from the customers by first-line support etc., we would have missed out on a lot of very valuable information. Of course, it's difficult to scale this approach, but I do think developers should be well exposed to end users' problems, needs and specific business/domain expertise in whatever type of organisation they are part of, rather than being isolated and disconnected. This is not in any way "insulting" to your team as the original article tries to justify; it's giving your team knowledge and understanding which they would otherwise not have, and getting them directly involved with the use of the software as well as its creation and maintenance.