I'll start by admitting I am not, and haven't really ever been, a full-time developer. I mostly worked in systems administration and infrastructure for small enough companies that regular helpdesk work was also very common, then I moved into technical support for technical folks. However, that said, I have written software that real people used in production. None of these were terribly complex systems - I wasn't designing any distributed systems or anything like that. But I've written a few user-facing services that allowed for things like vehicle pool inventory and maintenance tracking, new patient onboarding process and tracking, expense and accounting approval requests, a mass-mail UI, among some other small things.

As many of you are familiar, when writing software for users, one of the first things you do is gather requirements. "What problem are you trying to solve?" "What about this problem is hard, and how could it be easier?" Etc. You get a general idea, and you get to work designing and implementing what you think is the best solution.

The problem, though, is that this is a really awful game of telephone. Users (myself included) are bad at enumerating requirements. The real process of a given task is hard to distill into bullet points. There are a million little things that are impossible to remember in the abstract. It's also often difficult to really outline how a process or procedure works to precise enough a degree, which means translating that into a functional program from those early conversations is next to impossible.

I found, time and again, that the only way to make software that /truly/ solves problems is to sit with a user for a while and understand their needs and how they approach the software you've made. I learned this first-hand with my own software projects which evolved from stilted and stiff literal translations of requirements into more natural and comfortable tools that enhance someone's work, not dictate it. I've also learned this by working on countless support cases alongside caring and empathetic developers.

As a developer, doing support allows you to really see where the proverbial rubber meets the proverbial road. In fact, to a very large degree, it's the closest to genchi genbutsu you're likely to get. Let's face it - as the developer of a technology, most of the time you probably aren't also a user of that technology. If you are creating a medical records system, or a database, or an API gateway, odds are you aren't actually using those yourself day-to-day. (There are exceptions to this, of course. Sometimes developers are also the users! That's often the case for single-contributor open source utilities and similar, but it becomes less true the larger the project becomes, and it's especially true when the product is commercial).  So the next best thing you can do is get in close, from time to time, with the folks who do use your software every day. See the way it comes together; feel the pain points.

First-hand exposure to usage patterns allows for invaluable perspective and context, which makes you a better developer, the code you produce more thoughtful, and when it's a cultural part of your organization, it leads to the development of features and behaviors and interface points that are more intuitive and more delightful to use.

"But," you might say, "we already have a support team, who can relay this information back to us." Yes! That's true! And hopefully, your support team /is/ bringing you pain points and feedback from users and common issues that crop up. These are all great, and as long as the lanes of communication are open, that helps a lot too. But your support engineers are also missing some context. They aren't the ones who are writing this code or thinking about a new feature, or a refactor of some bit of syntax. So they may not know exactly what to bring to you, or they may not be able to connect all the same dots you, as a developer (see also: product manager) can, just because we all have different bits of information. First-hand experience in the support world lets you, as the developer, bridge those gaps.

If your organization doesn't have a program for this, just ask! I can pretty much guarantee that any good support organization out there would jump at the chance to let you sit in and help out. And any engineering manager should also encourage the opportunity for you to gain some broader perspective and skill-up on one of the least-applauded subjects in development: user empathy.