A practical example: one of my employers used a Java-based system to render their front end. Our developers wrote Java code that grabbed pre-styled page elements from a visual library. Although they could write additional Java code to edit an element’s CSS styling, that often meant visual changes were hard-coded into the system. This is a bit of a no-no for most developers, but a lack of CSS knowledge on the part of our Java developers (which was surprising to me), deadlines and pressure to move items to complete quickly got the best of people, especially if time to create or edit new CSS styles were not included in our work estimates. Between the time they took learning the appropriate CSS solutions and completing the code, hard coding was sometimes the only option to move features out the door on-time.
From a my standpoint, this meant I had to have a damn good reason for requesting visual changes, that I had to point out these changes during our story refinements (it was an Kanban shop), and that I’d often work with developers to help them identify the CSS properties to adjust.
Now, is this all strictly UX work? No. But it did bring a ton of value to the team. Eventually our Java developers took more time to learn CSS, our PM’s learned to ask about time needed for visual changes, and our process became much smoother and straight forward - simply because they had a design professional that new the technical requirements well enough to point at the beginning of the process, rather than in the middle of it.
The counter-argument is, of course, that UX can, and maybe should, be done in a vacuum. Especially from a UX Research perspective, we are normally more focused on identifying problems and suggesting solutions than we actually are with how those solutions are implemented.
It’s entirely possible to be a UXer who doesn’t know a lick of code. When it comes to landing a role and adding value to an organization, however, those with coding knowledge will usually have an edge.