Check out and get your ticket for Rails Remote Conf!

 

02:00 - Sarah Mei Introduction

06:11 - Why It’s Hard to be “The First Person”

13:27 - Transmitting Cultural Values

16:01 - What Companies Can Do

22:35 - What do you look for in a person as a hiring company?

24:46 - Setting Expectations Around Pairing Sessions

27:45 - Whisper Networks

34:08 - Performance Review

42:15 - “I will help you find a better fit.”

44:40 - Communication Culture

50:43 - Empathy

Picks

troll-repellant (Coraline)
Avdi Grimm: An alternative to `puts` in Ruby (Coraline)
Alan C. Kay: The Early History of Smalltalk (Avdi)
RubyTapas (Avdi)
Rails Remote Conf (Chuck)
Loot Crate (Chuck)
Prints and Visual Communication (Sarah)
Artful Making: What Managers Need to Know About How Artists Work by Robert Austin (Sarah)

Special Guest: Sarah Mei.

 

I’ll be right back.

We’re on for two seconds and I've already chased Avdi away.

Hey everybody and welcome to episode 230 of the Ruby Rogues Podcast. This week on our panel we have Avdi Grimm.

Hello from Tennessee.

Coraline Ada Ehmke.

Hi.

I'm Charles Max Wood from DevChat.TV. Quick reminder to go check out RailsRemoteConf.com.

We have a special guest this week and that's Sarah Mei.

Hi, everybody.

Do you want to introduce yourself? You haven't been on for what, 170 episodes?

Something like that, yeah. [Laughs] I'm Sarah Mei. I'm the Chief Consultant at Devmynd Software which basically means that I've gotten to work with clients on fairly short-term projects mostly having to do with either training or mentoring or helping them with some difficult transition of some kind. And I've been doing a lot of writing about how we hire people, how I probably want to hire people, and how that's been working for us. And so, I've been thinking a lot about that recently, too.

Didn't you give a talk on it at RailsConf or something? Or was that a while ago?

Yeah, it's been a while since I did a talk about it. I've mostly just been writing. All of my talks recently have been about software design. [Laughs]

Oh, gotcha.

Which, is not related to hiring, I guess. But, yeah.

Yeah, we'll just pretend all that stuff is boring. We got to talk about hiring.

[Chuckles] Yeah, who needs software design anyway?

So, what exactly is the problem that you're trying to solve with hiring when you're talking about it? Because it seems like as an experienced person, it's pretty easy for experienced folks to find jobs. In fact, I have lots of people coming to me and saying, “How do I find senior people?” And I guess maybe that's what you're addressing rather than how to find a job. It's how to hire the right person.

Yeah, absolutely. There are a couple of different problems. That's definitely one of them. One of them, especially in San Francisco and I know to a lesser extent other parts of the world, it's very, very difficult to hire someone with more than a couple of years’ experience because there are so many options. Not only are there lots of companies that are local, there are a lot of options for them to work remotely now. So, that's becoming more popular. So, it's very, very difficult to hire people that are experienced.

And the other problem that we're dealing with at the same time, which maybe on the surface doesn't look entirely related, is that we are trying to diversify the teams that we have so that we can build better software, so that we can get more perspectives into the development process. And I think that there are ways we can address both of them at once. But it's not an easy process. These are not easy problems, for sure.

So, let's start with the first problem. So, you've got a limited pool of people who have more than a few years' experience. And you feel like you need somebody who has more than a few years' experience. So, how do you attract those people so that you can actually hire them?

So, there are a couple of things in that question, I think. And one of them is that, do you actually need people with that much experience? And the second part of the question is: do you know who you're trying to attract? One of the things that are interesting to me is that there are… I've talked to a lot of people who are posting jobs on JobFind or on their website or on Craigslist and so on. And they're like, “Well, I never get anyone that applies to my jobs.” And they're posting for mid-level senior people. “I never getting anyone that applies to my jobs except for people that are in the main demographic that we have already.” They get a lot of men. They get a lot of white people.

So, they're like. “Well, what is that? Do these people just not exist? What if I want to hire outside of that demographic or if I want to make sure that I'm reaching those people? Maybe they just don't exist.” And the interesting thing that I found out over the last couple of years is that these people do exist. They just don't apply for jobs. [Chuckles]

And the reason is that it's very difficult to tell just going in for an interview whether it's a place that you can be successful as someone who is in many cases 'first person who's not in the main demographic of the team'. I've worked with a lot of companies that are fairly small, like 10 engineers maybe. Definitely less than 25. And they're trying to get beyond their primary demographic so that they can get more creativity into the development process. But it's really hard to be the first of anything into a team like that. Even into a team of three or four people, it's often hard to be the first.

And people who are mid-level and above really have any choice of any job they want, right? And they're not going to take the chance to be the first one in a company. They're going to go to a company where they're not the first one. And so, the question is how can you…? It's sort of a chicken and egg problem with [inaudible]. How do you make it so they're not the first person in that demographic and at the same time [chuckles] get that demographic into your… yeah, somebody has to be the first, right? And how do you get over that problem?

Sarah, can you talk a little bit about why it's difficult to be the first person of a given demographic in a dev team that maybe is all white males?

Yeah. Definitely, I've had that happen to me a couple of times. And the difficult thing about it is that often you are expected to be somewhat symbolic for everybody that you are “representing' on the team. Meaning that if I'm going into a team that is all male, then any mistakes I make are reflections on how women do software. [Laughs] And whatever I do that's positive is a reflection of what women are good at or how well they do software. And that's a very difficult burden to take on because I'm just an individual. And I want to be individually successful. Especially when I was earlier in my career, I didn't really want to feel responsible for other people's impressions of how women do software. And once… [Inaudible]

I just… can I just in here for a second? Because one thing that I want to point out is that a lot of people are going, “Well, I don't do that.” And I just want to point out everybody does this to some degree. Everybody does it. Men do it. Women do it. People of color do it. White people do it. We all do it. And so, just be aware. When you see this, you're to some degree going to do what Sarah is talking about.

Right. And it's definitely, it's an unconscious bias. There's some very interesting scientific literature on this, mostly from the 70s and 80s about how all of us look at characteristics and we make assumptions about what that person is going to be like. And then we make unconscious generalizations from the maybe one person we know in a particular demographic to how people will behave in general from that demographic. And that's what we do, right? We're patternmatchers, especially as engineers. This is what we do. We take patterns that we see and we project them forward into the future. And when you're talking about code, that's amazing. That's an awesome skill to have. And it's a large part of what makes us successful. When we're dealing with people, it's a lot more important to be aware that that's what we're doing and to understand that that can be useful but it's also sometimes a bit of a trap.

