Comment by onion2k
3 years ago
Guess how much would get done if you learned to explain why that work is important to a non-technical colleague? Lots. People don't always understand code, but they do understand problems, and why those problems are important to keep on top of.
If your PO is sensible then a couple of paragraphs explaining why refactoring is important with a closing line that says spending a week catching up on refactoring now will save 4 sprints of work in a year's time will get you the time. People aren't stupid. Once they understand why something is necessary they've very receptive.
Also, add refactoring time in to your estimates in the future and you won't end up in this situation, plus the code that's committed will be better.
Do your non tech colleagues need to have approval before saving a spreadsheet or writing a doc? Do they need to plan it out in tickets weeks ahead of time and get sign off before starting their work? Then report status daily on their progress?
One of my friends is a technical writer and she is amazed we put up with this on the engineering side. No one would ask it of other professionals.
>Guess how much would get done if you learned to explain why that work is important to a non-technical colleague? Lots.
From my experience, this is more a cop-out than anything else. At some point I'd expect you understand children with a track record of doing as they are told and informing you of important details do not need to be strictly parented around every corner. To expect that very thing from adults with way bigger incentives to behave feels off.
This is like needing to ask to go to the toilet. It's degrading. Utterly disrespectful. You expect people to stick around?
Updating a dependency, refactoring some code, or just making a 'simple' change sets off a chain of events that affect other people. The other devs need to review the code, the QA team need to test it, and then regression test the rest of the app, the devops team need to deploy it, the legal team need to update the legal documentation that lists the licenses for the dependencies the code has, the technical writers need to change the docs if the update has a visible impact for users, and so on, all across your org.
What looks like a small change to a developer is never actually a small change.
I really hope there aren't that many people impacted when you go for a piss.
Once you have technical decisions being taken by non technical managers you are sunk. It's hugely insulting to experienced engineers and it's a major reason that people leave. People crave respect and if they perceive that they aren't getting it, they will do what they can to get out. You cannot micromanage engineers in this fashion and expect to have good retention.
1 reply →
> making a 'simple' change sets off a chain of events that affect other people
Not every change affect other people, but isn't that my call to decide? Also "simple" in quotes implies it isn't i.e. you aren't trusting what you are told.
> What looks like a small change to a developer is never actually a small change.
Not true, this is hyperbole. If the lawyers need to be consulted to change dependencies this is something a developer should know and account for. Why keep devs out of the loop?
I consult with other devs, QAs (if needed) & external teams, perhaps with a ticket if deemed necessary, other times just a PR. I run the (CI) regression, I schedule/announce and perform deployment (we have platform team, not "devops" which is generally done by the app devs), I write the app docs, we have no legal documentation that lists the licenses for the dependencies.
I do this as a dev - why should I not be able to recognise if a change is small or not? let alone never being able to.
You are right if you work in an organization that is overly bureaucratic and incompetent. For the rest of us not so much.
Explaining why maintenance is necessary time and time again (tech evolves fast) is soul-crushing and quite frankly rather demeaning. I need x amount of hours for maintenance work every sprint, or the codebase will slowly become outdated and undesirable to work with. Again, tech evolves and changes rapidly, open source packages die quite often. Maintainers abandon their packages (my PO likely has no idea that we rely on free open source software to ship features), there are security issues with using abandoned packages… To sum up: when I see issues, I want to fix them. If I have to go through a corp process and ask for time to fix the issues… I sort of tend to lose the apetite/mood. This right here is the core issue.
> spending a week catching up on refactoring now will save 4 sprints of work in a year's time will get you the time.
In my experience that’s very rarely if ever the case. Managers will always favor features over fixes in the kind of company that ends up with a crippling tech debt problem. They got there by not listening to engineers and having salesmen managers. These companies never change and no manager wants to be the one who’s fixing things for the next manager after they get promoted. People are idiots (maybe) but they respond to incentives. And very often the incentive is that problems that may arise in a year or two are someone else’s problems so not worth fixing now.