Filling the Stack: Five Things That Helped Me Transition From Frontend to Backend Development

A few tips on how I added Backend/API engineer to my list of skills while on the job at Headspace.

Author: Lee Richardson, Senior Software Engineer

Intro

I started my career at Headspace (1000 years ago, way back in 2019!) as a Web engineer. Our frontend stack is primarily React, Redux, Redux-Saga, Emotion and several internal libraries for shared functionality/UI components. The first big feature I worked on was a group meditation feature, which we designed to be compatible with live audio or video streams. We were excited to add a live, community-minded feature into the app experience.

After several initial product iterations, we decided to focus on other community-minded features, and our squad no longer needed a Web engineer (quick side note on what Headspace calls “squads” — these are cross-functional groups organized around a particular business focus, usually containing a product owner, tech lead, and engineers across various disciplines). I started to feel lost, like my squad was moving onto bigger and better things and I was being left behind. After a few days of low-grade sulking, I started having conversations with engineers from other squads, taking a lap around the company to see what everyone was working on, and what might be a good fit for my skills.

After some research, I transitioned to be primarily a backend engineer in late 2019.In this article, I share a few tips on how my skills expanded while on the job.

Make Your Intentions Known

When my future role became less defined, I started to doubt myself and my future at Headspace. After some mindful reflection and meditation, I was able to catch myself in a negative thought pattern and snap out of it.

I had conversations with my manager and colleagues, to get a feel for what everyone was working on. I was explicit about wanting to find a new team. Word got out, and I eventually decided that I wanted to join the Headspace Health team to explore the healthcare space. I had previously worked with several members of the squad, and felt very excited and comfortable joining them in their ambitious journey.

The Health squad was already staffed with 3 excellent Web engineers, and as such their needs were on the Backend/API side. Having limited backend/database experience, I was a little hesitant to commit to becoming an API engineer. Lots of self-doubt and worst-case scenarios were flying around in my head. What if I can’t do it? What if everyone sees that I don’t know what I’m doing? What if I look silly?

By making my intentions known, and having conversations with colleagues from across the company, I was able to uncover several internal opportunities that may have otherwise remained hidden.

Embrace Convention

The mandate for the Headspace Health squad was to build a greenfield product from scratch, including a handful of API microservices. The biggest question right up front was a classic one — what language/framework should we use?

At the time of this writing, Headspace’s officially preferred languages for API services are Node/Typescript and Java/Spring Boot. Our squad’s tech lead had experience with Spring Boot but remained agnostic on the choice for our squad, assuming I would want to go with Node because of my experience with Javascript/Typescript on the frontend. Eventually we had to choose, and due to indifference among my colleagues the choice fell to me.

I did some research, sat in on some meetings, and poked around our respective codebases. Ultimately, I pushed for our squad to use Java + Spring Boot. My perception of the Spring Boot ecosystem was that it was more opinionated/prescriptive than our Node/Typescript ecosystem, and, in my book, that was a benefit (less decisions I needed to make, offload much of the architectural choices to the framework). The conventions in place made it a lot easier to avoid making bad architectural decisions by strongly encouraging code encapsulation and programming to interfaces.

There are also a multitude of great resources available for just about any problem you are trying to solve (shouts to Baeldung.com — pretty much anything I have needed to figure out is explained extremely well there). Make sure you know your versions!

Strong conventions, opinionated architecture, and abundance of online resources were extremely helpful for me as a new API engineer. I was able to start building without having to worry about the project structure or about making silly mistakes.

Find a Mentor/Personal Champion

In my first few months as a fledgling API engineer, I felt like I was starting slow. Learning a new language (Java), framework (Spring Boot), and IDE (IntelliJ) at the same time can be frustrating. Simple things like renaming a file seemed to take minutes instead of seconds (for example — renaming a file in IntelliJ is done via the refactoring menu instead of double clicking on the file name).

Two of my colleagues at Headspace were instrumental in my transition to API development. The Tech Lead for my team, Vincent, showed confidence in me from the earliest stages of my transition. Vincent’s belief in my ability to do the work was a big factor in my decision to give API development a try. Another colleague, David, was very generous with knowledge and resource sharing when I started working on features.

Try to take notice of people who enjoy sharing knowledge, and don’t be shy to ask. As long as you’re respectful of people’s time and attention and return the favor when there’s an opportunity, people can be very generous and willing to help.

Ask Questions/Attend Meetings

One of the first things I did when I started doing API development was attending API-specific meetings and reading API-related Request For Comments documents (RFCs) and feature specs. This helped me stay on top of the current state of our services, as well as look ahead to different incoming challenges & changes across our API services. It also inevitably led to a whole screen of browser tabs open when I started researching all the different libraries, terms, and tech that are discussed in the documents.

Headspace also has a Spring Boot working group that meets separately, where proposals and discussions specific to the Java/Spring Boot ecosystem are shared. These meetings were a great way to get familiar with concepts and terms specific to my feature development in our Spring Boot services.

Attending these types of meetings also presents frequent opportunities to chip in, and start contributing right away. Which leads me to my next point….

Start Small

The potential to solve exciting, complex problems drove me to pursue Software Engineering as a career. However, when faced with the challenge of learning a new language and framework, I found it extremely helpful to start small:

• Update & Add Documentation: Most of the time, there are ways our internal documentation could be improved. Being the newest member of the team to onboard onto our services also put me in the unique position to know what parts of the docs could be improved, tweaked, or flat out removed. I was able to write an onboarding guide to help anyone completely new to our Spring Boot ecosystem get up and running without issue.
• Code Review: Looking at other people’s pull requests taught me more about how our services work than any documentation ever could. Plus, you get to ask specific questions to help explain any confusing pieces. I learned about how our Spring Boot implements project structure, dependency management, unit testing, and more just by reviewing PRs and asking questions. I always thank people for answering my questions and show them how much I appreciate their effort. As an added bonus, you’re helping others get their code merged & moving towards deployment. Literally everyone wins.
• Update Dependencies: Sometimes it’s possible to help out without writing anything at all. Just updating your project’s dependencies can help by adding bug & security fixes, and new features in more recent versions. It’s also a good way to learn about how the project imports and deals with dependencies in general.
• Write a utility: One of the requirements for our project was the need for an audit log — simply a log that said what resource was being accessed by which (internal) user. After some research and consultation with my colleagues, I was able to write a small request filter that intercepted all requests, sent a log, then passed the request along to the rest of the application. This was pretty easy and painless to do, and was eventually added to our boilerplate Java/Spring Boot application that serves as the starting point for anyone spinning up a new service.
• Be Grateful & Pay It Forward: I always thank people for reviewing my pull requests, asking questions, and leaving suggestions. Paying it forward to others also helps to generate a culture of mutual benefit.

Wrapping Up

Those were five things that helped me make the transition from frontend to backend a little bit easier. As of this writing, I am working on adding a feature to Headspace’s Android app, and the tips outlined in this article are helping me once again. Every day I look forward to learning more, and helping others grow their skills as well.