Don’t “Learn Code” if You Don’t Want To
A blog post yesterday from the respected Frank Chimero ignited a lively Twitter discussion about the designer’s relationship to code. Some feel strongly that basic knowledge of HTML and CSS is essential for a designer in this day and age; some cling to the idea that a designer’s job is to make things pretty and the nuts and bolts of how that pretty thing is built are of no consequence. I’ve got an answer to settle all the 140-character arguing.
Ready? Here it is:
“Should I learn how to code?”
“If you want to.”
Really, it’s that simple. This question is no different from “Should I learn how to screen print?” or “Should I learn how to bind books?” Basic coding is a skill that will allow a designer to produce something they have designed, which is an immensely rewarding experience, but is in no way essential to the design process. Will knowing HTML and CSS make you a better designer for the web? Maybe a tiny bit, but no more than knowing how to coat, expose, rinse, and pull a screen will make you a better poster designer. We learn about how to design something by using it, not by building it. An avid reader is better suited to lay out a textbook than a bookbinder. If you’re reading this, you’ll probably visit and use dozens of websites today — most of us interact more with screens than printed material on a daily basis. Assuming you’re constantly analyzing the world around you for the basic principles of design (hierarchy, composition, etc.), and you should be if you call yourself a designer, I say you’re all qualified to design for the web.
I know how to develop websites. Once, I even coded a website that accidentally worked perfectly in IE6. However, at Friends of The Web HQ, I am surrounded by far more capable and speedy developers, as any designer working for a decent sized company or studio will be, so I haven’t touched a single line of code since I graduated.
Which reminds me, a real developer doesn’t want your garbage “designer/developer” slashie code anyway. It doesn’t matter how many articles you’ve read on A List Apart or how long you’ve followed Jason Santa Maria on Twitter; your code sucks. But don’t worry, it’s not your fault. Being a good developer and engineer is a full-time job, not a side-dish to your design career.
Yes, there are exceptions. Jonnie Hallman, one of my earliest design role models and now a close friend, is a designer/developer that consistently puts out clean looking, smartly engineered apps and websites. However, I am sure even Jonnie would admit that in order to keep his execution on par with is discerning standards he spends the vast majority of his time and energy wearing his developer hat; design is the cherry on top. Phenoms like Jonnie are the exception, not the rule.
Why this is so important
I am definitely not trying to discourage designers from learning how to code if they want to. Just as Jonnie designs and builds his own apps and Chris Muccioli designs and prints his own beautiful posters, you too can design something and bring it to fruition. I recommend doing it at least once.
However, I think it is dangerous and misleading to say that coding is an essential skill for a designer today. As I have discussed previously, one of the most apparent issues in design education to me right now is the deficient excitement around web and screen based design. The “designers need to know how to code” attitude is largely to blame for this. To some of us, code is meditative, logical, and beautiful. However, to most designers and design students, code is confusing, boring, and frustrating. This will probably never change.
I worry that posts like Frank’s, which perpetuate the myth that you have to know code to design for the web, are pushing students away from screen-based design. The Internet is an exciting and powerful medium and people should be jumping at the chance to design for it, whether they understand code or not.
Besides, breaking the rules is how we get progress. Think wrong.
Wednesday, August 31, 2011
12 Comments
Design
Education
Interaction Design
Interactive Media
Philosophy
User Experience
Web Design
As I mentioned in our brief Twitter conversation yesterday, all of my design jobs since my May 2009 graduation, whether 3 week freelance projects or my current full-time position, were realized because of my front-end coding skills. Not all of these jobs were specifically dev jobs; for example, my current employer liked that I could code if I had to, but it was explicitly not required in their job posting. Nevertheless, my coding skills have opened significantly more doors compared with fellow classmates who don’t know how to code.
Also, I think there’s a distinct difference between front-end and back-end coding in this whole debate. With my current skill set, I alone could not code a standalone web app; I simply don’t know any language like Ruby, nor the skills needed to install and maintain a database or how to integrate APIs.
But I can code a mean front-end, so I’m a little taken aback when you say “my code sucks.” It doesn’t. I use semantic HTML and CSS, I comment everywhere to make it obvious what the code is controlling, and I render pixel-perfect elements: if the padding is 7 pixels, make it 7 pixels, not 10. Granted, it’s a little different when I’m coding my own work (I don’t have to pass it off to anyone so there’s no risk in the engineer not understanding it), but I will say that one of my long-term freelance clients actually wanted to hire me precisely because of my excellent semantic coding.
I would say at a bare minimum, any designer that touches web work should at least know how to speak to code if they don’t know how to build it themselves. In our crazy competitive industry, any leg up make you more attractive. This is from anecdotal experience only, but a lot of my design classmates can’t even speak to code, and they are the ones who are struggling to find work.
I think the main point you’re missing is that before you can break the rules, you have to know the rules. Will it improve your ability to build websites? Yes, tenfold in fact. You would learn to build better sites by using them and understanding the mechanics behind it. It’s a commutative relationship. Also, viewing lots of websites does not make you qualified to design them more than eating food makes us qualified to be a professional chef.
Developers are a talented breed. They will run circles around designers. But the ability to have a dialogue between the two and understand one another makes the process incredibly easy, and therefore more cohesive.
Do not make a generalized statement such as “your code sucks.” It’s a sweeping generalization and it’s not a valid argument. It makes you sound foolish. There are exceptions, plenty of them. Lets face it, anyone can learn basic Html5 and css3. It’s more semantic than ever. It’s the designers attitude and ability to put forth the time to learn new things that seems to be the issue.
@Matt — Undoubtedly knowing a bit of code gives you a leg up. No arguing there. Also, I’ll believe you when you say that you write excellent code, but I’m sure you know that this is something that the vast majority of designers don’t have the discipline or interest to do correctly. Presumably, designers do what they do because they love it, and you can’t ask all those people to love code as well. My whole schtick is that I don’t think we should keep web design exclusive to those that love code, or tell students that without knowledge of code they won’t be able to design effectively for the screen.
I feel like I am on a bit of a mission to make designing for the web/screen more appealing, especially to students, and I think dispelling this idea that you have to be a developer in addition to a designer is the first step.
To extend my potentially tired print analogy, learning about how to spec a PMS color or go on a press check is a lot different than learning how to run the press. Right now, the message to a lot of designers is that you have to know how to run the press as well, and if you don’t like it or aren’t good at it then you can’t design an effective publication.
I agree with your personal preference argument, Andy, though I wouldn’t advise people to shut the door entirely. There is a lot to be said about partnership.
Traditionally, design is a profession where you are required to work in a partnership. Print designers work closely with printers to get the best version of their idea made. Specifically, in my field, the type designers never did everything; they always had to work with punch cutters that interpreted their design in various sizes in order to make their design a reality (a similar thing happens today with type designers and hinters).
Now if you’re a print designer and you go to a printer, he knows a little bit of what you do, you know a little bit about he does, but the project probably would be worse if either of you did it all. I would say in this instance two specialists that are comfortably familiar with what the other person does, makes a more complete whole than one person doing both.
I am always a fan of knowing just enough about something to be dangerous. Yes, if you want to build something really special on the web, hire a developer. But if you really want your partnership to work, you should know enough about his job that you could meet him on his turf if you needed to. This, I would say, is the reason designers should get comfortable with markup, coding, or whatever.
I have something else to say on a slightly different topic, still on designers and programming:
When I was in grad school, one of our teachers was fond of saying, “if you design with the same tools as everyone else, all your work is going to look the same as everyone else.” Designers need to realize that the tools on your computer weren’t made for you or your project, they were made for everyone and everyone’s project. They get the job done, but if you want to create something unique, you need to make your own. This point of view is nicely expressed in this article: http://letterror.com/content/toolspace/
The danger is that if designers don’t know how, or even that they CAN make their own tools—in this computer age, that means programming—they will risk having their ideas be dictated by the limitations of the tools they have.
@Andy — I hadn’t heard your print analogy, but I understand it completely. I also understand your desires to break perceived (and real) barriers to designing for the screen. But echoing yourself and Joey G., a lot of it comes down to motivation. Commenting code is akin to naming and grouping your layers in Photoshop. I take great effort to name all my shapes and group folders instead of just Layer 2 and Shape 5.
I still think it’s valuable for designers to at least learn enough development nomenclature to intelligently discuss ideas and problems with an engineer. Using an analogy of my own, if your car is in the shop, wouldn’t it be nice to know what the mechanic’s diagnosis is so you know if you’re getting charged for repairs you don’t need? It’s the same with web/screen design. If you are designing/art directing a CSS animation, you might not need to know how to actually code it, but it would be nice to know what browsers support it and its limitations so you’re not upset when the developer doesn’t return exactly what you expected.
@Joey — You’re right, simply using a bunch of websites doesn’t inherently make you qualified to design them. Analyzing their usability, hierarchy, composition, layout, and the whole user experience does, however. And most of the designers I know, myself included, are analyzing the whole world around them for these basic elements of design all the time.
In your cake analogy, I would say the chef is a lot more like the developer of the cake, and I do think that eating and looking at a bunch of cakes makes me qualified to design one with a pleasing shape and color scheme.
Obviously there are exceptions to my “your code sucks” statement; I even listed a few right below where I said it. My point is not that you, “Joey G.” are bad at coding. I’ve never seen your code. My point is that the vast majority of designer/developer slashies write code that keeps real developers awake at night. Very few of these slashies understand that coding is a craft the same way that printing is a craft. They think “I coded it and now it works so it’s done” when that is simply not the case. Someone needs to tell them that they’re probably doing a crappy job; that’s just the reality of trying to tackle something as huge as development when you’re not a developer.
@Matt — I agree completely, but asking someone to know the language, nomenclature, basic browser limitations, etc. is a lot different then asking them to develop a website. At the end of the day, I still took my car to a mechanic, I didn’t jack it up in my garage and start trying to fix it myself.
Being able to communicate effectively with developers (or anyone for that matter) is paramount to designing for the web whether you yourself can code or not.
@Colin — This is the balance that must be struck, and I think you’re exactly right. I didn’t intend to give the impression that as a designer you should shut the door entirely on anything. Partnership and collaborating is magical and that is what I am trying to make a case for here. Find a real, dedicated developer and partner with them, collaborate with someone of a different skill set. The work will be better because of it. Should you be able to talk to them and communicate effectively? Yes, absolutely. Do you have to know how to do his/her job yourself to do that? I don’t think so.
“Developers are a talented breed. They will run circles around designers.” Just think of the debate that could (should) spark!
I’m with you, Andy. While it is obviously helpful to understand a little code, it is by no means necessary. It’d be sad if talented young designers were scared away because they thought they couldn’t get by without it.
Having just graduated, maybe I can put some more perspective into this conversation.
At my university, we spent two semesters of senior year learning the basics of html and css (with bits of javascript thrown in). These courses were required, and were meant to do exactly as a couple of you mentioned- create a middle ground where a designer and developer could work together and be communicating the same language. I didn’t have much markup experience, but the basics were quite simple.
As time went on, I noticed much more frustration in the class. Things got more in depth and we were working very slowly. We weren’t taught exactly how to do things as much, but encouraged to look up solutions on our own as if we were being self taught. So even some of us who initially wanted to be that perfect hybrid designer-coder, were put off by the difficulty later in the courses. Sure some people were great or came in with knowledge of the language, but plenty were getting upset because the great design ideas they had in their heads couldn’t be realized with their basic knowledge (especially given the deadlines)
Personally, I still have a desire to learn to code. I was very put off by the difficulty, but being a well rounded designer is valuable. I can’t tell you how many jobs I had to sift through that were for hybrid designers. Though we took the classes, we realized our skill set only allowed us basic understanding enough to work with web devs not be them. So when I heard about Muse I was excited. Sure, I will keep up my practice with code, but I studied graphic design not web dev. And the fact is it takes a long time to learn to build amazing sites with great markup. In the meantime, if Muse can help me build a website I’m proud of, then I’ll do that before I let my shoddy amateur coded site go live.
By your logic, I should be a great architect simply because I live and work in a city.
Might I propose a different design method altogether for the small-time operator? Think of semantic, standards-based HTML and CSS as layout tools, not “code.” CRUD operations? Python scripts? That’s code. Designing in the browser allows you to become more comfortable with the way you build your pages, and you should be able to make any kind of revision you want fairly quickly by changing two or three CSS rules.
Moreover, when you show a client a static comp, they’re often confused and don’t understand why you’re bothering to do this extra step, other than you went to art school and want to show off that you know the names of different fonts, or something. They’re paying you to make a Web page, not a series of JPEGs. So, eliminate the comp phase altogether! Give them a web page that works in the browser they’re using. Use progressive enhancement techniques to make it sparkle in modern browsers.
I understand the argument of “visual people” not wanting to “think analytically,” but that’s fine. I’m a visual thinker that can accurately describe what I’m making—and that’s all CSS is.
Obviously this design practices mandates that you “learn code” and don’t make your markup “suck,” but it has infinite advantages. Designing for the browser—with the tools the browser understands—results in a Web that was designed to work.
Trackbacks