Some do suggest developers are too protective of their own code, but I'm certain 99.99% of developers would actually prefer to get their code broken early on, rather than having to deal with shouting boss' boss 2-3 months after deployment.
In my opinion the actual reason is lack of time.
Once you are pressed for deadlines, there's direct conflict of interest, and it's easy for everything becomes about meeting the deadline and less about quality of both tests and deliverables.
What developers probably are bad at is asking for that additional time up-front for testing and fixes. Management of course can be as bad at allowing that extra time, so it's a team job to get it working.
There are of course some other factors like superior domain knowledge or lack of user empathy that could affect ability to come up with right tests, but these should be easier to overcome if necessary time is available.
Some do suggest developers are too protective of their own code, but I'm certain 99.99% of developers would actually prefer to get their code broken early on, rather than having to deal with shouting boss' boss 2-3 months after deployment.
In my opinion the actual reason is lack of time.
Once you are pressed for deadlines, there's direct conflict of interest, and it's easy for everything becomes about meeting the deadline and less about quality of both tests and deliverables.
What developers probably are bad at is asking for that additional time up-front for testing and fixes. Management of course can be as bad at allowing that extra time, so it's a team job to get it working.
There are of course some other factors like superior domain knowledge or lack of user empathy that could affect ability to come up with right tests, but these should be easier to overcome if necessary time is available.
Do you think that devs are bad at design a full coverage manual testing?
I personally don't think so - there might be people that are a bit better or less so, but I don't think developers automatically make bad testers, no.