Having said that in some places and on some days (and working with some people) I don’t always have perfect energy for the fight.
And if you have to explain that alot then you become a problem to the team lead.
- Mike Judge, Office Space
Happy to have discussions and elucidate to others the change, and make whatever documentation necessary available, but if some leader somewhere things I’m a “problem” for merely having done the work…okay, let me solve that problem too: bye.
That’s an environment with serious trust issues manifesting as micro-management and I’ve got a severe case of post-micromanagement-stress-syndrome.
Sometimes engineers “feel” the need to refactor something that’s not related to a high priority project and end up burning days as they weren’t experienced/competent enough to really know where that string they pulled lead and got stuck fixing newly failing tests etc. and in the examples I have in mind the context isn’t the usual “product feature must deliver pressure”, it’s actually pure engineering project, where we had to rearchitect a system before our scaling hit a brick wall, so interesting engineering work by engineers for engineers and still some folks just chase squirrels.
I totally love the freedom I’ve enjoyed to fix things at my discretion in my career, but not everyone is good balancing the time/place or “picking your battles” and sometimes you gotta reign it in in others or the stuff that needs to get done won’t be.
One solution has been to do a 1:1 screen share with someone else who has more context or feels the impact of the changes more in their day to day, and work with them to get more constructive feedback and to approve the PR.
If anyone questioned me like that, I'd leave that company, that's kind of ridiculous.
That said, as much as I try to maintain a certain level of quality, eventually my designs break and I need to refactor things. In times like that I'm glad I have a good level of automated testing to catch regressions.
Sounds like you’re doing it right!
> I don't think this approach is suitable for most software engineering processes
I think that’s just badly managed technical teams.
What I started doing a few years ago was to group issues together by module/service. When I’d push work to the todo board, I’d include other, similar work. After all, it’s much easier to fix things when you’re already in context.
How can you tell that tech debt is at zero.
How hard is it to operate?
How often does it fail?
How hard is it to change?
How much time is spent in toil?
These questions underpin the idea of debt.
While there is no standard way to measure, I think almost any developer can look at code and either be impressed by its elegance or disgusted by its depravity.
Most people aren't very good at code cleanup, so I take the janitor role, since I enjoy it and have the skills.
Works pretty well for us.
If you could measure and graph technical debt, I would find the idea of "planned debt" compelling, but the reality is is that people only understand they are in debt once they see the bill, and at that point it's too late. Rational people will see the bill and say "I don't want to pay that."
If the CEO or CTO do not treat debt seriously and like it is their personal problem, that attitude will quickly be organization wide.
Debt is a type of corruption. Corruption by its very nature grows greater than linearly. Just like with COVID, corruption and debt permissiveness have an R0.
When one person is corrupt, then another person is also incentivized to be corrupt. Every person who is ok heaping on debt/corruption is another person who won't resist it and instead breed self-interest/defensiveness, cynicism, and learned helplessness.
This all leads to a core understanding of corruption (and imho, technical debt), which is that you cannot plan for corruption and it will grow much faster than you expect. Once the culture is set, it is an incredibly hard thing to change. The people most able to make the change will have been the first ones upset by the culture in the first place, maybe enough to leave. The people who have thrived and seen organizational success and therefore gained organizational clout will be the least interested in a cultural change and the least interested in seeing the difficulty of their job go up.
When a dev invests time improving the codebase, refactors mercilessly, and cleans up the code - they gain mastery over it, respect from their peers, and trust over the architecture. This is fantastic for your career long-term.
In reality, with developers hopping between jobs, it's a difficult case to make. Ironically, a hot job market for developers ends up hurting a key mechanism for technical mastery.
If the volume of changes really gets out of hand I'll split it into two smaller PR's, then deploy one PR, merge main into to the other, and deploy the other. It's a balancing act sometimes to know where to stop and call it "good enough."
1) Be upfront about it, the PM or whoever is making the business decisions should at least be aware that the ticket is not being addressed in the quickest way possible. Sometimes that's a real problem and that conversation is worth having. Mostly it's not an issue, at least in my experience.
2) Pretty much never done while fixing a bug, only when extending functionality.
3) Done in separate commits / PRs,but all linked to the feature ticket. Preparatory work for the change, basically.
I may also be doing it wrong, but this is what seems to have worked best for me and my teams.
I'm pretty certain that means new features are implemented alot more easily. Hard to quantify though.
I can say I'm always thanking "yesterday me" for finishing the job and cleaning up whatever "today me" is working on.
It's possible for me to do this because I do most of my programming on my own. I don't think this approach is suitable for most software engineering processes because they tend to deprioritise technical debt.