The role of the Application Support Engineer is to react fast on any problems that happen in the production environment and to come up with quick solution or workaround. Whether it be sudden drop in performance of the application due to boxes dropping from the load balancer, displaying corrupt data on the web page because third party had sent incorrect data or just a single customer had troubles with one of the features, etc. The app support should be the first one at the crime scene, to analyze what has happened, collect all the evidence, clean up the mess and provide the developers with all the information from the investigation. From business point of view, this role makes sense if the service needs to be online 24/7 and availability is crucial. For example, betting websites – there are games played all around the world at different time and you want to offer them to your customers in order to be attractive. So you want someone to babysit the website at all time, making sure the customers have the best experience possible. Meanwhile, there is also a protective shield around the developers so they can focus on their work without many disruptions, improving delivery times.
After 2 years as an Application Support, here is my personal experience of the role. At first it was good as I was getting familiar with the system, the technology, the business logic, etc. The job was interesting and challenging enough, analyzing, investigating and trying to find the loophole/problem. At the same time, trying to keep up with the new features and technologies the developers were coming up with. But as time passed, it started to get more and more irritating and annoying. I was getting the same tickets, over and over, again and again, same questions, same issues. Imagine going on a round-the-world trip with five children in a car and each of them asking you “Are we there yet?” every 30 mins. The challenge wasn’t there any more, only the repetitive, mechanical work was left. It actually became painful, I could actually feel brain cells dying in my head. Therefore, I decided to push myself for a developer role. If you are reading this and you are thinking like me back then, here are some tips and steps how I managed to pull it off.
- Improve your domain knowledge – make sure you know the end to end system flow. I find this very important even if you are not trying to become a developer. You must know what you are supporting after all. Is it one big monolithic application or is it a micro-service architecture? How do the different modules communicate between each other – HTTP or JMS? Where is the data on the website coming from – internal service or 3rd party? Knowing this greatly improves your communication and collaboration with the developers. It helps you by making them see that you are a technical person, thus you become trustworthy and reliable. Don’ be surprised if they start asking you for help with understanding business requirements. Since you live in both worlds – IT and “real life”, you can become quite the asset as you are the missing link between them. Once you get recognized as someone who is being helpful rather than a “troll” who is just wasting their time with meaningless tickets and tasks, then they will be more open to help you as well. And that help you will need!!!
- Implement solution for a constantly reoccurring problem – try to automate a process that you are asked to do manually one too many times. For example, BA is asking you to extract data from DB every week/day that he uses to create reports on customer activity. Perfect opportunity for you to create your own software. And it’s fairly simple, you need a UI that will allow the user to filter by different dimensions then connect to the DB, query it and return the results to the user, possibly allow him to export it to Excell sheet. First, this will reduce your work load and you get rid off unnecessary noise and an irritating task. Second, the BA will appreciate it because he won’t depend on you anymore to do his job and it saves time for both of you. The biggest benefit for you though is that you get to build your own application. You will have the luxury to decide what technologies to use, although you shouldn’t divert too much from what the development team is using, after all you want to be part of their team so you would want to go in the same directions as they are. You have the luxury to decide the design and structure of the application, what features to introduce. Best of all, no one will come and push you. You can take as long as you need since it’s something you are doing on your own initiative. It’s something you are doing apart from your regular job tasks. HOWEVER!!!! MAKE SURE THE DEVELOPERS ARE AWARE OF WHAT YOU’RE DOING. Even if it’s something as simple as in the example above, the development team must know that there is another application that is doing X, Y and Z. The moment your app connects to the DB, even to the network, it becomes part of the entire ecosystem. Imagine suddenly the entire database becomes slow because of too many open connections. The main applications start to timeout the connections and no one knows why. Developers start investigations and it takes hours before the data base admin gives your application IP as the source of the problem. In best case, the company has lost only a few thousands, your application goes to the trash and developers have lost one day in doing nothing. This leads to the next point.
- Find someone to mentor you – this will be someone to help you on a daily basis, someone you can always ask for help and will be available to answer your questions or doubts. In the best scenario that would be a colleague of yours but it could as well be a friend, relative, etc. Identify someone who can give you code reviews. Having your own project is great but you will be part of a team eventually. Therefore, you need to learn writing readable code for someone who doesn’t know the project’s context. A developer can point you to a certain design pattern or a different approach that will reduce code duplication and possible reduce the size of your project. Less code is easier to maintain after all.
- Ask development team for advice – approach someone from the developers and introduce your idea, maybe even schedule a 30 minute meeting every week with 1-2 of the developers. The point being:
A. Get their approval. They have a deeper knowledge of the entirety of the system so they can tell you, at the very least if it’s worth for you to spend time on solving that problem. Maybe they have already started implementing a solution for this and they might suggest you to look into another issue. Most of all, they will make sure you won’t interfere with the critical processes that support the business.
B. They know better what tools you can use to make your task as easy as possible. Of course, do your own research and mention what technologies you are planning to use. However, there might be some newer framework that they would know about and suggest you to try it out. In the end, the decision is entirely up to you but mind that the developers can help you more if they are familiar with the framework you are using. Otherwise, they will have to start learning it just like you and you won’t be able to take advantage of their experience.
- Make your new tool known to a wider audience – present your work to your manager, to BA, to anyone who would be interested in it. Explain the benefits from it and what value it has for you, for the business. You did a software development task by automating a process, therefore reducing the manual work needed and improving the time for the process completion. The BA can now get his data in 30 seconds, instead of waiting for you 30 mins to finish whatever you were doing, read his email, come up with the correct SQL query, fetch the results and respond to the BA’s email. Emphasis that it’s something you did on your own, it was an extra effort on your behalf, you had to learn this, this, this and that, etc.
- Approach your manager or the development lead to change your role – if you’ve continued to add more feature to your tool or created other tools, there will be a point where you should have the confidence to raise the question that you want to transfer to the developers team with the management. Since you have proven your good understanding of the domain, you have shown good coding skills and flexibility in learning new technologies, the chances are that you will get what you want. Simply because from the dev lead point of view, it’s much easier to integrate a new person in the development team, who is already familiar with the system environment rather than hiring a complete stranger who will need 3 months of training and is yet to prove his professionalism.
More or less, these are the tips I can give to all Application Support Engineers who are looking to move to a development role but are unsure from where to start. The same should apply for Test Engineers but I would imagine they would need to dig into a programming language first. Do you have any other tips or questions? Please do share in the comments below. 😛