Navigating New Responsibilities

When presented with increased responsibilities at work, I recognize two options: I can either embrace the challenge or retreat to the comfort of my desk with VSCode. Neither path is definitively right or wrong; rather, you'll know what suits you best when the time comes. Over the past year, I've navigated both choices.

On the first business day of 2022, I joined a new team at Meta, clearly expressing to my manager my intention to develop skills outside my comfort zone (UX). I aimed to delve deeper into back-end development to enhance my T-shaped skills. Admittedly, I also wanted to combat the imposter syndrome that arose from working at a high level in the tech stack.

Six months into my new role, my manager assigned me a critical privacy back-end project due later in the year. Chaos ensued when a key simulation malfunctioned, leading my team to spend the next two months troubleshooting end-to-end dependencies. I once learned C++ in a day just to submit a pull request in another team’s codebase.

While debugging the privacy project, a partner team filed a SEV (priority ticket) against our UI, as a feature I maintained encountered a 500 OOM error. With both projects halted, my comfort zone felt distant.

After resolving the SEV, I informed my tech lead and manager that I had been optimizing UI queries over the past weeks. I understood the necessary work, but time constraints made it difficult to address everything.

My manager encouraged me to spearhead efforts to resolve the remaining UI performance issues. However, I hesitated, wanting to concentrate on the back-end project I had been assigned. Despite the privacy project allowing for extra padding in the timeline, I feared that taking on additional responsibilities could jeopardize my progress. I worried that failure would diminish my value as "just" a UX person.

When my manager suggested I reconsider leading the UI initiative, I declined again. I already grasped the UI problem and wished to further my technical growth. Thus, I decided to let a newer hire tackle the UI issues as a ramp-up project and an easy win.

Returning to my desk that day, I had valid reasons for declining the added responsibility. Part of it stemmed from fear, but I also lacked clarity on what my manager was asking of me at that moment.

In hindsight, I could have demonstrated my understanding of my area of expertise without implementing the fixes. By writing tasks and sharing progress internally, I could have showcased my skills. My manager was aware of my aspirations beyond broadening my technical knowledge; he sought detailed communication about the problem. Leading the UI effort would have consumed more of my already limited time, but it could have provided significant project impact when my privacy project was struggling.

All is clearer in retrospect. If given another chance, I would have embraced the extra UI responsibility to enhance my promotion prospects. While I felt stretched, I recognize that saying "no" at the right moments is a crucial skill that requires practice, and one should never regret prioritizing their mental well-being.

A few months after that decision, a new college graduate joined my team. My manager tasked me with onboarding her so I could allocate some of my responsibilities. Feeling more assured about my back-end project's status, I accepted the challenge and began assigning her tasks from my privacy project, as well as designing a new asset migration project for her to complete.

As the privacy project nears completion, I'm looking forward to 2023, where I'll lead an even larger back-end initiative filled with uncertainties. This time, two team members will work under my guidance. Once again, my comfort zone is far behind me, but I’ve learned that embracing discomfort is part of the journey.

Why You Might Code Less

Coding will never occupy 100% of your time. Even junior ICs have meetings to attend and non-coding responsibilities to fulfill. As you ascend the ranks to senior roles and beyond, these non-coding duties will only increase. Here are a few key responsibilities that come with this shift:

1. Writing or Updating Documentation

   Start this task at any point and continue indefinitely. No one is "too inexperienced" to contribute; even new hires can fill in conceptual gaps or "gotchas" they encountered during onboarding.

2. Creating Design Documents

   As the scope, ambiguity, and complexity of your tasks increase, you'll need to write design proposals that gather requirements, analyze or research, and share findings with stakeholders and collaborators. Juniors, don’t rush this step; while it may be tempting to dive into coding, sometimes a little planning can save a lot of time later.

3. Adopting Adjacent Roles

   Software engineering teams often face skill gaps. You may need to develop skills in roles like project management to set deadlines and oversee project completion. For instance, Meta’s "bottom-up" culture means that engineering ICs make decisions about what work gets done, often needing to act as their own project managers.

4. Mentoring Junior Developers

   As you gain experience, you'll often find yourself responsible for onboarding new hires and mentoring junior developers. This role will enhance your communication skills and strengthen your promotion portfolio.

Conclusion

Recent advancements in AI, like ChatGPT, have led programmers to wonder if they will soon be replaced. However, the reality is that we are already steering our careers away from coding through the software development cycle. With each new level, ICs move further from the code editor and closer to conference rooms.

Consequently, today's software developers may soon find themselves coding less frequently. While this evolution may evoke nostalgia for simpler times, it ultimately paves the way for the next generation of developers. It’s a privilege to work in a field that allows me to mentor others, hoping they will surpass my achievements.

As I take on more responsibilities, I appreciate the coding days of my past. The support from my more experienced colleagues enabled me to focus solely on implementation with confidence. Facing new challenges has required diverse approaches.

Progress is rarely linear, but by cultivating a growth mindset, the "senior shift" will occur when you’re ready for it.

Thank you for exploring my reflections on software development culture in 2022. Connect with me on Medium, Twitter, or LinkedIn for updates on future posts.

Further Reading

• My Early Software Engineering Career Success Plan
• 3 Writing Exercises Guaranteed to Make You a Better Engineer
• Don’t Just Ask Someone to Be Your Mentor
• Dear Junior Developer, I Don’t Care About Your Portfolio

Is Coding Still Worth Learning in 2024? - A discussion on the relevance of coding in today's tech landscape and what developers should consider.

Coding won't exist in 5 years? A look at the future of coding and the evolving landscape of software development.