Should designers code?

— 39 minute read

In our second episode, we discuss the wonderfully polarizing question, “should designers code?” We'd go so far as to say that this is the definitive guide to this question, as we remain as cool-headed, reasonable, and rational about the topic as is humanly possible. And you honestly will never need to read another article about it. Nor should you. The question of whether designers should code is now a solved problem.

Not only is this episode more fun than flogging a dead unicorn, it also sports our new intro and outtro music, performed by Mr Pickering himself. We've also got a painfully proper transcription this time around.

Please enjoy!

Transcript

00:38 (Heydon): Since our first episode, I've decided to work in some structure, so I've written—I've actually used a word processor—to write an introduction. And that introduction goes like this: “Hello! In this episode, we ask the question, ‘should designers code?’ We're certainly not the first people to ask this, and you'd be forgiven for accusing us of flogging a dead unicorn. But we have to say”—oh sorry, I fucked this up, really. I'm gonna try it again from the start. (laughter)

01:08 (Stephen): Okay.

01:10 (Heydon): “Hello! In this episode we ask the question, ‘should designers code?’ We're certainly not thee first people to ask this, and you'd be forgiven for accusing us of flogging a dead unicorn. But what we have to say is better, because it takes the exalted form of metacommentary. Just kidding. Let's get stuck in.” (laughter)

01:31 (Heydon): How does that sound? Does that work as an introduction?

01:32 (Stephen): (laughing) Okay, that's good, yeah.

01:34 (Heydon): I've done my research—I've done a very small quantity of research but which can still technically be referred to as research—and I've basically gone and tried to find all of the articles which touch on this subject, and I've got a list of them here. So perhaps if we start with that… those articles are titled:

  • “Should designers code? No, Part 1” (Heydon, laughing): I like that one. “No, Part 1” was my favorite part of that.
  • “Coding for designers: how much should we know?”
  • “Should UX designers learn how to code? A definitive answer”
  • “Why designers shouldn't bother learning to code”
  • “Why designers need to learn to code”
  • “Should designers code, or should developers design?”
  • “Why designers should stop coding (written by unicorn)”
  • “Should designers know how to code”
  • “UX designers should code (among other things)”
  • “Should a designer code?” (Heydon): I don't know which designer they're referring to.
  • “Five good reasons why designers should code”
  • “Why designers should not code anymore”
  • “Designers who code for real, learn for real” (Heydon): I don't know what the language there is meant to mean. For real! For real!
  • “Product designers should say ‘Fuck you!‘ to being forced to code” (Stephen): Wow.
  • “Designers shouldn't code; they should study business”

(Heydon): and that's all the ones I could find. I—

03:04 (Stephen): Hey, hey, hey! You missed mine!

03:06 (Heydon): Wait, what was yours called? I'm gonna add it to the list now.

03:09 (Stephen): “Put the ‘designers should code’ debate to rest”

03:15 (Heydon): But's that's too reasonable.

03:17 (Stephen): Oh, I'm sorry, I'm too reasonable. I should be… polarizing.

03:21 (Heydon): It's too even-handed, even in its title.

03:25 (Stephen): Yeah, I should be more confrontational. I'm sorry. (laughs)

03:30 (Heydon): I honestly don't recommend it.

03:32 (Stephen): No, well, yeah, your experience… we'll probably need…

03:38 (Heydon): I mean, I'm okay.

03:40 (Stephen): No, I mean—

03:41 (Heydon): I didn't get death threats or anything like that.

03:43 (Stephen): Oh, I'm surprised. But no, I didn't mean in the sense that you're suffering somehow, but in the sense that things can get complicated pretty quickly. Yeah, so, “Put the designers should code debate to rest” was… well, ask me what you want to ask me, first. (laughs)

04:08 (Heydon): No, reiterate what you said in your article, because I think that's important.

04:15 (Stephen): Well, what would you say if I said designers should learn how to communicate well, or effectively. Would that be weird? Or am I asking too much? Should they all hire a special PR person or liaison to talk, to sit between them and their clients or stakeholders, or should they also learn how to—you know—write an email and communicate well?

04:42 (Heydon): Yeah, so this—obviously I'm gonna say that I think communication is a very important part of (laughs) whatever you do, whether you normally call yourself a designer or a developer or an engineer or whatever.

(Stephen): Right.

(Heydon): It all succeeds or fails based on effectively you manage to communicate. How persuasive you are, how good you are at listening, how good you are at adapting to other people's perspectives, all of that is good stuff. The so-called soft skills which aren't actually soft. They're hard.

