Sarah MeiVerified account

And at that point, all you’ve accomplished with the money & time they gave you for the rebuild is to shift your problems to the network layer, where they are way harder to see, analyze, test, and fix. That is not progress. IMO that’s engineer malpractice.

So...is it just impossible to improve your working conditions, when you’re working in a hoarded codebase? Are you just DOOMED to feel anxious every time you need to go near the precariously balanced User class until one day it just...falls over on you?

Ha ha! Of course not! This is where communication skills come into play. Because it is not at all trivial to even _understand_ the incentive structure that got you where you are, let alone to negotiate a new, healthier set of incentives.

The most common “presenting” pathology in the hoarded codebases I’ve seen - by far - is that developers don’t feel they have time and/or permission to refactor code.

Frequently occurring alongside that pathology is another - that developers see “refactoring” as a completely separate activity from building features or fixing bugs. A key indicator of this pathology is seeing stories in the backlog like “refactor user class.”

Just like its physical analog, a hoarded codebase only improves if you intensively work on changing those habits. This means deciding you will always do small, opportunistic refactorings when they appear to you in the course of fixing a bug or adding a feature.

I’m not talking about taking three extra days on a 1-point story to totally rewrite the user class. I’m talking about noticing a method you’re working in is out of place, and moving it - even if you don’t have time to extract the rest of the concept from the 8000-line file.

Just like when you’re dealing with its physical analog, your number one most important mantra when you want to improve a hoarded codebase is: Improvement Over Consistency.

This is SO HARD for us as developers. It gets drilled into us from day one that consistency is key to good code. And if you had good code, then sure, that would be true. But right now you don’t. Improvement Over Consistency.

One book on the shelf and five in the pile is better than six books in the pile. Improvement Over Consistency.

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.

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.

It could be pressure from above, or a positive reputation that they want to preserve, or that they really need their full bonus this year because they already put a nonrefundable down payment on a swimming pool.

Humans are complicated systems. They operate under a constantly- shifting set of motivations - many of which they are not consciously aware of. But as you improve your communication skills (by doing it badly at first), you start to get a sense of what works for different people.

No matter how you approach it - by staking out the moral high ground, negotiation, subterfuge, or some combination - changing the incentives you operate under, and the habits those incentives create, is HARD. And sometimes it’s not possible.

Or at least, it might not possible for you to achieve, with your current level of communication skill.

Either way - notice what’s limiting your ability to write good code. It is NOT: - knowledge of the latest framework - how fast your tests run - your own weak moral fiber - your manager, PM, or CEO It IS: - how well you understand & work with people

One important note here is that people who are _not_ in the demographic majority need much better communication skills to achieve the same results, vs people who are in the majority.

This is a large part of what discouraged me, early in my career - that I couldn’t be blunt like my male peers, because it didn’t land the same way. To be effective, I had to put a lot of calories into learning how to people, while the guys spent those calories learning new tech.