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. :-)

15 Responses

  1. Great post.

    I’d add a third “but”: There could be a tendency to design solutions based on what you know now to code rather than designing the best solution. We’d like to think we wouldn’t do that but it’s hard to avoid.

  2. Jennifer;

    Just a short ‘here, here!’

    I think this is a really brilliant response to Jared’s post. Your experience with respect to the perceived value of design and coding matches mine exactly. Basically, when it comes down to prioritizing releasing the next thing, or planning the thing after, releasing the next thing always wins.

    And, yes, you are very correct to try and parse the meaning of ‘code.’ I was the first response to Jared’s post asking for detail on this point, but my question went unanswered.

    Thanks!

    Tim

  3. No way designers should code, coding has nothing to do with design it severely slows you down. You can try it at http://www.divvers.com it is very much the same as photoshop once you get the hang of it you’ll love it as much as you’ll love your freedom. Ok that was to much but seriously things are a lot more fun with out tons of html.

  4. As someone who has both coded and designed, I would say that while a designer may design better with an understanding of code—just as a coder might code better with an understanding of design—that duality mostly matters in the implementation phase of a production. After all, THAT is the point of convergence where it is beneficial for a designer to bend willfully to engineered patterns while a coder flexes gracefully to anticipate design extrapolations.

    However, in earlier phases of production, I believe it is best for designers to design with an abandon unimpeded by knowing how something might actually be built. As well, I think it is important to architect fundamental code structures with a certain ambivalence to how the interface might eventually look or function.

    In my experience, it is great to know the both when it’s efficient to work interchangeably from one chair, but there are definitely times when one hat or the other should be the only hat you are wearing.

  5. That’s a great point. Especially if the design demands originality, it’s good to unfetter one’s creative thought from thinking about how it’ll be implemented. It takes self-discipline to do that. On the other hand, sometimes originality isn’t as important as getting something designed, built, and out the door with minimal cost. :-) In those cases, sometimes I just work within the known bounds of the system I’m given (e.g. a WordPress theme), right from the beginning of the design process.

    I also agree that architecting large-scale software structures ought to be done with little regard for interface details. At that point, you may not have much of a design anyway — and even if you do, who knows how much it’ll change before it’s finalized, right? Planning for certain kinds of change is part of the art of software architecture, and UI change is a big one.

  6. This is what I do when I code AND design: I code a little, then design a little, chip, chop. The processes get intermingled from the outset, and as a result I think many decisions get made much too early—for the design as well as the code. Like you say, it requires discipline to remain objective, but it can’t be stressed enough how that discipline must suppress very powerful urges.

    What has caught me time and again is how the coding can “paint me into a corner” with a design that becomes ever more difficult to change. Even with loose couplings and mock data, the coding can begin to “tie-down” a design very early. Sure, alterations can still be made, but at what cost and effort? Reluctance to play with the design is inevitable and the design can suffer as a result. In certain ways, the obverse is true with the design dictating the code.

    A developer should always consider the objective of putting all the code and design into one brain. I believe the objective is rarely (if ever) to achieve the very best code for the very best design. It’s almost always in favor of the fast and cheap, and at the expense of quality.

  7. Jenifer:
    An added point to your first “But”…

    At a Toronto IxDA event in late 2010, Jon Lax, partner at the agency Teehan & Lax, pointed out during a talk that at the corporate level, and according to the Generally Accepted Accounting Principles (GAAP), code is considered an asset, while design is considered an expense.

    I think this has a lot to do with the perception that designers who code are more valuable to an organization.

  8. I agree with practically everything you’ve said here. It’s a nice augmentation to my original post (which, as you correctly pointed out, I kept brief).

    However, I don’t think your point about work gravitating from design to coding when both options are available is quite right. It sounds, from your description, that your experiences have been a combination of Sturgeon’s Law and poor resource management. It may also be the case that you took on work you should’ve probably said no to.

    Sturgeon’s Law says that 90% of everything is crap. Project work isn’t immune to this fundamental law of production. It’s hard to take a single data point as a rule, when it comes to the “but in reality” clause because there’s a good chance you’ve found something that’s fallen into the 90% zone.

    What you described sounded like you had a manager who didn’t understand what a designer contributes to a project. I don’t find this the least bit surprising, since, until recently, that would be most project managers. Design’s new found importance is just that: newly found. And not everyone gets it currently.

    However, the trend lines are pretty clear: more organizations see value in design, understand it’s contribution, and aren’t reassigning the resources to engineering, QA, or t-shirt production. As the organizations learn where to plug design in, the managers will be less likely to do what you describe. Just because something was happening in the past, doesn’t mean it can’t happen in the future. You’re right: it’s complicated in reality. However, that doesn’t make it not true.

    A final point: many consultants and contractors forget they can walk away from projects that aren’t a good fit. I think, as the value of design increases, there will be more opportunities for designers. As opportunities increase, the better consultants, contractors, and even full-time hires, will improve their due-diligence skills and only take jobs which are an ideal fit.

    Remember: Good judgement comes from experience and experience comes from bad judgements. The more experiences you have in the world, the smarter you can be about your future.

    • I think that, as usual, we’re both right. :-)

      If Sturgeon’s Law is true (and I have no reason to believe it isn’t), then even in a culture that values design, most designer/coders will still have trouble fitting into an organization in a way that uses their talents fully and doesn’t shortchange design. Most orgs are still broken in various ways, and in my experience, that brokenness often shows up when designs need to be “approved” and then turned into working code.

      Yes, more orgs are recognizing the value of good design, and thank goodness for that! But you can’t ship a Fireworks document. Nor a prototype (at least, you shouldn’t, though many have tried). The people who actually build the working product will always have the most valuable skillset, when the rubber meets the road — I don’t see that changing anytime soon.

      And I agree that a savvy and more experienced designer/coder will be better at picking jobs that are a good fit. :-) It’s hard to walk away from a commitment, though, ya know?

  9. As somebody who used to be a full-time developer for some years (with UI design responsibilities) and who does only (ux) design now, I do have an opinion too that is based on my own experiences. You can do both but if you do, you need to accept the fact that you’ll be mediocre in both (unless you’re some kind of super-talented freak – I just never met one of those). The divided skillset can be well enough for startups. It can be quite enough for bigger companies as well but then we’re not talking about cutting-edge. If you want to be good at client work, concentrate on one profession. I’m now reading filling in the blanks, tens of more ux books – including Jennifers’ – are on the table waiting. My developer colleagues read about TDD, cloud hosting, advanced Javascript etc. There’s only so much time to learn new things.

    Facebook, Google and others like that are another story. They can ask for designer-coders since their needs are different. Design-wise they’re only working on pretty straight-forward stuff. Facebook’s visual design is very simple. So is Google’s. They don’t need that many true artists to come up with different artistic visions of Facebook. They have people doing the real designer work. The designer-coders they now want can just take the ready-made elements and use them. A good front-end developer with a UX-eye can handle that. They also have their masterminds designing and maintaining the architecture that’s optimized to serve 600 million people with real-time updates. Huge amount of data. Huge scaling challenges. No worries, designer-coders won’t mess it up, they just need to follow the practices that the lead architects come up with.

    With Designer-coder they mean more like “We want great people to do front-end development that’s great for users”. They want people who understand design, UX and development. They want people who love perfection. They want people who see if something is misaligned by one pixel. They want people who care about that one pixel.

    See, no need for super-wide nor super-deep skills in the same person. It’s enough if you the codebase inside out. Those who seek for designer-developers are bright enough to understand what their needs are. Why to recruit artist if they know, there’s no use for guys who paint well?

    Your colleagues are just better developers or designers if they only concentrate on one of those. If not, you’re not really working with that talented people. The trick to learn both is to put in the hours – years of full time work with people who are better than you. If you want to be really good in something and have deep, wide understanding about that, that’s a lifetime.

  10. I started at a (very large) financial company in tech support and they paid for my master’s in software engineering. But instead of heading into one of our production support shops, I gravitated to our user experience team.

    Three years there taught me I’m a lousy fit for the visioning team, because I can’t stop myself from designing things we can actually implement. I love detailed UI design, not visioning.

    Now I’m in our user-centered design shop. (Did I mention “very large” company? Most places probably don’t separate information architect from UI prototyper from UI developer, but we do.) Now I can play with some visioning at the beginning of a tactical project (where we don’t engage the UX folks) dive into the weeds of the design during the prototyping phase, and still have intelligent development conversations about midtier, data, and performance considerations with my development peers. And I have a lot less trouble with those conversations than my UCD peers who have no true development background.

    On the other hand, while I have a measurable amount of design experience now, any hiring manager who wanted me for my software engineering degree would likely be disappointed to find out the last time I architected code was in class. I know the theory behind the patterns and what “bad smelling” code is, but I’ve not touched C++ or Java since 2005, forget learned C# or perl or Python or Ruby or any of the languages the “cool kids” use. Heck, I just learned JavaScript in the last few months.

    My point: there’s a spectrum between design & development, and if you’re tenacious and careful you can be extremely lucky like I was and find the spot you want to occupy.

  11. Great article. I know very few designers who code great AND have great design. I supposed ‘great’ is subjective. Personally, I believe that visual communication requires a working knowledge of code and what’s possible, but it’s time for business to cough it up and pay for each role. I want an expensive car that’s also cheap, for instance…

  12. Pingback: Coding and Designing | is ALL CAPS

  13. Great article and even better discussion. The only thing I’d like to add:

    In my case, my many years work as a designer, then designer/front-end developer ended up becoming the vehicle for my current job as an UX/UI Information Architect for one of the top three eComm retailer sites on the web. I have to say that I’ve realized just how much I love my job because my past experience allows me to traverse the entire valley and climb all the mountains, all the while making solid recommendations and decisions. And in my position, I have the unique opportunity to actually design the interface and functionality, which I pass on to creative and IS, who implement the “it” I created in terms of both “skinning” and “make it go”.

    I can say hands down, without a doubt, the designer who can code is far, far more valuable and instrumental, and as you point out, its a careful exercise in self-branding to ensure both skills get utilized equally, or at least close.

    Thanks for the great article (and your book!)

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>