Well, I don't hate fixing performance problems, but I do see the value in deprioritizing them (... indefinitely, sometimes) if they don't render the program unu

Well, I don't hate fixing performance problems, but I do see the value in deprioritizing them (... indefinitely, sometimes) if they don't render the program unusable by the end users, for precisely the reason you mentioned ("it's expensive work which doesn't deliver any functionality and can break things"). It's especially exacerbated if you know the way forward would probably take a week (or month, or more) of development effort, and for what? An incremental 10% improvement in load times? When management shifts these priorities, it's not just at the scale of the individual programmer, it's company-wide. Suddenly it's a lot more justifiable to spin up projects for larger-scale performance fixes. Otherwise, you mostly have scattered individual efforts to clean up low-hanging fruit. Regarding breaking things specifically -- that's one of the clear wins I've found with testing. Something breaks, so you write a test to (a) verify your fix and (b) ensure that you don't break that same thing in the future. Sure, there's extra upfront cost to writing good tests, but that saves you (or your coworkers) debugging effort down the line. (disclaimer: I work at Google but am not on the Chrome team. These opinions are my own, etc etc.)