I was at a women's technology meetup once. And there was a young woman of color who was going through a bootcamp. And she was talking about the fact that all of the other women in the program had dropped out over time and that she was now not only the woman but the only person of color, and some of the struggles she was having as a result of that. There was an older woman in the room with us who said, “Oh honey, don't worry about stuff like that. Just do your best.” And the young woman of color was like really taken aback and just stunned into silence by someone saying that to her.

And the woman recognized that and turned to me and was like, “Coraline, come on. Back me up, here.” And I was like, “I cannot back you up because I totally disagree with you.” That is not her experience and that is not the experience of a lot of other women. And there's this attitude I think among older people who have not experienced or not recognized discrimination that it's something that just doesn't happen.

I think also, and I've noticed this in myself as I get older because I'm turning 40 this year, now that I'm successful I don't see it as much. And therefore, if I'm not careful I start thinking it doesn't happen anymore. [Chuckles] And the way that I try and keep myself down to earth is that I talk to a lot of younger women. And this is a large part of the reason why I go out and I do the things like RailsBridge and so on is because I want to make sure that I still understand what the experience is for the younger folks in tech.

Yeah, if you want to hear more about Sarah's experience with RailsBridge, that's actually what we talk to her about. Of course, it was three years ago, but yeah.

Oh, that's right. It's been a while, hasn't it?

Yeah. I think that's a really sneaky bias, too. And I've definitely encountered it. I've encountered it myself and in other people, because just dealing with women in tech I've known women that are well along in their career. And it seemed like they were doing just fine and they may have even said they don't really see these kinds of biases. But the sample bias there is somebody who made it that far.

And it reminds me a little bit, to draw a software metaphor, of I wrote an article recently that become very popular, about what it's like to come back to a Ruby project after six months. And all the little death by a thousand cuts issues in trying to get the darn thing back up and running and the tests passing and all the bit rot that sets in. And it got a huge response, because lots of people had this experience. But it's one of those things that when you're up and running with the project, you don't see it. Or when you're well along and used to these issues, you don't think about these setup issues. But then the people that are just coming in, they run into all these one issue after another, where the darn database doesn't work, or something like that. And it's very easy to, when you're farther along in the industry whether it's technical stuff or social stuff, to not see those entrylevel issues.

Yeah. One other thing that I have seen is that I've wound up talking to a lot of people who listen to the shows. Several of them have been women who are new to programming.

And I think we also fall into the trap a lot where we assume that all of their experiences are the same, or that they all have the same personality. Where in reality some of them, they went out, they self-taught, they just got in, did the work and figured it out, and then found a job. And they found a job that worked out nicely for them. And there are others that have done similar things but really struggled because they couldn't find a company that would hire them either because they were women or because they were new or because of whatever. And I think it's hard to gauge what those reasons are that companies hire one person over another.

But all told, the experience is different. The personalities of the people involved are different. And so, we say, “Oh, well women all face these challenges,” or, “New developers all face these challenges,” or, “Experienced developers have these challenges.” And that may generally be true but it's not always the case in all cases. And so, we tell people to go and try and do specific things.

And we have to recognize that that isn't always the experience that everybody's going to have.

Yeah, absolutely. The way I think about it is that I think about a team in terms of its demographics. But then we hire in terms of individuals. And we need to find folks that challenge the [received] mindset that a team has. And you need to do that deliberately. At the same time, you need to make sure that your team is ready to take on that chaos. Because it often is, getting someone into your team that has a very different set of past experiences from the other folks can be a very, it throws everything into disarray for a little while, right? Because you're reforming your culture. The culture is made up of just the people that are in it. And when you have a fairly small team and you bring in someone so different then the culture shifts. And you need to give it a bit of time to settle down again.

And this is why hiring a lot of people at once is a really challenging thing for any company, but especially for a small team. I talk to people who are like, “Well, I've got 15 people now and I'm supposed to double it by the end of the year because we just got our [inaudible],” or whatever. And it's just like, “Yeah, good luck with that.”

It's really hard to do that and maintain, be able to [inaudible] enough guidance over the culture that you end up with the culture you want at the end of that, because you've got so many variables with all the new people coming in at once.

I take exception to the general use of the word 'culture' to describe a development organization, because in my mind, culture is an expression of shared values. And if the people on your team can't express what those values are… ping-pong and beer after work does not make a culture. A culture is about what you believe in as a group and how you act on those values.

Yeah, I totally agree.

So, if you can't agree on a set of values, do you not have a culture? Or do you just have an unhealthy culture?

I'd say it's unhealthy.

Yeah, I think that having people come in, transmitting cultural values is another interesting problem. How do you articulate? Most teams haven't even really articulated what their cultural values are, let alone come up with a way to transmit them.

I think that transmission of culture goes beyond organizations as well, out into the broader industry. I think we're still trying to figure out what it is we value in software developers in general.

I think that's true. And we're at a very interesting point right now where we've got a lot of folks coming into software for the first time who are not… don't have the same set of backgrounds as a lot of people of who are here. A lot of people that are here already either have a traditional computer science background like I do, or you have what I consider to be the traditional open source background [chuckles] which means that you started programming when you were a teenager or even earlier. And then you self-taught yourself through mailing lists and books and so on, and now find yourself a bastion of the industry, so to speak. And I think that we have a bunch of people coming in that aren't from either of those backgrounds.

And that's very exciting to me, because it means that we are going to be able to build software that is much more interesting than what we have right now. Because the software really is an expression of how you as a group think. And if your software is chaotic, that's expressing that your culture is chaotic, that you don't have a shared culture, really. And if you can turn your culture into one of creativity and exploration, you can make some really, really interesting things.

And I don't think we're seeing a whole lot of that yet because most of the folks coming in, right now the folks from the very first dev bootcamp cohort have four to five years of experience right now, right? Those are the very early folks. And so, I think it'll be really interesting to see what happens in the next say, three or four years, when we start getting a large amount, a large number rather of new level developers who come from these non-traditional, non-open-source traditional backgrounds.

Assuming they make it that long.

Exactly.

Yeah. So, I want to change directions a little bit with this, mainly because I want to talk specifically about what companies can do to attract both more experienced people, since that seems to be the thing that I just keep hearing over and over again, “We want somebody that has a lot of experience.” And then the other thing is, is how do you attract more of those people with more diverse backgrounds?

Yeah, that's interesting. I think that… so, one thing about “I need someone with a lot of experience,” is that at least in San Francisco we get a lot of title inflation.

Yeah.

People say they want a senior developer. What they really want is someone with three to four years of experience who can pick up a story from the backlog and just work on it without a whole lot of guidance. And that's what they mean when they say a senior developer, which I think… so that's an interesting translation that we should think about in terms of what that means for job titles and job descriptions and hiring and things like that. So, there's that.

