Code like a designer
This is a topic that seems to be an unending source of Internet arguments (just like the capitalization of the word Internet), should designers code?
Dun dun dunnnnnn!
I'd like to start this off by saying this is an idiotic argument, because it's really two or three groups talking past each other most of the time. I'm writing about it because people keep talking to me about it, so I'd like to just put all my thoughts down in one public place. If you clicked through to this article and you already knew that, just go down to the end, there's a prize waiting for you (although if you read my hot take on this it will still be there for you…just sayin')
On one side you have organizations who are cheap and want one person to do the job of two or three people. Maybe they really can't afford to hire for all of these jobs? Maybe they can? It doesn't really matter because most people are in agreement that this is a crazy expectation and you get what you pay for. This is not what I want to talk about.
On another side you have people who say, "Designers don't need to learn HOW to code, they just need to learn ABOUT code." This argument is interesting, mostly because it's hard to know ABOUT something like computer programming without actually knowing HOW to do it at some level. Beyond knowing that computer programming is a thing that exists, and that you need a computer to do it, and that programs are what make the computer go, you're really going to be hard pressed to know ABOUT computer programming without accidentally learning HOW to do some of it. Like a For loop. If you know ABOUT a For loop you basically know HOW to code one in at least one language. See what I'm saying?
On the final side of this triangle of misery and flame-wars is the group of people who say, "Designers must learn how to code if they're going to design software, software is their medium!" I will disclose right now that this is the side that I'm on. When I used to do print design, I learned a whole lot about: desktop publishing, printing presses, printing techniques, ink, paper, modern bindery methods, and modern automated finishing methods. I never had any intention of running a print-shop or working in one, but I knew what could and couldn't be die-cut and what kinds of finishes were more or less expensive to do, which is important when you're working with a client who has a budget. I knew how much you could adjust the ink saturation on different model presses so that when I talked to the press operators at press checks I wasn't wasting their time. Most importantly I learned about desktop publishing software because that's how I could best represent my ideas in a form that was very similar to the final production piece. But even when you're designing a printed thing, you actually print and cut it out to see how it will work as a physical object. You prototype it. Adobe's desktop publishing suite is arguably the best set of tools for creating fancy things on a flat (or nearly flat) physical medium when paired with a reliable laser printer, and that's the only reason we used them.
most importantly I learned about desktop publishing software because that's how I could best represent my ideas in a form that was very similar to the final production piece.
Desktop publishing is where this exhausting argument gets snagged and starts to spiral into a place so painful you want to drink and listen to Morrisey, because that would be more cheerful.
For a lot of people, including a lot of designers, the work of a designer is to operate desktop publishing software (Photoshop, Illustrator, InDesign…and the many "web influenced" modern variants like Sketch, Affinity Designer, and any of the Adobe Edge products) because for a long time those were the tools of designers in the PC era, and a lot of people don't know what designers really do for a living. Those are the tools of illustrators and graphic designers. But talk to an industrial designer or an interior designer or an architect and they will probably laugh at you if you assume they live in Photoshop, et al.
There are some of us who have decided to take our design skills and go to work on software with complex interactions, and for us we've had to leave behind the tools of print and graphic design (for the most part) and learn the tools of our new medium, a set of tools that have existed for 40 or 50 years in some cases. Those tools are the same tools developers use, because they're the best tools available for bossing a computer around. Just because we're using the same tools as the developers, doesn't mean we're using them the same way, or to do the same job. The job of a designer is to solve problems given a set of constraints, and medium is usually one of those constraints. When I'm writing code, I'm exploring ideas and rendering them in the medium of computer software, which is a VERY big difference from writing code that is sturdy enough to standup to an Internet full of people using it all at once, or that is efficient enough to not set a CPU on fire. I'm the first to admit that I don't know how to do those things (although there are a lot of modern frameworks that make it so I don't need to worry about those things.) One of the jobs of a software developer is to figure out how to make software that won't break your computer the first time you use it, or burn your datacenter down.
More and more, modern software development isn't the high-tech pioneering that it was 20 or 30 years ago. The new computer engineering frontiers have moved away from the consumer Internet. The tools have developed to a place where designers can take our designer way of thinking about problems and apply them to software, and we get software! That didn't happen when I was starting out, you needed to know about how to build a lot of things that you get for free now just to make a basic application, especially in the early days of AJAX.
Just because we're using the same tools as the developers, doesn't mean we're using them the same way, or to do the same job.
This is where we need to pause and remind everyone that yes, designers can optimize and developers can create without worrying about any of those realistic scalability or efficiency concerns. These are not hard buckets so much as they are the core skills you're hiring for when you hire a designer or a developer. Let's all agree none of us thinks anyone is this one-dimensional and not go down that rabbit hole. Good? Good.
So go ahead and learn how to code if you're a designer and you want to design computer software. If you've ever seen how ideas get generated in most software development teams, they start when someone says something like, "Hey, check out this thing I made!" and 8 months later you have the next SnapChat. This is why designers need to know how to code. To be able to say "Hey, check out this thing I made!" and that thing isn't a digital painting of a piece of software that only exists in the mind of the designer. No one is ever as excited by that as the thing that moves and responds to user pokes.
Go code like a designer! Make your ideas come to life and participate in the process of making software, or go back to designing for some other medium. Trying to take the tools of print and forcing them on to the medium of programs isn't going to work. It hasn't worked. Just stop. Please. Also, let's not have this argument anymore, ok?
And now, what you've all really been waiting for…
Spikes sloth doesn't care what your title is, as long as your ideas are good