Episode 452: Consulting refactor and extra work, extra scrutiny

Episode Overview

• The hosts discuss a question from a junior developer at a consultancy who took the initiative to refactor a messy legacy codebase without explicit permission from their manager or the client.
• They explore the potential risks and rewards of this "rogue refactoring," particularly the challenge of communicating the work after the fact and getting recognition for it.
• The conversation delves into the unique dynamics of consultancy work, where time is strictly billed and unsolicited improvements can be viewed as unapproved scope.
• A second question is addressed concerning how to handle excessive scrutiny and pushback on self-initiated pull requests that aim to improve the codebase.

Key Concepts

• Unsolicited Refactoring: The act of improving a codebase without it being part of a planned task or sprint. While well-intentioned, it can create friction if it's perceived as derailing planned work or costing unapproved time.
• Consultancy Dynamics: The hosts highlight that in a consulting relationship, work is often strictly defined by contracts and tickets. Refactoring that wasn't requested by the client can be difficult to justify, as it may not align with their perceived value or budget.
• Communicating Value: A central theme is the importance of framing technical improvements in terms of business value. Instead of just saying "I refactored the code," it's more effective to demonstrate outcomes like "future features will be developed faster" or "we've reduced the bug rate."
• "Whataboutism" in Code Reviews: The phenomenon where unsolicited or "off-the-books" pull requests receive a higher level of scrutiny and suggestions for ever-expanding scope, as the normal cost-benefit constraints of a planned sprint are absent.
• Hedonic Treadmill of Refactoring: The hosts humorously discuss the feeling that the anticipation of a clean codebase is often more satisfying than the reality after the refactoring is complete, as one's standards for "clean" simply adjust.

Quotes

• At 00:06 - "It takes more than resolving deadlocked technical disagreements by picking number three to be a great software engineer." - The podcast's opening tagline, setting the stage for discussions on the non-technical aspects of software development.
• At 03:45 - "Tired of just moving tickets and fixing bugs, I decided to refactor the front end of the entire application." - The listener frames the core problem: taking initiative to improve a poor codebase when regular work feels unfulfilling.
• At 05:05 - "It's hard to tell them after the fact because what they might think is, 'Wait, what about all the features that we wanted that we didn't get because of all this time that you took?'" - Jameson highlights the primary risk of presenting unsolicited work, which is the perception that it came at the cost of planned feature delivery.
• At 19:32 - "If you want to learn and you're passionate about improving stuff... you could advocate for either specific targeted improvements to be made in the sprint or or just to say like, 'Hey, I want a teeny bit of capacity also to do some of these improvements to learn.'" - Jameson suggests a proactive approach to formalize and legitimize improvement work within the team's existing process.

Takeaways

• Frame unsolicited work by its positive outcomes. When you present improvements you made on your own initiative, focus on the tangible benefits you've created, such as increased development velocity for future tasks or a reduction in bugs, rather than the process you followed.
• Proactively formalize time for technical improvements. To avoid the friction of "off-the-books" changes, advocate for officially allocating a small portion of your team's sprint capacity to learning, experimentation, and addressing technical debt. This makes the work visible and approved.
• Communicate with your manager before going rogue. Instead of refactoring in secret, have a conversation with your manager about your desire to improve the codebase. You might be able to create an official process for this work, which avoids surprising the team and ensures everyone is aligned.