Sarah MeiVerified account

Remember, there were TWO problems that got you here - organizational pressure to forego refactoring, and a feeling that refactoring can only be done when you have time to do it all at once. At this point, we’ve only fixed the easier problem.

There are many in the Software Development Thoughtleadership Corps who take an individual, moralistic approach to organizational pressure. “It’s your job as a professional!” they say. “Just write good code! If they push back, just tell them ‘that’s not how I work!’”

This, of course, is horrible advice that comes from a place of extreme privilege. It does _occasionally_ work for white dudes. For most of us, though, if we tried it, we’d be labeled “difficult” or “naïve” and eventually managed out via tepid performance reviews.

And besides, even if the organization capitulates based on your ability to defend the moral high ground - it doesn’t actually fix the root issue.

To actually fix it, you need to negotiate with the individuals who are applying the pressure. You need to understand THEIR incentives, and align your desired changes with those. You don’t want begrudging acceptance. You want enthusiastic buy-in.

If you can’t get that, then it’s highly unlikely that your hoarded codebase will ever improve. Your ability to write good code is thus quite literally constrained by your ability to communicate with other humans.

It’s not as impossible as it sounds. On the surface it might look like your manager’s desires (i.e. for you finish features faster by skipping the small refactorings) are diametrically opposed to yours.

But there’s almost always a win-win in there SOMEWHERE. You can start by trying to understand what is driving that desire for them. It might not be what you think.