I'm pleased to report that I have changed roles within EnterpriseDB and am now officially a member of EnterpriseDB's support and professional services team. I have a number of other responsibilities as well, so I will not be spending all of my time on support, but I have been and will continue to spend a significant chunk of time on it each day. When I've talked about this with people, they sometimes look at me as if I have two heads. After all, I am a backend server developer, and developers as a breed are not known for enjoying support.
But I have a bit of a different perspective on it. To some degree, I enjoy writing code for its own sake, but it has always seemed to me that the real purpose of writing code is to solve some problem. When you don't talk to the users, you don't find out how well the code you've already written solves their problems, or what you ought to work on next. And you don't find out about the bugs, or the rough edges.
A recent experience underscored this point for me. I mentioned to Namrata Rajnoor, who is part of our support team, that the time zone setting could be changed by editing postgresql.conf and issuing pg_ctl reload. Namrata disagreed, and proved she was right by actually testing it. Turns out, we have a bug. I haven't figured out all the details yet, but it appears that it works - at least most of the time - when changing between one explicit time zone setting and another - but it doesn't work so well if you remove the explicit setting from postgresql.conf and try to revert back to the default.
Of course, this is only a small example, and there are others, but it's the sort of thing that you tend not to find out about as a developer. You know how it works, but what you don't know is how it fails. Only when you really engage with the people who are using the product on a day-to-day basis do you start to find out where the bodies are buried - what actually works, and what doesn't, and which problems affect many people, and which affect only a few.