Table of Contents

Introduction

As I reflect and contrast the experiences of engineers right out of university with my experience in my first full-time job, a common tendency I have observed is the need to refactor large pieces of code without consulting the original author. This often stems from the belief that code could be improved without taking time to understand the constraints and reasoning behind the technical decisions made by the previous author.

<aside> <img src="/icons/light-bulb_yellow.svg" alt="/icons/light-bulb_yellow.svg" width="40px" /> In the grand scheme, the proposal could meet all the business, time, and resource constraints that validate the need to make that change. Nonetheless, it is still a hypothesis until it correctly disputes strong indicators upheld as truth by the previous approach, thereby justifying why the code should be refactored.

</aside>

Early-Career Engineer Trap

One good trait of early-career engineers is that they are very excited to be building software. For many (and reminiscing on my time right out of university), it was hard to believe I was finally getting well-paid to do what I enjoyed most. Sadly, this enthusiasm could fluctuate as we progress through our careers, and the tricky part is sustaining this (topic for another day).

In the context of enthusiasm and refactoring, without the right management or mentorship, it's very easy to have a net negative or short-sighted result. When an enthusiastic but inexperienced engineer sees a piece of code that doesn’t align with what they term “good or efficient code,” the first sequence of thoughts often revolves around:

1. Deciding to modify it in isolation,
2. Create a pull/merge request with the change and
3. Expect that their team members will welcome it with a broad smile.

Loop-hole: Modifying Code in Isolation

<aside> <img src="/icons/light-bulb_yellow.svg" alt="/icons/light-bulb_yellow.svg" width="40px" /> The above is a typical broad view of shipping software; the problem lies in modifying the software in isolation with little to no consultation from the previous author or more experienced engineers who manage or contribute to the code frequently.

</aside>

Often, the decision to modify in isolation always doesn’t factor in one or more of the facts that:

1. The previous author(s) invested significant effort in weighing multiple tradeoffs before settling on the present approach,
2. One could be lacking a significant context or knowledgeable business constraints influencing the decisions, which could be violated post-refactoring,
3. There could be a cascading effect across multiple teams - especially for shared or critical pieces of code,
4. There could be pending issues with the current solution and documented considerations or alternatives,
5. The rest of the team might not share a nearly similar level of priority for the proposal,