Designers that code: a response to Jared Spool

In his blog post entitled “Why The Valley Wants Designers That Can Code,” Jared Spool points out that designers who know how to code can be enormously valuable, specifically to Silicon Valley startups. These “super designers” bring two people’s worth of skillsets to the table, plus role flexibility. And that means happiness for everyone!

As usual, Jared is basically correct (though I can’t answer for Silicon Valley, since my clients are mostly East Coast). But the reality is complex. I think that in his brevity, he glossed over some issues that can make this dual role very difficult and painful.

The part wherein I agree with Jared

Yes, of course having both design and coding skillsets is valuable! I’ve made a career out of that concept, and I wouldn’t want to work without either of them at this point. Design and engineering have different histories and methods, but their highest values are the same: build something useful, delightful, and high-quality. There are many reasons why coding skills are valuable:

  • A designer who knows how to code can prototype her designs quickly and skillfully, with a broad choice of tools.
  • A designer who codes can keep the ultimate end in mind during the design process. How easy will this be to implement? What tools are available to implement this interaction technique? Does this aspect of the design require too big an engineering investment to even consider at this point? Code-level technical knowledge can help you understand images and video better, which I’ve found useful.
  • If you can build your own designs, you can see that design through to implementation while maintaining your design vision. There’s nothing “lost in translation” when you try to communicate your design to the coders. (Good communication artifacts and skills help, of course, but it’s still time-consuming and fraught with potential mistakes.)
  • If you still need to hand off your work for implementation, communication with engineers is easier if you know the materials they’re working with. Informal conversation and hanging out can be more fun, too.
  • The “self-improvement” reason to learn to code: everything you learn changes your brain. As you learn more about writing software, you start to look at software products differently and with more depth. You learn to think in terms of abstractions, functions, parameters, components, frameworks, object classes, templates, latency, etc. Your thinking may get more precise and nuanced. And as you practice debugging, your overall problem-solving techniques will improve.

And finally, yes: hiring managers do like candidates with multiple skillsets. Who wouldn’t? But there’s a big problem with that.

The first “but:” coding considered more valuable

This seems so wrong, but it’s been true for me — organizations often value coding skills more than design skills. And when that happens, and you have two skillsets, which one do you think will get used more? Yeah.

The hiring manager may like having a dual-skillset person, because of the flexibility it gives the team. They may even pay you more. Yet in my actual experience with a dual skillset, I ended up spending lots more time doing coding than design, often due to the non-creative efforts — debugging and refactoring — that eat up lots of engineer time.

I also found that heavyweight interactive software tends to require large and heavyweight engineering efforts, especially when compared to the time it takes to design their interfaces. Now, I’m not talking about tiny websites and agile startups here, I’m talking about major software with hundreds of thousands of lines of code. (Or millions, in some cases.) All custom. To keep something like that running well, engineers need to spend serious time designing and building the software itself. And when you have lots of pre-existing users, you can’t break backwards compatibility when you go in and add stuff, so that adds yet more complexity.

To a large company with products like this, engineer time tends to be more valuable than designer time. That’s how the product gets built. Yes, user interface design must be done well, with a correspondingly careful effort — but in the end, design took up maybe 20% of my time on projects like that, while the remaining 80% was all coding (often debugging, often with other people’s code). Not my idea of a fun time.

Here’s another problem with the larger companies. What does your job title say? More to the point, what will you get evaluated on at review time: your design efforts, or your coding efforts? I’ve never seen both weighted equally. If you want to go this way, work it all out with your manager before you jump in. What do you want to spend your time on — design or coding — and how can you best bring value to your employer? How will your manager help you balance the conflicting demands on your time?

Even in a much smaller organization, your “coding” skillset may ultimately be valued more than your “design” skillset. In my experience, it’s not because people don’t value good design per se; it’s because that website just has to get built, and if you’re the only one who can build that fancy new page layout someone requested, that’s what they’ll ask you to do. And they may not come to you with minor design problems, since you’re busy coding. Habits form. Next thing you know, you’re not doing design much anymore.

So, it’s possible to be seen as both a designer and a coder. But it requires very, very careful management of your personal brand. Set expectations clearly, and defend your personal boundaries — if you’re doing more coding than you like, you’ll have to decide when and how to push back or ask for more design responsibility.

The second “but:” software engineering takes time to learn

Now I’m going to be a snob. There’s coding (HTML/CSS/JS, using JQuery to create modules on a page, prototyping, etc.), and then there’s coding. Software engineering, that is. It’s an art, and a craft, and somewhat of a science, and it’s something you can spend the rest of your career learning and never reaching the fluency, speed, and wisdom that the real masters possess.

…Actually, that’s a false dichotomy. There’s a nice continuum between them; you can dig ever deeper into the languages and tools that a designer ought to know, and the more you learn, the better you’ll get at what you do. Find your happy place on that continuum.

The thing is, it takes a long time to build up these skills and mental tools. They take practice. And many concepts are genuinely difficult to learn, evading all but the smartest engineers. Here’s what an experienced senior-level software engineer knows and has done:

  • They’ve used many languages and frameworks, to the point where everything “new” looks vaguely familiar.
  • They’ve worked with many tools — development environments, editors, debuggers, interpreters, compilers, build-and-test systems, code generators, databases (and again, after a while the new things seem like remixes of old things).
  • They understand the subtleties around threading, pointers, memory management, order of growth, exception handling, recursion, the problems with instrumentation, and other things that can trip up a naive engineer and cause software to Just Not Work Right. These concepts endure across decades and languages. (They’re quite useful to know, so if you want to make yourself more valuable, they’re great places to start!)
  • Likewise, they’ve learned well the enduring concepts behind software creation — software architecture, defensive design, API design, object-oriented class design, self-documenting code, iterative or agile or test-driven development, optimization, refactoring, debugging, testing, and general software upkeep.

So there’s lots of good stuff to learn before you can create production-quality software systems. But here’s what I worry about: it takes years to learn it well, and this is what a lot of good software engineers do for 50+ hours per week, building knowledge and picking up new skills. Practice, practice, practice.

Hey, designer. Can you afford to invest those years?

(“But you did,” you might say to me. Not exactly. I learned that stuff straight out of college, and then I slowly moved into UX design, so I didn’t need to make the choice to stop practicing design while I learned engineering. Not sure I would do that if I’d started right out in design.)

Coding? Oh, sure. That’s absolutely worthwhile for a designer to pick up. I highly recommend learning as much as you can about HTML/CSS, Javascript, Actionscript, Flex, PHP, Ruby if you need it, Python… all good! Build things, experiment, prototype the hell out of your designs, produce professional-quality CSS, debug lots, read and think deeply about program design. Just don’t — and I say this gently, not accusingly — don’t fool yourself into thinking you can produce a substantial, high-quality, stable, enduring software system without either being a serious professional engineer or collaborating with one.

If you’re a designer who want to learn “real” software engineering, and you understand the opportunity costs to your design career, then go for it! You’re in for an adventure. Go forth, learn, increase your professional value tenfold, and make the world a better place.

If you don’t, and you would rather just code prototypes and create excellent HTML/CSS pages, then no one will hold it against you. Certainly I won’t, and I bet Jared won’t either. :-)