 How many of you are designers? Designers at all? How many of you are designers only? You only do design, you never do JavaScript. If so, I'm not sure why you're here. You, you're my favorite. So I started out as a designer and I loved it. The only thing that I found was being a designer felt really constricting for me. And I always wanted to do more things. So I branched out into development. I actually went to the IronNerd, which is the competing code school, and I loved it, I loved being a developer. So how many of you are developers only? Like you, no one trusts you to do design. Like your stuff looks like prototyping and you're like, oh God, don't show this to anybody. That was never me. I have always had a design background. I was the kid that drew like fingernails on their stick fingers. So I've just been really, really like into design from the very beginning. So the thing that I found is actually, I think really what's happening is more and more everyone is starting to do all of the things. And so you really can't say anymore, I'm just a designer or I'm just a developer. You always have this, I do a little bit of design and I do a little bit of development. I do a little bit of all of those things. So I think most of us do a little bit of everything. I would personally label myself now as a front-end developer. I used to be a graphic designer and I learned an enormous amount about stuff like colors and typography and hierarchy and a lot of those principles are really important as a designer but more than that, there are principles of the designer that are really, really important as a developer. And how I, is that working now? Okay, cool. Yeah. So there's a lot of trending now towards specialization and a lot of people, I think they say, well, I'm a front-end developer or I'm a back-end developer or I do these things and more and more and more, the complexity of websites necessitates that we specialize in these things. That's being said, it's really important to realize that drawing lines in the sand is really just, it's a terrible strategy. It's losing for everybody. Design isn't purely aesthetics, just like code isn't purely just, I ruined that. Development isn't just simply lines of code. Okay. So in reality, the principles of good design often mirror those of good development and every member of the team, whether you're a designer, you're a developer, whether you're front-end, you're back-end, you're DevOps, UX, UI, whatever you wanna call it, everybody has the same goal and that goal is to ship a product and a lot of times we forget that one thing, that we're all on the same team. So let's take a look at a few of the skills that designers have that would make us better developers. Spoiler alert, that's my Twitter handle. So first skill is creativity. So one of the most common skills associated with being a designer is in fact creativity and a lot of times when we talk about creativity, we talk about what's called big C creativity and so that's this idea that the biological and behavioral traits that contribute to extraordinary achievement of individuals. So it's this like pie in the sky, like amazing creativity thing that it's almost like it's descended upon you and it's just like desperately sought after stroke of genius. It's this idea that oh my gosh, like I have this idea. But that's really constricting. That's just one kind of creativity. Creativity can actually be defined in a lot of different ways and so we like to call that little C creativity or just everyday creativity and it's a lot less elusive and one of the really important things about little C creativity is that it can actually be practiced. So anytime you can do a thing over and over again, anytime you can sit down and say okay, I'm going to try this, that's a lot more important than just waiting for this pie in the sky idea to descend upon you because there's nothing you can do to make that happen and creativity that you can practice is super, super important because that gives you the control. So everyday creativity is simply the ability to investigate, generate and recognize ideas, alternatives and possibilities. Ultimately what you're doing is solving problems. So it's not descending upon you, you're actually setting down and you're solving a problem. So as developers we practice what Benjamin Dalton who's a sociologist refers to as habitual creativity. So we hack things together, we make it work, we iterate, we debug, we refactor. I'm a new developer, I'm doing a lot of those things. So we consciously seek to improve on our habitual actions to build up routines and practices that are more efficient and successful than they were previously. So we're always trying to get better. Like Tyler said, we're always learning. We should always try and be doing new things. And creativity doesn't mean that we're always building new things and reinventing the wheel, it just means that we're doing something a little different than we were before. And what's really, really easy to forget is that design is not evolutionary so much or it's more evolutionary than it is revolutionary. So it's slow changes, it's a process. It's not this creativity that stands on you and all of a sudden you have this great idea and everything works. That's not how it works. That's not how it works for designers and it's not how it works for developers. So by reorganizing, recombining, and reinterpreting concepts and ideas, we're practicing creativity. So stop thinking as a developer that this is something that is the designer's responsibility. That's your responsibility too. Just you may be solving different problems but it's still creativity. We're still relying on the same basic skill to reframe our thinking. Intuition. By practicing creativity, we're also developing intuition. Intuition builds on creativity. It basically gives us the insight and ability to perceive the quality of our ideas. So experienced designers can identify when something doesn't feel right. It's just the sort of sixth sense of, ooh, I don't really like that or oh, I think that's the right way to go. Does developers actually have that skill too? I'm a relatively new developer so my intuition on whether or not something's going to work is not so great right now but it's getting a lot better even just over the last six months and that's really exciting to me. So basically experienced developers have a really, really great programmatic sense of what's going to work. And harnessing this intuition and harnessing this ability to say, I think this will work. I think that this won't. That can dramatically increase your efficiency and that's super, super important especially if you want to be employed. So my first job out of college was actually working as a graphic designer at a local agency. And I was the only designer there for a little while as an intern. They also had another guy that worked there eventually. And so after a few months, this guy left to found his own agency and all of a sudden it was just me and then the two founders of the company and basically two project managers. And my bosses were in their 50s and 60s respectively and it just became really, really apparent all of a sudden how incredibly, incredibly unexperienced I was and how vast the gap was between them and me. And so the first large scale project that we tackled was for a company, a French company called Chomera that actually is a local office in South Carolina. And one of the most tedious tasks that we did was recreating, editing, designing and typesetting about five or 600 different data sheets. That is so boring. I mean, it just, it eats at your soul. So the number of data sheets to get through was just, it was astounding. It's boring, it's awful, there's nothing you can do about it. Especially considering the size of our team, there were just four of us and I was the only designer. So what that really means is it was just me doing this thing. And so when we sat down and we're talking about how we should proceed, one of my bosses said, well, let's just edit the PDF. We already have that. The problem was the PDF was not the native file. I don't know how many of you have ever done Adobe Creative Suite. This stuff was actually created in Quark, which is super popular in Europe, never really popular here. So basically it was just, it was a huge mess. So not having access to the native files dramatically increased the amount of frustration for me and the difficulty of getting a really consistent look and feel. And so I realized, gosh, you know, this is going to take me forever. And we have literally hundreds of these. So my boss was super, super hesitant to invest time in something he couldn't directly sell to the client. He really was hesitant to my idea of creating a template to make things more efficient. So I came in one weekend and I built a template by myself on a Saturday. Completely didn't tell my boss I was going to be doing this thing because I knew he wasn't going to like it. So on Monday morning, I switched to using my template instead of doing it the way I had done before, which was just adding them one by one by one. And I was able to do about a half dozen or so in the amount of time it would have taken me to do two or three normally. And so when I went to my boss that afternoon, I said, hey, you know, here's my work I'm done. And he was really shocked at how efficient I had been. So I told him the whole story. I said, hey, you know, listen, I came in on Saturday and I built this template and I knew it was going to be more efficient. And basically the template what I was looking for was something with enough structure to make it worth it, but enough flexibility to really be able to use it over and over and over again. He was not real excited. If you've only been working for somebody for two months and you tell them you're not following their rules shockingly, they're not real thrilled. But so there was a moral to the story. I brought in my lunch that day on Monday and I also brought in a bunch of stuff to eat for dinner in case he was really unhappy with me or worse, he fired me. So he wasn't immediately impressed but the project continued on, he wasn't angry and eventually we finished the project using my templates. I am not telling you that ignoring your boss is a good idea. In fact, that is super, super risky. It's a terrible idea. I got lucky, I trusted my gut instinct and I turned out to be right. So for me, it's an instance of trusting your intuition and saying, hey, I have this feeling that something is going to work. And a lot of times as developers, we forget that that's in there and that that is a skill that designers are sort of taught to trust this intuition, this creativity. And I think sometimes developers maybe not quite so much. So you might not be right. It could totally backfire and it could not work but I think it's a good starting point. The next thing is communication and understanding. So once you've mastered the ability to generate and then judge the viability of your ideas, you can put them to work. And as designers and developers, we rarely build something that exists on its own. Typically it's part of a larger whole that's built collaboratively. So there's more than one of us doing this thing. Design's not purely aesthetics. Development is not just lines of code. Designers have to learn how exactly functionality affects form and developers have to figure out how to be creative in building out functionality. Ultimately, both of us have to work with one another to create the product. Rather than seeing ourselves as two separate groups, we need to work together to achieve greater success and remember that the ability to communicate effectively among all members of the team. So really all members of the team, not just developers with other developers, designers with other designers, but developers and designers and really everybody. This ability to communicate is at the heart of both design and development. So if you Google the phrase designer, developer communication, you'll have 19.7 million results. So obviously there are a lot of people thinking about this kind of thing. With so many blog posts and articles and just advice on the subject, it really shouldn't come as a surprise that this ability to converse between designers and developers between different teams is so hard for people. After all, it's a common to hear designers and developers say that they feel like they don't speak the same language. And that's true. The vocabulary that we use is really, really different. But that's the thing. I don't think that a lack of shared sort of knowledge or a lack of lingo that we share between the teams is the actual issue. Instead, I think this statistic, the 19.7 million people, I think that speaks less to a lack of communication specifically and more to a lack of understanding. And to me, those are two separate things. So how can designers and developers overcome the lack of common vocabulary to get to a place of understanding? I think that starts in a place that's pretty obvious. Learning how to break down boundaries and overcome stereotypes is a great place to start. It's not easy. By actively promoting positive open communication in which collaborative searching and questioning are encouraged, we can establish a baseline of shared knowledge and understanding. So start with something really, really small. You are both human beings. And that's a great place to start. Sometimes when I'm talking to people, I feel like that's all I have going. And I'm sure you all have felt that too. It's just, it's so hard to figure out what's that first step. So great first step is reframing your request in terms of objectives to be fulfilled instead of dictating their implementation. So instead of telling somebody, I want you to build me this, tell them, well, I'm looking for this. Like, I'm trying to increase the number of clicks here or I'm trying to do this. And it's so much less dogmatic. It's so much less frustrating to hear, hey, help me try and figure out this thing. Then for somebody to say, this is what you have to do. And that's just, it's so frustrating. So when things kind of backfire, when things aren't going well, one of the things that we really need is empathy. So the natural outgrowth of a relationship, a super healthy relationship founded on communication and understanding is empathy. And that's just the ability to identify and relate to one another's thoughts, attitudes, and feelings. So it's the ability to see that developer or to see that designer as somebody who's on our same team. They're not giving us mandates. They're not frustrating us. It's just, hey, we're both working on the same thing. And we have to shut the product. That's ultimately our goal. So empathetic design has been talked about a lot recently, much more so than, for example, empathetic development. But really, empathetic design, as popular as it is right now, is super, super old, actually. There was an issue of the Harvard Business Review that came out in November 1997 that actually talked about empathetic design. And they said, the techniques of empathetic design, gathering, analyzing, and applying information gleaned from observation in the field are familiar to top engineering and design companies, but they're not common practice. I would say that you could make a case that that is still true today, and that was in 1997. So obviously we have a great long way that we can progress. Pete Smart is another designer who went on this super cool trip to learn about 50 different problems he could solve with design. Ultimately, he was focused on design, but really what he learned was empathy. And by getting away from his daily routine, by getting away from the things he does, just over and over and over, he found out that the constraints of his design process were really allowing him to miss the empathy that is so super important. And so he said, real empathy is not naturally fostered in focus groups. It's not uncovered in analytics. It doesn't start with personas or empathy maps. Real empathy starts with people. And that's what I was talking about with being a human being. Just start with the tiniest thing that you can possibly think of that you like about that person. And sometimes that's really challenging. But while Smart's journey focused on design, the lessons that he learned are also equally applicable to development because empathy is for everyone. Empathy is for people. So a programmer that is really skilled at anticipating and responding to the customer's needs is significantly better at capitalizing on the possibilities offered by new technology. And in fact, some of the most impressive ideas come from engineers and designers who actually use the products that they're developing. If you're close to something, if it's solving your need, you're gonna have a lot better feeling of, oh, hey, I think that this could really work or this would feel right to me. So rather than relying on traditional research techniques and data that's gathered in relative isolation from other disciplines, we're focusing on just this one tiny little thing. Empathetic design demands creative interactions among members of an interdisciplinary team. So basically they're just saying work together. So we're together from day one and that really can maximize innovation directly by connecting the people who know what can be done. So a lot of times that's the developer who's implementing the feature or the designer that has this understanding of, okay, this is how this looks, with the person who needs something done. And sometimes that's the user, but sometimes it's also us. I mean, when we're using our own products, we have this really good understanding of, gosh, I know how to make this work, but I don't know how to make this look good. And so that's really where the connection between designer and developer comes in. So by combining the knowledge of unexpressed needs with the knowledge of how to fulfill those needs, companies can really utilize their existing technological abilities much more effectively. So while empathy is definitely good for the user and it's good for creating better products, it's also really great to create empathy among our team to build an empathetic culture. An idea that's designed in innovation companies says, when companies allow a deep emotional understanding of people's needs to inspire them and transform their work, their teams, and even their organization at large, they unlock the capacity for creative innovation. And I think that's something that you really have to start at the very beginning. You have to say, okay, where can I start? How can I show empathy? Adam, I think, gosh, I guess this guy's name is Weitz Weitz. He is an assistant professor of management and organizations at the Kellogg School of Management agrees with him and he says, the organizations that engage in these types of activities are very effective in what they do, particularly in the domain of innovation. So all of these skills, communicating, understanding, empathy, creativity, intuition, this stuff all goes together. It's all part of a bigger piece. And so by promoting even one of these things, we also subtly encourage the others. So it's the idea that healthy culture begets healthy culture. Unfortunately, sometimes everything just sort of falls apart. Everything blows up in our face and we just really can't see the other person on the other side. And so what we need then is patience. So sometimes the creative juices just aren't flowing. Our intuition leads us down the wrong path. Communication is failing. Empathy, definitely at an all-time low. What then? So I would say that those of us working in design and development have committed ourselves to a life of constant improvement as evidenced by the fact that you all are here today. We've committed ourselves to never stop learning. We've dedicated ourselves to keeping up with this super, super, super rapid pace of development and design in our industries. And design and development are both similar in that they're kind of like a craft and they require an incredible amount of knowledge and depth that takes a lifetime to master. So you don't sit down one day and decide you're going to be a developer and at the end of the afternoon you say check. That's just not how it works. And being a designer, it doesn't work that way either. So this constant pressure to be learning, to be doing new things, to always be implementing something that maybe you didn't know how to do before. It's super stressful and it's no wonder that we forget to be nice to each other. We forget our manners. Sometimes we revert back to childlike name calling and being kind of awful, but we're only human. So basically, whether we're designing better interfaces or developing new features, it's super easy to lose patience with ourselves but also with others. And there's a certain amount of work that is necessary to... Or there's a certain amount of pressure that's necessary to sort of force us to work, to inspire us to do great things. But sometimes that pressure can get in the way. And so a lot of times what we have to remember is that we need to give ourselves time to try and to fail. So we can't judge each other on super, super fleeting moments that are really short or hasty decisions. We need to focus instead on the body of work as a whole and forget about those super tiny snarky, sort of like Twitter remarks, or when we say one stupid thing and it all of a sudden defines our whole existence. We should give each other the benefit of the doubt and understand that everybody fails and everybody messes up and everybody, a lot of times just feels awful about it. So designers know that innovative ideas don't come at the flip of a switch. Instead, the most effective solutions are often the product of hours and hours of thinking and sketching and reworking. So similarly, the results, the best results in development are often those of refactoring and taking the time to look at a function or look at a snippet of code and decide how to make it better, more modular, more simple, less dependent on other things. And so we really need to give ourselves time to think, time to architect, to ideate, to push through the barriers that really seem insurmountable. And really at the end of the day what this all comes down to is this idea that we can put our heads down and get to work knowing that the answer is going to come eventually. If you're patient enough, eventually it'll come. And we knowingly can practice patience, trusting in the belief that our best work is yet to come. So don't judge yourself on what you've done already. Sort of focus instead on what's coming. And so the pinnacle of our careers is not in the past, hopefully, but it's in the future. So as a new developer, that's something I try to keep pressuring myself to think, okay, like you're just going to get better. And I hope everybody does that and remembers that there are a lot of skills that crossover between design and development and that everybody really works well on a team. Finished. So three questions. So she said what was a skill that I had as a designer that was super, super helpful when I became a developer? I would say probably the idea of empathy. So a lot of times in my job right now I'm asked, hey, why did you code that way? I would have done it like this. And so a lot of times developers get super hung up on this idea of code efficiency. And that's great, like I love code efficiency. That being said, as a user, if it's awful, I just, I can't get over that hump of like, this is terrible. So the idea of empathy for me is super important. I ask a lot of questions, probably to the point of being annoying. But that's something that designers are taught is to question and to ask and to just like almost to be annoying like that and to say, hey, I don't know that answer, but I'm gonna try and solve it. I would say that's probably the most important thing for me. Okay, so what resources have I used as a new developer? I would say, and this really, really irritated me when my teacher told me this, but he said, read the docs. I feel like everybody says that. It's true. A lot of times it means I'm reading them six or seven times because there is a certain amount of programming knowledge that you need as a junior developer to be able to read the docs, to be able to understand those things. I remember reading a blog post from Adia's Money and it was like eight pages long and at the end of it, all I got was decouple all of the things. And so that was something where I was like, well, you can look at it in one of two ways. One, you can look at it as I just spent 20 minutes of my life reading this article, I have no idea what he said. Or two, you can say, okay, all I learned that he is that he wants to decouple all of the things and that's something that I can take in a super, super, super simple form and still put into my work. I would say for me as a junior developer, there's a lot of development that is still really frustrating. Specifically, I think there's a lack of mentoring, shameless plug if anybody wants to get into that. I think it's something that is incredibly, incredibly important. That's probably the biggest challenge I've faced as a junior developer is that a lot of times my face has heard of like, when I'm asking questions, am I being annoying? Or sometimes it's like, I'll follow along to a certain extent and then I think, well, gosh, I really don't know what you just said. And it's like, do you ask? Or do you just sort of swallow your pride and go for it or do you just sort of like, put your head down and be like, I don't know what you just said. Like the big O thing, I loved the talk, totally over my head. And I'm willing to admit that. I think that's a really big thing for a junior developer is to say, I don't know, but I'm learning. And I think that's probably, if I could put it into like a nutshell, that's the biggest thing. It's just to constantly tell yourself, I'm still learning. And I think as a junior developer, that's important, but whether like you're 10 years down the road, you're still learning. And that's super important to remember. That's a complicated question. Okay, so he said, did I find a company that had this culture or did I create it? I actually work as a freelancer, so there isn't really a company. I inherently ask a lot of questions. I sell about 30 hours of my 40 hours a week to one specific company. And they've been really, really good about me asking questions and about me positing all of these things and saying, hey, I don't understand this and trying to bring in this company culture of empathy, of communication, of design. I think that's something that everybody needs to work on. I can't come in and like dogmatically say, hey, I think your company needs to run like this, especially as a junior developer, especially as a new hire, that's a terrible thing. You're likely to get fired. Actually, I tried that and I did get fired. So I can tell you that that's what happens. I think everybody needs to work on it. Everybody from the top down, it's super important. And I don't think it's a, I can't give you a simple answer of one way, this, one way, that. But definitely, it's a good place to start that you can be empathetic. You can communicate, you can be understanding. And even if you're not changing the company culture, so to speak, you're becoming a better developer yourself. Yes, I love fair programming. A lot of time can be really time consuming. I personally like it because for me, someone showing me something is a lot more important than someone talking at me. I had a teacher when I was in high school that thought I was stupid because I was in a German class and she just did a lot of speaking. Two years later, I moved to Germany. I'm fluent in German now. I know that that doesn't seem related to fair programming, but I think that basically it's just the idea that someone sitting down and involving you and showing you is so much better than them just like spitting things at you. And that's really, it's a great way to learn. Thanks.