Earlier quoted context omitted.
Yep, the curse of doing things right. You can't prove it was needed. You need to demonstrate that you are fixing genuine problems, or you will eventually be replaced by someone who delivers faster, even if there are subsequent bugs. One way to do this is to negotiate with the business in what needs doing, using risk. If you think there is a risk of a security or stability issue then you should be able to assess that…
While this works with rational actors the experience I have had in the industry is often the opposite. In fact, the company I work for now is probably the only company I've worked for in the last decade that actually correctly evaluates risk. The average corporate drone overseeing the engineer org is very typically the least rational actor in the entire org. Given the opportunity most start-up and mid-tier business w…
The business should be able to choose what the priorities are. The business does not exist to produce beautiful code.
If a business wilfully disregards security or stability risks that they were informed of, and they get bitten, then they will almost certainly end up paying more to fix in resource and engineering time. But that's the trade off they chose to make.
If a business plays the blame game here, it's simply time to find another job. They are not going to be a good place to work at all.