Overcoming self doubt by embracing growth discomfort and applying core engineering skills to new domains

I’m a front end developer, front end engineer, web engineer. The title doesn’t matter as much as what I do – the web is my specialty. I’ve been doing web stuff for the last 9 years, doing it professionally for 8 of those years. I’ve seen the landscape change a lot since then, as most of us who started in this era and beyond have experienced. The web has gotten increasingly complex, but I’ve held on tightly to the fast moving pace. It’s been an enjoyable ride; I absolutely love what I do.

While I always considered myself a web gal, I did dabble in the back end throughout my career. The engineering bootcamp I attended focused mainly on back end development. When I started working professionally, I worked on back end tickets here or there as needed, but rarely independently and never very in depth – almost strictly pair programming and/or XS-sized tickets. I was glad to work on back end if it was what I had to do to help my team. I wanted to learn, too. But it didn’t give the same warm fuzzies that front end development did.

Not too long ago, my team at work had a new feature we wanted to build; we made our predictions and it looked as though it was going to contribute a sizable amount towards our quarterly and yearly goals. There was a back end service in the organization we knew of that would give us the data we needed to build the feature.

There was another team in the org who wanted to use the same service in their new feature. The service could not handle the requests per second (RPS) volume. This elevated RPS ultimately ended up taking the service down (and a portion of the rest of the surrounding system too 🫠).

The service was not a big focus for the owning team at that moment in time (not to mention the owning team technically did not exist anymore). My team stepped up to “be a good neighbor”, offering to contribute to improving this back end service. A workstream formed around the need. My manager asked if I’d be interested in participating as an embed with the team. I volunteered; it was multifold. I wanted to unblock the affected teams and our project. I knew the impact it had; I wanted to enable us to move forward.

When I started this particular role, one of the first paradigms I was faced with was embracing T-shapedness — a person who has a depth of knowledge and skills in a specific domain, with flexibility to learn and take on tasks across different domains. My mindset hadn’t changed since years past – I was glad to do back end work if needed. However, I wasn’t over-the-moon-excited about it. I wanted to get better at web! I was starting to climb the precipice of what later felt like a plateau in my web skills. If I had to do back end, wouldn’t that take away from me being a strong web engineer? Deep inside, I aspired to be a specialist rather than a generalist.

In fact, my first week of the embed, I had a bit of the ick. Back end wasn’t visually interesting or easy or FUN. It initially brought on a lot of negative feelings. I felt isolated; I handed off a project I had been working on and leading for some time to another engineer on my team. I felt like I was watching them from afar, jamming away on next steps, and here I was over here trying to make a dumb integration test run on my system.

As the embed started, I bumbled through our back end onboarding documentation. I could barely complete a tiny task independently. I knew I had to set healthy expectations, but at that moment, it wasn’t in my intuition. I was hesitant to ask for help. I’m a senior engineer, I should be able to figure this out, right?

Okay sure, Java back ends do not have a visual aspect and therefore it can’t be visually interesting. Of course it wasn’t easy or fun (yet). This was brand new to me. Dabbling in back end over the years had nothing on the many years I have spent learning web and honing my craft. I didn’t just have the ick; I was feeling growth discomfort in a big way. I kept comparing my web engineer self to my budding little back end engineer self. That isn’t a fair comparison.

In other areas of my life, I’ve been trying to reframe negative thoughts. Instead of reacting to them, I wanted to take a pause, observe my thoughts, and respond to them. Just because a thought popped into my head didn’t necessarily make it real. What was I really feeling?

I was so busy focusing on how much I was tripping over syntax or language specific intricacies that I didn’t notice that my intuition was pretty on point.

For instance, one task was to migrate an API from one service to another – both services I had next to no familiarity with on top of my burgeoning Java familiarity. Reading through the code felt somewhat foreign. New syntax, new naming conventions and folder structures, new concepts… I felt troublingly slow on the uptake.

While my mind was swimming with self doubt, I came up for air. I reminded myself that I’ve refactored code in web projects so many times before. I had a north star to point towards – the “definition of done” in the ticket. And most importantly, I had my workstream mates there to support me. They were glad to answer my questions and even pair program with me. Maybe I didn’t know how to achieve what was required of a ticket immediately. But most of the time, I was on the right track.

At no point did anyone ever say, “Wow this is so bad and incredibly wrong, you call yourself an engineer?! You’re dumb!” The only negative framing was coming from my own mind. I quieted those “should-be-able-to’s”, and just asked the questions. If I had all the time in the world, I am positive I could figure it out. But it isn’t a team of me. We have the ability to lean on each other, to learn from each other. And as I asked, I felt my mind grow.

By slowing down, taking a moment to respond rather than react, I empowered myself to grow. I spent a little more time watering my garden rather than standing in the sun expecting it to grow all on its own without a little love and nurturing. I’m not just a talented web engineer; I’m a talented engineer.

With this mindset shift, I was able to complete tasks to help the workstream complete ahead of schedule. The stability improvements transformed a service chock full of outages at elevated RPS into a service that exceeded that RPS without any degradation of service 🎉. We even could have wrapped our project early. As a result, we expanded our scope and took on work from an adjacent workstream. My workstream mate told me that I was doing great work and commented on that intuition I had, just like I observed about myself.

Additionally, this experience reinforced some important lessons within myself. This embed didn’t take away from my web skills at all, as I had feared. In fact, expanding my breadth in a new domain helped me to increase the depth of my web knowledge. Embracing T-shapedness more has given me the ability to use my newfound back end abilities on another project, completing a large chunk of API work independently. Working on both the back and front end of this project has created a seamless integration and a deeper understanding of how the systems connect. Knowing the intricacies of the complete system will help us scope future work in this area. I can also pair program with my teammates, teaching and empowering them to grow their T-shapedness too. Plus, I actually like working on back end now. What I didn’t know before is that it does appeal to me, it just works out a different part of my brain. It’s exciting to have this new, shiny nugget of knowledge in my back pocket for when I need it.

This experience gave me the confidence to trust myself and my abilities in new landscapes; it gave me the tools to tear down the wall that growth discomfort tries to build up. It helped me challenge the negative thoughts that are too often my go-to, responding and reframing. That will go above and beyond just being a web engineer. That will help me as a person. That’s one of the best parts of what we do.