Support… Sometimes it can feel like a fruitless job on the team. After all, as this blogger points out, you are essentially the customer service representative for the team. Customer service employees, however, not only deal with the compliments, they also deal with the bitter complaints as well. For this reason, I think developing solid, bullet-proof code is one of the best ways to ensure your team members spend more time developing, and less time putting out fires.
Things that have made me a better developer
A support role can not only improve your customer service skills, but I think it can also make you a better developer. Here are a few things I’ve learned over from my time doing support work.
Data sucks… Deal with it
Assume that any and all data sucks. Bad data is probably the number one cause of an incident to happen in production. Make sure that your code can deal with it.
Any time you are using an element that is passed in, make sure you are careful when using that object. For example, if you are calling a getter on an object that was passed into the method, make sure you check to see if that object is null before you call the getter.
Also, you think you got a web service response that matches a list of enums you have. Nope. You don’t. At some point, the service is going to add an enum. Are you prepared for that?
Log your data
Log any state information you might have about the current running thread. I cannot emphasize this enough. If you are using log files, and for many you probably are, log your state information. Often times, I see somebody throwing an exception where they could just log some informational data.
For example, if a user is selecting a book from a list of books, that would be a good time to state:
[INFO] [2014-12-23 04:34:34] [<session id>] Book1 has been selected by user1234
Another good thing I like to implement is a session logging feature. If it is a web application, I use Servlet Filters to inject a session ID into log4j. Take a look at log4j’s MDC feature for how that can work. Once you do that, any log message will have our session id (see above).
Who cares if your code isn’t properly indented on a couple of lines? Right? Wrong. As a support person, I need to be able to read your code. If it’s unreadable, there’s a good chance I will not only get a headache, but that I will also miss something. Plus, in general, if you are sloppy about indentation, it just makes me wonder what other things in your code are sloppy as well.
Who cares if it’s not documented very well? Right? Wrong. Again, if you can’t document what your code does, then how are you writing it in the first place?
In conclusion, hopefully these things I have learned will help others improve there developer skills as much as they have helped me improve mine. In the brighter future, I see things like Akka and its Mailboxes feature being a great help for supporting applications, but I still feel like these few tiny bullet points will be important no matter what.