The “designers should code” bullshit and a not so new idea

True to some extent, but the more you know about what is and isn't possible, the closer you are to basically knowing how to program. I suppose how abstract your knowledge can be depends on what you're trying to do.

For example, I think game designers need to know a significant amount about how game engines work: maybe not the algorithms of, say, gouraud shading, but they do need to know what's possible and not possible in NPC AI, and the more complex the behavior they're designing is, the more they need to know about how NPC AI actually works, to have even a reasonable guess at how their ideas would translate into reality.

A few people have argued this under the labels "computational thinking" and "procedural literacy", a category of skills that doesn't necessarily involve knowing the syntax of C++, but does entail being able to think in terms of algorithms and technologies. There's also an older idea of "design thinking" that sees it as almost always including some technical aspect; that's common in architecture, where the ideal architect is a designer but still quite familiar with at least parts of material science.

But I can say the same about programmers when it comes to design.

This is something that needs effort from both sides if you care about final result

I also think most people are thinking from the perspective of the scrappy start-up, where you must be multi-talented in order to cover various roles. In large organizations there's designers that only produce wireframes, then another designer comes along and produces the final visual output, and finally another guy comes and codes it. Not that it's the right way to do it, it's just that the expectations are being set too high.

Instead of putting down web designers who can't code, appreciate web designers who do it. This comes from a web designer who can code.

But there are people that have a vested interest in playing designers and developers against each other.

I've seen this happen time and time again, both via internal management and external clients: feeding designers and developers separately different bits of information (but never the whole picture), letting them make commitments based on that information and only then bringing the two together. The end result is that in order to make good on their separate commitments, designers and developers are left with very little room to compromise, which undermines the cooperation. The goal of this little divide-and-conquer game is to pressure them to come up with a result they otherwise would not have committed to given the time and budget constraints.

There's a reason why designers and developers are often very deliberately hired or managed separately for the same project. There are plenty of people who believe having designers and developers work together too closely is not in their interests.