The Unstoppable Urge to Refactor: A Developer's 'Big Plans' vs. the PM
Description
A three-panel comic from 'theycantalk.com' featuring two beavers, illustrating the classic conflict between a developer and a Project Manager (PM). In the first panel, one beaver looks at a river scene and says, 'i have big plans for this code.' The second panel reveals the roles: a larger beaver labeled 'me' (the developer) sits next to a smaller one labeled 'PM,' with the PM pleading, 'please, no more refactors.' The third panel is a close-up on the developer beaver's face, showing a wide-eyed, determined expression as it thinks to itself, 'big plans.' The humor lies in the relatable tension between engineering's desire for code quality and architectural purity versus the business's need for stability and predictable feature delivery. Developers, much like beavers, have a natural instinct to build and improve structures. The 'big plans' represent ambitious, often necessary refactoring projects that can feel essential to the developer for long-term health but appear as disruptive, high-risk, low-reward endeavors to a PM focused on the product roadmap
Comments
7Comment deleted
The PM's definition of 'done' is when the feature is shipped. The senior engineer's definition of 'done' is when the 'big plans' are complete, which, according to the roadmap, is somewhere around the heat death of the universe
Every time the PM says ‘big plans’, I know the color-picker ticket is about to spawn a Kubernetes cluster and three new platform teams
The PM thinks I'm refactoring for code quality, but really I'm just building the perfect abstraction to finally justify rewriting the whole thing in Rust next quarter
Every senior engineer knows this exact moment: you've finally mapped out the perfect refactoring strategy to eliminate that gnarly coupling in the core service layer, maybe introduce some proper domain boundaries, extract those god objects into something resembling SOLID principles... and then the PM gently reminds you that the last three sprints were 'just refactoring' and stakeholders are asking why velocity dropped 40%. The beaver's thousand-yard stare perfectly captures that internal dialogue where you're simultaneously planning how to sneak the refactor into 'bug fixes' while knowing deep down that today's technical debt is tomorrow's P0 incident at 3 AM
PM: no more refactors; me: cool - I’ll rebrand it as “strangler-fig migration to reduce blast radius and MTTR” and ship the same 3k-line PR
Just a small refactor: a 12-week domain model rewrite tucked behind a feature flag and filed as an NFR
PM's dam empire scales infinitely; dev's refactor bandwidth caps at one log per sprint