And then the second problem is that one of the ways to expand the list of people who would be interested in your company who are mid-level is to hire some of these junior folks to bring in some new ideas to the dev team and to make it so that it is a little bit more demographically interesting. And what that means is that you get the mid-level people. The mid-level people who are in those underrepresented groups suddenly look at your team as a possibility because they're not going to be the first person there.

Mmhmm. So, basically bring people in at the lower level and then train them up?

So, that's definitely one aspect of it. That requires a shift in thinking in terms of a lot of different things, right? How you talk about code, bringing in your first junior person is a big transition. We have an opportunity right now to really diversify our teams in a way that we've never had before. And we in the Ruby community especially have that opportunity because so many of these coding schools teach Ruby. We're on the forefront of that movement.

In fact, it's really interesting. At RailsConf a year ago, two years ago maybe, I ran into a guy from a company, a PHP company. And I was like, “Oh, are you thinking about converting some of your stuff to Rails?” He was like, “No.” [Chuckles] I was like, “Okay. You're here. You're interested in Rails as a hobby.” “No, no. Not really interested in Ruby at all.” I was like, “Okay. So, you realize this is RailsConf?” [Laughs] And he's like, “Yeah. So, the reason I'm here is because there's a half day track on working with junior developers,” that we had put together not because we… it wasn't one of the tracks we had announced. But it was something that came out of all of the talks that we received.

We looked through the talks we received and we realized there were a lot of people interested in talking about their experience working with junior developers or being a junior developer and giving advice to people who want to hire junior developers. And so, we formed this ad-hoc half-day. It was three talks, four talks track. And apparently the presence of that in the schedule was enough for him to convince his boss to pay for him to go to RailsConf.

Oh, wow.

Yeah. And this was after the track was over. And he was like, “Yeah. And the first talk that I saw in that track was worth the price of admission.” We're in a very interesting place here in the Ruby community. We are… everyone else is interested in what we're doing and wants to see how they can take advantage of all these folks coming in who are new.

So, how do you approach this, then? How do you approach bringing in junior people to augment your team and grow to that mid-level level?

It's definitely not, it's not a fast process in many cases. I think that there's a lot of great talks and stuff out there about how to do this. You can look at the RailsConf videos. I think they're all up still on Confreaks from that track. And we had it again last year. And the hardest part is figuring out how to say out loud things that you didn't have to say out loud before.

When you've got a team that's all mid to senior level people, there's a certain, especially if they're all demographically similar, there are some efficiencies of communication you're talking advantage of that you may not even realize you're taking advantage of. There's shorthand that you all have in common. There are concepts that you can count on everyone to have. There are things you don't have to explain. And when you bring a junior person in, the main thing that changes is that all that stuff needs to be much more explicit. It needs to be… you need to say out loud things that you didn't realized you needed to say. And you won't realize it initially until they start asking questions about stuff.

And so, in my opinion the most important thing that you can do when you're bringing in a junior person is make it safe for them to ask questions. There are a lot of teams where the culture is such that you gain status by appearing more knowledgeable and that you lose status by appearing less knowledgeable. And in some of those cultures, when you ask a question and demonstrate that there's something that you don't know, that is a loss of status. And this can be very subtle. But it's definitely present in a lot of the team cultures that I've experienced. And in order for a junior developer to be successful, in order for you as a hirer to get the return on your investment that you're going to have to make, you need to make it possible and safe for them to ask questions. And that can be a very difficult thing to do.

Do you think having a culture mentorship plays into that, being for a senior person to be open to teaching a more junior person and open to learning themselves from different perspectives of junior developers?

Yeah. I think that that's really important. I think that an attitude that everyone has something to learn and everyone has something to teach goes a really, really long way. And I look at mentoring, I think a lot of people look at mentoring as a one-way relationship where it's like this person will help me or I will help this person. But the good mentoring relationships that I've been a part of are much more two-way in that the person I'm mentoring and the person who's mentoring me, I feel like I had things to learn from them and they feel like they have things learned from me as well. And a lot of the relationships that in hindsight I realize were mentoring relationships at the time really just felt like friendships.

And I think that people can hear the word 'mentoring' and think teaching, in which one person is in a teaching role, always higher status if you will, and one person is in the learning role which is always lower status. I think that that kind of dynamic can be very poisonous and that you need to be careful about making sure that everyone who's involved can express and expresses openly that they have something to learn, especially the senior people. Modeling this is really important. Not just to tell them, “Okay, yeah. It's totally cool for you to ask questions.” Senior people have to ask questions. And they need to do that in public. And they need to do it a lot. And they need to make it okay for the junior people to ask questions.

So, one other thing that I'm wondering, bringing in junior people. I've noticed that in interviews with senior people, it's kind of a blend between demonstrating what you know and also figuring out if you're a good team fit. With junior folks, depending on their level of experience they may not have a deep knowledge of technology or the technologies that you're using. So, how do you interview them and figure out if they're the one that you want to hire? What do you look for?

I think it depends on how you team culture works in terms of… or rather how your team works. So, if you're a team in which everyone works individually and then you do code review, versus if you're a team that does pair programming for example, most of the teams that I work with do pair programming. And the way that it works for them is to bring them in and pair program with them for a day or half a day. And what they're looking for when we do that is not necessarily “Are they going to be able to point out syntax errors?” I've got an editor for that. And I've got tests. Basically, what we're looking for is “Are they helpful in terms of asking questions at the right places?”

There's a technique in pair programming that I'm sure most of you have heard of called rubber ducking or programming in general, right? Which means that all you have to do in order to get over a problem that you're working on is explain it to something. And it could be a person or it could be a rubber duck sitting on top of your monitor. [Chuckles] And I've worked at places where they hot glue the rubber duck onto the top of every monitor [chuckles] so you could remember to try and explain it. And having a pair who is, for me anyway, having a pair who's junior can be much more productive than working by myself because then I do have a person to talk to about the problems that we're having.

So, basically I'm looking for “Does this person respond thoughtfully to the questions I ask? Do they ask questions that seem like they're interested in what we're doing and that they are paying attention?” Not necessarily “Are they asking questions about…” I'm not looking for them to demonstrate technical knowledge, as you said. They're coming from a place where they don't really have that yet. But I'm really looking for the ability to talk about code and talk about problems that we're having in a way that is helpful.

How important is it to set expectations around that pairing session though? Because I know that for a lot of junior people, they may have little to no experience with pairing, especially with a more senior developer. And pairing itself, if you don't know your pair, can be incredibly stressful.

