A few people have asked me over the last few months about my shift from an Android engineer to backend. After Googling around about this topic, I found there are plenty of people who have made the switch; especially the other way around. I thought I’d to the collective wisdom of the internet with my own experience.
1 – You’re still coding and adding value
You’re just doing at a different level of abstraction now. Previously I was working with user interfaces, making REST calls, storing things in a cache and building libraries. Now I’m not working with user interfaces but still doing the other things. I also noticed that my immediate stakeholders changed but nonetheless, I still have end customers in the real world who are using the things I help build. In both roles I was contributing to the success of the company and facing new technical challenges.
2 – Try Pair Programming
Many of the tools I was using changed! To learn the new tools, libraries and frameworks I found that pairing programming helped me immensely. My current company has been doing pair programming for almost 15 years now and the people there are really mature in its practices. I could go on about the benefits of pair programming but long story short: try pair programming, you will learn faster.
3 – Read production code and tests
I found that reading code was great to understand the common development practices and assumptions our engineers have used over the years. It’s only when I read code what I saw the similarities in the Android codebases I’d worked with. The similarities included such as interfaces, inversion of control, polymorphism and other techniques; It started to click there wasn’t a whole world of difference. But hey, it could also be because it was effective use of the language features since both were Java and Kotlin. While reading production code was hardly, I found that reading the tests was the best way to learn about the business logic (how the code should work). You can do the same, Find class responsible for a business function, goto its test class and read how it should work. If the tests are written in the form of a BDD acceptance criteria, it’ll contain the pre and postconditions of the logic its testing. You should be able to gather plenty from just the name of the test. So read tests too!
4 – Expose yourself to infrastructure
I joined my current company at the time where we started building all our new workloads in the cloud. I had a few challenges learning about the backend stack along with ‘infrastructure as code’. Since everyone in my team was learning it too, I decided to jump on board and tried not to sink. Even if your company doesn’t use the cloud, sit and pair with your operations teams and understand what it takes to deploy and run the business. I can guaruntee that you’ll learn something almost every time, the additional benefit will be building empathy within the different technical departments of your organisation. Sounds like a win-win to me. Lastly, I found that learning about infrastructure broadened my understanding of how services can be designed and built.
5 – Be patient
You’re not expected to become an expert in server side development overnight but you are expected to put in the effort to learn and then contribute. Try to find people in your org who have made similar pivots in their career to learn what tactics they used.
That’s all I have to share for now on this topic, I’m sure there are plenty of other things that can be done to help. If you’ve got any questions or suggestions that I can pass on, feel free to get in touch.
