Embracing Chaos: The Hidden Battles Behind Some Pull Requests

TL;DR - We all encounter tasks that make us question our abilities, until we get the code to run. However, these moments of uncertainty are often hidden behind a successful pull request, making us feel like we’re the only ones who struggle. Coding can be messy; let’s normalise that.

The Unseen Struggle

I’m in over my head. Why did I commit to this? The screen in front of me blurs, frustration clouding my vision. Hours have slipped by, but the problem remains stubbornly unsolved. Someone else could have done this quicker and better. Am I even cut out for this role?

Doubt eats away at me, always there as I stare at the lines of code. My fingers hover over the keyboard, poised but hesitant. Another tweak, another run. Fail. The error messages taunt me, a stream of red text mocking my efforts.

I dig deeper into the code, analysing every function, every variable. Maybe it's a syntax error? I scrutinise each line, looking for a misplaced semicolon or a misspelled word. Nothing.

Wait—what if I just adjust this? A slight glimmer of hope appears. I make the change and hit enter. I hold my breath as the screen processes, only to deflate again. Failure. Grr…

The hours blend into a blur of trial and error. My mind races, desperately sifting through possibilities. I try Stack Overflow and ChatGPT, read documentation, and watch tutorials, searching for a clue. Each promising lead ends in disappointment, my frustration growing with every dead end. The sun sets outside my window, the room darkening as I stubbornly press on, refusing to let this defeat me.

Then, a breakthrough — a slight alteration of a lowly line of code. Success! The code compiles smoothly, no errors in sight. I test it against various scenarios, each one passing without a hitch. It’s working. It’s all working. Relief floods over me, followed by a growing sense of pride.

Against the odds, I’ve done it. The feature is complete, polished, and robust. I lean back in my chair, proud of the battle I’ve fought and won. Next step, create that pull request. Down the line, however, when the the pull request is reviewed, the reviewer won't know about the struggle I faced. All they'll see is a well-written pull request that gets approved almost immediately.

A pull request represents the outcome of our efforts to build something. It's the stage where engineers have overcome obstacles, clarified logic, and resolved unexpected results in the code—hopefully, without any bugs. When a fellow engineer reviews your pull request, they won’t see all of that. They won’t know about the searches on Google, the tips from Stack Overflow, or even the use of AI to generate or optimise code. All they see is polished, high-quality code, which, if written by a more senior engineer, can be quite impressive.

While this recognition is positive, it can leave less experienced or less confident engineers feeling inadequate. I've experienced this myself, especially earlier in my engineering career. There were times when I reviewed a teammate’s pull request and thought, “Wow, that’s a clever implementation! Will I ever become skilled enough to write code like that?”. It's a common feeling, but one that can be overcome with time, experience and self-compassion.

Enter Pair Programming

For some time now, I've been mentoring and supporting junior engineers through pairing sessions. In a recent discussion with my manager about pair programming, we explored its value, particularly when pairing with less experienced engineers. Countless articles have been written highlighting the benefits of pair programming: it enhances productivity, reduces bugs, and yields higher-quality code. Collaboration is fostered, and learning occurs through practical application.

Pair programming comes with its challenges. It requires individuals to show courage and vulnerability, such as admitting when they lack knowledge on a topic. There can also be pressure to perform well and uncertainty about suggesting less advanced technical approaches. Skill disparities between participants can lead to frustration for one or both parties, as tasks may seem disproportionately easy or difficult.

Additionally, the mental toll of pair programming shouldn’t be overlooked. Participants might feel they have little personal time and feel obligated to continuously engage with others, which can be exhausting, especially for those with neurodiverse traits. I have previously written about my experiences of being a Highly Sensitive Person. As an HSP, I have found pairing to be quite draining at times (Although I acknowledge I have also gained much from pairing).

Balancing these factors is crucial for ensuring productive and sustainable pair programming sessions.

The conversation about pair programming highlighted an interesting benefit that is often overlooked: pair programming demonstrates and reminds us that others frequently encounter similar challenges when coding. It is normal to forget syntax, search for better technical implementations, and debug for hours only to discover a simple typo.

Normalising the Challenges on the Journey to a Good Pull Request

"The reason we struggle with insecurity is because we compare our behind-the-scenes with everyone else’s highlight reel."

I encountered this quote a few years back and it resonated deeply. As a deep thinker prone to overthinking, I am greatly aware of my inner thoughts, feelings, and personal battles, none of which are visible in others. This quote serves as a reminder that we all face challenges, and just because I am aware of my own flaws while seeing none of others’, does not mean I am alone in my struggles.

Likewise, when we compare our messy coding process to the polished code in another developer’s pull request, we do ourselves a disservice. We deserve better, and so does our mental well-being.

We all know that comparison can be detrimental, often leaving us feeling inadequate or unworthy. In an ideal world, we wouldn’t compare ourselves to others at all. However, as social creatures, comparison often serves as a gauge of our standing in the world. Therefore, it’s a matter of finding balance—a matter of taking comparisons with a pinch of salt and reminding ourselves that these are not like-for-like comparisons.

If you've opted for a career as a Software Engineer, you've entered a highly competitive and constantly evolving field. Staying current means regularly encountering unfamiliar topics, frameworks, languages, and technologies. You'll navigate through uncertainties, experience both frustration and triumph, and alternate between tension and relief. Along the way, you'll inevitably write code that's questionable, but you'll also learn to refactor it and prepare it for a approval-worthy pull request.

Pair programming is one great way to remind ourselves and show others that coding can often be a messy process. So is talking about our less-than-perfect experiences. So let’s celebrate our successes, but let’s also celebrate our “bumpy roads” that led us there.

Coding can be a messy process; Let’s normalise that.