Hello, everybody. My name is Diane, as you just said, and my talk today is about pair

programming as a mechanism for growth. And honestly, this is my first time giving a talk at a tech conference, so I kind of feel like this is my audience right now. Before we get to the talk, though, let me tell you a bit about me. Professionally, I'm a career changer from the finance world, and the highlight of that career,

I kid you not, was working with enormous Excel spreadsheets to track principal and interest payments on collateralized loan obligations. So another profession that usually induced this response if I tried to talk to people about it. But thankfully, I realized that the reason I enjoyed that job was because a

few of my teammates and I were working on automating things, and that involved some basic programming and this realization to help me make the jump over to software development. I've been a developer for the past year and a half at a small company called Allovue, and we make financial management software for K to 12 school districts to help them budget, manage, and evaluate their

finances to better serve the needs of their students, which is something I can feel proud about, so I like my job. And the front end of our app is built in Ember, the back end is in Rails, and we are hiring, so here's a link to our

website. Okay. So in my personal life, I have two adorable dogs, the ones on the right. My favorite hobby is a partner dance called Lindy Hop. I love to travel and always jump at the chance to interact with animals, and honestly, I'm a bit ridiculous because look how excited I look to be celebrating my

30th birthday, a.k.a. my double quinceanera. Anyway, let's get to the content of the talk. So I said I'd be talking to you about pair programming, but I just want to clarify what I mean by that. Really, it's just two people working together on some programming problem. Generally, there are two roles,

the driver who sits at the keyboard and types, and the navigator who directs the problem solving. And the focus of this talk is going to be on the junior- senior pairing dynamic, although I think a lot of the advice can benefit developers at all levels. So why did I choose to do a talk about pair programming? Well, in my experience, it seems to get a bad rep. You may be

thinking that it's a waste of time to pair or it's only for the benefit of the less experienced person. And of course, nobody wants somebody looking over their shoulder, and a lot of people can see pairing that way. And so they might see it as awkward or a scary test. And don't get me wrong, bad pairing definitely does exist. I've had and heard of some

cringe-worthy experiences. And in fact, in my first nine months as a developer, I paired regularly with a guy who would literally laugh at my lack of knowledge when I ask a question. So needless to say, I didn't feel very good about pairing after working with him. But there is good pairing too.

I was also really lucky when I first started out to pair with a developer who was patient with me and helped guide me through thinking through problems for myself. And that pairing relationship helped us both grow a lot. And that's kind of the basis for this talk. So I've made this claim that it can help you grow. But how? First, for senior developers,

trying to explain something to someone else helps you develop a deeper understanding of the material because first, it helps you to better organize information in your own mind. And second, it helps you recognize gaps in your knowledge that you may just skip over on your own.

It also helps you learn by exposing you to new perspectives. There is so much to learn in web development that we all know different things. And as Bill Nye said, everyone you will ever meet knows something you don't, even that junior developer fresh out of boot camp. Obviously, that's not what he said in the last part. So for junior developers, first, there's a lot of stuff

you can teach yourself on your own given enough time content-wise. But when you pair regularly with other developers, you're going to learn a lot faster than you would learning by yourself. Second, I like to think

of programming as a craft. Each time we write code, we're working on building something in a tradition that draws from what others before us have learned and built. So when you're pairing regularly with other developers, it's kind of apprenticeship that helps you hone your craft and learn skills that are much harder to pick up from written or video resources,

like how to break down a problem, how to choose between possible solutions, and how to get yourself unstuck, for example. There are also a number of ways that pair programming helps all developers grow, no matter your experience. First, pairing does involve a lot of talking, so it'll force you to practice your communication skills. And let's face it,

software developers are not known for being really great at that. Also, when you're talking a lot, there will be times when you and your partner can't get your point across, like right now. And of course, this can be frustrating, but you have to figure out how to work through it,

which gives you a chance to practice patience with yourself and others. Finally, pairing helps you build a better rapport with your teammates. And I think that's pretty important because as the complexity of our apps grows, the loan coder is less important than it used to be. Okay.

So now that we've gone through all that, why should you listen to me talking about this? Well, first is this. I do have the mic right now. But more importantly, I'm lucky enough to work on a dev team that values pair

programming, and I spend about 20% to 25% of my time pair programming. So I've gotten a lot of experience with it over the past year and a half. I also have a lot of experience teaching with people. I was involved in a lot of tutoring and mentoring programs from junior high through college, and then I also trained a lot of colleagues and onboarded a lot of

colleagues in my previous career in finance. And of course, teaching skills come in handy when you're pair programming with somebody. Finally, it can be difficult to give direct feedback to a more senior developer on your team, so senior devs are less likely to get this sort of feedback from people they work with. But of course, I don't work with any of you,

