NOEL: Hello and welcome to Episode 66 of Tech Done Right, Table XI's podcast about building better software, careers, companies, and communities. I'm Noel Rappin. 

If you like Tech Done Right, keep an eye out for our new podcast - Meetings Done Right. Meetings Done Right is 12 episodes with communication and culture experts, all focused on how to improve your meetings using the new Table XI Inclusion Meeting Deck, and other tips and techniques from our experts. For more information about the podcast and to learn how to buy a Meeting Deck of your own, go to MeetingsDoneRight.co or search for Meetings Done Right wherever you listen to podcasts. 

Our guest this week is Ariel Caplan. Ariel is a developer at Cloudinary and the Founder of the Dev Empathy Book Club. At RailsConf this year, Ariel gave a keynote about culture through The Stories We Tell Children using examples from Israeli and American children's literature. In our conversation, we focus on the stories that developers tell ourselves about who is successful, what it takes to be successful, and what people and skills are left out of those stories, and how we might be able to change them. So, here's the show and my conversation with Ariel. 

Ariel, would you like to explain who you are to the people who are listening?

ARIEL: Sure. I am a Rubyist for the last few years. I currently work at Cloudinary as a Backend Developer. And I gave a talk at RailsConf which I think is probably the genesis of this episode which is basically about how we tell lots of stories and send lots of messages in a lot of what we do, things that we don't even notice, and the way that these subtle messages and these little stories shape our community and are shaped by our community. So, I think we're here to talk about some of those ideas today, not just a repeat of the talk, but to dive deep and think about some of these stories that we're telling in the various tech communities that we're a part of.

NOEL: The show notes will contain a link to the talk which I recommend you check out. But what I want to talk about here is sort of more generally the concept of the stories we tell in our tech community particularly, I think, going off the themes that you were talking about the stories that we tell people who are entering the community or thinking about entering the community. So, what kinds of things do you think we emphasize in the stories that we actually tell to new members of the community? What do you consider these stories to be? 
	
ARIEL: There's a wide range, I think, of what I would call a story but there's a few things I would probably call attention to. One thing is we get into this community possibly because we are interested in programming and we like tech and that's cool, but also because we want to get a job. And so, the things that companies look for in jobs, I think, are one really important example of the stories that we're telling to new people in the community because that kind of says, "OK, know as you're thinking about really entering the professional world in the context of the tech community, what are the things that we care about? What are the traits that we're going to value?" And so, just as one example, look at you know 100 job descriptions. It's very likely that you'll see a whole bunch of different technical terms, different languages and frameworks and tools and things that you have to know this, bonus points if you know that, whatever bonus points means. You're not likely to see nearly as many references to things like works well with others, is able to communicate clearly. Although, at least, that has been slowly growing in job descriptions. You'll have very little about, let's say like in senior postings, you're not necessarily going to see a lot of knows how to mentor junior developers and bring them up. You'll see it here and there but a whole lot less than like has five plus years experience with PostgreSQL. And that's just one example. There are a number of channels through which we kind of send this message that technical skills are important, that empathy and soft skills, they're good, they'll help you out, but they're not nearly as important.

NOEL: Even the phrase soft skills... 

ARIEL: Yeah, absolutely. I'm not so comfortable with it. 

NOEL: We tell the story in a lot of different ways, I think, that developers are creatures of reason. 

ARIEL: [Laughs] Absolutely. 

NOEL: And that the important thing for success in a technical job is technical knowledge.

ARIEL: I think one really critical example of this is the Myth of the Lone Genius. And I'm certainly not the first person to talk about this. There's a phrase that's out there for a reason. But we have the vision and the story of these people who like went to a prestigious college because I guess they had enough money to do it from their parents and then they dropped out in the middle and then they went on to find these gigantic companies, and that's like the creme de la creme in the tech world. And we talk a lot about like these people did what they did with other people, with teams. They had to develop relationships. They had to learn how to manage other people. They had to learn all these very, very human skills along the way. And by the way, it's not just them. There's a whole bunch of other people who followed more traditional tracks as well. So, there's this worshipping of genius and of technical knowledge, there's almost a worshiping of a lack of interpersonal skills sometimes. The idea of all you need to know is the tech and all you need to know is things and you don't really have to be able to work with other people and connect with other people in a deep way in order to do your job. If any of the literature that I've read is any indication, the exact opposite is true. The technical skills, yes they're important. Yes, they're kind of a baseline, but so much else is really, really important and critical in accomplishing the basic things that we're trying to do.

