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!)

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?

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.

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.

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.

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.

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.

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.