Depends again on the type of work, and it absolutely has something to do with quality. You’re caring about not breaking existing functionality, you’re refactoring, you’re moving forward with confidence in your code.

That’s absolutely a quality thing. I can assure you that you could move a lot faster if you didn’t try and meet such standards, not that it’d be a good idea necessarily, but in isolation it proves the point.

Developer testing is checking whether the code does what the developer themself thinks it should. QA testing is checking whether the code does what the customers / users / rest of the world thinks it should.

It’s a lot faster and easier than it used to be. Things like xUnit in the .net world make setting up tests friction free to the point where I question a codebase that doesn’t have some kind of basic unit tests. It doesn’t make mock testing or integration testing easier but I would argue if you know the base code and logic is sound those tests are less relevant.

One thing I found is that if testing is easy, your code structure does change a bit to aid with a “test first” approach and I don’t hate it. I thought it made me slower but it doesn’t, it ensures that when all the ground work is finished, the gnarly part of wiring everything up goes much faster.