I’ve now worked as a support developer for almost six months, albeit two days a week during the university semester. Now that I’ve really been able to sink my teeth into the work by working full-time after exams I thought it would be a good time to reflect on everything I’ve learnt so far. If you’re not a technical person, you may still find some applicable value in this post.
Technical skills
In terms of building a range of technical skills, it’s hard to beat working on a support team. You learn the whole application, front end, back end, database interaction, different platforms the application can be run on, different versions of the application and the unique bugs that exist in each of them. This is opposed to being a “pure” developer, where you are working with a particular technology and architecture but in greater depth. My command line skills have also drastically improved. Anything to do with restoring dependencies, fixing network errors, using debuggers, connecting to and querying databases, restoring corrupt databases, doing backups, using Amazon Web Services and the list goes on. You really don’t get that breadth of exposure when you’re working on a little silo of work as a “pure” developer.
Soft skills
The most useful soft-skill learnt is the ability to task-switch quickly and without making mistakes. On a support team your work on a minor bug fix is often interrupted by a priority one such as a major client’s application has crashed and they are unable to start it again. Naturally, you need to get straight onto the latter. Switching tasks like this means, you must switch your workspace to suit the task at hand, mistakes are easy to make and they mean time is wasted. It really comes down to attention to detail. You must completely focus on the current task. If part of your mind is still solving the previous problem you’re very like to blunder.
Another soft-skill you’re likely to improve upon as a support developer is writing instructions and being very clear and concise in writing. As a blogger, this is something I already knew the importance of. It’s a different kind of clarity required when explaining technical procedures to non or less technical people.
Starting at the bottom
A support developer is probably considered the bottom at most software companies. However, I think it’s crucial that every developer experiences what it’s like to work on a support team. It makes you a better developer. When you realise the frustration of sorting through someone else’s messy code to find a bug, you will be more inclined to write clean code. When you’re attempting to find the location of a bug but there are no unit tests, you’re now more likely to add unit tests to your own code. When provisioning services and repeating steps over and over, you realise how much time automation can save and so you strive to automate wherever you can.
Starting at the bottom is a necessary step in any career. Without being in the trenches, recognising what can go wrong in the trenches, then how are you ever to help those in the trenches, or better yet, get people out of the them?
Sure, I want to progress past being a support developer, but I’ve learnt to value breadth of knowledge more than I would have otherwise, and I’ll always be willing to make time for any member of a support team to talk about code I’ve written.