NOEL: That even goes beyond tech. Think about how many pop culture stories there are about the brilliant but terrible person who you have to put up with because he's brilliant. So, this is like your Sherlock Holmes, your House, your Sheldon Cooper Big Bang Theory, all these people who are considered, their genius is so unique. I feel like a common story that we tell. People whose genius is so unique that we have to put up with how terrible they are to other people. 

ARIEL: Absolutely. 

NOEL: And I feel like that bleeds over. I was thinking as we were preparing for this about how like the Lone Founder Myth has kind of changed a little bit in the last generation or so, from like the classic Silicon Valley started in a garage story to Mark Zuckerberg is not really a 'started in a garage' kind of story. It's more like the 'move fast and break things kind of story'. How do you see these stories actually playing out in terms of day to day expectations that people have on teams or in projects or as they interact with the larger community? Do you see these things as having an effect? Do you see efforts to sort of change these stories within various communities?

ARIEL: One thing I can point to and I'm not sure it exactly parallels the story, but it's really not too far off from it, is the way that many teams work in many individual work streams. And so, they'll say, "Well, we want to adopt Big A Agile and so we'll start introducing all kinds of rituals and we'll have our stand up or we'll have our weekly or bi weekly big meeting," whatever it is. But that everyone's just kind of going off and doing their own thing. And there's this idea of everyone should be able to just accomplish everything that they're doing on their own and maybe get a little bit of help from other people if you're really new, but more or less everyone's in their own individual work, as opposed to having a more collaborative work system where tasks are assigned to two or three people. You work together very closely. Maybe there's pairing, maybe there's not as much pairing on certain tasks but at the very least, a sense of collective responsibility. I think holding up the Myth of the Lone Genius convinces people that while I've been in this industry for X number of years, I should be working as a lone genius, too. And so, you see these teams of like very, very senior people who are often, I think, a lot less effective than teams who don't have as much "senior" talent but at the same time, are able to work collaboratively, are able to have important conversations about the work that they're doing, maybe sometimes have ethical concerns that completely sweep past the heads of the programmers who are working on them. And I'm not going to start going on one of these crusades about programmers and ethical responsibility, not because I don't think it's important. It's absolutely important. I just sometimes think that that starts to blame the programmers solely for the decision that have been made differently by business people. I want to go down that track right now because that needs its own discussion and its own nuance. But I think that's just one example where we say the programmer's job is not to think about the importance of the work that you're doing, the programmer's job is not to think about how to work well with other people. The programmer's job is just like know everything right away and hammer out the code. And that leads to worse code, it leads to worse products, it leads to sometimes unethical products. And again, I don't want to jump to a conversation because yes, it is important to have, but it is important to have right. But I think there's a lot that comes out of this.

NOEL: That's not a story we tell. We don't tell the story of the programmer who thought their manager was telling them to do something that was unethical and pushed back. 

ARIEL: Yeah. [Chuckles] That's true. It doesn't make good headlines, I'll say that. It's not going to get a whole lot of clicks.

NOEL: We don't tell the story of like -- we don't have a cultural myth of the game developers who unionized. 

ARIEL: [Chuckles] Right. 

NOEL: Actually, that was a little bit flip but there are other industries or other work cultures where that is an important story that they tell, that we banded together and we got a better work environment because of it. And that's not a story we tell. We tell a story where you are expected to not just put up with high work expectations but thrive and seek them out.

ARIEL: There's an essay I really like Avdi Grimm called The Passion Gospel. He basically describes there how there is this concept in our community. Again, look at job ads. Job ads are so much of our culture because they come at that kind of critical juncture in the career. But job ads are one of the key places where this is propagated. So, you'll see this idea that you have to be passionate about technology, passionate about the industry that this particular company is working in. And he says if you think about it, that's ridiculous. I don't expect a person who works in a couch factory to be passionate about couches. [Chuckles] There's this incredible video by, I think it was a British comedian, I forget what the name is. It's linked to in that blog post as well, so I'm sure we'll be able to link to it. But essentially, kind of taking this idea of being passionate about what you do and putting it in a lot of other fields and showing how absolutely ridiculous it is. Passion is this idea of being completely given over to something to the point that you lose self-control. How many of us can really say, again throwing out a random technology, "I'm so passionate about React. I just lose control every time I see React.createClass," or however you're doing it. It doesn't really matter. "When I see that on my screen, I'm just completely given over to a wave of excitement about React." I don't know that that's a desirable thing. That's a bit much.

