Lurking on the internet forums related to software engineering, you will often find people asking questions like:
- Is getting accepting a support role bad for your career?
- How do I get out of a support job?
- Is technical support experience valuable?
I found myself asking these same questions some years ago when I unwittingly accepted an offer that turned out to be a support engineer role. I was inexperienced and eager to land a job so I never thought about clarifying what the exact responsibilities of the role are going to be. When I turned up to the new job on day one I was mildly frustrated to find out I was to be part of a support team. It became only more unpleasant that I had to work non-traditional hours, starting my day in the afternoon and ending it in the late evening which meant I would reach home after midnight. Setting aside the logistical challenges I am going to talk about what observations I have made working in support and how has it impacted me in a positive way.
Talking with customers and building a feedback loop.
Support tickets are a good indicator of how good a software application has been delivered to the intended customers. In some sense, they form an open channel for generating feedback. As they usually say, where there is a problem there is an opportunity, it becomes really critical for the success of a project to be constantly listening to what the customers are saying. The concept of MVP and agile methodologies have come into prominence because of this very need. The key to innovating at any software company is keeping the feedback loop as small as possible, so as to keep iterating on the product.
Traditional support teams are not seen as part of the agile/scrum team. Support usually falls outside the purview of product development, but many companies like Stripe, Zapier, Basecamp, etc have become aware of the advantage of having support bridge the feedback loop.
Even though your company may just be treating support as a tactical solution to keep the lights on, you can still learn a lot by finding patterns in the tickets being raised or talking with customers to understand underlying problems with requirements or design. Proactively making a plan to reduce support tickets at your workplace is a very desirable skill to have. Working in support allows you gain such useful skills making you a more rounded software engineer.
Cross skilling and becoming a valuable player.
Drawing on the above theme of "challenges equal opportunities" and the fact that you might have to be creative dealing with certain kinds of support tickets, you can make a case for gaining experience with skills outside what you would normally practice in a traditional development team.
As a backend engineer, there are numerous opportunities to explore the DevOps and Software Architecture aspects of software applications. I would assume there are similar opportunities for frontend engineers in improvising design changes (I have rarely heard of designers being part of support teams, although I strongly believe they should but that's a topic for another day.)
In my own experience I had to
- install SSL certificates
- upgrade the OS on AWS ec2 instances
- migrate large amounts of data to new database
- tweak deployment strategies
- solve a bug in legacy C codebase
Each of the above have made me learn something new that I did not know before.
What is the ideal balance?
As I write this blog post I have managed to articulate some of my feelings about working in support. There is definitely an upside to being in support. And there are obvious downsides. You must be already thinking, why do teams have to exclusively do support or development but not both. As it turns out some engineering teams do aim to own both aspects of building and maintaining a software project.
But managing both support and development can get out of hand if not proactively managed. Most developers love to be in a state of flow which can be hard to achieve if you need to react to support tickets. Triaging support tickets becomes a crucial part of the process so the developers do not have to context switch for longer periods of time.
What helped me attain a maintainer mindset?
It is somewhat ironic I felt, that the thing that helped me most while working as a support engineer is the experience I had working in greenfield development. The better developers automatically tend to be excellent support engineers. Skills like being able to navigate legacy codebases from day one, being good at debugging techniques, knowledge of cloud providers, and their logging mechanisms, become crucial parts of a support engineer's toolset.
On the other hand, having the experience of support team enhanced my development skills even more. I began channeling the real world issues I resolved into how I developed new features. I was greatly interested in finding out how the software I developed behaved in the real world and whether my assumptions were correct. I paid more attention to the technologies I chose to work and how they would evolve in future. In short I was thinking about the future maintainer who would inherit my codebase.
I would like to end with a quote from an article on Aeon, titled Hail the Maintainers which, I feel, encapsulates the essence of maintainer's mindset.
Innovation is a dominant ideology of our era, embraced in America by Silicon Valley, Wall Street, and the Washington DC political elite. As the pursuit of innovation has inspired technologists and capitalists, it has also provoked critics who suspect that the peddlers of innovation radically overvalue innovation. What happens after innovation, they argue, is more important. Maintenance and repair, the building of infrastructures, the mundane labour that goes into sustaining functioning and efficient infrastructures, simply has more impact on people’s daily lives than the vast majority of technological innovations.
Thanks for reading!
If you liked this one, you can check out my related blog posts: