Sarah MeiVerified account

So where does communication skill come into all this, you might ask? Is this another rambling thread that took an unexpected turn into philosophy and isn’t coming back? (I mean, that’s a fair cop. I do a lot of those.)

Well, let’s say I’ve convinced you that you need to do those small, opportunistic refactorings. You’re all in! You’re ready to work through the discomfort of introducing deliberate inconsistency in the name of improvement over time! Fantastic! HOW do you do that?

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.