Re: "Quality" is a structural attribute, not a bolt-on
"you use that to WRITE the algorithm, and once done, you NEVER! HAVE! TO! TEST! IT! AGAIN!!!
... until your business requirements change and you have to modify said algorithm so that it returns a different results set under circumstances x, y and z, but otherwise must return exactly the same data as it has been doing until now.
That is the value of full and proper unit test coverage - it's not about making sure your code works right now, but ensuring that it continues to work as expected after modification. Otherwise, the chances are you're just playing whack-a-mole with bugs.
The idea that "just writing it right in the first place" is an archaic throw-back to the pre-internet era when systems were monolithic and updated once in a blue moon by a single big-bang operation. Businesses now expect new functionality to be delivered rapidly and seamlessly, and as developers, we have to adapt or die.
The irony is that until a few years ago, I used to think along the same lines - "what's the point of unit tests? I've manually tested my code and it works!" But now, when faced with modifying a chunk of code that was written a year ago by someone who is no longer with the company, finding a good suite of unit tests that document how it's supposed to work and catch what I might accidentally break is not only reassuring, but also vastly increases the speed I can work at.