The mentor I never knew I needed 🪄

When I kicked off my software engineering journey at Apollo, I was armed with Google, Stack Overflow, and overconfidence. Who needs a mentor? Then came 3 situations that made me rethink this in a good way. A mentor was the real-life cheat code I needed and found one!

🌴 Branching my way out of the deep end

There was a project which was essentially a “relay race” of engineers working in sequence. Before we started, I had a chat with Umang, my mentor & Staff Frontend Engineer for the Growth team here at Apollo, about how to handle merging my changes to master.

We had two options:

A) Feature Branch: Create a feature branch, merge all approved changes there, and only merge to the master branch once everything is properly tested. But, this could result in a feature branch so massive it might require its zip folder!

B) Feature Flag: Continuously merge changes directly into the master branch but keep them hidden behind a feature flag. This seemed like the better option for several reasons:

• Feature Branch Overload: A huge feature branch would be a nightmare to review and merge into master. Plus, squashing and merging such a big branch would make it hard to figure out who to blame for what—umm, I mean, who worked on which part!
• Risk of Big Bang Bugs: Merging a gigantic commit all at once could lead to unexpected errors. And testing those massive changes would be trying to find a needle in a haystack.
• Staging Overkill: Testing such a large chunk in staging would be overwhelming, and we'd have to face a monster-sized testing phase in production.

By using the Feature Flag approach, we got these benefits:

1. Incremental Testing: Smaller, incremental updates pushed to production made it easier to test with real data and spot issues quickly.
2. Staged Rollouts: We could gradually roll out features, minimizing risk and making the deployment process smoother.
3. Faster Reviews: Smaller, more manageable PRs meant quicker code reviews.

❓Do you even "Backend"?

As a senior frontend engineer, Umang advised that having “a bit of” backend knowledge would be incredibly beneficial - particularly in my own product area.

Following this, I took on a low-risk project involving backend work and made small but meaningful contributions. This step was enough to help me build confidence and reduce my dependency on backend engineers for the initial debugging of incidents. It also eased my apprehension about backend tasks and provided an excellent learning opportunity within my working domain.

Sometimes it's these little nudges to jump into unknown territory that prove to be of massive value, not only in my growth, but to support our greater team!

🚪 Opening new doors

With Umang's guidance, I ventured into building custom ESLint rules—something new in my front-end career. His support opened up new opportunities for me, and soon I became confident in this area.

One of the ESLint rules I developed centralized environment variable usage by requiring all variables to be defined in a single file. This streamlined tracking and management, making updates easier and significantly enhancing code maintainability.

Additionally, collaborating with the Design System team, I contributed to core UI components and expanded my expertise in accessibility. New doors that would have never opened otherwise!

..we are hiring!

To quote a rather popular movie - "Help shall always be given at Apollo to those who ask for it!". And particularly when you are dealing with complex, large-scale technical problems daily. We are looking for smart engineers like you to join our "fully remote, globally distributed" team. Click here to apply now!