Yeah, absolutely. I think that it is important to talk about upfront what we're doing and to talk about the fact that… what you're evaluating on. So, that we are, what we're looking for in junior folks is X, Y, and Z. And for oftentimes that is communication skills and interest in what we're working on and not necessarily “Do you understand our spec? Do you understand testing? Do you know what kind of tests to write here?” Because most people who… [Chuckles] there's a lot of people who are senior that can't answer those questions, right?

So, I look for… yeah, I think it is important to set expectations about what you're looking for. I think that doing pair programming interviews is something that you probably shouldn't try if you're not actually doing pair programming for work. I think that you need to be fairly experienced at pairing in order to be able to conduct one of those effectively.

I also love the interviews where they make you code on the whiteboard.

Oh yeah. [Chuckles]

Those are just evil.

I heard a story just yesterday on the new ruby channel on IRC about a young man who's going for an internship. And they actually did a group interview with different people applying for the position and had them all whiteboarding at the same time.

Oh my gosh. That sounds like a nightmare.

Is that like a political debate with markers?

Basically. And he was incredibly intimidated by the process. And seeing other people who are more confident in their whiteboarding skills, and he panicked. And the feedback he got at the end of that session was that he was disengaged.

Yeah, I think that unless your actual process of working involves writing code on the whiteboard, that that's not a super effective way to interview.

You said that a whole lot nicer than I was going to say it.

[Laughs] At how many companies does their process actually involve writing code on the whiteboard normally? Yeah, I talked to one person, gosh, not even that long ago, whose way of hiring junior developers was that they hired only the people who won programming contests in the local university.

Huh.

And I thought, “Hey.” [Chuckles] That's an interesting thing to optimize for. Things like that optimize for some interesting things. They optimize for competence and showmanship and the ability to be comfortable in front of a crowd. And I'm sure there are development jobs that require that. I don't know, maybe consulting or something. This is a product company, so I don't think it was that. But I think that you look at folks that are successful at that type of thing and they tend to be demographically the same probably as the team you already have and not [really] serving your purposes of hiring a more diverse team.

One thing I was interested in getting your opinion on, Sarah, is the existence of whisper networks, especially for women and people of color. We talk. And we share experiences at working in different companies. And that definitely affects… you know, I just went through a job search and it definitely affected the companies that I even talked to. Have you been part of any of those whisper networks? Have you seen their effects in your own life?

Yeah.

Can you explain what you mean by whisper network? I'm not sure if I completely followed that.

Basically in particular women in tech talk to each other about their experiences with different companies. And they talk about it in non-public channels.

Okay.

And that's referred to as a whisper network.

Oh, right. So, you're getting information from your whisper network about the company that you're applying to. And then you can make a determination as to whether or not it's a friendly place to be.

Exactly.

Okay. Sorry, Sarah. I didn't mean to interrupt you. Go ahead.

Yeah, no worries. I think it's good to clarify. No, whisper networks have been around forever, mostly informally. So, [inaudible] I would meet someone, another woman at a conference, we would talk about things, or I would talk about things on various mailing lists, and so on. I think that it is important to have these spaces that are safe for us to talk about these types of things, which is why I think that promotion of spaces that are designed for women technologists or people of color or both to talk about their experiences is important. I've certainly taken into account people's experiences with various companies, particularly people that I know. But sometimes people just that I've heard about or things that I've heard about on Twitter. And I think everyone else does, too. And not to say that companies can't come back from a bad experience. But it is something to be aware of, that a company's reputation is often built on how well they treat people that may or may not be senior, right? Especially folks coming in that are junior.

And companies are making a lot of mistakes, to be honest. And a lot of it is inexperience dealing with junior folks or the fact that they didn't research or do homework ahead of time. And I think that people, a lot of times, want to hire junior folks because they're available. And this is definitely something that I've been talking about a lot in my writing. At the same time, you need to make sure that you are ready to be able to make them successful. And a lot of it is very subtle.

Like in Devmynd I've been working with people to talk about the differences in the people, in the ways that people communicate or are comfortable communicating. Some people are very comfortable when they have a piece of feedback that they want to give someone, they're very comfortable just walking up and talking to them and telling them that feedback. And other people are not as comfortable with that. I've never been comfortable with that as a feedback mechanism. And that's made a lot of things very difficult where it's like, I would get performance reviews. It would say “We need you to speak up more.” And I would think to myself, “Well, [laughs] I can try that.”

I think that when you're thinking about hiring junior people, a lot of things have to change. And one of the things that needs to change is this fact of… we have this idea of how we want our developers to behave a lot of times. And a lot of times you look at these job descriptions and it's coded right in there. And you'll get this feedback where it's like “We want you to talk more. We want you to do this more. We want you to do that more.” And a lot of times, I realized as I got older, that what that feedback actually meant was “We're not willing to accommodate your method of communication. We need you to conform to ours.” And that is possible for some people and I certainly survived. So, [chuckles] I got good enough at it that I could fake it, at least.

But I think that a lot of the ways that we evaluate developers are based on our idea of what a developer currently is. And a lot of that needs to be reexamined in light of the expansion of the pool of people that constitute what a developer is.

I definitely had that experience you're talking about with different forms of communication. I think women and men communicate differently even in a professional setting. I was in a situation where I was remote on a team, one of only two women. And everyone else was local. And the communication style that was favored by the group was raising your voice and interrupting other people, which is not something I was comfortable doing at all. And I got feedback that I was not participating enough.

Exactly. Yeah, stuff like that. And it's so baked into, especially in larger companies, it's so baked into how they think about what a developer is that it can be difficult for them to let go of that. A lot of times people tell me, “Well we hired a junior developer but they just didn't fit in very well.” [Laughs] And you're like, “Well, [chuckles] you need to expect that.” And you need to understand hiring a junior developer will help you figure out what about your culture you don't want to move and what about it is movable. Because everything is a little bit different.

This is reminding me of an article that I read recently. It wasn't about software teams in particular. But the article is from Harvard Business Review that's entitled 'Why Do So Many Incompetent Men Become Leaders?' [Chuckles]

And it talks about the fact, let's see. People… there's a finding that leaderless groups have a

natural tendency to elect self-centered, overconfident, and narcissistic individuals as leaders, which it turns out that those qualities actually aren't very good leadership qualities. They don't lead to team success.

Imagine that. [Laughter]

But these are the people that tend to be advanced. And also, and then that tends to be the archetype that people are looking for in leadership. And again, this isn't directly about just software teams. But it fascinated me because one of the conclusions that they come to in this is that some of the advice that you see out there for women in companies to, “Well, just act more like men do,” might actually help them to advance in the companies. But it's not necessarily good for the companies. It's not necessarily good for the teams or good for the overall organizational success. Because this archetype of this is the kind of person that we want, is actually negative. It's not good for the team. And so, just to your point of we have to rethink what sort of people are we, what sort of qualities are we looking for, yeah. We do.