NOEL: No, and I've been in enough technical kind of almost bikeshedd-y arguments where it seems like people do form very personal attachments to technology or bits of environment and feel like they have to defend them when under attack. And it's not desirable, I don't think. 

[Laughter]

ARIEL: Absolutely. 

NOEL: And when we were prepping for this, you were talking about Tim Cook in the Apple keynote which I actually didn't see but I heard about, and I think that fits in.

ARIEL: Yes. Tim Cook in his keynote this year basically concluded with saying that he wants to show appreciation for all people, who over the course of a number of years, for the sake of the innovations that were put forth this year, had given up nights and weekends with their families. I think the way he said it was, "They've given up nights and weekends with their families, and so on and so forth," which to me could not have been like a clearer indication of, "I need to check this box and thank them for doing it. But I kind of don't care," just that 'so on and so forth' kind of did it for me. I didn't see the rest of the keynote but I did see a lot of buzz about that particular thing. It could be taken as, "Oh, its so wonderful. He's acknowledging the sacrifice that these people have made in order to benefit the world." Or you could say, "They made a cheese grater looking piece of hardware and it took them a few years and it's going to make Apple a lot of money. And for that, we had to tear them away from their families." How terrible is that?

NOEL: There are a lot of stories that we tell in this sort of realm that are in effect very beneficial for the people who employ us to have be stories. It's very beneficial for Tim Cook that the story of the passionate engineer who works nights and weekends and doesn't see their family is a story, because that enables Tim Cook to have fewer engineers than Tim Cook might otherwise need.

ARIEL: And the funny part is it's probably not even true. Again, there's so much literature about the fact that people can't really do more than a certain amount of creative work during a week. And so, all those nights and weekends, I don't know how much they helped but certainly talking about it didn't necessarily help the industry. And the truth is though like this happens in so many companies. I've seen it time and again that people want to encourage a certain kind of behavior from their employees. And so they say, "OK, what am I going to reward? Obviously, we've all been taught that rewarding outcomes is kind of unfair. So, let's instead reward this extra effort." It might even come from a good place or again maybe it comes from a very cynical place of wanting to boost the company's bottomline. But either way, the result is it means that people have this terrible motivation to show their dedication to a company, to a product, to a team by putting in extra hours by staying late in the office, by putting more of their time and energy. And again, not necessarily in a way that's even healthy, both for themselves and for the teams and the products and the companies that they're working with. But they have this as motivation because otherwise, how am I going to advance in the company, how am I going to prove my loyalty? That's a narrative that, again, needs to die in a fire but it's so common.

NOEL: I don't know about you. I've been fairly lucky most of my career to be in situations where my time was respected and I was not expected to do that kind of thing. In that times when I have been in that situation, one of the things I find is that people become incredibly -- I don't think this is true of every case. I think there probably are cases where people really do push in a different way. But one of the things I found is when I am expected to put in that kind of time, that the employees become sort of incredibly slack with their own time. There's a lot more of like a lot less focused time on task, I think, as a way of dealing with the fact that there is really only so much creative work you can do in a day, no matter how many hours you spend trying to do it.

ARIEL: I don't want to take a pot shot at another industry. But I think it's pretty widely accepted that this is one of the big problems in law that lawyers are paid for billable hours. And so, you're always encouraged if you want to make a junior partner or whatever it is, you've got to put in as many billable hours as you can. And so, lawyers literally don't see their families. And I've watched this play out. When I was younger, I was a counselor in a day camp. And there was one kid who I figured out pretty quickly. He had everything he wanted in the world from a financial perspective but he never saw his parents because they're both lawyers. They left in the morning before he was up. They came back in the evening after he was asleep and they said 'hi' on weekends. And look, everyone's got to choose the career that works for them and you're bound by the restrictions and the rules of that career. But it hurt me to see the human impact of that particular career choice. Again, I'm not telling people don't be lawyers, don't be this, don't be that. I'm saying that this is a narrative that we need to figure out how to change, not just in our industry but in society as a whole because it's hurting us much more than it's helping us.

