Should Your Company Require Designers to Code?

When Leonardo da Vinci began his painting apprenticeship, he didn’t start by putting paint to canvas. No, the teenage protégé spent hours each day grinding pigments and preparing brushes.

Why? The prevailing academic theory was that he had to acquaint himself with the tools of the trade before picking up a brush. The same is true for every aspiring da Vinci of design. Although today’s drag-and-drop tools make no-code prototyping possible, the designer without a functional understanding of her medium — code — will never master the craft.

Think of it this way: Would you hire a cake decorator who couldn’t bake? A carpenter who couldn’t cut wood? A fashion designer who couldn’t sew? No, you probably wouldn’t, and understandably so. My company, for much the same reason, only works with designers who can code.

Code Switch: The Moment We Went Code-Only

Our policy, believe it or not, was a bit of an accident. When my co-founder and I started the company, it was easy to say, “Everyone codes.” We did, and we hired others who did as well. Only when we began partnering with creative agencies that didn’t know CSS from USSR did we realize how critical this knowledge was to the design process.

Over time, we saw a pattern in our collaborations with third-party agencies: An agency’s designers would create beautiful layouts, which we wouldn’t see until after the client approved them. Time and time again, the agency’s designers would forget about factors our developers had to contend with: page states, user paths, browser sizes, device differences, and more.

Inevitably, we’d be forced to return to our client. Gnashing our teeth, we’d present the client with a choice: Scrap the design, or provide us with additional time and money to fix its flaws. As you might guess, those weren’t fun conversations.

After some sober reflection, we formalized our learned preference: Everyone we work with will code.

We’ve found that clients reap the benefit of our must-code mantra. They’ve been overpromised untenable designs before. Now, when they come to us, they know that we can build and deliver everything we present.

Our Coding Philosophie

The all-code life at Philosophie works for several reasons. First, we’re makers. Our clients hire us to design, test, and develop new ideas. If we didn’t understand the boundaries of our raw materials, we wouldn’t know which boundaries were pliable.

Second, we work in small teams. Because each team has broad purview over its project, we hire Renaissance men and women. When everyone involved can code, the team can move dramatically faster.

Finally, our “everyone codes” strategy is one of luxury. We’re a small company, so we can hire very selectively. Rather than conduct recruitment campaigns, we wait to grow our team until the perfect unicorn trots through our doors.

The bottom line? Our model works for us. For others, it may not.

To Code or Not to Code?

There are, admittedly, good reasons why many companies don’t require coding expertise for nondeveloper roles.

For one, hiring developer-designers can be impractical, particularly for enterprises. Specialization is helpful, and sometimes even necessary, when leading large teams. Imagine the chaos of a corporate manager corralling 50 developer-designers, having spoken only at the coffeemaker with most of them.

Developer-designers, as that manager would surely find out, rarely excel at both roles. Experience designer Roger Belveal, in an oft-cited Quora post, observed, “Some people can play the piano and the banjo, but when they play them both at once, it sounds really crappy.” Dyed-in-the-wool dualists are rare, and those who can seamlessly transition between the two skill sets are rarer still.

Still, that doesn’t mean that they don’t exist and that you shouldn’t hire the truly talented ones. Just don’t expect a designer-developer to match a full-time front-end developer’s engineering expertise or a dedicated designer’s artistic chops. An on-staff coding guru or Jackson Pollock-level creative mind can shore up soft spots.

The increasing complexity of UX design presents another argument for a specialized staff. If your product spans platforms and user segments, a designer-coder may not have the time or skills to prototype in code. We rarely face this issue, however, because we work primarily on new systems, which don’t involve the additional challenges of cross-functionality.

My favorite criticism of the design-code model, however, is Conway’s Law, first posited by Melvin Conway in 1967. Conway’s Law suggests that designers can know too much about software, at which point they find themselves solving problems in convenient (rather than innovative) ways.

I’ll be the first to attest to the reality of Conway’s Law, but the first step to overcoming a problem is recognizing it. We break this law by maintaining a diversity of experience levels on our staff. Newer designers sometimes unearth solutions that jaded veterans may ignore.

The Code Conundrum

It’s possible that, for your business, requiring everyone to code is simply unrealistic. In the world of software design and development, however, there are certain skills that every person needs at his disposal.

Everyone, even those in noncoding roles, should know CSS and HTML. They’re easy to learn, and no webpage is built without them. A firm grasp of the logic underlying databases is another must. How a system stores information connects as closely to how it presents that information as the heart connects to the lungs.

Arguably, this systems-based view of software is the greatest gift that fundamental coding knowledge can bestow. Great designers and developers don’t see a project in terms of individual pixels; they consider how its constituent parts interact to create the overall experience.

For better or worse, this debate is far from over. The industry, at least for the moment, is trending toward coding designers. The model may not work for everyone, but I’ve learned my lesson. Our designers — and any others we work with — will know code.