One of the quirks of being an enterprise software developer is that when your users find a problem with the product, they actually call your company support. Most of the time, the support resolves the issues on their own, but sometimes, especially for complicated ones, developers have to get on the call and see what’s going on.
Most of the CityView R&D team is on vacation for last couple of weeks, and I’ve been swamped with the requests from the support, implementation specialists and the project managers.
I have to say, getting on call with clients and to watch them use the software that you wrote can be a humbling and very enlightening experience. You get to watch your users struggle with the software you helped create. It is very painful to see them click a button, and see “Object reference not set to an instance of an object” error slapped onto their face, just because I didn’t check if a variable was null before I called a method on it.
Programmers who are two or three levels removed from the actual users of their code are unlikely to be aware of the context in which their work is used. They will not be able to make informed decisions.
Raymond Chen puts very elegantly in his 17-year old post, A day in the trenches,
Product support calls let you participate in the other end of the pipeline. The software is written, it’s out there, and now you have to pay for all your mistakes and bad designs when people call in with their problems. It’s software karma.
I think all developers should be made part of support calls, occasionally. It helps build empathy, when you are writing software. Not just for your customers, but for yourself, few months from now, facing a strange error, just because the current me didn’t write a clear message indicating what and where something went wrong.