Mike Kus at Think Vitamin gives five reasons why designers should code. A designer colleague of mine has a different opinion. “Technology does not dictate design,” he says.

First, think of what a technical person hears. They hear that you don’t care about how anything you are doing works, and that sounds like crazy talk. After all, that’s where developers spend ninety percent of their time—caring about technical considerations is their job and responsibility. And anyway, isn’t the history of art also the history of technology? Technology has enabled art since the first human-like being placed his hand against a wall and spit pigment around it.

That’s a technical perspective.

Of course, “technology does not dictate design” turns out to sound more absolute than it really is in practice. What my colleague was really saying is that he doesn’t want to hobbled by a perception of what is possible, feasible, or easy. It’s like, well, budget negotiations: you start with what you want ideally, and then you negotiate down from there until you finally reach what is possible. That’s the only way you can have innovative ideas, do things that haven’t been done before, or push the boundaries of a medium.

From a design perspective, thinking about technical limitations before you’ve even launched Photoshop is premature, intentionally painting yourself into a corner.

Now that sounds less like crazy talk and more like rational strategy. And I can see that because, one, someone took the time to explain it to me, and two, I took the time to listen.

Whether or designers should also be developers is a simple question. They shouldn’t. They should be designers. But everyone should cross-train, no matter what their discipline.

The problem of narrow focus

As you get deeper into your own work, there’s a tendency to believe that everyone’s job is easy but yours.

Why is the designer spending so much time deciding on a color pallet or border width? Why does the developer spend so much time trying to understand the abstract role of buttons? Why does it take for-freaking-ever for the UX people to figure out how to lay out a form? Why is it so complicated?

I’ve worked with other people who’ve excised anything from a project that wasn’t web-standard, fast-loading, typical, and expected. No Flash—that requires a plugin. No transparent PNGs, you can’t see those on IE 6. No conditional comments, even though every browser that matters handles them properly, they’re not an accepted standard. No Javascript, it doesn’t work on text-only browsers.

Who am I kidding? I used to be that person.

It was a great way to think, actually, because it let me be an “expert” and also drastically reduced the solutions I had to consider, the work I had to do, and the creativity I had to scrounge. Of course, it became rather difficult to do anything new, exciting, or fun.

Mindy Wagner of Viget Labs also says these “philosophies” really just mask lazy thinking:

The thing is, we shouldn’t forget that we are helping to shape a young industry. We are doing our craft a great disservice by taking mental shortcuts. We should be thinking harder, questioning more, and resisting the urge to jump on any bandwagons. Please, take time to stop and think about all the possibilities – and all the incredibly talented people behind those possibilities – before filling the web with more blanket statements.

Arguing which process sits at the top of the heap, or who is a real designer or a real developer, is little more than hand-waving in the absence of an actual problem to solve. And if you’re inclined to do this, you probably tend to see your teammates less as a highly skilled professionals and more as a resource to be exploited or tools to use. Designers see developers as the instrument they are using. Developers see designers as JPG vending machines.

Not only is that an unconstructive way of dealing with your team members, it also breeds interdisciplinary resentment.

The truth is that design and technology—along with other groups like “marketing” and “financial”—are in a big conversation about a project with a budget. These two things dictate everything, and everyone—no matter what their discipline—is going to have to make some compromises. And if you want to have a conversation with people different from you, you’re going to have to learn their language.

The sixth reason

Mike has five reasons designers should learn how to code, and I’ll add a sixth. The crosstraining fosters communication and respect between the disciplines. It works even better if developers also learn how to design. Then instead of “design priorities” and “development priorities” you begin to focus on “project priorities,” and that just makes everyone more effective. Especially when the budget is tight and the dreams are big.

That’s not limited to designers and developers, of course. If you are part of a team that requires many different diciplines, you should make it your responsibility to understand what they are doing and what they care about. And help them understand what you are doing and what you care about.

When you crosstrain, you begin to understand the things other people do that seem frustratingly trivial. They may even be trivial, at least in the current context of the project. But if you can speak their language, then it’ll be easier to get your other team members regain focus. And it will also help you recognize when you’ve lost yours.

In other words, it’ll get you off your soapbox and into the conversation.