Well, and to me it does feel a little bit like you're telling those women, “We hired you to be someone you're not.” In other words, we didn't hire you because of you. We hired you because we want you to be someone else. And that doesn't make any sense to me.

By the way Sarah, I'm curious. Do you think it's possible to have a healthy performance review process?

I've never seen one. So, here's one of the interesting things about that. I think that we have a very individual-focused culture at large in the programming community. Although in recent years, we've decided that “cowboy coding” is not something that we want a lot of and that we want people that will work together with other folks in the group to advance the group's goals as a whole. And if you look at what companies want, if you look at job descriptions or you look at job postings, a lot of them are like 'team player', so on and so forth. But then they do these performance reviews in which they are evaluating individual performance relative to everybody else on the team.

And you can do that explicitly as in Microsoft-style stack ranking where a manager has to rank their people that report to them in terms of who they would fire first and who they'd fire last. Or it could be implicit in which there is no actual stack ranking but the performance review process serves to write down for the company who are the most valuable people. And the difficult thing about that is that the people that make a team successful, like you were saying Avdi, a lot of the people that make a team successful may not do things that look like they are making the team successful. They may not look like leadership. They may do a lot of things that work to make the team successful behind the scenes that don't look like leadership.

And a lot of those things are difficult to quantify. They're difficult to come up with metrics for. And the performance review process, a lot of it is about finding some metric that you can assign a number to and then making sure that you are meeting that number. And coming up for a metric for the things that are actually important is in my opinion pretty much impossible, with the understanding of culture and dynamics and communication that we have right now. There are lots of ways to help make the team successful. And pretty much none of them involve things like number of lines of code or deadlines met or number of people mentored or whatever number you can come up with.

I think forcing people to come up with numbers, or even just goals, is useful for a company of a large size. Because then they can be like, “Okay, we've got people working on these goals.” But when you're a smaller team, it doesn't really make any sense to me. Because you want people to do whatever is the best thing for the team at that particular moment, whether that goes against what their stated goals are or not. And therefore when you get to the end of a performance review period and you look at these metrics or you look at these goals and you're like “Well, we didn't do that because it turns out that's not what we needed,” you don't want to penalize them at the end of that period for doing the right thing. You don't want to set up a set of incentives that push people to do the wrong thing. And that's what most performance review processes do.

I've also seen situations where the performance review is the only time you get feedback from your boss, which I think is really wrong.

Does anybody here have any positive experiences on either side of the performance review process?

The only positive experience that I've had with any of it was when it felt more like mentorship and less like your job or bonus or whatever is on the line.

Even when I think back to the jobs where I consistently got great performance reviews, I still have this knot in my stomach about the whole process. I hate that. It just fills me with loathing. And these were places where they were saying “You're doing great.” It's just the whole thing is just, it's insulting.

It is. And I think part of it is that they are like “Okay, here's a standard and we are going to give you a performance review that is how well you are meeting this standard.” And that is a very industrial way of thinking about a team. Because what would be more useful I think for everyone involved is if it were possible to say things like “Okay, we've hired you. You're here. How can we make you successful? Tell me how we can make you successful?” Because if someone's not successful, honestly it's almost always not the individual's fault. There are always things that the team could do to make that person successful. And if a performance review process were less about “Here's how you're measuring up to our standards” and more about “How can we help you be successful and what do you want to be doing?” maybe it could be a little bit less horrifying. [Laughs]

And it's… the focus on the past is so antithetical to “How do you get people to change or improve

in as much as people can?” I think about it form a parenting perspective. Like, I if I took my son and I sat him down and said, “Look, we need to talk about how you left the toilet seat up six months ago.” [Chuckles]

Yeah, yeah. Like [inaudible] that.

Man, those toilet seat reviews. That's serious stuff.

[Laughs] It doesn't accomplish much to talk to my kids about something they did yesterday, let alone “Let's save up a bunch of crap over a course of months.”

Yeah, but…

And then complain about it.

But that said, I have worked with and managed people that no matter what I did, no matter how quickly I followed up, no matter how much I praised them for the good things or talked to them about the things they did poorly, they just weren't going to do the job. I think sometimes you have to let people go. But I don't know that they yearly performance review or whatever is the right avenue for that. And I want to be clear we're not advocating that you can't let people go if they're not going to work. But I think the mechanism of, every so often you go in and you tell people how they're doing in their job isn't helpful. It's the feedback in the moment that really makes a difference.

Yeah. And I think that people are… this is one of the things that I realized quite a while ago, which is that people are successful to the degree that the culture of the team they're on supports the way that they like to work. And what I mean by that more specifically is that if you're on a team where the way that they like to work is different from yours and they're not willing to shift that, then you're not going to be seen as a good developer. I had several jobs in the past where my reviews were quite negative and that I was not participating enough. I was not… I didn't fit in enough with their culture, even though it's not like I'm any better at programming now than I was then. But I just found companies where that culture was better aligned. And suddenly I was a great developer.

And I had been ready to give up on the whole industry. I was just like “Well clearly, I'm just not very good at programming because I have all these jobs, I've had all these jobs, and none of them really seemed to think what I did was useful.” And then by accident I found one where that wasn't the case and I was like, “Oh, this is what it's supposed to feel like. Okay, cool. I like this.” And so, I think that we're just… and those companies weren't trying to make me unsuccessful. They just weren't really aware of, and I wasn't either when I was younger, they weren't really aware of those differences in culture and how they were affecting the way that I worked. And someone that is a great fit for one team will be a horrible fit on another team. There are still teams where I guarantee you, I would go in and I would not be a good addition to their team because I just wouldn't fit into the way that they like to work. And thankfully these days, I'm much more aware of those and can head them off before I [chuckles] get anywhere near them.

And I think that a lot of times the performance review process is couched in terms of “How good are you at this?” rather than “How good a fit are you with what we're doing?” And I think that when you referenced someone that just isn't going to do the work, to me what that sounds like is someone for whom this culture is not a great fit. And we just need to have a frank conversation about that and I'll help them get another job where they are a better fit. So, I'm not saying that you don't let people go or you don't help them find something else to do. But I think that on the other hand you do need to be aware that sometimes someone who looks like they are an 'underperformer', there are things that you could change that would turn that around.

That's fair.

And a lot of that is up to the manager, is up to the culture of the team as a whole.

I don't want to belabor the point, but you just casually mentioned something that I've almost never heard anybody talk about, which is you said “I will help you find a better fit.” Beyond supplying references, nobody ever talks about that.

I think it's really important, because my experiences when I was younger have led me to the belief that there aren't really very many people that are bad at this. There are just people that are not in a good… for whom my team is not a good fit. And I think that, I guess maybe I take a bit of a, maybe slightly [chuckles] un-American viewpoint which is that when I hire somebody, I'm doing it because I'm making an investment in them as a person, not just as a resource, or a developer, or a

mechanical mover of stories from one column to the other. That if it turns out that it's not going to work out, then I am perfectly happy to help them find something better. And that's one of the reasons that having a good network is important.

Yeah. I think that's definitely the case with pretty much any person you hire, is you have to make an investment in them. I don't think you get around that. That said, I think sometimes people opt for an opinion where it's “Well, they should hire them and take a chance on them, even if this or that.” And I think depending on how stable the company is and how profitable it is, they can take more of a risk on somebody than other companies.

I think that that's true. I also think that companies that are less stable, perhaps that are early stage, are the ones where they can least afford group-think, if that makes sense.

That's true.

And this is part of the reason why it is quite difficult to get a startup off the ground. And you see so many of them fail. And a lot of it has to do with the fact that they weren't able to retain the people they needed to build what they wanted to build. And it's a very San Francisco centric viewpoint, I'm aware. And I know that in smaller companies that are running on tighter budgets for sure, it's difficult to take that risk. And I guess the question is: how strongly do you feel about the fact that you need that creativity? Do you need creativity in your team? Do you need… are you planning this for the long term? If you're planning it for the long term, then if you don't diversify fairly early, then you're locking yourself into a big problem later on. And so, I guess it depends on where the company is and what they're doing, and how much you think you need that type of thing.

Yeah. Are there any areas of hiring or interviewing that you think are important that we haven't talked about yet, Sarah?

I think that there's one thing that we've talked about, we've talked around the edges of a little bit. But I think it would be useful to talk about it explicitly. And that is different communication styles of different types of people. When you are working with a team of folks that come from a diverse set of backgrounds, a lot of what we value in software developers is the ability to articulate what you want, to ask for what you want. For example, see also [chuckles] the last 20 years of articles about how to negotiate your salary as a woman. Here's what you should do to ask for more money. Here's what you should do to do this and that and the other thing, and to make sure that you get promoted.

And one thing that I've realized recently is that that is an interesting manifestation of two completely different types of communication cultures. And there's a great article about it and there's been a bunch of articles since. And it's 'Ask versus Guess Culture'. And for folks who are from an Ask Culture background, what that means is that it's okay to ask for anything, because they can always say no, right? And what that means is I've got friends who are like “Hey, I'm going to be in San Francisco. Can I stay with you for a week?” And they're like, even though I don't know them very well, they feel okay asking it because I could just say no, right?

On the other hand, if you come from a Guess Culture, then the way that you're oriented towards thinking is that you want to not ask for something unless you are pretty sure that the answer will be yes. Because having to tell someone no is very awkward. And so, you lay out the groundwork and you lay hints and basically the people around you are supposed to understand what you want and then essentially offer it to you. And the entire business culture that we have in the United States is oriented around people who come from Ask Cultures. And a lot of times those happen to be white people, and then in particular who come from those cultures. And it definitely, it makes it much harder for people who are from Guess Cultures. Because basically all of the advice is “Be and asker”. [Chuckles]

Do the asking thing. And if that's not how you think about communication, it can be very difficult. And when you're a manager, especially, I think that it's important to understand that to take a look at the folks that you're managing and see, “Okay, is this person an asker or a guesser” and to be able to articulate that to them and to talk about if they're not… so for example, if you're not around them enough to be able to pick up the guessing cues, one of the things that you could talk about is be able to be explicit about that, like to say “Those are the people for whom you can't wait for them to ask you for something, for example.”

And this is why you see this thing where men will march into their boss's office and be like “I want to get a promotion. How do I do it?” right? And women will never do that. They'll figure out what they need to do and they'll do it and they'll wait for their boss to notice that they've done all the things. And as a manager, you need to be aware of those tendencies, even if what you would really like is for everyone to be an asker, because it certainly makes your job easier as a manager. I think you need to acknowledge that that's just not going to happen. [Chuckles] And then if you want support a diverse team you need to be able to manage both of those types of people effectively and be able to make sure that they're both being rewarded, even though one is asking for things way more than the other.

Makes sense to me.

And it's probably also worth recognizing that any desire to normalize one particular culture like Asking Culture as the correct culture or the logical culture is just totally biased.

Well, it's easy to assume that people think about things the same way you do. And we all know that that's not always the case. But it's a real easy leap to make. And I think we all make it to some degree whether we realize it or not.

Yeah. And before I realized this difference between Ask and Guess, this caused me a lot of frustration in my life. Because people would ask me for things and I would feel very, very awkward saying no. And once I figured out that “Oh, they're just asking because they think saying no is no big deal,” then it was actually easier because I realized that they didn't have the same weird tropes around saying no that I had in my brain.

And similarly, if when I'm dealing with someone where I feel like they don't realize that I'm not an asker and that I need to tell them something, it actually makes it easier for me to articulate what I want and to ask for it if I think “Okay. It's just that this person is an asker and so they are expecting, without even really thinking about it, that if I need something I will tell them,” [chuckles] rather than asking me, “Do you need X? Do you need Y? Do you want this? Do you want that?” which is what I

would like them to do. It makes it easier for me to be like “Okay, fine. I'll just play by their rules this time and I'll ask them something and then maybe we can have a conversation about that difference.” [Chuckles]

So, it sounds like in the case where you have a manager that manages both askers and guessers, the onus is on both the manager and the employee to figure out how to communicate with each other.

I think that that's true. I think that the manager is the person on who…

Well, that's his job, yeah.

Right. That is their job, right? Their job is to figure out how to manage effectively all the people that they have. And I think when people say 'managing up' this is sort of what I think. This is one of those “Okay, I am going to look at this person who's my manager who probably used to be an engineer and may or may not know anything about managing people. In fact, probably doesn't. And I'm going to understand what their… and basically I am doing part of their job for them by figuring out how are they expecting me to communicate with them?” And that's sadly common, especially in engineering and other technical professions where the people who are the managers are often promoted up from the ranks of the technical employees that they are now managing. And they may or may not know anything about [chuckles] what they should do differently now that their job is no longer to produce code.

It strikes me Sarah that almost everything that we've talked about with you today can be boiled down to people having a lack of empathy. Do you think that we have a problem with empathy in our field?

I think we do. I tend to talk about it in slightly different terms. I think that we've had this fiction for so long that what we do is somehow technical and rational and beyond the reach of all these squishy people problems. [Chuckles] And certainly there are some people that were attracted to this field because of that. Or even if it's just sort of indirectly, if I had been really great at communicating when I was in college, maybe I wouldn't have chosen a major where I spent most of my time programming by myself.

