Quitting At Work, and Normalizing Burnout Conversations

Well, well! This piece reads like a bit of a downer doesn’t it? 😅

Still, I wanted to share some not-so-glamorous sides of the developer experience (mine included). I believe that being able to feel, accept, process and channel negative experiences, is a vital skill. I hope you enjoy. 🤎

PS My Calendly is open again for anyone needing tech career guidance. 🎉

To enjoy content like this in your inbox, subscribe to the Arit Developer newsletter HERE.

I Quit A Work Project... And I Felt like Sh*t

Several months ago, I took on a large project at work. In summary, my task was to:

• Migrate the data within ~25 columns from one table, and split them between 2 new tables. There were over 650,000 discrete records that would be affected.

• Update all related business logic within dozens of files in the backend, so that they read from the 2 new tables, no longer the old.

• Update all related tests.

Huge task. But I was excited; I had several team members available to help if I got stuck, so I believed I would just advance systematically through each part of the project.

Things Get Messy

I was wrong. Even though I divided the work into parts and sections that made sense implementation-wise, I ended up with an enormous pull-request that had over 100 commits, 77 changed files and 60+ comments.

So many parts of the app were broken. So I put my head down and fixed each break, only to have other parts break in turn. I kept going, but by this time, I was not enjoying the process anymore. I ran out of bandwidth for my other responsibilities (like reviewing my teammates’ work, or fulfilling opensource duty). This one project consumed me.

The teammates designated to help me were indeed helpful. However, because they weren’t working with me on the project, catching them up with my recent changes became tedious, and they had to do significant amounts of context-switching each time.

My Breaking Point

Eventually I fixed all the broken code. Then came the task of fixing the tests. In hindsight, leaving the tests until the end of implementation was my biggest mistake, because I had lost track of the sources of the breaks in each test. One day, as dozens of tests kept failing despite my best efforts to remedy them, I reached my breaking point, called my manager and said:

I’m done. I have nothing left.

My supportive manager agreed to pass the project onto a more senior developer for completion. I remained engaged by reviewing their work, which allowed me to understand what still needed to be done. When the pull request was finally merged, I was palpably relieved.

Then the fallout began. I was physically tired; experiencing aches and spasms in my shoulders and back. I was mentally tired; for the first time since I wrote my first line of Ruby, I woke up NOT looking forward to coding.

I felt like such a failure.

Why couldn’t I just keep pushing through to the end?

Why did I grow so tired? Why did I miss all these small mistakes?

Will I ever become a senior developer?

Rest & Recovery

Speaking with my manager and mentors helped me start processing what really happened, not just how I felt about what happened:

Arit, you took that project 90% of the way - that is a victory!

What you needed was more dedicated support, which was on leadership, not on you.

This one project is NOT an indicator of your ability; the scope was huge, the finish-line kept extending and you were exhausted.

Now a week or two out from the experience, I’m feeling better.

I’ve taken smaller-scoped tasks with clearly-defined technical implementation steps. I’m working … no, breezing through them now, applying the competencies I gained from my last project.

I’m remembering that, yes, I can code and I love coding.

Eventually I will achieve the technical proficiency & staying power necessary for complex, multi-month projects.

One line at a time, yeah? 🥰

Breaking Burnout Down

My mentor Vaidehi Joshi wrote a thought-provoking thread about burnout in a professional setting. Here is her thread’s first tweet:

After the project I wrote about above, taking some time off was presented as a way to help recover from my fatigue.

However, I didn’t feel like that was a fitting solution, because my fatigue was not merely related to work-volume. Rather, it resulted from feeling increasingly inadequate as I worked to fix code-breaks that kept popping up like whack-a-moles.

A better solution for me was to choose work that restored my sense of competence and self-efficacy. Once I did, my vigor and interest returned. But if I wasn’t clear on the source of my fatigue, I probably wouldn’t have been able to identify a suitable solution.

Particularly in the tech industry, I think we need to further normalize conversations around burnout.

We should empower each other to express feelings of burnout, and support identifying, naming & addressing the true sources of our burnout. We also need to permanently retire beliefs that equate burnout with not being fit for the job.

Thank you, Vaidehi, for your thought-leadership! 🤎

Photo Credit: Liza Summer on Pexels