NOEL: Another narrative that I think you touched on has to do with how we expect senior developers to answer questions and respond to the needs of people who are newer into the industry. And I think that we have, a lot of times, like a pretty rough history with that, a pretty tough story about learning. I was wondering how you would describe the stories that we tell ourselves about how to treat people who are learning new things in our community.

ARIEL: There's definitely a lot to say about this mostly because so much of it has been said in a toxic way. There are these ideas out there that you have to work hard to be a developer. Again, part of these myths of determination and grit, being kind of the core elements, kind of a certain amount of innate technical skill would seem to be somewhat contradicted by the idea of even asking the question in the first place because you should just be able to kind of dive in and figure out how everything works. So, already the moment somebody asks a question, they're in a very vulnerable place. And the truth is this isn't unique to programming. It's just a little bit worse in our community. But in general, in society, there's a lot of times when people will be looked down on simply for asking a question. So again, in our community where we've developed the myth of the genius developer, it's all that much worse. Now, on top of that, I guess maybe it emerges out of a certain sense of our time is so valuable and we definitely have a lot of... the idea of the phrase 'developer time' or 'developer hours' definitely holds a lot of sway. And so, we think a lot about 'is it worth spending my time on this'. And unfortunately, that question very much gets asked when it comes to questions from juniors or creating training materials for juniors whether it's literal juniors or people who are maybe new to a company, to a technology, et cetera. Even if you’ve been programming for the last 20 years, you can still be a junior in a certain way.

So, we've kind of developed this idea of in order to optimize for the person who has to answer questions or for the person who has to give that training, your obligation is to meet them as much as you can. And so, it can be anything from like, "You should spend 50 minutes googling it," which is not such a wild idea versus like, "Here is a 3000-word essay on all the things you have to do before you dare to ask a question and make sure that you ask a question the right way." And I wish I was kidding. I wish I was exaggerating but that essay literally exists and it is extremely popular. So, I don't want to go back too much to that talk but this is just a link we can drop. I mentioned it there and you can verify it for yourself. This is an essay by an individual who I'm not going to mention. But the founder of Stack Overflow, Jeff Atwood, and again, Stack Overflow is kind of like the central place where people are asking questions in our community. The founder of Stack Overflow wrote an essay about how much he loves this other essay about how to ask the question the right way and how so much of Stack Overflow is based around this idea of you have to ask a question the right way. And so, that puts a huge burden on the person who's asking it. It creates fear, a culture of fear around asking questions, and it means that we are, as a community, held back in our learning because we're just too afraid to ask questions.

NOEL: I think it relates a little bit to what we're talking about lone genius, too. I think there's a sense of like there's a story that we tell that you should be able to find all of this out without other people. And therefore, by asking a question, you're like violating this implicit pact which is crazy, like everybody has questions. [Chuckles]

ARIEL: [Laughs] Yeah.

NOEL: But I think that there's this sense, and I actually think one of the places that you see a bleed over is in interviewing where it certainly still is and has in the past been even more common to ask people, to do sort of really artificial whiteboard programming kind of tasks without any of the things that you would use if you were actually doing the programming in the real world. And I think it kind of relates. I think that those sort are related in the sense that we expect you to be able to have all of this knowledge in your head be a self-contained development unit.

ARIEL: One of the best advice I think I got in that regard is you can't get away from whiteboard interviews or maybe whiteboard interviews 2.0 where they actually let you use a computer. But these questions are there on, I don't know what percentage, probably nearly all companies use them which is why there's now a movement against it because it's so ever present. But one of the best things you can say when you're faced with one of these problems is I don't know. It has to be that you really don't know. But that lets you have a conversation. They see how you're able to learn things. And if that company is going to be a good place for you to learn and pick up things, the way they're going to react to that is, "OK, great. Let's see how this person learns something, learns to deal with the challenge that they haven't seen before." And if it's a company that's not a place that you want to work at, maybe they'll turn you down. That's not the worst thing in the world.

NOEL: The phrase that was just coming to my head as I was talking about this is 'real programmer' which is I guess another set of stories we tell ourselves, that there is such a thing as a real programmer. And real programmer, I think, is always defined as like one level away from whatever I'm doing at the moment.

ARIEL: Right. You have to be open to like someone who is a little bit below you, otherwise it just looks arrogant. So, you open the definition just a little bit but not really beyond that.