And it's sort of a self-reinforcing thing, right? I program by myself a lot and therefore I spend less time talking to people. And so, I don't develop those muscles of talking to other people and understanding them and trying to see where they're coming from. Whereas my friends that were poli sci majors or something, they spent most of their time talking to other people. That was what they were doing. That was their major and that was what their classes were about. And so, that muscle got strengthened in them and weakened in me.

And I think that we are starting to realize now that software is a team sport. It's not like longdistance running. It's more like soccer or baseball where everyone… really, you can't be successful without putting aside your ego and figuring out how to make the team successful. And I think you're right that we have difficulty as a group. Perhaps as a group we're less proficient at doing that. Because we've thought for so long that software is an individual thing.

But that's not to say that it can't be learned. Just like my friends the poli sci majors got better at it in college while I got worse at it, it's a thing that you can practice and get better at. And the more you talk to people, the more you interact with other folks that are not like you, the better you get at understanding what they're going through. It certainly can help to be deliberate about it, for sure, to understand that these are limitations that I have due to whatever that I've been reinforcing by staying at home and not talking to people except for when I go to the bathroom or something. [Laughter] But I think that for me, what turned the corner for me was getting into a shop that did full-time pair programming, because suddenly I was spending eight hours a day talking [chuckles] which I think I had never before in my life done. [Laughs] Certainly not as a job.

And spend eight hours a day doing anything and you'll get better at it. Some people faster than others, for sure. It took me longer I think than a lot of people. But after doing it even for a couple of months, I could see the difference. I went to an alumni event probably three or four months after I started pair programming full-time for my university. And a lot of times it was an engineering alumni event, and so a lot of times what those things had been in my past experience was like, I would just stand around and they would stand around and we would make awkward conversation once in a while. And if someone had brought their partner, that was way easier because then they could [chuckles] smooth over the conversation a bit. Because generally they had better skills at it.

But what I discovered after a couple of months of pair programming, I went to one of these alumni events and I was the one smoothing over the conversation. Like I had suddenly acquired this magical ability to talk to people and to get them to talk to me and to actually have conversations. And even though what we talked about wasn't code, the skills transferred. And so, that was very interesting to find out. And so, I'm not really sure what the answer is in terms of helping people generate this empathy. But I think that understanding that that deficit exists and understanding also that it's a skill that you can get better at and practice is important.

Yeah.

I think that as a Ruby community we're becoming more aware of things like that. And I think that's why we're seeing more conferences featuring so-called soft talks. And I hate that term. But talks that are about interpersonal relations, talks that are about empathy, talks that are about differences.

Yeah. I think people are starting to realize that your code is a reflection of your team, not a reflection of individuals necessarily. And the quality of your code will actually reflect directly the quality of your communication as a team. So, I think that being able to talk to people is a useful skill regardless. But there are some people for whom being able to talk to people is a useful skill because it will make their code better, sure. I'm willing to [chuckles] acknowledge that in terms of getting them onto that page, for sure.

I also just want to jump in here. Because it sounded like, and this is along the lines of how I feel about things, I don't know that we necessarily have a deficit of empathy. I think sometimes we do. I think it depends on the person and whether or not they see that there's a problem and whether or not they care about it. But in a lot of cases, especially over the last several years, is I've talked to many more developers and really felt that we have problems. I talk to people in the JavaScript community and the iOS community and the freelance community as well, that we do have a problem sometimes retaining people from different backgrounds. That there is empathy there. We see that there's a problem. We see that people come into the field that are unhappy. And we feel that. We feel that pain. But we don't know how to solve it.

And so, I think it is a mix of both some people don't have empathy and they don't care and that that hurts the mission of bringing people in. And then I also think that there are people with empathy that don't know how to solve the problems or they don't recognize or know how to pick out what is making people unhappy or making people feel unwelcome or making people feel like they can't be involved. And so, I think it's both. I think it's both skills and empathy.

Yeah, that's interesting. Certainly some people don't really know what to do about these problems. They feel like they're huge problems and that there is nothing that they can do that will make a big enough impact to move them in one direction or the other. But I think that one of the interesting things that I figured out in my work with RailsBridge is that if you focus on solving whatever small problem is in front of you, that over time that stuff adds up.

Mmhmm, absolutely.

And a lot of times what that means is following these people on Twitter [chuckles] just so that you've got a set of voices in your timeline that maybe you don't quite understand or you don't have the same [inaudible] as and just listening to them. Or going and listening to the talks that they do at conferences and so on, and building that network of folks that are not like you so that you can over time start to understand where they're coming from. It's certainly not a fast process. But if you focus on solving a problem that you see in front of you, it's for me anyway, a lot less frustrating than looking at the huge problem and trying to figure out what steps need to be taken to solve this huge problem.

I agree. It's just that for me, sometimes people have to talk about it in front of me explicitly before I understand what the problem really is.

Yeah. That's what I mean when I say it takes time, for sure. Sometimes, a lot of stuff, when I follow folks that have a different set of experiences from me, for example when I follow people of color, a lot of times what they're saying doesn't ring true with my experience and [chuckles] for obvious reasons, I suppose. But usually what that means for me is that I just need to listen more, that I need to follow more of those people and try and hear what they're saying.

Yup.

And that can be very difficult, because a lot of times I'm like “But, but, but… but that's not…” And really, what I should do is just listen to more of what they're saying and try and figure it out from there.

I definitely agree with the value of tuning into the experiences of people that come from a different background. And I've gotten a lot of value out of that. At the same time, I feel like there's still a dearth of organized information about just how to get better at human relations and at empathy and at understanding people.

I just finally started the audio book of 'How to Win Friends & Influence People' which, one of these books that lots and lots of people have recommended over the years. And in the introduction the author says that he's found all these, according to his research and his polls and stuff, many, many, many people are really, really interested in learning how to do human relations better, how to get along with people better and stuff like that. But he couldn't find a single college course in any course across the US that actually addressed that topic, even though there were all these people saying it's the thing they most wanted to learn. And that was written a long time ago. But I still feel that way. I don't know. If I want to learn C, I know. Or if I want to really learn C, I know to go to Kernighan and Ritchie. If I want to learn Ruby I know to go to the Pickaxe.

It's been enlightening but also very confusing and fragmented just like following new people on Twitter. And I don't know. What is the course to take? What are the core things to read to really start understanding how to understand people better, how to expand my empathy? It's either I don't know any or I get into some realm like the Buddhist teachings on compassion and now there's a hundred books that I could pick from. But it's tough. I wonder. Sarah, do you have any thoughts on starting points for people that really want… a lot of us want to learn in an organized way.

