Good for you for leaving things better than you found them.
But when management compares your output with Cowboy Chris, the fastest code-slinger in the West, they'll think he's better for the company even though he's racking up tech debt on his journey.
Ideally you'd get credit for the good work you do that makes the whole team more efficient.
being (sustainably) fast and producing quality code often go hand in hand. If management doesn’t know Cowboy Chris generates most of the debugging time, that’s a management problem.
A good management team is aware of which people are fast in short sprints but end up tangling things up on longer efforts, which people take time to build steam but never hit that slow-down, and which people fit other patterns (for example, the extremely rare fixers who can take Cowboy Chris’s shit and funnel it into something useful, or the even rarer speed demons who can sprint like that forever because they are like Chris but they work cleanly too)
Good engineers, given the chance, will find and stick with those managers too.
> But when management compares your output with Cowboy Chris, the fastest code-slinger in the West, they'll think he's better for the company even though he's racking up tech debt on his journey.
Maybe.
OTOH, not only can focussed refactoring make delivering the features it is associated with faster, but refactoring—delivery-focused or not—is a really good way tonbuild knowledge of and proficiency with a code base, so if you aren't doing huge quantities of non-germane refactoring, it can actually be a personal delivery-speed enhancer, as well as the benefits for the team.
But when management compares your output with Cowboy Chris, the fastest code-slinger in the West, they'll think he's better for the company even though he's racking up tech debt on his journey.
Ideally you'd get credit for the good work you do that makes the whole team more efficient.