Influencing Your Team to Ship Better Code (When you aren’t the boss)
A friend reached out recently for some work advice. He is the newest and least experienced software engineer at a fairly small early-stage startup, but already he is noticing that the team doesn’t seem to care about code quality. He wants to be able to influence the team to ship better code, but he’s not sure where to start.
Code quality can’t always be the highest priority
Code quality isn’t always the highest priority, nor should it always be the highest priority. Early in the life of a product, shipping something is more important than working perfectly cleanly.
A startup with nothing shipped, no customers, and very clean code
is a dead startup.
A startup with gnarly code and tons of customers might just survive to pay off its technical debt.
Ship better code rather than nurturing bad habits
In my friend’s case, it seemed like the rough code quality was getting in the way of even shipping early versions of the product. Sometimes, a week after they shipped iteration one of a feature, iteration two stopped dead in its tracks due to tech debt.
Fixing bad code quality habits on a team is hard. It is especially hard if you don’t have the organizational power to do it. You may never be able to fix them.
It isn’t 100% a technical problem.
It is a problem of attitudes and power structures and people.
Know that first and foremost.
I’d approach it as I would approach any difficult conversation with my co-workers. Don’t start with your opinion or your proposed solution. Start with the data.
Data is something that everyone can see and something that can be measured. You can’t attack the whole problem at once. Talk specifics.
The approach: how to talk about code quality
The best time to intervene on bad code quality is right after it causes a problem. I mean a business problem: the type that money people and people-who-answer-to-money-people care about.
Did your team just miss a deadline because the new feature collapsed under a pile of tech debt? Wait until people stop freaking out, and then present your case.
First, the data:
Start with what everyone knows and can measure. This class is 1,000 lines long, and has no tests. We missed a deadline because we were working up to the last minute on it and then we got hit with a bug an hour before the demo.
From the data, the inference:
We were working to the last minute because it is hard to understand a 1,000 line model. We had a bug because we didn’t have enough good tests.
Then, the suggestion:
We should start covering this in tests. We should measure our test coverage. We should not allow any new code unless it comes with new tests. We should put a hard cap on the LOC of models.
Finally, the buy-in:
Go in for the “ask”. It is hard to say no when the quality problems so clearly led to a bad outcome. It is much harder to argue against a real missed deadline than a theoretical “best practice.” It helps if you volunteer to do most of the upfront work. Put yourself on the hook for integrating a test runner, setting up CI, or creating linter configurations.
You can influence your team to ship better code.
Just remember: People don’t want to do bad work.
They simply disagree over how to do good work.