05:14 (Stephen): Right. And there's a lot of those, right? There's a lot of meta-work around design. Of course, that's kind of inflammatory from my end, because communication is something that you probably need in most jobs. Not even design, but anything else you could think of, almost. But what about if I said, let's say you're an architect. Would it be useful to know something about the materials that are going to be used to make the bridge, for example—

(Heydon): Right.

(Stephen): —the bridge that you're building. So that people don't die. Right? If you're a fashion designer, is it useful to know something about textiles, different materials and how they react, and should you know something about the production process so that you know what's possible to make and what isn't. And without having to do those processes yourselves, these things are probably pretty useful. If you design furniture, it could be useful to understand the processes that are needed to create something that you design and to even know if it's possible. Or if you're gonna have to hand carve these things, you know, for thousands of people, or whatever.

So, my position on the whole designers should code debate is not that designers should code like it's a requirement, but it enriches your skill set as a designer. I see it as: you have pencils, you have a mouse, you have a stylus, you have Sketch, Photoshop, paper… If you do UX you can interview people, you can survey them, you can watch them as they use something… There are all these different ways that you can—all these different tools in your toolbox, and code is one of them. And I think that when people talk about this, they're thinking about, like, you need to become a developer. Or you need to make production-ready code. That's not it at all. It's about understanding how these things are made, to a level that allows you to create better design work. So, how can you, as a designer, understand, and say, from an accessibility perspective: you kind of have to know what those concerns are. And learning a bit about HTML will help you understand: “Okay, so if I do (x), then I have to be careful about this, because it might not be as accessible as we want it to be.” Or something like that. So you don't have to become an accessibility expert, or an HTML expert. But there's a definite usefulness to learning HTML and knowing what's possible with CSS. And it's also kind of fun to play with those things. To find out… playing with materials.

08:23(Heydon): Find their tolerances, in a way, isn't it? So they're becoming familiar with what's possible and what's not possible. You know, I have to say that we do think about it along the same lines. In one of my notes I've written down here is, “code is a tool/material”. You mentioned Sketch, and I've written, “code is equivalent to Sketch, Inkscape, clay, or pipe cleaners”. They're all just materials. And I think that's where we go wrong a lot of the time, is, I think, being able to code is a sort of functional skill. But design is something else. It's higher-level. So, I think we have this false dichotomy, which is between people who are developers and people who are designers.

(Stephen): Exactly.

(Heydon): What we mean is: people who think about things at a high level and people who think about things at a low level. And I think “design thinking”—if you want to call it that—can be part of those two levels, it's just that sometimes you're thinking more in the abstract or thinking more holistically, or just like, using systems thinking and trying to connect together sort broad concepts. And that's probably more the kind of activity we'd expect from someone who's role is designer. Although I think that's an arbitrary title, to some extent.

But there is design to the way that you write HTML, and there's design in the way that you organize CSS. There's design in the way that you make relational databases have an internal structure that makes sense. And not just in terms of performance—from a back-end perspective—but also in terms of communication, going back to that. So, if you're writing an API, you want to make sure that that API is designed such that other people understand it. So that in itself is a form of… it has to take communication into account.

So yeah, I think “high and low level” makes more sense as a way of comparing what people's activities are within an organization.

The first question I was going to ask you was, “what is design?” (laughs) Which is a horrible question to ask.

10:40 (Stephen): Yeah, because there's no right answer. I kind of like Jared Spool's answer to that question, which is—and I don't even really know what it is exactly—_but basically to me, design is… well, what Jared says is “design is the rendering of intent.” And I kind of like that definition, because it's broad enough that it kind of encompasses the reality of my 25 or 26 years as a designer, that it never really has a very narrow focus. So, I like that definition because it kind of covers all the stuff that I've had to do in my career as a designer, and it speaks to the intent, right? It's an intentional thing. If you just randomly let stuff fall on a screen then there's no intent. So you could argue that's not design. But you could also argue that _deciding that you would randomly let things fall on the screen is some kind of intent. So you designed it to be random.

11:53 (Heydon): Well, you might design an algorithm which allows a program to then randomly place things on a screen. But then you've designed the algorithm even though the actual result, the specific decision making, is done by a randomized process. I mean, I remember that quote, the rendering of intent, and I actually spoke to— was that Jared?

(Stephen): That was Jared. Yeah.

