Book designers don’t necessarily need to know how to sew a bookbinding. But they should probably know how different bindings affect the feel of a book: how a nice coptic stitch can allow a book to lie comfortably open, while a heavy dose of glue will cause a volume to snap at the hand that reads it.
Interior designers may never need to know how to lay tile by hand. But they should probably be able to account for grout as an extra dimension—otherwise a perfectly planned set of bathroom tiles will have to be cut to fit.
Every medium has its own grain. You don’t have to be the person working the material yourself to design for a given medium well. But it certainly helps if you understand something about how the grain of the medium really feels, and that’s hard to get without some first-hand exposure.
If you design user interfaces, your medium is software, and its grain is expressed in code.
Unfortunately, most designers are kept about as far away from code as possible. We have all kinds of design and handoff tools that are built to abstract away the code grain of software. They’re not bad tools, they’re useful tools, but if you’ve never worked closer to the medium yourself, you’re gonna have a hard time even seeing what choices are baked into these tools that you don’t have any control over.
There are all kinds of software architectural decisions that play into the experience of a software product for end users: what information is stored and where, whether an interface renders in a browser or with an operating system’s native controls, how information and interface state persists when a user refreshes or reopens an app, whether users can start doing something before they log in. This kind of stuff won’t surface in a design mockup, but there are still important product decisions here that go beyond just “implementation details”.
Which details matter? The rub is, depending on what you’re working on, certain details will have more and less leverage. You’ll have to decide for yourself which details to focus on at any given time. Your answer will probably depend on whether you’re roughing out ideas or trying to ship something for production.
But if you don’t even know which details you could consider, you’re completely removed from being able to decide which ones are important.
I think designers have been kept away from the material of software for too long. Not necessarily because anyone set out to exclude them, but because the industry convinced itself that the right abstraction layer could make the complexity of code disappear. It can’t. The complexity is in the product whether the designer is involved in managing it or not.
So no, designers don’t need to know how to code. But the grain of the medium shows up in the work whether you understand it or not—and as a designer I’d rather be able to grasp it for myself.