My Engineering Transition from Mobile to Backend
As an ex-iOS software engineer at PSPDFKit, my transition to the Server team was both exciting and challenging. It involved learning new technologies and tools, as well as adapting to a different workflow and set of responsibilities. In this blog post, I’ll take you along on my journey of switching teams and shed some light on the challenges I faced.
My Journey
After completing college in 2014, I began working professionally as an iOS software engineer. Two jobs and a master’s degree later, I got the opportunity to join the iOS team at PSPDFKit.
On the iOS team, my day-to-day work initially involved tasks such as implementing new iOS features, maintaining and improving CI infrastructure, and doing customer technical support.
Later, as the company expanded its focus from native software development kits (SDKs) to hybrids, I started working on our cross-platform SDKs with the Hybrids team. This was a natural progression, as I was already working with Flutter a little bit when I was part of the iOS team, so I was familiar with the platform.
However, once I’d fully transitioned to working with hybrids, I discovered I didn’t enjoy Flutter and React Native as much as I thought I would. That said, having worked in mobile development for a long time, I’ve often wondered about how things work in other fields, particularly in backend development. At PSPDFKit, I’d also seen other team members successfully switch teams, and this gave me reassurance that I could do it as well.
At this point, the Server team felt like a perfect fit to me. It works on some nice products, such as PSPDFKit API and Processor, and to top it all off, the team is using one of the most loved programming languages: Elixir. The possibility of learning a new language in a new domain felt very exciting to me, so I decided to bring it up with my manager(s).
Bringing It Up with Team Leads
The culture here at PSPDFKit is a really open one, and when I discussed switching teams with my manager, Rad, I received nothing but complete support. Rad synced up with the Server team lead at the time, Arek, and the two created a transition plan for me, which enabled me to gradually hand over my current duties on the Hybrids team and move on to the Server team. I was also assured that if the switch didn’t work for me, coming back to the Hybrids team was an option.
Transitioning to Server
At the start of the transition, I still had a lot of work I was doing on the Hybrids team. So, we started gradually, with one day per week when I would read the Server team’s internal documentation. Since the Hybrids team was both small and relatively new, there was a lot of collective knowledge that wasn’t documented anywhere. So, as my offboarding task, I started creating internal documentation, including articles and architecture diagrams that would make it easier for someone joining the team to quickly get up to speed. I also had a lot of helpful one-on-one meetings with Rad where we discussed topics pertaining to professional development, such as becoming a manager of one. During that time, I also slowly started reviewing Server pull requests by other team members, and I set up my machine for Elixir development.
Finally, after a couple months, I arrived at my last day on the Hybrids team, and I officially switched to the Server team. This meant I’d be working full-time with the Server team, but I’d be there to help the Hybrids team if necessary. Arek had created a really useful onboarding document for me, which clearly listed out my tasks and expectations for the onboarding period. Initially, I was assigned small tickets, and I had a lot of screen-sharing and pairing sessions with Arek and other members of the team. I also started shadowing team members during their support weeks so that I could understand their thought processes when solving a customer issue.
Eventually, my one-on-one meetings with Arek transitioned into status updates only, in which I drove the meeting and could ask for help if I got stuck somewhere. After I got more familiar with the codebase, I started working on bigger and bigger tasks, such as refactoring the payment retrial mechanism and adding new APIs.
Learning Elixir
To start learning a new language like Elixir, it can be helpful to first read an introductory book or tutorials on the language to get a broad understanding of its features and standard library — which is exactly what I did. Elixir’s interactive mode also enabled me to quickly test various language features. In addition, Arek suggested a website called exercism.org, which explains language concepts and helps users reinforce those concepts by writing code — I really loved learning Elixir interactively like that.
Elixir, being a functional language, requires a significant shift in thinking for people like me who are used to the object-oriented paradigm. Elixir’s unique pattern matching concept also doesn’t have an equivalent in most other languages, and initially, I found it a bit difficult to use it effectively. However, after writing more of the language, it has become one of my favorite concepts, and I can see why Elixir is considered one of the most loved programming languages by developers.
Conclusion
In conclusion, I feel like having an engineer from a different team, such as an iOS engineer on a Server team, can introduce valuable benefits for everyone involved. Not only has it expanded my knowledge, but my expertise in iOS offers a unique way of approaching ideas and challenges I encounter in my new role. On a personal level, I feel much more excited about my day-to-day job given the chance to learn something new. Now that I’ve spent more than a year with the Server team, I can also say that I have become a productive member of the team.
Meanwhile, from the company’s perspective, onboarding an engineer from within the company can be easier due to their existing domain knowledge. For my part, I’m really grateful to PSPDFKit and my manager(s) and colleagues who gave me this chance to switch teams and who helped me through the process.
