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.
Welcome in Services team
ReplyDeleteCongratulations Robert!
ReplyDeleteVery cool! I admire developers that aren't afraid to leave their ivory towers and cocoons and see where the rubber meets the road.
ReplyDeleteYeah, I get similar results by following the PG user mailing lists. More developers ought to pay attention to lists like pgsql-novice.
ReplyDeleteBTW, as for your specific example: the reason a commented-out entry in postgresql.conf doesn't affect the backend's state is that it's just a comment, and the GUC code considers postgresql.conf to contain commands to change variable values (or not). However, we got enough complaints about that definition that it eventually got changed. I guess your associate is testing an old version.
We are delighted to have you as part of the services team. It is working out great for everybody.
ReplyDelete@Tom Lane: I think it's still broken in master.
ReplyDelete