so I don't have that limitation. So let's start with tips for senior developers, since they're the ones likely to be leading a pairing session. Yes. So before you even begin a pair programming session, you want to go into it with the right mindset. And this really has two parts.

First, remembering what it's like to be a beginner, and second, dropping expectations of what your pair should know. So let's talk about remembering what it's like to be a beginner. Now, but I learn new stuff all the time, you might be thinking. And considering Ember does releases

every six weeks, and there are new add-ons to figure out all the time, and of course, there's the ever-changing tools that you use in web development, you're definitely not wrong. You are learning things all the time, and it is part of our jobs to be lifelong learners. But do you remember what it's like to not understand how closure actions work in Ember, or how params objects work? I'd argue that this is not

a difference, sorry, this is a difference not in magnitude, but in kind. As a beginner, you don't even yet know what you should know. There are so many unknown unknowns, and this can be overwhelming. Of course, once you're more experienced, those unknown unknowns become

known unknowns, and that's a lot more manageable. So if you started coding in high school, and you just can't remember what it's like to be a beginner programmer, have you tried something new recently, like taking a surfing lesson, or put together your own keyboard, take a moment to remember what it felt like to be a beginner, and be somewhat overwhelmed by the task at hand.

I'll wait. Okay. So why am I asking you to think about this? Well, when you're thinking from this perspective, it makes you better

at explaining things, because you're less likely to take your current knowledge for granted, and you'll have more patience for trying to explain how something works. So let's move to the second part of approaching a pairing session with the right mindset, which is dropping expectations of what your partner, quote, should know. After giving this talk at a local

meetup, a developer came up to me to ask for some more specific advice on pairing with a particular junior dev. And when he was describing this to me, he sounded quite annoyed, and that's best summed up by him saying that this person doesn't even know how to name things properly, like he'll name a function loop. Granted, that's a terrible name.

But he had this expectation that the developer should already know how to do this, and it made him frustrated, and he never said anything to help that person improve. And I'm definitely not assuming I did ask him. My point is that there's so much to learn in programming that we all know

different things. So if you expect a person to know a particular thing, instead of getting annoyed or frustrated that they can't already do it, teach them how. It'll save you a lot of time and frustration now and in the future. And if you're annoyed with someone when you start pairing with them, excuse me, it'll probably make the pairing session less productive.

Okay. So now you're prepared to go into your pairing session with a good mindset, and you're pair programming with...sorry, with a good mindset. When you're pair programming with someone new, try to establish psychological safety. Now, I know this can sound a little bit touchy-feely,

but if you have one takeaway from this talk, I think this should be it. So Google's People Analytics team worked on Project Aristotle in which they did research to try to discover the secrets of effective teams. And here's what they found. Psychological safety more than anything else was critical to making a team

work. And pairing is just like a mini-team, so I think this is really applicable here. But how do you go about creating this feeling of psychological safety? Well, first, you want to emphasize to your partner that you don't know everything. And you want them to ask questions and interject with their own

ideas. While pairing, admit when you don't know something instead of trying to gloss over it, go look up stuff in the documentation, Google it, and look at Stack Overflow and just generally show them what you do when you don't know. Next, don't be dismissive of your partner's ideas. And this is important,

so I'm going to give it its own slide. You want to tell them that there is no such thing as a dumb question and really mean it. When they do ask a question, don't be dismissive or incredulous that they don't know something. You want to set the expectation that it's not just okay for them to speak up when

they don't know something, but it's welcome and necessary. You want to help your partner develop their problem-solving skills and continue to take risks and offer creative solutions because, of course, what else are we doing as software developers? And if you think something that they suggest won't work, don't just dismiss their idea,

explain why you think it won't work. And if it's something small and specific, let them test it out in the console so they can see why it won't work. Of course, they, we, are new to this field. So, sorry, I lost my place. So, of course, we're new to this field,

and many of our suggestions may be just plain wrong, but not all of them. And this isn't just for your partner's benefit. You may be in the habit of doing something a certain way, and a junior developer can help you get out of a rut. For example, this one time, I paired with a senior developer on a problem,

and I brought up an idea that he dismissed with absolutely no explanation. We spent a couple hours of him proposing and going through these various ideas, and nothing seemed to work. And each time something failed, I'd bring up my suggestion again, and he'd dismiss it again. And then after a couple hours of things not working, he went back

to my suggestion, and it turned out it worked, it was easy to implement, and then he apologized to me afterwards for not considering it sooner. So there's a great quote from Alan Kay, who's a computer scientist, that a change in perspective is worth 80 IQ points. Of course, I'm not sure about that number, but I do agree with the sentiment.

