alt Hacker NewsWell, we clearly come from very different work methodologies.
You have deadlines, velocity is a goal rather than a measurement, and probably several other (IMHO) process mistakes. In such systems, doing what is best for the organization can often be bad for your personal career. Still, that's probably the norm in much of the industry.
My view is that having bugs is costly. They cause problems in development, and alienates users. A bug free code base is an incredible asset to have!
You say it's inefficient to "switch context" and fix a bug the moment you find it. There is some truth there, but... (1) there are ways to work without huge context load, (2) I don't have to fix the bug that very minute. Usually, I make a note and get to it the next day or so. Also (3) the average bug fix in a well structured and tested code base is usually pretty quick.
> If your way was both more efficient AND more aligned with human nature then everyone would be working like this
This assumes the software industry is really well organized. After 40 years experience writing software, that is just hilarious! Though I probably also thought that before I got involved with much better organizations.
I suspect we do. Though you misunderstood my comment about velocity. I was using that purely as a way to demonstrate that something measurable is affected by dropping everything to fix a bug. Sounds like you do wait for an opportune moment to fix a bug and do not make it a top priority after all so I think you see the cost of interruptions.
But yes I am aware of lots of parts of this industry where you do not need to rush a project no matter what. I worked at places that had a breakneck velocity and at places where it is much more chill. I prefer the latter but I can say that I still want to ship software which means goals and deadlines. Bugs should be fixed ASAP but priorities must also be respected.
After 20 years doing this as a career, I agree this industry is a bit of a mess :)