12:21 (Heydon): Yeah. So, I think I spoke to him about this. And I queried it. Because I thought, wrongly—and he clarified for me—I wrongly assumed that what he meant by “rendering” was turning, making something visual.

(Stephen): Oh.

(Heydon): …as rendering as kind of about “painting”.

12:41 (Stephen): He means it like more of the manifestation of intent.

(Heydon): Yes. In which case I absolutely agree with him. But since we're on the subject, I think that is where we go wrong quite a lot. First of all we don't define our terms. So when we write an article saying, “should designers code?”, we should really define the term first: what do we mean by “design”. When you say, “should designers code,” the designer part is so under-defined that you don't mean anything.

So “should graphic designers code” might be one way of putting it. And I think—going back to what you were saying—if they're graphic designers who deal with a medium that is coded like the web, they should at least have an understanding and appreciation of how that code works.

(Stephen): Yeah.

(Heydon): Otherwise, they're just going to make the wrong decisions. Like, otherwise you're making a bridge out of balsa wood because you think, “oh, you know, balsa wood's fine.” (laughs)

(Stephen): Yeah it looks good. It smells good.

(Heydon): Yeah, exactly. It's got a nice wooden effect.

(Stephen): Yeah, exactly.

13:45 (Heydon): Yeah, so that bothers me. I mean, we've talked about this before. We hark back so much to print design, and print design is obviously making visual artifacts on 2D spaces. And web design is that, too. But there are totally different constraints, or lack of constraints.

14:12 (Stephen): Yeah, but okay: so that word “constraint” is very useful in this sense, because to know about the constraints, you have to get some knowledge about them. Print designers would… I was a print designer back in the day, and I had to learn that—well let's say I was doing an ad, and this was going to be printed in a certain newspaper. And, so I was preparing that… I'd have to know that this printer, we know if I want something to look black, it has to be 85% black because the paper absorbs the ink in such a way that it'll look black. If I use 100% black, it'll just become this bleedy mess on the paper. I have to know about that. I don't have to actually know how to run the printer or anything like that. But I do have to know about this process.

15:15 (Heydon): You have to have an appreciation for it, don't you? And I really like the word appreciation in these contexts, because it means both “have a respect for” and “have an understanding of”.

15:26 (Stephen): Yes. So I think that's it. And what I often tell people who say, “should I code?”, I'm like, well you don't have to, but in order to—let's use your word, appreciation—have that appreciation, then you at the very least should collaborate heavily with a developer, if you're doing web or app design of any sort. Because living in something like Sketch is a really poor proxy for anything that will actually be the end result. It's just not very useful. I think it's useful when coming up with ideas. But I think people fool themselves if they think, “well this is what it should be like,” and I'm gonna hand that to a developer, and then it's up to them to make it—

16:16 (Heydon): I think you've touched on something really interesting there, in that it's something paradoxical about that. Or sort of counterintuitive, maybe. In that, we think of these graphic design tools like Sketch, or Illustrator, or whatever, as creating kind of the idealized and very “set” version of something. But actually, we should be using them in a much less precious way, to do prototypes of things, that we will expect to be augmented or otherwise changed by the reality that is the code environment.