NOEL: As a Ruby developer, I've certainly been in the real programmers... I've certainly heard the real programmers. You see real programmers use Emacs. Real programmers, I don't know, people who do JavaScript, especially people who are CSS experts have certainly heard that. I don't know about you but I think CSS is magic and the people who can control it are amazing. Yet there's this sort of myth that the closer to the computer you are, the real your work is.

ARIEL: I think this plays into some things that we've been talking about before, this idea of the programmer as being removed from people more, you speak machine, you breathe code which is just funny to imagine in my head what that would look like. 

[Laughter]

ARIEL: I might make some nice art with it, but like that is a lot. And it wasn't always that way, by the way. Back in the day, when women were doing most programming in the early days of computers, no one thought about it that way. And suddenly, they developed this mythos of programmers are technical, programmers are moving people and I think very much along with it, that programmers are masculine.

NOEL: Yeah. There's a very weird and interesting sort of history to when this change happened, which was... I'm going to mistime it. But there was a change where at one point, actual coders tended to be women and the job was perceived incorrectly mostly as being related to secretarial work. And that switched, and the stories that were told about people who were developers switched at the same time. I'm going to do something kind of dangerous. I recommend a book I haven't read which I think covers this which is a book called Coders which came out in the last couple of months which is a little bit about this history, I think. And I'm probably going to be wrong. Maybe it's terrible. I don't know. I haven’t read it. But yeah, there's this interesting time where the things that we said culturally about what a programmer does changed dramatically as the makeup of the people who are doing the job changed in a way that's interesting and kind of uncomfortable.

ARIEL: Absolutely. And a lot of that mythos, we've probably shed like 5% of it but it mostly remains even today that it's nowhere near 50/50. But there are many more women in our community, there are many more, not just women in the rank and file, but prominent women in our community who were making noteworthy contributions then too. It's just that no one noticed. I think today, at least it gets a little bit more noticed. But we're still trapped in this mentality of programming being this very masculine thing and again associate it with masculine, again being tied to technical masculine being tied to non-emotional, non-empathetic, et cetera. I think that the whole recent fiasco of Google bro James Damore where he spoke about or he wrote about this idea of the people versus things distinction. I mean, his whole idea and I'm going to just mention one problematic aspect of it. There were many problematic aspects of what he wrote. But one thing that he claimed was that there's this people versus things distinction which exists in the psychological literature. It is questionable. It is out there. That some people are more drawn to people; some people are more drawn to things. And men tend to be drawn to things; women tend to be drawn to people. Programming is things. Hence, more men are going to be drawn to it, which again, there's a lot to argue with in that argument. But I just want to point out one piece of it which is that people versus things and assuming that programming is things and not people, that's patently false. So much of what we do is working with other people, figuring out how to coordinate. I mean, there's Conway's Law which is decades old, many decades old, which says that the programs that we write are essentially a mirror to the humans that write them. They're a reflection of human systems. We are humans building things for humans with the assistance of other humans, and the fact that the program is executed on a machine is an implementation detail.

NOEL: I spent a lot of time these days building software, as a consultant building software for non-technical teams who are trying to add web components to their business. And that's a very, very human process. 

ARIEL: [Laughs]

NOEL: That is a process where if you're not good at explaining, in both directions, you have to be good at translating the needs of the people into things that can be operationalized in the computer and you also have to be good at explaining the constraints that the computer imposes or that the programming system imposes to the person who is just trying to run their business and really doesn't care. But you have to explain it to them in a way that they understand that there is a real constraint and that some things really are more complicated than you think they're going to be or are impossible or something like that. And that's a human problem, and none of my software projects are successful if you can't deal with that human problem.

ARIEL: This is one thing that I'm curious about because I'm a bootcamper. I went to the Flatiron School and I don't know what a traditional Computer Science education looks like. I've read through curricula but it doesn't necessarily stick in my head exactly, "OK, these are the things." I know that people are learning a lot of algorithms, maybe more modern curricula which talks about data size and deep learning and things. I'm waiting for there to be a course about technical communication to non-technical people, non-technical communication to technical and non-technical people.

