This is a result of always having the refactoring put on hold for feature development. Eventually engineers realize the only way to address tech debt is to refactor as part of a feature or bug fix.
This doesn’t happen when developers have trust they’ll be allowed to refactor although sometimes it’s a case of learned behavior from previous employment.
> This doesn’t happen when developers have trust they’ll be allowed to refactor although sometimes it’s a case of learned behavior from previous employment.
To my surprise, this is not always true. Some engineers do things because they have fun, even senior ones, and they will keep on refactoring things until there is a hard stop.
Best is to never generalize. It may depend from team to team, etc.
If you don't let them do this from time to time they will quit eventually, IME as a manager. Whether that's beneficial to the org or not is debatable. You can kind of "release the pressure" in a planned manner via hackathons, but those almost always never have the appropriate frequency.
When my coworker did it, it was the result of zero self discipline or focus, so he straight up got distracted by thinking of a way he could rewrite the whole app instead of making the two line *already understood* fix. He was a very good programmer and a terrible engineer and terrible coworker.
The prioritization of refactoring is strongly context dependent. A small startup with a fast moving product trying to acquire and retain customers cares much more about serving said customer right now than an established business who has more freedom and engineers available to dedicate time to forward thinking projects like refactoring.
I've worked at both large companies and small startups, and I've never seen taking on tech debt pay off. Features never get delivered as quickly as anyone wants, but sometimes tech debt completely prevents even thinking about features, and not being able to even imagine implementing something is a much worse problem than being 2 extra weeks late to the newest pivot. If I were starting a software company today, I'd want to keep my POC code about as clean as I'd keep production code at a large company. Well, cleaner. It's going to be alive as long as you are, and there will never ever be a good time to rewrite it.
Having said that, I am very skeptical about what some people identify as tech debt. Things like "we're using X logger instead of Y logger, this codebase is unmaintable" I tend to not prioritize, but things like "this system looks weird and we don't understand if the code is wrong or the documentation is wrong" is something that should be addressed with high urgency. It's very easy to spend a lot of time maintaining misbehavior that should just be fixed, and the first step is understanding whether or not something is wrong.
I do that on non-time-critical cases, if it doesn't matter whether I deliver it within an hour or day better to just do it now when I have it fresh in my mind.
Okay I must have forgotten this, now that you point it out. But that’s nowhere near as elegant as compact compared with how JSONata handles it. The ideal tool probably lets you choose. Xpath, jq, jsonata, etc
I just encountered this setting up my personal domain email.
It’s super annoying to get the powershell exchange online plugin working on an M1 Mac. The documentation says to use homebrew, but to work around the M1 issue you have to then download a specific package from Mac Ports and manually symlink some libraries.
It was really a poor impression to realise it’s so much harder to set up on anything but a windows machine.
This doesn’t happen when developers have trust they’ll be allowed to refactor although sometimes it’s a case of learned behavior from previous employment.