Ruby Midwest - Must Have 10+ Years People Experience


Kansas City, MO, USA
04/05/2013 to 04/06/2013

Solving a technical problem is relatively easy: there tends to be precedence, easily accessible data, black and white results, and a long list of knowledgeable developers to lean on. People problems are stickier; there are far more variables, no tests you can write, no debugger to use. In this talk, I’ll focus on our biggest issues as developers and community members. We’ll examine what’s broken, what works, and some useful people katas.

Special thanks to Confreaks for recording this :)
Transcript: 

[SLIDE: Must have 10+ Years People Experience]

[SLIDE: @ashedryden]

My name is Ashe Dryden. I'm on twitter as @ashedryden. I'm pretty much everywhere online as ashedryden. I'm an indie developer in Madison, WI. I'm also a conference organizer and I talk to a lot of people about things like diversity and empathy and being humans beings because I'm a human being and I think that's pretty cool.

[SLIDE: It's people all the way down]

Out of curiosity, how many people are in here? [raises hand] None? Oh, so we have like, 10% people? Alright, cool, just making sure. 

Technology is made of people. I've been in the tech industry for about 10 or 12 years and I've worked with a lot of different people. I've worked by myself, I've worked on teams, I've worked with other companies on things and the biggest thing that I take away from any of this is that every single person is different. Every single situation is different and it really is people all the way down.

[SLIDE: good great programmer]

One of the things I love about the ruby community - and I want to preface this by saying that I've only been in the ruby community about 2 years, I came from PHP - is how passionate people are about improving. We're really big on things like crafstmanship. We have these community values that we all share and they're really important to us. It's something I've never seen in any other community. 

[SLIDE: Manifesto for Software Craftsmanship (1 of 2)]

I'm sure that most people recognize this. This is the Manifesto for Software Craftsmanship. And we talk a lot about this at a lot of conferences that we go to. But we tend to focus on the technical stuff - 

[SLIDE: Manifesto for Software Craftsmanship (2 of 2)]

- and we miss this part. And this is probably the most important part to me, because I don't work by myself. I don't create software in a vacuum. I work with other people - I work with my clients, I work with their users. So the way that I speak with them and interact with them is really important. I'm surprised that we don't talk about this more.

[SLIDE: Dream job? Maybe not so much.]

Show of hands [raises hand]: how many people have worked at a job they didn't like? Oh, so there are more people that have worked a job they didn't like than there are people, cool. Sweet. 

We spend a lot of time at work. The vast majority of us spend about 40 hours a week; I hope that no one is spending longer than that at work. And then we go home and we work on open source or other community projects. We're kind of always dealing with a type of "work". 

[SLIDE: Nope/Do not want]

I have wanted to change this for a long time. I really don't like working as much as I do, I really believe in having a work/life balance. And part of not wanting to work as much is that we're really not good at working with each other. 

We're not good at communicating with each other. We're not good at dealing with problems. We have a relatively easy time dealing with software problems. We can test things, write tests for things, send it off to a QA department to have them deal with it while we do something else. But when it comes to interpersonal problems, it's a lot harder. 

[SLIDE: Solve the actual problem.]

We are really bad at solving actual problems. I think a lot of people have heard the term PEBKAC - problem exists between keyboard and computer. We've probably had a lot of users say something like "it doesn't work for me", and then you find out they're clicking on the wrong button or they're looking at the wrong website (I've had this happen before!). We aren't getting to the actual problem of things. 

I've worked for a lot of companies where when people problems were brought to them, "Oh, I have a problem with this person" or "I can't work on this team; there's too much pressure, there's always so much anxiety", and ask "how can we fix this?", we try to apply software solutions to the people problems. I can't tell you how many times I've worked at a place where we say "this project is so far behind, we should just start over, redo the estimate, work with the client and figure out where we can go or how we can make this go better", and they say "well we should probably pick a different project management tool" instead of "we are really bad at managing projects."

That's not a discussion that we have a lot. I'm kind of interested in why that's so.

[SLIDE: What are the problems?]

About 4 years ago I quit my job - my capital J-O-B job - and I work for myself now. Which is the best job I've ever had because I am an awesome boss. I give myself a lot of leeway in things and lots of treats. 

I started making a list of the kinds of problems I kept seeing at the places I was working because I wanted to make sure that I wasn't going to do that with my clients. I wanted to be sure I wasn't going in to one of my client's teams to lead and bringing these problems with me. And maybe that I could even help solve these problems. 

[SLIDE: Wait a minute, what if I'm part of the problem?]

I started making a list and realized that I wasn't immune to the problems. There are a lot of things that I contributed to that I could see "oh crap, I was part of the reason that project went off the rails."

[SLIDE: Well, this is awkward.]

That's really awkward. I have a really hard time - and I think most people do - admitting that I am the problem and trying to solve the problem within myself. It's a lot easier to say "the project manager told the client that we would get this out too soon, we didn't have actual requirements...". We've all heard these excuses before, so I don't have to go into a long list. It's hard to internalize these things and say "well, oh crap, I am the problem."

[SLIDE: List of problem areas]

I made a list of about 8 problem areas. Of things that were the actual problem along with things we could start using to actually fix the problem.

In the ruby community, we do a lot of things to help us practice getting better at being programmers. We do pairing so we can actually get someone else's perspective on something and change the way we solve problems and think outside the box. We go to code retreats. Then we also do something called "katas", which are very small problems we repeat to learn more.

Let's go through the list.

[SLIDE: 1. learn]

The first one is learning. As programmers we know that there is always room to learn more. Things are evolving all the time, nothing stands still. There are new ways of doint things even if the software isn't actually changing itself.

[SLIDE: Empty your cup]

There's an excellent book called Apprenticeship Patterns, which I highly recommend. One of the sections in the book talks about how we learn and how we take in learning. One of the stories is emptying your cup.

It's about this master that is teaching a student philosophy. Every time he brings up something new that he feels the student could benefit from learning, the student says "oh waitwaitwaitwaitwait. I already know that. I've used it on 5 other things. I totally get that and you can just skip to the next thing.

Keeps happening, keeps happening, keeps happening. 

Later in the day the master prepares a tea ceremony and gives the student a cup. He starts filling the cup. It gets halfway full. Three quarters of the way full. Gets all the way full. Starts overflowing and he just keeps pouring. 

The student says "what are you doing?! Can't you see you're spilling all over the place?!" The master just stops and puts the tea pot down and says "how can you expect to learn more things if you don't empty your cup? How can you take anything more into you if you aren't changing yourself to be a vessel for learning more?".

[SLIDE: Beginner's mind]

Having a beginner's mind is something that I learned is very important from Apprenticeship Patterns. The book walks you through and teaches you how to be a beginner. It's funny to think that we need to learn to be beginners but a lot of us have been doing this for a long time and we forget what it's like to be the newb in the community. We forget what it's like to be someone that doesn't know something. 

Unfortunately in our community we have a lot of problems around dealing with beginners. We assume that people don't know enough. We might judge a person based on how new they are to the community. The ruby community may be better at this, but all of tech in general has a very big problem with it. 

[SLIDE: Kata: learn]

This presentation is divided into lessons learned and things we can do to practice these lessons. I want everyone to be able to take something away from this and apply it to the way you're acting to each other, to your coworkers, and to people online.

We need to be able to consider other people's point of view. I've had a lot of problems with coworkers I've worked with where I'll start talking about something and they consider themselves the resident expert so automatically start denying the things I say. Even if I may bring a fresh perspective. And I know that I've been guilty of this myself. "I already know that, I've read all of the docs on it, I get it, I know the person who wrote it so I can just ask them the question."

But we don't always have the answer. The answer isn't even always readily apparent and in talking to someone it can grow from there. Assuming that we know doesn't help anything. 

[SLIDE: Why? game]

This is probably my favorite game to play with new people; I play this a lot at conferences. Walk up to someone you don't know today and ask them a question. Ask them where they're from, where they work, what they're most passionate about, what their favorite talk was. Don't stop asking them questions. Keep asking. Don't offer anything about yourself until they stop and ask you a question. You'll be surprised how often we're so quick to try and push information that we know or about ourselves onto someone else before they're interested in that information.

[SLIDE: 1. ask questions. 2. don't offer info unless asked.]

The first rule is ask questions. Keep asking questions. The second is don't offer anything unless asked.

This works really well with people that are new. So if you're bringing someone new onto your team, this is a great way to find out what they know, where they want to learn or grow. We don't know all of this stuff without finding out. 

[SLIDE: 2. empathy]

The second section: empathy. This is one of my favorite topics. 

Empathy is emotional understanding. I can put myself in your place, I've been there before; I totally get it. 

I have a woman that I mentor in Madison, just starting to learn Ruby and Rails. She's wanted to go to conferences for a long time, she hasn't been able to afford it. We've been helping her with books and that kind of thing. We have a conference in Madison called Madison Ruby and another friend of mine just bought an extra ticket to the conference and gave it to her. No expectation, he just understood. "I've been a beginner, I haven't always been able to afford going to conferences, especially as someone who my job isn't paying for it or there isn't any obvious financial benefit coming out the other end. I've been there, I get it."

[SLIDE: know that feel, bro]

Everyone has been a position where someone has dismissed your idea and it makes you feel like crap. "I put a lot of time and effort into this and you didn't even give it the time of day." Someone decided not to merge your pull request. "Man, I really wanted that to be my first commit on this project. I really wanted to get a commit it, but now I just got dismissed and they don't understand how much work went into that."

[SLIDE: we can't know all the things]

We can't know all the things. Take the time to ask genuine questions. get the context from people.

[SLIDE: Kata: empathy]

[SLIDE: Hacker School Rules]

Hacker School is this program in NYC that this past year Etsy sponsored. One of the things that they tried to do with this session was they tried to get more women involved and I want to say they had about 40% women attendees. 

[SLIDE: internalize this stuff]

On the wall at Hacker School is a list of rules. Very simple rules, they seem super obvious. I have spent the past year trying to internalize them. I fail all the time, but I'm trying really hard. 

[SLIDE: 1. no saying "well actually..."]

The first one is no saying "well actually". I call this well actually disease. "Well aaaactually, that's not the way that it works." It's like Comic Book Guy from the Simpsons who is so quick to jump all over everything that you're trying to say to tell you it's wrong or not technically correct.

[SLIDE: 2. no feigning surprise]

The second one is no feigning surprise. "I can't believe you don't know that! You don't know who that person is?!"

[SLIDE: 3. no backseat driving]

Three. No back seat driving. "You really should've done this another way. You should probably just start over. I dunno why you didn't ask me in the first place."

[SLIDE: 4. no sexism, racism, or discrimination]

No sexism, racism, or subtle discrimination. We all know what the obvious stuff is. It's pretty obvious when you say things like "girls aren't good at programming". It's not so obvious when you walk up to someone and assume that they're someone that isn't "just a booth babe" or sitting at a table and is "just in marketing". Try to respect people.

[SLIDE: 3. listen]

The next session is listening. How many people have been in a conversation they couldn't get a word into? Makes you feel really weird and left out. Especially if you're in a group where you don't really know the people. Everyone is talking and you're just sitting there uncomfortably. You start trying to say something and everyone else is really quick to jump in.

[SLIDE: this slide intentionally left blank]

Listening is really hard. We don't do this enough with other people. We are thinking about what we are going to say next, because that's really important. We'll start talking automatically over someone else while they're trying to share something because we're so excited and they have to know this thing right this now.

And as programmers we tend to be really articulate people. We spend a lot of time online writing long emails or long blog posts on things or speaking at conferences about things we're really passionate about. We're used to people listening to us a lot. That makes us really great at speaking. Maybe not the most eloquent, but we are pretty articulate.

Most people in this room have probably spent their lives as geeks. We're used to being the ones with the answers. We're used to being the smart kid. We're used to being the ones that people come to for our opinions because we're smart; we know what we're talking about.

[SLIDE: ain't even bovvered, tho]

We have to remember that when we're trying to talk to people and when we're trying to get them to listen that sometimes we aren't the best at that stuff.

Sometimes people do get excited and they can't hold it in.

Sometimes people are really bad at social queues.

Some people are very afraid of change or not being in control. I see this a lot with people that have titles that correlate to them being in a higher echelon than everyone else. "I'm used to people listening to me all the time, because I'm the authority figure on this."

[SLIDE: kata: listen]

[SLIDE: watch for interruptions]

Today, after this talk, go out and join a conversation. Just watch for interruptions; count them on your hand. You'd be surprised how often this happens. Sometimes I sit at a table and I'll be interrupted twice and I'll just stop talking. Just because it's not worth it to me to try and fight to stay in the conversation. So how many people are you excluding by not giving them the space to speak?

[SLIDE: 4. respect]

What makes you feel respected? What makes you feel valued as a person for the things you do or what you contribute? It might be easier to define as what makes you feel disrespected? What happens when someone says something that is just enough of a cut at the person you are or the work you do that you end up feeling bad about yourself? Think about a time that you've been complimented on an idea you had or if someone came up and thanked you for a project you worked on. It makes you feel really good, like you're providing value. "This is a place I belong because people see what I'm doing and appreciate it.

[SLIDE: value the time of others]

This is a tough one; I've seen it a lot. I've seen this in the issue queues, in a library that we maybe use frequently. "Oops, a regression was introduced. We've been working for hours on this, but we're totally getting flamed in the issues. People have no idea that we were up until 3am working on this stuff, ignoring our families, we didn't go to social functions because this is important enough to us, we want it to work on it and get it out so everyone can use it."

Consider the time and effort that goes into doing those things. What else could that person have been doing if they weren't sitting and fixing issues that you're able to provide value to your clients based on. Stop making snarky comments in the issues queues.

[SLIDE: come prepared]

Do your research before attending meetings. I'm lucky that I have clients that send me agendas before going into a meeting. I would rather not have to say "I don't know, but I'll get back to you later." I want to provide as much value while we are in the same room as possible. 

Take notes if you need them. Ask questions if you need it.

[SLIDE: If you aren't getting or giving value where you are, go somewhere you can.]

One of the first thing I did in the tech community was attending BarCamp. If you're not familiar, it's an unconference where everyone that attends is also someone that contributes back. Anyone can teach something, provide value to the community. The major tenent of BarCamp is the Law of Two Feet, which says "If you aren't getting or giving value where you are, go somewhere you can." The people that show up are the right people.

[SLIDE: :( that's not cool.]

If you feel disrespected, speak up. Selflessness isn't respect. You're not respecting yourself if you're in a situation where someone says something that is disrespectful. Try to find a way to make sure that's not going to happen again. 

This is the method I use. Sadface, that's not cool. For the vast majority of issues in our community, something subtle like this works to call people out. 

[SLIDE: kata: respect]

[SLIDE: offer to help without expectation]

Offer to help someone without expectation. Go out of my way to ask what I can do to help someone. Can I write docs for you? Write tests for you? What can I do to make things easier on you, because I appreciate what you're doing and I want to help you do it. 

[SLIDE: 5. exception handling]

[SLIDE: my code is totes perfect.]

My code is totes perfect. I never make any mistakes. We don't have anything in our tool belts that allows us to check for problems. We don't have to worry about things failing without bigger things blowing up.

We treat people just like that. I expect you to act in a certain way all the time. The vast majority of people in any room are actually humans. We all make mistakes; I certainly make mistakes all the time. People calling me out on it and I expect them to. I consider myself a little more versed in these issues than the average person and I still screw up all the time.

[SLIDE: assume best intentions (yes, this is hard.)]

Assume best intentions. Not everyone always means something the way they say it. It's really hard. I've gotten a lot of subtle digs from people where I ask them "did you mean to say that to me?" or "can you rephrase what you just said?".

It's easy when you're behind a computer and you have the extra time to think about what you're saying, but when you're sitting next to your coworker and say something it's completely different. If your coworker maybe says something that makes you really upset, remember that they haven't had the extra 30 seconds they would have online to think about what they were going to say. They don't have the correction plus * to be able to send next. 

[SLIDE: graceful degradation]

Let people fail gracefully. Don't burn the whole house down if something goes wrong. Every day interactions are hard and dealing with new people is hard.

We have to figure out how to help people through these sticky situations and to get their sea legs. We have to help people learn and grow without being turned off to the entire process. 

[SLIDE: bug: will not fix]

Some things can't be fixed. That's really hard. I've had coworkers I knew I couldn't continue to work with. I knew that this wasn't a positive situation that I wanted to continue to put myself in, the powers to be wouldn't do anything about it. So sometimes you have to learn to walk away.

It's hard if it's a friend of yours or someone you really respect, but your sanity is more important than that.

[SLIDE: kata: exception handling]

[SLIDE: Apologizing: a recipe]

A recipe for apologizing. It's super super easy. It's like making ice, if you've seen the "how to make ice" recipe.

[SLIDE: 1. Acknowledge.]

Acknowledge the problem. "What I just said was not okay."

[SLIDE: 2. "I'm sorry."]

I'm sorry. Literally, that is all you need to say. Don't add a caveat in there. If you say "but", start over. That's not an apology.

[SLIDE: 3. Make amends by learning.]

Try your best to not do that again. You're gonna screw up, I do it all the time. The way you can respect the person you offended - or even if they don't realize that you said something offensive - make yourself better for the next person you have an interaction with.

[SLIDE: 6. appreciate]

This is the audience participation section. 

[SLIDE: who's made a difference to you?]

Think of someone who's made a difference to you. You're gonna need it in a second.

[SLIDE: free as in high five]

Telling someone thank you is super free. It doesn't cost you anything. I have unlimited thank you's in my magic bag of holding.

It makes me feel good when I say thank you to someone and I see them smile; it makes them feel good. "I feel like I'm appreciated, I feel like I'm doing something of value." Everybody wins!

[SLIDE: kata: appreciate]

Alright, ready?

[SLIDE: open up twitter. Yes, right now.]

Grab your phone. That person you were thinking of earlier?

[SLIDE: tell them "thank you". #rubythanks]

Tweet them: "Thank you [person] for doing [thing]."

Don't let that stop with today. Go out of your way to say thank you to people. I can't tell you how many times I've heard someone say "I really enjoyed pairing with her, I really enjoy the way she solves problems or the way he thinks about things." And I ask them if they told them that and invariably they say "I didn't think about that." It makes *me* feel better about that person that you told me, but that person would love to hear that.

Everybody tweet?

Oh, I forgot to send mine. I hope I'm the only person that tweets from the stage today.

So how did that make you feel? Does it make you feel good to know that someone on the other end of that is going to see that and smile and that their friends are going to see that and smile? THat they might work an extra 10mins on something that they're providing to the community for free or that they might stay an extra 10mins after work to help you with something because they know you actually appreciate it?

[SLIDE: 7. model behavior]

Modeling behavior. We've learned a lot and we've come up with things that we're going to start applying today, I hope.

[SLIDE: Meets minimum standards for human being]

It's not enough to do the minimum anymore. We know better now, right? We're going to go out of our way to start changing this. To start making people feel welcome in the community and that they feel valued and respected.

[SLIDE: change is really hard]

Change is really hard. It takes a lot of time and practice. It starts with us, though. Have you ever worked with someone that inspired you just in the way they treated other people or wrote code or wrote commit messages even? It changes the way you do things.

I work out of an office in Madison called Bendyworks and there's someone there named Joe. Over the past year he's worked on something called 1up, which is a program that he started to spend a year becoming a world class developer. Every two weeks he would change what he was studying. He'd pair with someone, write blog posts, release open source projects. Bendyworks has growth days on Fridays, so every Thursdays he goes around with a white board. It has listed all the open source projects that Bendyworks cares about. It's got a big matrix on it and he asks people to initial what they want to work on to give people the momentum to move forward. Now you have something you know you'll be doing something, something you know you'll be contributing to. We can help pair you up with someone who is also passionate about that.

Joe is really inspiring to me. I really appreciate that he is doing his best to not only make himself better, but to help the people around him be better.

[SLIDE: be the change you want to see in the world.]

I'm sure most people have seen this. This is a kind of clichéd platitude, but it works here. Bear with me here.

[SLIDE: be the person you want to work with.]

Be the person you want to work with. I want someone who is nice, not just nice, but helps me get better. Someone who goes out of their way to help me, is respectful. Someone who represents our community or our company in the best way possible.

[SLIDE: be the person you want in the issues]

Be the person you want in the issues. Would you want someone doing poop icons for 20 characters across a comment in your issues? Probably not.

[SLIDE: 8. class You < AwesomeFactory]

Last section. So now that we have all these tools, it's time to go out and make things better.

About 3 months ago I started mentoring a woman named Sara learning Ruby and she's never programmed before. I thought that was really cool; I can't think of a time before I was programming. It's cool that she is starting to get into it, she's got a bunch of programmer friends.

About a month into her learning Ruby, she sent this out.

[SLIDE: (tweet) "HOLY FUCK I JUST WROTE A PROGRAM IN RUBY!!!!! ALL BY MYSELF!!!! AND IT WORKS!!! #RUBYNUBY #RUBY"]

That tweet made me feel awesome. It made me overjoyed. Right now

[SLIDE: sorry, think I got something in my feels]

it makes me feel super super awesome. But not only that, the response that she got from the ruby community - people she doesn't know - was amazing. She got tons of retweets and favorites, people were responding to her and saying "welcome to the community", "we want you here, you belong here". Think about what that does to someone who hasn't met anyone here. Who's not been to a conference before. It's a huge deal!

[SLIDE: kata: awesome factory]

So what I want you to do is go out and do something. Mentor someone, go to a conference and help out with a RailsBridge or a RailsGirls. There are a lot of easy ways that you can participate in the community; just ask! I'm sure that if you posted on twitter saying "How can I help people in my city do this?", you'd get tons of responses.

Be an ambassador for the community and for your employer. You're representing us and them when you go out into the community. I want people to say "people in the ruby community are nice, they're awesome and welcoming".

I actually started a little rivalry with the Python community about how can be more inclusive. Who can make people feel more welcome and help change the ratio of diversity in our communities. We go out of our way to make things better and we make each other better in the process. 

So we picked up some tools today. 

[SLIDE: empty your cup.]

Emptying your cup. Being ready to learn new things.

[SLIDE: hacker school rules]

The Hacker School rules. Remember there are four of them.

[SLIDE: watch for interruptions]

Watching for interruptions.

[SLIDE: offer to help]

Offering to help.

[SLIDE: apologize like a pro]

Knowing how to apologize. 3 ingredients, super easy, just like ice cubes.

[SLIDE: say thank you]

Saying thank you. 

[SLIDE: make more awesome]

And making things more awesome

[SLIDE: We need to be <del>jerks</del> <ins>encouraging</ins>]

So we're going to start changing things today, right?

[SLIDE: Be excellent to each other]

And we're going to go out and be excellent to each other. I wanna see the difference in you, and I hope you guys can see the difference in me. It's really important to me that people see me as someone who is respectful and fun to be around and provides value and I'm sure it's important to you.

[SLIDE: thanks!]

So thank you.

Support Diversity in Tech

95% of funding for my over 1500hrs community work per year - including this and other free online resources, AlterConf, and Fund Club - comes from donations.

Donate Now