So when your peer comes up with a potential solution, ask yourself if they're onto something, and it just might save you some time and frustration, and help you grow as a developer. Okay, so now you have the right mindset. You've established psychological safety, so let's get to some practical advice on how to go about pair programming. Before you write any code,

I recommend that you start with an approach discussion. Review the problem, and whatever background is needed, as well as the different approaches you could take. And this should be a discussion, so ask questions, and make sure to get your partner's input. Avoid going on a long monologue,

like I'm doing right now. Once you have an approach to start with, make sure that you and your partner are on the same page, and that your pair understands what you're planning, lest you end up like these two. Next, guide your pair through solving the problem for themselves.

So when you're working with a junior developer, it may be tempting to just tell them how to do something, but they'll grok things a lot faster if you guide them through thinking through the problem for themselves. But how? Well, the first step is to think about how you go about working through a problem. I bet you break it down into smaller, more understandable chunks,

so help them do that. And you can help them do that by asking thought-provoking leading questions to guide them through thinking through each step. And when you ask your partner a question, make sure you give them time to think. Don't just say, and what do you think this does? Well, here's what it does. Then next, let them make mistakes,

and ask them why something didn't work afterwards. You really want to put the focus on your partner so that they're actually doing the work and thinking through things. Next, when you're trying to explain something,

explain it better. And to do that, you want to simplify, simplify, simplify. I know, but that's terrible. So Albert Einstein, whom I think we can all agree is a pretty smart guy, said, if you can't explain it to a six-year-old, you don't understand it yourself. Now, there's a lot of language and acronyms in web development that a newer developer might not know.

So when you're trying to explain something, describe it in the simplest possible terms, or tell your partner to stop if they aren't familiar with a term you're using. And if your partner doesn't understand your first attempt at an explanation, don't get frustrated. Get clarification on what your partner

understands by asking them to explain it in their own words. This is a surefire way to pick out ideas or areas that need more clarification. Use more precise language. Try to avoid using vague terms like thing. Using thing a lot may make it

easier for you, but it makes it harder for your partner to understand. So take the time to find the right word. And if you just can't get your point across with words, try a different approach. Here's a couple of things to try. Can you create a simplified example in the console so your partner can play with it and see the output? If you're working on a complex application,

it can be difficult to filter out the various things that aren't really necessary to you getting and understanding the core concept. So seeing and playing with a simplified version can help you really grok what's happening. Next, can you make a drawing of the underlying concept? And this doesn't have

to be anything fancy. You don't have to be a fine artist to do this. But your brain processes information differently when you hear it versus when you see it. So drawing a picture of the concept can help your partner understand it better. My first pair programming experience on the job

involved implementing an action that had to be passed up through multiple levels of the hierarchy to register a change and then pass it back down to the component to update the UI. Now, I found that really confusing, and it can be hard to follow the words that I just said, of course, even. So my partner drew a picture of it, and then immediately it made sense to me.

So next, I have a couple pieces of advice that may seem contrary to advice you've heard about pair programming. First, let the junior developer type as much as possible. So I know this may be difficult for you, but resist the urge

to grab the keyboard to just fix that little thing real quick. I even heard of a developer who got boxing gloves to stop herself from typing over her pair. So there's always that option. We all learn by doing, and let's be honest, a single PR in Ember can span dozens of files.

So let them have the experience of navigating the application and actually typing out the code. As an added bonus, if your pair stops listening and goes off into their own world, you can always give them a little left jab to get them back into the pairing process. That's a joke. I'm not actually advocating

violence against your coworkers. So in a similar vein, my final tip for senior developers is to wait to point out mistakes. It seems like one of the biggest benefits people cite for pair programming is that you don't have to deal with syntax errors because you have a second set of eyes to correct you, but this can break

a newer developer's concentration and flow. Give your pair some time to correct a typo, for example. I cannot tell you how annoying it was when I was just starting out and my partner jumped in to tell me that I'd spelled something wrong. A good rule of thumb is to wait 10 seconds to give them a chance to correct

it on their own. And if they don't, you can always take a pause and then ask later and then even use it as a learning opportunity when they have a console error. So just give them a little time and they might surprise you. So now I want to transition to talking about tips for junior developers.

Like my advice for senior developers, I think that junior developers should first try to approach it with the right mindset. And this has two parts. First, remember that coding is in fact hard and it doesn't come naturally because it's an entirely new way of thinking. It will take time.

And this is where I struggle with my own advice. No matter how quickly I learn something, it's never fast enough. But it can be intimidating to work with someone a lot more experienced than you because it can seem like they just magically know things and you'll never get there, but don't get discouraged.

