BackFor Designers, Learning To Code Isn't A Yes-No Question
From 2005 to 2014 (or 483 weeks to be exact), the London-based consultancy Berg stood quietly at the vanguard of interactive product design. The studio’s preoccupation with "finding opportunities in networks and physical things" positioned them about a decade ahead of their time, so it’s no surprise that tech brands like Google and Twitter hired Berg to help them invent the future present—in which tablets are ubiquitous, AIs are "as smart as a puppy," appliancesconnect to the cloud, and text messaging is the new UI.
Matt Webb was Berg’s CEO, and now splits his time between design consulting, advising hardware startups, and softwaretinkering. Unsurprisingly, he has to know how to code. Well, sort of. If anything, Webb is a living example of how the question on everyone’s mind—"Should designers code?"—doesn’t have black-and-white answers. "Code has good and evil forces inherent in it, and it’s these different capacities that we all need to develop a ‘native tongue’ understanding of," Webb says.
Sounds right. But how? I recently interviewed him on this very subject. Here are his thoughts (condensed and edited for clarity):
WHY HE STARTED
Over the course of about two days in college, I had a spiritual experience with transistors. And suddenly everything was different.
I studied physics, and in my second year we were studying electron orbitals in semiconductors. One day the job we had to do was to make something that works like a transistor: like a canal lock or gate with lots of electrons on one side and not so much on the other, and when you poke it on one side all the electrons rushed through. We made this model and found out that it matched up with all our calculations, then we put it to the side and they gave us a real transistor—a little black plastic piece with three legs, and we tested that too. Then we got a handful and had to make ourselves a logic gate, and then we threw it away and were given a 6502 processor, which is an incredibly simple CPU.
And I remember vividly the moment we hooked up our 6502 to a little keypad and a little display, and typing in "2+3" and hitting the button to make it execute. And in my head, just seeing every single button register and every single transistor gate open and close, gave me an incredible sense of vertigo from what was happening all the way down to the electrons themselves. And I suddenly felt like I understood it, even though I really didn’t. But at that point I was like, "I don’t know what I want to do next, but it has something to do with computers."
I’m really bad at coding. I can barely build anything more than about 20 lines of code. But that kind of introduction gave me a view that [programming] isn’t anything transcendent: Mt. Everest still is just a really big hill. Talking about transistors doesn’t explain anything about the culture of code and the kind of mindset you need in order to do it creatively, but it does de-alienate you from this world which in the beginning is completely outside your conceptual grasp.
ON TREATING CODE LIKE A PHYSICAL MATERIAL
I know barely anything about wine, but I remember going from the moment where the variety seemed potentially infinite to "Okay, there are two colors of wine, and they taste different." Once you have that tiny handle on it, you can recognize when something doesn’t taste quite right, and you can do something with it. You can start seeing opportunities. You start seeing how to hook things together.
Here’s an example. I had a computer in my room at college, and I realized that I can have a webpage on my computer, and from that webpage I could run something on my computer that would run in my room. So I made a little web-form that, when you typed into it, would use a speech synthesizer to speak it. A good friend of mine was in Australia at the time, so if he wanted to have a chat on email but I wasn’t at my computer, he could go to this webpage from an internet cafe, type something into it, which would speak out loud and grab my attention from somewhere else in my flat. It was about 10 lines of code.
It’s just figuring stuff out—doing whatever next step that makes sense at the time. Coming up with a next step that makes sense is sometimes hard, but the way to do it is to just spend time with it. So it feels a bit like sculpting. You know how they say that "the statue is in the rock"? All you’re doing is chipping away the part that isn’t a statue, one piece at a time. You have to be pretty down with the idea that it’s going to be useless and embarrassing to begin with.
HOW HE LEARNED: MINDLESS DOING BEATS MINDFUL STUDYING
Some people need to understand what’s going on on a deep level, but learning new stuff for me is about just going through the motions. The only language I can be bothered to do anything in is Python. I remember how I learned it: I got a book about "idiomatic Python", and I didn’t concentrate very hard. I just copied it out. I literally typed in everything that was idiomatic.
It’s like learning how to drive. You sit in this chair with your instructor next to you, and you just do what you’re told in the moment—despite driving in the completely wrong direction, being dangerous in traffic, and all the rest. Then 10 hours of this passes, and you’re a competent driver. And 20 hours passes, and you’re a pretty good one. And it feels like you’ve actually learned nothing, but clearly you’ve learned loads. It just bypassed your conscious mind.
ON CODE AS CULTURE
It’s important to know what automation is doing to people—to know what a "below the API" job is, or could be. This is the same as knowing how the security agencies are monitoring emails and using meta-data. But does everyone literally need to know how to code to in order to do this? Possibly not. It might just be that they will understand it culturally, because someone near them knows how to do it. Not everyone needs to do the same thing, but you do need enough people doing it so that these things can be absorbed.
ON CODE AS CONTROL
There’s a quote that resonates with me from [Ted Nelson’s 1974 book]Computer Lib, which was like the Bloomberg article ["What Is Code?"], but written on a typewriter and self-published. It says, "Whatever it may do in the real world, to the computer program, it’s just another device." That statement says everything we need to understand about how Uber treats a driver: the driver is just another device. It’s dehumanizing.
ON WHAT CODE CAN’T DO
I think there are some important reasons why people shouldn’t learn to code. One is that it can encourage you to take this "break it down," algorithmic approach to absolutely everything in life. Code is such a powerful approach, I think you can easily kind of steamroll over the other things. Do you remember those kids in school who were really good in debate class? When they’d start treating every single conversation or interaction that way you wanted to remind them that not everything is debate. Sometimes you’re just bantering in the park.
So the coding "stance" is not always the most appropriate way to engage, but also, what does it teach? People who grew up with different video games learned that there’s always a solution to that one screen puzzle on the platform they’re on. It could be impossibly hard, but that everything is tractable in its approach. Maybe that’s not healthy, because you don’t come to know what code doesn’t do. It doesn’t talk about feeling and it doesn’t talk about anything holistically. It doesn’t talk about aliveness, and connection, and things that are true without being provably true.
I’m not going to say that people who code always have this approach, because they absolutely don’t. But as a descriptive mechanism for our society, I think there are things that it might be leaving out.
ON THE FACT THAT YOUR MILEAGE MAY VARY
Bear in mind that I’ve come out of 10 years of running a design company, and all of that was about embracing the intuitive. And while that is something that code was a big component of, it was only one medium. At Berg it was woven into a much richer tapestry that you would never get by just employing one mechanism. That said, we got to places that were better because we employed code as one of those mechanisms. It just has to be a thread, not a kind of dominant thing.