Yeah.

Because that's how us geeks are sometimes.

Yeah [chuckles], absolutely. And I think that's the problem, which is that there are a lot of books out there but a lot of them are written for folks with a lot more experience talking to people already. And it's not until recently that we've realized that talking to people is a skill that we should have as technical people. And so, I think that's why there's not necessarily a whole lot of organized stuff out there. I think Dale Carnegie is an excellent place to start. And I've read that book every couple of years I think for the last [chuckles] maybe decade or so. Because it really has a lot of timeless help in it.

The other thing that I found that is helpful for people is that the way that I used to think about things like “sales” was that your job was basically to lie to people, to come up with ways of saying things that weren't really true so that they would believe you. And so, I looked at a lot of ways of improving communication like that. I was like, “Oh, I don't want to manipulate people. I just want to do my thing.” And what I realized is that a realization that really helped me move forward with that was that I have some things that I want to tell people and there are different ways that I can say it. And different ways that I say it will, different people can hear the different ways that there are to say things.

So, if I just say something and I'm very blunt about it then there's a certain set of people that can hear that. And then there's a certain set of people that won't. And that I need to, when I'm talking to someone, figure out what is the way that I can say this thing such that they can hear it? And that helped me move past this idea of “I'm just manipulating people to get what I want.” [Chuckles] To me, that was a very helpful thing. But I agree. There are not enough resources out there for people that want to learn how to do this in a realistic way.

Alright. Well, I think, I kind of need to get this wrapped up. But it's been a really interesting conversation. If people want to know more about this kind of thing or follow up with you Sarah, what are the best ways to do that?

Well, I think that they can definitely get a hold of me on Twitter. That's probably the best thing. I'm not very good at email. [Chuckles] I think that there are some interesting… but I definitely recommend the Dale Carnegie book. A lot of the talks that I've done in the last couple of years have been around this subject, at least incidentally. I've been thinking about it a lot. [Chuckles] But yeah, so Twitter's probably the best way to get a hold of me.

Alright. Well, let's go ahead and do some picks.

Before we get to the picks, I just want to acknowledge our silver sponsor.

Coraline, do you have some picks for us?

Sure. My first pick is a GitHub project called Troll Repellent. It's a microservice that automatically comments on and closes issues that are opened by bothersome users. And if you have an open source project, you probably know the types of users I'm talking about. Basically any time a blacklisted user opens an issue or a pull request, Troll Repellent will automatically close the issue and comment with a polite but firm message of your choosing. It's built as a Sinatra app designed to run on something like Heroku. All you have to do is configure the server, configure the webhook on GitHub, and everything will just work for you. So, Troll Repellent could be useful for managing your community and managing difficult people in your community.

We talked a lot about empathy on the show today. And I want to point out something that Avdi wrote just this last week, 'An alternative to puts in Ruby'. I'm not going to say a word about it except that you need to go and read it. I think it was based on an experience that we both saw on IRC. And I really appreciated what he wrote. And I think it should get some wide distribution so I'm sharing that today.

Awesome. Avdi, do you have some picks for us?

Yeah. The other day I finally got around to reading the classic paper 'The Early History of Smalltalk' by Alan Kay. I'm not going to get too deep into it. But I'll just say go read it. “But Avdi, I don't care about Smalltalk.” I don't care. Go read it. It's one of those things that well it really doesn't matter if you don't care about the history of Smalltalk. First of all, Smalltalk history is extremely relevant to Ruby. But even if you don't care about Ruby, it's still just a fantastic essay about the history of computing and philosophy and roads less traveled that I kind of wish were more traveled. And also just how a very smart person thinks through interesting problems with the help of his friends. So yeah, 'The Early History of Smalltalk' is one pick.

Apart from that, I feel like I haven't done a plug for a while. So, if you'll forgive me I'm just going to say that if you haven't already, you should check out RubyTapas. It's how I make my living and a lot of people seem to like it. Lately I've been talking about things like various practical strategies for logging. And then on the more conceptual side, I've been talking about things like why having a User model is possibly a bad idea and why that's really problematic from an object-oriented modeling perspective. And that episode got a lot of people making very positive comments. So, if you think that sounds interesting, RubyTapas.com is the place to go. And thank you for [chuckles] letting me plug for a moment.

I'm such a nice person that I'm a model user.

Alright. I've got a couple of picks here. The first one is I'm also going to do a plug for Rails Remote Conf. It's in a couple of weeks. So, if you're into Rails and you don't want to travel for a conference, go check it out.

Another pick that I have, I know I've picked this on the show before, but I just like it. I like getting cool stuff every month from Loot Crate. So, if you go check out LootCrate.com, they do comic book stuff. They do other geek culture stuff, video game stuff, Marvel Superheroes stuff. I've got all kinds of stuff in here that makes my kids jealous, which is kind of funny. My toys are cooler than their toys. But I just think they're awesome. So, I'm going to go ahead and pick Loot Crate.

Sarah, do you have some picks for us?

I do. I have a couple of books that I've been reading recently that are not entirely related to our topic today. One of them is called 'Prints and Visual Communication'. And it's about the way that printmaking evolved towards photography when are and printmaking, the goal of them was to be photo-realistic and to actually depict things. Because that was the only way that you could see something that wasn't right in front of your eyes. And what I think is very interesting about this history is not necessarily that we should be interested in art, but that there's a lot of parallels between some of the groups in that book and what developers are like today.

Like for example, there was a group of folks that did engraving in the early 18th century. And there were different schools of engraving. There were different languages, they called them even, different languages for different kinds of hash marks. This kind of shadow or that kind of hash markings, that kind of shadow, of making a line drawing of something. And these engravers were very highly paid. They had very technical jobs. They were able to travel and take jobs wherever they wanted to. And then suddenly when photography came along, they were suddenly ('suddenly' over the course of 50 years, but suddenly in terms of history I guess) relegated to doing wedding invitations. [Chuckles]

And I think that one of the interesting things to think about is what is out there that could do that to programming? Programming is a very technical thing that we do. And it feels like it's going to be around forever because it's been around forever as far as I can tell. But it's very possible for us to just move on and quickly. And the question is what's going to do that?

And then the other book is called 'Artful Making' which is a book about, it's really a book about how people should manage artists. But it has a lot to do with how, with good ways of managing a development team as a creative process. So, that's my other pick.

Alright. Well, thanks again to our panelists. It was a super interesting discussion. And hopefully this helps some companies figure out how to diversify. And I think we talked a good deal about why they want to as well. So, we'll go ahead and wrap up the show. Thank you all for listening and we'll catch you all next week.