NOEL: The striking thing about Computer Science education -- OK, I am a CS major but I'm a CS major in a Liberal Arts school, so I was not and I didn't  -- I went to Brandeis, I did not go to an engineering school, I went to a liberal arts school. But then I did go to George Tech for grad work and that is a very engineering school. And I can tell you, and this is somewhat out of date, but based on the conversations I've had with people more recently not tremendously out of date, that Computer Science education is very, very removed from actual day to day developer practice, which is not to say it doesn't have value. There's definitely some value sometimes in being able to ground the things that you do in some of these more abstract ideas about algorithms and about data structures and things like that. But for the most part, they don't talk about test driven development although that has changed a tiny bit in the last 10 years or so. They don't talk about working in teams, again although that's starting to change a little bit. They don't talk about working with legacy code. This was recognized as a problem even 25 years ago when I was a grad student that the program at Georgia Tech was going through incredible contortions to try and create a legacy code base that people could learn software engineering principles and that was fairly unusual at the time. So yeah, all of these kind of communication skill things are not emphasized in formal computer science education because it has different goals like it's an academic discipline that is furthering the academic discipline which does sometimes have value in the outside world but has very little to do with getting this company's MVP product up in three months.

ARIEL: [Laughs] And that's sort of interesting, is that I have started in my head, and it's an oversimplification, of course. But I've started to kind of group tech companies and tech products into more or less two groups. So, there's stuff that's heavy on algorithms and all the things that you do learn in a computer science program to the best of my understanding, and then there's like everything else where you're more in the line of business software which I'm guessing is the vast majority of software that's out there. But it's funny. So, I started out my programming career in New York. I moved to Israel and the tech scene here is very, very different. There's a lot of companies that are doing cyber security. Cyber security is huge here. There are a lot of companies that are doing all kinds of computer vision and things like that. Things that are much, much deeper. My own company, Cloudinary, we're an image processing company. And so, I think it must have been last week, I was sitting next to somebody in a meeting, I noticed he was casually glancing over an academic paper with formulas on it that had Greek letters I did not recognize aplenty. So, there's these kinds of products that really do take advantage of a lot of the wisdom of the traditional computer science discipline. And then there's stuff that has nothing to do with it. And I sort of wonder if the narratives that we tell ourselves about what the world of software looks like is very much skewed in one direction or another by the things that we experience and by the companies that we work for, by the communities that we connect with. And so, in the Ruby community, I think there's tons of Ruby in line with business software. In Japan, I understand, it's a little bit different that there is a lot more of the algorithmic type of software that's going on there. And RubyKaigi, for example, the conference in Japan for Ruby is full of that. In the US, there's tons of line of business, web apps, stuff like that, a lot of stuff that's built on Rails.

NOEL: In the US, the algorithmic scripting stuff tends to go to Python or R. 

ARIEL: Exactly. And so, that means that I can make grand bold statements about how the computer science stuff is not teaching people skills but I probably, in my own head, have a skewed perception of how valuable the algorithmic stuff is in the industry as a whole because I'm not taking into account the kinds of products I have not worked on that so many people are working on as well. So, I think some balance is needed. At the same time, whichever side of the fence you're on, you absolutely need people skills. And I think that's a non-negotiable.

NOEL: Yeah. I think it's interesting the extent to which we talk about different communities and the Ruby community which I think has made significant strides in the past five years or so to change the story that they tell themselves about the community. The Ruby community has always had, as part of its story, Matz is nice and so we are nice, and I think has in the last five years started to interpret that differently than it might have 10 years ago. But it is interesting to me to see when I do wind up at a conference that is not a Ruby conference how different the cultural feeling of the gathering is. It just feels like a different group of people setting out to do a different problem and therefore, they have different values and different stories, honestly. And I think that you can see the impact of just these kinds of stories when you go between communities like this and you see that there is both a difference or related difference in the kinds of things they tell themselves about their community and the way the community acts towards each other. And it happens even within the difference between the Ruby community and the Python community, or the Ruby community and the .NET community. I think that's interesting but it does imply that we have some agency here to change the way the stories we tell and the way that our community treats itself. What kinds of things do you think we can do to use that agency to move the community that we're a part of or a community that you're a part of?

