I stopped asking because the answers were always some variant on "that encourages programmers to be lazy, because they know QA will be there to catch it" and because it seemed like lot of companies treated that question as a culture fit red flag. The responses were pretty hostile, like I'd asked why none of the engineers were wearing suits.
I have no idea whether it's a good idea, but the current tech culture seems pretty opposed to it.
As a new manager, he was who I leaned on the most to find out things, and who saved my ass on a number of occasions.
He deserved more respect than he got.
If the QA person has skills along the lines of a software test engineer (like at Google and other places) and can actually create tools and automate things and write some unit tests or acceptance tests, then they're half-a-programmer and I'll be happy to rely on them and share the work. Otherwise I assume the QA is there just to bow to management/marketing and give the OK for deploys.
It's also worth mentioning that when coming up with our values/principles, we started with the understanding they can and probably will change over time, especially as we grow. So while we don't have dedicated QA team today, we'll keep an open mind do whatever works best for us in the future.
That phrasing is a bit different than what I think they meant. Programmers familiar with the problem domain should QA the code of other programmers is how I took it.
I've never seen the value in "pure" QA people largely because you need to be a developer to be an effective QA person [writing automated, repeatable tests] at which point you are just looking to use the developers that are more meticulous than the others to write those tests.
They are still ultimately software developers / programmers / whatever. Its just the problem domain they spend half their time on is QA instead of Ops or whatever else.
Maybe I'm just used to being part of an IT department embedded in a larger company where we tend to mix a couple things in a single position. :P