Thanks for the thoughtful response here.
The argument was framed this way from your piece:
You’ll end up limiting yourself as a designer. You want to build what you design? Great! It’s a solid instinct. But when you sit down to design, you’re going to start thinking about what you can reasonably build yourself. And, inevitably, you’re going to think of some fantastic feature — the one your users really want and need — that’s too technically sophisticated for you to code yourself. And so you’re going to limit your design. Trust me, I know: I realized my days coding websites were coming to an end when I started to change my designs based on what I felt comfortable building.
Though my summary wasn’t in direct reply to yours specifically, I encapsulated the general argument out there this way:
Coding limits your design thinking because you’ll only be creative within the bounds of your development skills.
Readers can decide if my summary is a straw man or not. In my view, if there’s any daylight between the two, it’s rather esoteric and hairsplitting in how and when creativity is applied. But even so, does any of that change the essence of the argument being put forward? The nucleus of the argument is essentially a warning: Code skill is a toxin. Learn with caution. Use at your peril.
The example you provided has serious risks indeed, but for me it’s not at all a consequence of the designer’s code knowledge. It’s from these two factors: 1) The same person promising to do both the design and the development under 2) a tight deadline. Under those conditions I wouldn’t expect anything other than a design constrained to that person’s maximized skill along the whole process.
My point really rests on this assertion: Designers certainly don’t have to code — I think you’re on the mark as one can be with that. But the fact that designers pay a penalty from having too much development skill is, I strongly feel, an imagined one. The same amount of evidence exists for code making a designer better as there is of limiting them.