They struggled a lot with the same concepts when they were just starting out. But this is our time. Second, literally have the right mindset. I read this great book by Carol Dweck called Mindset. She's a psychology researcher who studies learning and achievement. In it, she describes two

types of mindsets, fixed in which you believe that your abilities cannot change and growth in which you believe that they can. People who have a growth mindset are more persistent when faced with a challenge and get less frustrated by failure. And let's face it, dealing with failure is a big part of our jobs.

Luckily, you can move from a fixed to a growth mindset. I think that the most helpful idea from the book for moving to a growth mindset was the value of not yet. If you're not getting something, it doesn't mean that you can't. It just means you don't understand it yet. So if you find that you're beating

yourself up for not understanding something, remind yourself that coding is objectively hard and you can understand it, but you just haven't gotten it yet. I think a good tactic for proving to yourself that you can grow your abilities is to keep a list of things you learn while you're pair programming and, of course, while you're programming on your own. And over time,

as you watch this list grow, you'll see in black and white how far you've come. So next, recognize that as a junior developer, you can contribute more than you may think, even if you're very new. As I talked about earlier, experienced developers can fall in the trap of just doing something because

that's how they've always done it. And having a new perspective is quite valuable. Second, you can help your partner question their assumptions. Ask why they're doing something a certain way and they may find that there's a better way of doing it that they never would have come across if you hadn't asked them to explain their thinking more clearly. I have a note here that says,

do not press the button because I always try to press the button at that point. So I'm going to resist that. So for example, recently a senior developer on my team asked if anybody would be a rubber duck for him to get him unstuck on his task and I volunteered. He was working on a deployment bug and I'm not

afraid to admit that I have zero experience with deployments. So to start off, he quickly gave me background on the issue and walked me through the problem with an expectation of what was causing the bug as he later told me. In trying to understand the problem, I asked him a lot of why questions.

I challenged him when he said something worked in a certain way and it seemed fishy to me. And all this made him reconsider his assumptions. As a result, we realized that it was something else entirely causing the bug and not only did we fix that bug, but we found and fixed another one as well. So the lesson

here is to be, oh, sorry, be a good rubber duck. But don't just be a rubber duck, be a Ziggy Starduck. And by the way, this is my actual rubber duck and I wish I could take credit for that great pun, but you can buy it on Amazon. So as my final point on this topic, the code we write for humans,

sorry, yes, the code we write is for humans, not computers. Your input can make the code more understandable. Now, I know this might sound strange that our code is really for other people, but we're not putting punch cards into

a giant computer that takes up an entire room. Code in the higher level languages that we work with is written once and read by people many times in its life. So if you don't understand something, it can mean that the code is too complicated and should be rewritten in a more understandable way. And that's

for you, that's for other developers, for other developers, and let's be honest, our future selves. Next, don't be afraid to say that you don't understand something. I don't know does not equal I'm stupid. It just means that you don't know everything and the truth is that nobody does. There's a great visual

representation of this I got from my coworker. On the left is what you may think, that your pair knows everything that you know and then some, but in reality, there's so much to learn that nobody knows everything and our collective knowledge looks more like the picture on the right, a bunch of overlapping circles of knowledge and experience. Okay, so don't set a bad

precedent for yourself now. If you can't say I don't understand as a junior developer, then when can you? There is a caveat to this. Don't just say I don't understand. Try to ask better questions. So you can start out by

stating what you may understand. And by the way, this was gratuitously stolen from a great blog post by Julia Evans, which I'll put it which is in my references, and you can get a lot more tips about asking better questions from there. But explaining your current understanding has two benefits. It gives

your pair the context that you have so that they can better answer any questions, and it can help clear up any misunderstandings and answer a question before you've even asked it. Next, you want to ask specific questions as you go along, whether that's because it's a question about a term you're unfamiliar with or you don't understand where an object

passed into a function is coming from. You'll get more out of a pairing session if you're clarifying things regularly. Finally, don't be afraid to ask your partner for what you need. As the great Stevie Wonder is saying, if you don't ask, you don't get. So if the developer you're pairing with isn't doing

something I suggested here that you think would be helpful, ask for it. And as I said in the beginning of the talk, I know this can be hard. So here's a bit of shameless self-promotion. If you're too nervous to speak up, you can always direct them to the video of this talk.

So thank you very much for being a great audience. I hope you got some useful tips that you can use in your pairing sessions. And if you'd like to contact me, I have a very unoriginal Twitter handle, Diane Aromo. So I'll leave you with a picture of my dog as a puppy and my references. Thank you very much.