16:55 (Stephen): Exactly, I consider all of those, anything that comes out of those tools… they're throwaway deliverables. I mean, they're useful, for a certain part of your your process, potentially (they're not always that useful). But they're not in and of themselves valuable as an end result. They're only valuable to get to the next step in your design process. The only thing that counts is the interaction with the end result. That's really the only thing that counts. And everything else should just be a method to get there. So this idea that people spend a lot of time perfecting their designs in Sketch… really all you're doing is fantasizing about an end result. But it's still pretty far removed from that end result. And I think this whole debate is about designers not wanting to learn additional skills, and it's also about non-designers not wanting designers to learn additional skills.

18:06 (Heydon): It's gatekeeping, to some extent.

18:08 (Stephen): Yeah! It certainly is. And I think that's a big problem.

18:10 (Heydon): Well, it's also a lot of self-promotion there as well, isn't there? The people who are writing that designers should code… really, a lot of those articles, in my experience, were really them saying, “Hello, I'm a unicorn. I can design and I can code. Hire me.” (laughs). That's the subtext.

18:32 (Stephen): Yeah, and I think at the root of it, from both sides: there's a fear that the designer is venturing into “non-designer territory”, as if this broader skill set will somehow distract them from their core impact as a designer, or that they can't be good at it. You used the word gatekeeping. That's really useful, because I think that's what it is. But the whole problem with this debate is a kind of exclusionary aspect to that I really find disturbing. Some designers are kind of afraid to start coding. I've had designers come up to me and say they're just afraid to do it because they don't want to do it “wrong”.

I'm like, oh man, if that's the message we're giving to people, that's terrible. We're kind of preventing all these designers from adding to their whole experience as a designer and learning more, because they're afraid they won't “do it right”. We all know, if I write a bit of Javascript, and I were to post it publicly, then I'd have like a hundred Javascript people be like, “you should have done it this way and you should have done it that way.”

I think designers should code poorly. They should just play around.

20:00 (Heydon): Well, they should just code in the way that suits them.

20:02 (Stephen): Yeah! And just do it for learning, do it for fun, do it to play around. All that stuff is gonna add to your knowledge and help you learn. You don't have to meet any requirements that developers might give you. You don't have to worry about performance and all that kind of stuff. If you're really interested, that will come in time. Otherwise, just play around with it. We don't tell people how to hold a pencil, right?

20:31 (Heydon): Right. But I think we've sort of slipped into the trap again of talking about designers and developers as two separate, discrete groups. And that's one thing I'm quite uncomfortable with, I suppose. And whenever that question is asked (“should designers code?”) I always… like I said, what do we mean by “design” or “designer”? To me design is something you do; it can't really be a title in and of itself. Like I said before, there's a high level and a low level. You can make low-level design decisions and you can make high-level design decisions. But they're always design decisions. So it's really just… thinking. Or doing, like Jared, the rendering of intent. The intent part is the thinking part, I guess. It's the “what am I trying to solve, here?” And you might be solving a minor performance issue in the way that your relational databases communicate. Or you might be solving the question of what product should we actually make for the people we imagine are our market. But everyone is designing and everyone is thinking.

So if you were to take this should-designers-code question and turn that on developers, you'd be asking, “should developers think?” And if you put it like that then it's obviously like, yeah they should think about what they're doing. And you touched on it earlier about the idea of people writing code—actually making code, not just having a distant appreciation of it, but actually cranking out code—if they're doing that without thinking about what they're doing, what are they doing? You know? (laughs) I mean that's how people first of all end up becoming quite unethical, because they've just defined themselves and valued themselves based on how good they are and how fast they are at cranking out code. There are going to be people doing that for the wrong people, for the wrong organizations, for Nazis or whatever. But also, they're going to make really badly structured programs. Because they're badly designed.

I guess what I'm saying is that everyone should think. And then you have the tools that you lend the thinking to. And there's really no… Sketch could be used by someone who's nominally called a designer. But why can't Sketch be used by a developer. A developer could pick up Sketch and draw out how they think that their API should work or how their stack should be structured. You draw boxes and lines between things and label them. It just happens to be that Sketch is then put to use to create something more “engineery” or certainly we associate with programming a lot more.

I used to work with an organization where we had people who identified as programmers or engineers and they were very self-conscious about their design skills. So they would always come to me. My friend Neil, in particular, would use the CSS color name “coral” and he would make everything coral that he wanted me to then take and kind of make belong to our design system and actually kind of “design it up” if you see what I mean. So he wasn't interested in that kind of stuff. But he had an appreciation for it. And he had an appreciation for me and what I was able to lend to it. But that's not to say that he wasn't a designer in any sense. He just wasn't that interested in aesthetics. And that's another thing that often we get wrong, is we equate aesthetics with design or “design things”.

He designed this fantastic app. And when I say “designed it”, I mean he made it out of paper, made a paper prototype. It was this app called Minute of Listening that we made for some schools. And the idea was that kids in schools—classes—would have a focused minute of listening to sound and then discussing it. It was really an exercise in developing their articulation skills. And this application was quite simple; it just allowed you to play a sound but then go through, like, calendars to go back over old sounds and things like that. But he designed it; he just didn't brand it, if you see what I mean. And the materials he used were paper. And this is another conversation, but actually, paper and interactive paper prototypes, I find, translates way better to code than graphical artifacts.

25:31 (Stephen): Oh yeah, definitely.

25:33 (Heydon): Interactive paper prototype, you know, you know it well. But, you can make it modular and you can make it change state, because you kind of, you drive it, sort of thing.

(Stephen): Yeah.

(Heydon): But, yeah, that's going into another topic. But I guess what I was saying originally is that it's easy to fall into that trap of saying, well, I think, yeah, it should be cool for designers to be able to code. But then if they code, does that make them coders? No. Because it's just a skill. It's a tool. And I think it's better to look at it like that.

26:03 (Stephen): Yeah. I agree with you. So, I appreciate what you're saying, that there's a problem with labelling and that just the fact that you've got a certain label on you leads to a discussion of whether or not you should be doing certain activities. Which is ridiculous, right?

(Heydon): Yeah.

(Stephen): And in that sense, that we're all designing. At the same time, I think it is useful to to tackle that subject that's in all these articles. And that's about a specific type of design work. And I think it's implied, but we can say it. It's usually about the people who are designing, most of the time, the graphical interface that people will interact with.

(Heydon): The layout, the colors… the brand. I mean, that's what I would call the brand, I guess.

(Stephen): Well, maybe, but I think that a lot of these designers are also involved in trying to intentionally decide upon the type of interaction that has to happen and things like that.

(Heydon): Oh, okay. Yeah, that's fair.

(Stephen): It wouldn't necessarily be purely visual. A lot of people nowadays would probably call it “UX/UI”.

27:23 (Heydon): That's the thing, isn't it? As soon as you actually… Choosing a font and putting the words in a Sketch file or whatever it is: that's UI. But as soon as you think about the actual words and what they're saying, that becomes UX. (laughs)

27:39 (Stephen): Yeah. Which is why I think those should never be different people, as far as I'm concerned.

(Heydon): No, absolutely. It's atomizing whatever design is too much.

(Stephen): Yeah. And I think these atomizing labels are harmful. They pigeonhole people, and I don't like that.

(Heydon): I'm glad you said “pigeonhole”. I've got a note here that say, “pigeonholes”. (laughs)

28:05 (Stephen): Oh, okay. (laughs) Yeah. So, I hate that. I've worked with developers who have such a good sense of typography. I only have to—what you said about paper is interesting—sketch something on paper and have a five-minute conversation and they kind of know what I mean. And then they know how to translate that into code. Depending on what it is, I can also translate it myself into code. Though that's not generally the type of work I do nowadays.

The thing is, that you have this particular developer, who I know by name. You know, this is an actual person and not just a label. They have this specific skill set which is fantastic for certain projects and I know exactly what kind of result I'm going to get. And the person sitting next to them has another unique skill set that's different from the first person, but that allows me to work with them in a different way. And that's fine. And this idea that anyone who's a developer needs to work this way and have this skill set, and someone else has to have that same exact skill set, that's crazy.

(Heydon): We're judging people based on their skills, as always.

(Stephen): I probably shouldn't use the word “crazy”.

29:32 (Heydon): It's… it's foolish. Let's say foolish.

(Stephen): Yes, exactly. That's a better word.

(Heydon): Or “fuckwitted”. (laughing) I know that it sounds like I'm being—what's the word—facetious, but actually I like to use a sidebar on ableism. Obviously if you say “crazy“, crazy paving, no one thinks that that paving has mental health issues. So, I don't know if that's crazy like… I try to avoid saying it, because I try to avoid words which can be problematic. But I know what you mean when you say “crazy”.

(Stephen): Yeah, but still, now that I know, since… well I've kind of grown up saying things like “That's crazy!”. But once I learned the connotations of that… I'm glad I caught myself right now and we can even talk about that briefly.

30:33 (Heydon): Yeah, I think it's worth talking about. Absolutely.

(Stephen): Yeah definitely, because these things do hit people in a certain way. I'm glad you mentioned… let's call it “fuckwitted” or whatever… foolish.

(Heydon): Well, this is what I was going to about the fuckwitted thing, is that… So, if you were to call someone a halfwit, I think that would be ableist. Or disableist—it depends which word you think is more appropriate. It's one of those things where the opposite seems to mean the same thing. But to say halfwit, that implies that they actually have a physical issue with their brain.

(Stephen): Like a deficit.

(Heydon): Yeah, exactly. What you really mean is that they're ignorant, or they're foolish, or they're silly. Or they're impulsive. Or something like that. So, I like to use the term “fuckwitted” or “fuckheaded”. Weirdly, “fuck” would be the word that was censored; not the word “half”, for obvious reasons. In this context, it's less offensive. I think of the “fuck” part as being, like, ideology, or bad ideas, or bad beliefs. And those do not pertain to—and they would only have a loose correlation with—any possible physical abnormality in the brain which would cause someone to not be able to be as coherent as they might like.

32:01 (Stephen): So, you're talking about behavior, right?

(Heydon): Sorry?

(Stephen): With “fuckwitted”, you're focusing on focusing on behavior?

(Heydon): I'm kind of focusing on someone being a vessel for bad ideas.

(Stephen): (laughs) Which is no less of an insult, I would say.

(Heydon): (laughs) But it's not an ableist insult.

(Stephen): Point taken. I tend to use the word “fuck” at times. I used to use it quite a lot. But I feel it comes across as more aggressive than, like, foolish, for example.

(Heydon): Yeah, I think foolish, like fuckwitted, implies the same agency. Like it's your responsibility not to be foolish. And there's no reason why you wouldn't be, except through being privileged, or self-serving, or lazy. Or any of those things which you have control over if you want to have control over them.

33:09 (Stephen): Right. There's nothing physiological happening there. Yeah.

33:13 (Heydon): But in any case, yeah. What were we talking about before?

(Stephen): (laughs) I have no idea.

(Heydon): We were talking about pigeonholes.

(Stephen): I think that the chance that I'll use the word “crazy” again in that context is very, very small. Or at least smaller than it was.

(Heydon): (laughs)

(Stephen): What was foolish again? I kind of lost it. Pigeonholing? We were talking about pigeonholing.

33:45 (Heydon): Well so, I actually saw a tweet today to which I thought, ”oh, that's fortuitous, because I'm going to be speaking to Stephen soon.” And to me it kind of related to what I was amping myself up to talk about in this episode. And it was from someone called @RanaAwdish? I'm sorry if I mispronounced their name. And it was one of those little dialogs in a tweet form, and it was:

“Me: How was your day?”

“8-year old: I just worry they're doing it wrong.”

“Me: Doing what wrong?”

“8-year old: They separate everything so we can't understand anything. Who says music isn't really math or math isn't science really. Someone made categories but the world is mushier than that.”

And then they clarified in a reply that their child didn't say mushier, they actually said smooshier.

(Stephen): Oh. Oh, yeah.

(Heydon): Regardless…

(Stephen): That's brilliant.

(Heydon): I mean, whether that's apocryphal or not, I don't know. I mean, that would be quite a smart 8-year old who said that. No reason for us not to believe that that was an 8-year old who said that.

(Stephen): Right.

34:55 (Heydon): But yeah. We were talking about the atomization of roles…

(Stephen): Yes.

(Heydon): …UI person, UX person… also, I think it speaks to the school system—going at a higher level—that we teach people that are values in discrete skills. When we should be—people should be—employed or valued based on their ability generally just to solve problems and to help the world become a better place.

Now, whether they're using Sketch, or a word processor, or code, or pipe cleaners, or clay, or whatever. Or paint. Or what have you. Little bits of detritus that they find laying around on the street… in order to do that. In order to inspire people, or to create things which make the world safer and better, or whatever it is. We should be employing them and valuing them based on their ability to fuse those things together. Or there being a close connection between their ideas and how they can manifest them. Their ability to realize things in general.

I think we actually have this problem more on the development side than the design side.

The idea that you can be employed as being a “React developer” is really weird to me. Because that's a very specific way of realizing something. You shouldn't be employing someone because they know React. You should be employing someone because they know how to make good things possibly with React.

36:33 (Stephen): Yeah, yeah. I agree.

36:35 (Heydon): We don't have Sketch designers, do we?

36:38 (Stephen): Well, there are design job openings where they specifically ask for knowledge of a certain tool. And I just somehow think, well, when you're hiring a carpenter, you don't say, “a carpenter with seven years experience in this particular brand of staple gun.” You know. It's like, maybe the staple gun company goes bankrupt, and then there's a completely different kind of staple gun that's coming along, or you switch to just a good old hammer and nails. I don't know. It just seems so ridiculous to me.

I think now I remember the point I was trying to make—the foolish thing—is the idea that everyone needs to have a particular skill set…

(Heydon): Oh, that's right.

(Stephen): …and that we can define that. Somehow we think that's the right combination of abilities or tool knowledge, or whatever, when it's—and I hesitate to use a word like “diversity” because we might go way off the track again—a wonderful thing to have a developer who has a good eye for typography. And it would be a terrible thing to say every developer has to have this same kind of eye for typography. Because you might have another one who's really good with color, or they might know a lot about human-computer interaction, or they have a real interest in usability research. That's great. Why do we have to define these lines? And that's why, even on my Twitter bio, I call myself a generalist. Which I think I am. I'm not particularly good at many, many things. I'm good at very, very few things, but I have a broad working knowledge of many different areas. And that's just because I can't sit still, and I have a lot of interests, and those interests come and go, and there are only a few that stay. But that's okay.

So, that whole idea of the “T-shaped” designer, I think that's a good thing. And that everybody's “T” is different, and that adds to a team. I mean, you get this kind of weird overlap where different people in teams kind of learn, “oh, well Mike's really good at this, and Sheila's really good at that,” so you kind of figure out who you're gonna work with on certain things, and you learn from them, and they learn from you. And you kind of help each other out. Why would we not want that? Why would we want a bunch of clones that do exactly the same thing in the same way? It makes no sense to me.

39:37 (Heydon): But also, the skills that we're looking for might actually not be skills that we need either. So, we're trying to create a product and we've decided that typography is an important part of that and we desperately need a typography specialist. So we advertise for a typography specialist, and someone comes in who's really good at actually writing, let's say. Instead of typography and typesetting, they're actually good at writing. And they sit there, and they go, “Do you know what? As much as I love typography—and I think the typography should look nice—your wording is terrible. It's offensive, it's exclusionary, it's inarticulate, it's unreadable.” And they'll go, “Well, thanks. We'll take that into consideration. But we're really looking for a typographer. So, goodbye.” You know? They're looking a gift horse in the mouth. Because there's someone who had come in who could really help their organization.

(Stephen): Yeah.

(Heydon): And frankly, over something which is more important. But they've already decided that they wanna—I mean—whiteboard interviews, I suppose it relates to, doesn't it? That kind of thing.

40:49 (Stephen): Where you think you know exactly what you want and instead of being open to something you might not have thought of… So, that's kind of what we're trying to do where I work now. There's this sense of, when someone comes in, well, they're not exactly a fit for what we were looking for. But, actually they'd be perfect this and this, you know? That's kind of nice. It's nice to work in that kind of atmosphere, just based on talking to someone.

(Heydon): Yeah, that's really cool. That the organizations have that initiative. Actually, I benefitted from people having that attitude once. I interviewed for a job, and what they were really looking for was a PHP developer. Someone who really knew PHP. And I was asked, like, programming questions around PHP. And I had read a couple of books on PHP. I was no PHP developer. I knew HTML and CSS intimately. What's interesting is that the person who ran the company—who was, as it turns out, a bit of an asshole and a tyrant—he was adamant that he therefore didn't want to employ me. But the developers he got to interview me actually kind of petitioned him and said, “None of us can do HTML and CSS. We need someone like this.”

But, of course, he didn't himself understand HTML and CSS. He didn't value it. And so, therefore, he sort begrudgingly hired me, based on their advice. And then the rest of that job was a nightmare, because I got on very well with them, but he was always trying to catch me out on things and trying to make me look bad.

42:43 (Stephen): Yeah. That's just being a bad boss, right?

42:46 (Heydon): Yeah, well he was just a dickhead, basically. But it was cool of the people there to be like, “well, this is a different skill.” And that also touches on the “should designers code” thing, because what kind of code? Because HTML is very different kind of code to CSS, which is a very different kind of code to—I don't know—Haskell, or whatever. And this goes back to our first episode, Is CSS a Programming Language?, a little bit. But whether or not you consider it a programming language, it's a skill which I think I think few people would say does not involve code.

43:28 Yeah, I agree. So, when I say, “designers should code,” I mean all designers all designers should learn Haskell. (Laughing) No, I'm kidding.

(Heydon): I'm not a real designer.

(Stephen): We had discussed it last time, about that calling something a programming language can also create kind of a barrier to whether people will think they can do such a thing. Right? So there's this idea of, “Oh, I'm not a programmer. I can't—I would never be able to learn something like that.” And I think that's the thing that bothers me about the whole debate. The designers should code debate. That it feels like a lot of developers are kind of “coming to the defense”—between very big quotation marks—of designers by saying, “You shouldn't tell designers they should code.” But, of course, I'm not convinced that that's always in defense of the designers but that it is kind of gatekeeping. And, in a sense, trying to limit what designers can do. Where I would say if you're a designer and you'd like to learn a bit more, or add something to your toolset, or maybe just play around, there are no rules. And you can easily get started doing a couple of things with HTML and CSS or doing a simple tutorial. And you might it terrible and uninteresting. But it might open a new world for you. And why not explore that?

45:08 (Heydon): I'd even go further than that and say that I think stuff that is created by people who don't identify strongly with the skill set or the tool is often much more interesting, and breaks new ground. Because they're not self-conscious about what they're writing. Because it's not part of their identity that they're “a good coder”, or whatever. They're just like, “Oh. I'm gonna take my ideas and I'm going to throw something together. I know it's going to be a bit of a mess and probably not as performant or as well-structured as it might be. But at least I'm doing something.”

And then they will actually just—their closer to solving the problem. Because they're not identifying with being, “I'm the best at…” The kind of self-referentiality of just writing code the best, without thinking about the problem that's actually being solved.

46:07 (Stephen): Exactly. And I think it's… I've made prototypes—I actually made one prototype in React. That is literally the first and last time that I will ever do that. So I kind of had to learn a little bit of React, and I couldn't wrap my head around some of these things. I'm like, why? Why are you doing it this way? And I'm sure there are reasons for it. But I thought, well, let me do that, because the whole company was using React.

(Heydon): Well, it was your way of getting your head around the material that happened to be being used.

(Stephen): But it's just a prototype, so I didn't have to do it that way. But I did it that way, and if it were a physical thing, it would probably be, like, shards of metal that were duct-taped together, you know? That would be the physical representation of this code that I wrote, which was probably awful.

(Heydon): Dead skin and Pritt-stick.

(Stephen): Yeah, exactly. (Laughs) So I handed this off, and of course, some of these developers had some comments about the code. But I was like, well, I had this feeling of freedom. Because I don't have to worry about that, because it's a prototype. Would you have rather had a Sketch file from me?

47:26 (Heydon): Or would you rather have just had a Grunt file, which helps you bootstrap the application or the prototype which you've yet to build.

47:36 (Stephen): Yeah. So, there are some things that become self-explanatory because they were in this admittedly poor prototype, but they were clear. Certain things that had to happen when you tapped or clicked on something.

(Heydon): Well, that's what it was for, right? You fulfilled your obligation.

(Stephen): That's what it was for. Rather than stringing together some static images where I have to explain and spend a lot of time documenting, ”Okay. When you tap on this thing, this thing happens,” and then hope that they understand what I mean while I'm moving my hands in the air, trying to express something. And just hope that they get it. Now I can just say, “This is what I want, but I'd like that to happen a little bit faster,” or whatever little extra tidbits I need to give them. It seemed to work. But then someone's always going to look at the code. I'm like, I trust you to write good code. See this as a glorified Sketch file that's way better than a Sketch file. And then I don't have to worry about any of that stuff. It doesn't have to be performant, it doesn't have to like, fit in the whole toolchain that they've got going.

(Heydon): That's the engineers job.

(Stephen): I'm not trying to take anyone else's job. I'm trying to communicate something.

49:08 (Heydon): Well, I mean, they should be grateful that you're not doing that stuff.

(Stephen): Oh, I'm so grateful.

(Heydon): No, no, I mean they should be grateful that you're not doing it, in a way.

(Stephen): (Laughs) Thanks a lot.

(Heydon): Because you're not stealing their job.

(Stephen): Exactly. I mean, I would hate to be in full front-end development today. And I know I'm going to sound like some old guy, but it was easier. When I was really involved in front-end development, I had one foot in both, basically, when I had a company that did design and development, which arguably are the same thing, in a sense. But back then, things were simpler. Even the choices were simpler. You didn't have to choose: Vue or React? And why? And then you have to deeply understand both of these. At least, I feel like I'd have to deeply understand both to make a choice.

I'm glad I don't have to do that. Basically, what I want to do is: I have this thing in my mind, and I need that to not be in my mind anymore and someone has to build it.

(Heydon): Yeah, I know that feeling.

(Stephen): I need to communicate that to you. And what is the best way to do that? Sometimes, it might be a sketch on a piece of paper and a five-minute conversation. And other times, I need to be more explicit about how I want a particular thing to happen on the screen. And since I have that extra bit in my toolset of being able to do these HTML and CSS and limited Javascript prototypes, I can better communicate that to you. And that, to me, is very valuable. And I think that if we gate-keep, we're preventing a lot of designers from discovering that same thing. They might have a tool that helps them communicate even better than they do today.

51:09 (Heydon) Right. Yeah. And I think that should be, the standard should be, here's a problem for you. Use whatever it takes to fix it.

(Stephen): Yeah.

(Heydon): Yeah. And obviously, if the problem is highly technical, you'll probably choose someone with more experience in what is likely to be thee technical areas or with the technical tools that might best fit it. But i think we need to be way looser, in general.

51:40 (Stephen): Yeah. Don't pigeonhole. Don't gate-keep, don't pigeonhole. Embrace all these different skills, you know?