ARIEL: One thing I think is just to be very, very aware of the stories that are being told and to have some understanding of how to move the needle. So just as one example of something that I did not too long ago, Rails announced that they're going to have new imagery that appears on the website and when you spin up a new Rails app rather than just having the Ruby on Rails logo, there's going to be like a bunch of people standing on a globe smiling, waving, friendly, fun, et cetera. And I said, "That's great. That tells a very different story than before," where it felt very, I want to say, enterprising and corporate, but a little bit enterprising and corporate which is not a bad thing. It wasn't the right story for the Rails community. And so, this is more friendly, it's welcoming, it sends a certain comforting and welcoming message to beginners. And at the same time, I said, "Well, it's not sending the same message to all people." I can't imagine I was the only person who noticed this but I said, "These look like a bunch of young cool white people who live on the same street corner in Palo Alto." I think we could do a little bit of a better job representing the actual diversity of the Rails community. All I had to do was walk over to DHH who's like the czar of Rails or whatever, BDFL, and basically in a very respectful way I said, "I love what you're trying to do with the imagery." It came from a very sincere place. I said, "I really love the imagery. At the same time, I think we could do a little bit better, and here's why and here's how." And I think when I presented it in a way that acknowledged what they were trying to do, that recognize the value in it, and that was looking to improve the community not to take people down. I think that was appreciated. And really within a couple of weeks, they made some updates to the imagery to reflect a broader diversity on a number of axes in terms of ethnicity and in terms of culture and in terms of ability. There were people with different abilities in the imagery and that was also very important to me. 

I think that realizing that people are generally well-intentioned. Not everybody is well-intentioned all the time, I think, is also very clear. But looking for these stories and by the way, realizing also about yourself. I'm not going to notice all of the stories that I'm not telling or the stories that I am telling that I didn't think about. I need to be open to other people mentioning that to me. They won't always mention it in a respectful way and that's fine. That's on me to try to be open to that feedback and accept it in the right way. But when I approach somebody else about something that I've noticed, to learn how to do it in a way that's going to be sensitive and empathetic, that's going to understand where they're coming from, that's going to assume the best in them. And my goal here is to have a conversation about it and ultimately to achieve shared goals of improving the community that we both care so much about. That's a lot of it. So, it's noticing the things that are there, being open to other people pointing out things that you might have missed. And when you're going to point out to somebody else, point it out in the right way. In this, as in everything else in life, communication skills are really, really helpful. I could recommend a whole lot of books. Towards the end, I'll probably recommend my book club about this. But yeah, I've learned a lot about communication skills in the last few years and definitely has helped in my ability to have these difficult conversations with other people. There is a book, by the way, called Difficult Conversations which I very highly recommend, among others. But yeah, being able to express in a way that's going to be heard is so incredibly important as well.

NOEL: Great. I think that sort of takes us to the end of our time. But if people do want to talk to you more about stories or anything related to these topics, where can they find you? And this would be a good chance, yes, to plug your book.

ARIEL: Cool. Of course, I'm on the Twitters, as are we all these days, @amcaplan. It's Caplan with a C, by the way. A lot of people make that mistake and think it's a "k". I run Dev Empathy Book Club which I just mentioned. So, Dev Empathy Book Club is basically is not just if you're interested in reading books, although obviously, that's very welcomed as well. We always love that people participate in our book discussions. But the goal is basically to have a community of people who are looking to improve our interpersonal skills. And so, we read stuff about management, about design, and about communication. And it's been certainly a tremendous learning experience for myself and for my co-host, Justin. And we've gotten some good feedback within the club, as well. So that, you can find at DevEmpathyBook.club. Dot Club is the TLT, that stands for top level domain. I guess my personal side and all that, you can find it in those.

NOEL: Great. Thank you very much for being with us today. I really enjoyed it.

ARIEL: And me, as well. Thank you for having me here.

NOEL: Tech Done Right is available on the web at TechDoneRight.io where you can learn more about our guests and comment on our episodes. Find us wherever you listen to podcasts. And if you like the show, tell a friend, or your boss, or my boss, or your social media network, or tell me. I really like hearing about when people like the show. Leaving review on Apple podcasts helps people find us.

Tech Done Right is hosted by me, Noel Rappin. Our editor is Mandy Moore. You can find us on Twitter at @NoelRap and @TheRubyRep. 

Tech Done Right is produced by Table XI. Table XI is a custom design and software company in Chicago. We've been named one of Inc. Magazine's Best Workplaces and we're a top-rated custom software development company on clutch.co. You can learn more about working with us or working for us at TableXI.com or follow us on Twitter @TableXI. We'll be back in a couple of weeks with the next episode of Tech Done Right.