[MartinCron]

Eh, there's a difference between testing code you just wrote, and actual QA

That's what I'm challenging. I think the whole "developers can't test their own code" business is a myth.

There really is something to the idea of the "curse of knowledge" and there really is a different mindset when you're trying to make something work and trying to make something break, but isn't switching between contexts and mindsets and levels of abstraction a core part of being a developer?

Developers can get lazy and don't bother testing their own code. Developers can get sloppy and don't bother thinking through corner cases. Developers can be short-sighted and write poorly-encapsulated code that is brittle and creates side-effects.

[pavel_lishin]

> isn't switching between contexts and mindsets and levels of abstraction a core part of being a developer?

Sure, but you can only do that so rapidly. Why not just let me stay in the flow, and test the changes I expect, and pump out more code and bugfixes, and let the QA look at things I might not catch?

I'd rather do a quick test of my code and send it off to QA than spend two hours second-guessing myself as to whether I've tested everything in-depth enough.

[MartinCron]

I think the throughput you get of pumping out more code (without really testing it) may be a micro-optimization.

I only bring this up because I once worked at a place with a really strong, borderline omniscient, QA Department and I felt myself getting sloppy and checking in things that I knew were probably wrong, but I knew that QA would find it and tell me how it was wrong. It appeared to be optimal for me as a developer, I got lots of code pumped out, but as far as the whole organization or product, it was a net loss.

Subsequently, I've worked on a few projects with no dedicated QA people, and my overall "getting good software shipped to users in the real world" effectiveness hasn't decreased.