It's easy to make the assumption that developers haven't ran the code at all, but I find in reality that's rarely the case. In my experience it almost always has something to do with an unexpected environment variant.

It's very easy as a developer to get so comfortable with the "happy path" of navigating code that you forget to look outside of the happy path when devising your test cases. It takes time to learn to identify the test cases you're not regularly exposing yourself, and these test cases are often ones not described in a requirements or specs doc.

As a developer this bugs me too. I once was team lead on a team which had two developers (bad hires) who seemed to believe that it was only their job to write the code, someone else's job to run it and test it. I started putting "and test the code" in the tasks; a team member successfully lobbied our manager that that was another task. So now I had to write 2x as many tasks, and the predictable result happened: the developers who didn't test their own code grabbed all the "write the feature" tasks and banged them out rapidly (easy to do when you don't make sure it works!) The more experienced developers were left to pick up the "and test what you wrote" tasks, which really amounted to rewriting the bad code. Then management said, "Why are you (senior developers) wasting so much time testing code? It generally seems to work and we can always fix it later."

There was just no way to win. I'm glad I don't work in that environment anymore.