This course has been updated! We now recommend you take the JavaScript: The Hard Parts, v2 course.

Check out a free preview of the full JavaScript: The Hard Parts course:
The "Introducing Pair Programming" Lesson is part of the full, JavaScript: The Hard Parts course featured in this preview video. Here's what you'd learn in this lesson:

Will introduces the concept of pair programming, which is an agile software development technique in which two programmers work together at one workstation

Get Unlimited Access Now

Transcript from the "Introducing Pair Programming" Lesson

>> Will Sentance: Pair programming info is without question, Codesmith wouldn't work without it. Of the 1,000 hours you spend at Codesmith, about 400 I'd say are paired. Everyone's laptop pulled to. Thank you, Amin. Thank you, man. My passive aggressive thank you.
>> [LAUGH]
>> Will Sentance: Never is a thank you be less grateful and more demanding.

[00:00:23] All right, so pair programming is the secret approach to how you grow as an engineer. Let's look at it up here. There are two types of learning out there, or there's a spectrum. Harder learning, easier learning. Easier learning spoon feeds. Maybe a diagram, no diagram. Easier learning is spoon feed, that's fine.

[00:00:44] So people mention Code Academy, Code School, wonderful. For your first 30, 50, even 100, even 200 hours, great. You have to just keep going, just keep pushing and if it spoon feeds you it keeps it going and repeating and re-writing a function 100 times, that's worth it. But at some point, you're gonna start a plateau in your growth if you follow the spoon fed approach.

[00:01:12] You're gonna remain a junior developer, an entry level developer. That's not what you want. You wanna grow into an autonomous problem solving mid or senior developer. So how do you do it? You do hard learning. You don't do the easier learning for long. You do hard learning. So hard learning is things like, shout out to Clara, I go and try and build projects.

[00:01:38] Hard learning is doing MIT OpenCourseWare and all the problem sets of it. Hard learning is doing all those MOOCs and all the problems that's associated with them, like Coursera, edX. Has anyone ever finished one of those? I doubt it. So maybe you have, this could be a life changing moment for me.

[00:01:57] Which one did you finish all the problem sets on?
>> Speaker 2: It was not a programming one, I finished a different one.
>> Will Sentance: Okay, there you go, that's confirmed my bias, and?
>> Speaker 3: Coursera for Ruby.
>> Will Sentance: You completed a full Coursera course?
>> Speaker 3: Yeah.
>> Will Sentance: All the problem sets?

>> Speaker 3: Yeah.
>> Will Sentance: Let's give her a round of applause.
>> Will Sentance: My God, this is unprecedented.
>> Speaker 3: I felt obligated to, cuz my company paid for me to do it. [LAUGH]
>> Will Sentance: So I'll tell you this. Seriously, commitment device is very, cuz it's incredibly hard, right? The hard learning, what happens?

[00:02:25] You hit a block, and that's what hard learning is. At that moment you give up. So you grow as a problem solver and you grow as a communicator when you hit a block, when you cannot make this thing work and everything is screaming at you, go do something, make a cup of tea.

[00:02:45] Just run, you wanna get away from the struggle. But that's when you grow. That moment where you keep pushing through is when you grow. If it takes a commitment device that your company paying for you to do it, okay, that helps. But most of the time, we do tend to slip into the give up approach when we do hard learning.

[00:03:04] But hard learning is where we grow. It's where you become an actual engineer. No one ever became an engineer, unfortunately, by doing Code School. I love Code School man, JavaScript Road Trip if I hear that theme tune one more time. But instead we fall into the trap doing easier learning and thinking we're growing but we hit plateau, like what we do next?

[00:03:26] Or we do hard learning but we risk giving up. Now if we push through the hard learning, suppose we're doing JavaScript 30, we're pushing through, suppose we're doing, I don't know, Coursera or edX course and we're pushing through. Great, now we move into this camp, this bit here, even here we're not safe yet.

[00:03:52] There's a spectrum here of how we do the hard learning. On one end is the researcher. So you'll say okay I've heard Will say I should be doing hard learning. I've heard him say it, I'm gonna go do a project. I'm gonna build a project or I'm gonna go and do some hard code rule problems or I'm gonna do some problems, they're gonna be hard.

[00:04:13] But I'm gonna do it. Okay, great! And then you see ten words in the question that you don't know and you go, okay. You go look them up. And in that documentation, you see another ten words you don't know. Okay, now it's half way through. Now it's lunch time, so you take a quick break and then you come back and you go okay, I've got.

[00:04:34] And by the end of the day you have read everything there is to know about object-oriented programming in JavaScript. But you have not put your hands on the keyboard once. You've fallen into the researcher trap, that's one extreme. You're doing hard learning but you're not actually doing it.

[00:04:49] You're doing hard work but you're not doing it, hard problems but you're not actually doing it. Other end, the Stack Overflow approach. This is the, I'm doing a project, I'm doing real hard learning, this is real problem solving. Okay, this isn't working. Let me, there's a snippet. Man, someone has had this error before.

[00:05:06] Snippet from Stack Overflow, take snippet, copy and paste. Still not quite working. Take another snippet, copy and paste. Okay, another snippet, copy paste. Okay, they're not working together. Post those three snippets and ask someone how make them work. I was working Stack Overflow approach. You're doing hard learning.

[00:05:24] You're doing hard problem. But you're doing the just make it work. No idea, no idea how it's working. So it might seem we're stuck in a catch 22 with all this stuff. That is a little arrow above that pointing at the green area. Pair programming lands us perfectly in the middle.

[00:05:42] Hopefully, if we do it right, between the I must understand what I'm doing in the hard learning and the other end, the make it work. Pair programming says because you have to never problem solve, never come up with a solution, never come up an approach to solving the problem and type it.

[00:06:03] If you come up with the approach, your hands are behind your back, you're having your partner interpret your pseudocode as sort of way we talk through our code up here which there's gonna be a lot more of it in the next two days. You have your partner turn your pseudocode, your spoken verbalized problem solving approach into actual code.

[00:06:25] What that means is you explain your approach to solving the problem and then have them actually interpret your approach into actual code. You have to understand it just enough that you can explain it, like this is why we're gonna do it, this is how we're gonna do it.

[00:06:41] But you don't have to understand it so much because you can't leave your pair programming partner waiting there while you research all of object-oriented programming. You've gotta at least get your hands dirty, cuz they're sitting there waiting for you. But nor can you just plug and play because you've gotta talk through the code line by line to them and have them actually turn it into code.

[00:07:02] So you're forced to land in the green area between on the one end, the must understand everything, never get my hands dirty and the don't understand anything, but hey I've put my hands on the keyboard. This is an incredibly powerful approach. Let's see it in action. Let's imagine we have Barb and Lindsay.

[00:07:19] Okay, so Barb and Lindsay, they see a problem presented they want to work on. It says, okay, Barb and Lindsay, display ten tweets from Twitter's API on the webpage. Ten tweet from Twitter's API on the webpage. All right, so Barb says Lindsay, do you know Twitter's API and she's like no.

[00:07:40] Let's go look at Twitter's API doc. Let's go look at the doc, the documentation, see what it says about how the API works. And then they get there and Barb sees, Lindsay, it says that it's gonna give us very conveniently an array of ten strings, which are the ten tweets directly from this address.

[00:08:02] And Lindsay's like, that's not likely. But Barb says yes it is. There it is, look that's what it says, just an array of 10 strings effortless, easiest API in the world. No authentication, nothing, just there they are. And Barb's really happy, Barb look happier. Barb really happy. She's grinning she's so happy with how easy this API is.

[00:08:23] And then Lindsay says actually let's look again, I think there's a jQuery method that we can use to append strings to a dumb element, to a bit of the page, to a dumb element, like an element with a class name like tweets container. So now they've done their research.

[00:08:41] That was the research stage, they did that together kinda hustling, figuring that out. Now they move into the driver navigator stage. So let's say Barb says hey Lindsay I've actually got an idea how we can approach this. Do you mind if I navigate? So Barb's job is now gonna be to talk through an approach to solving this problem, and her hands are never gonna touch the keyboard.

[00:09:09] If she feels, man, Lindsay just, I know what I want you to do, that's the moment where her technical communication gets to level up. Cuz she needs to be able to explicate how to solve the problem to Lindsay such that Lindsay can actually type it out on the keyboard.

[00:09:25] So for example, Barb says all right Lindsay let's start by declaring a function. Let's call it append tweets. Let's have it be passed the parameter, let's call it tweets array, that's a placeholder. And the body of the function, let's iterate through that tweets array, loop through it, take each string, each tweet, and pass the tweet string to jQuery's built-in append method.

[00:09:57] And let's called that append method on the DOM element with the class name, let's call it tweets container. Let's call it that. And now, at this point, so they've used their research, and Barb has spoken in pseudocode, and she's never put her hands on the keyboard. And now, Lindsay, she's our driver, so she's actually at the keyboard.

[00:10:19] She's going, okay, declare a function, append tweets. All right, function append tweets parens, tweets array is the parameter, okay tweets array, close parens, open curly braces, iterate through the input array, four in parens let i equal 0. And at no point did Barb say Lindsay, function, append tweets, open paren.

[00:10:45] No she was saying all this precise pseudocode, which we'll be working on today as Amin said we are declaring the function multiplied by two. We are declaring output and assigning it to the return value of the call two multiplied by two with the argument four. That pseudo code is what Lindsay's turning into actual code on the keyboard, okay.

[00:11:14] What this does is it ensures that Barb has enough understanding to be able to talk through it, but not too much that she's stopped and not coded. And that Lindsay has the ability to interpret that precise pseudocode. After about ten 15 minutes they could swap over. Now you may hit a block and be like, damn I have no idea how to solve this.

[00:11:35] So yeah as always, try figuring stuff out. But if you have an idea, force yourself, actually Barb I have an idea. Do you mind driving? And so Lindsay's gonna explain her idea. You know that moment when you're like, let me just try this. Can we console log that.

[00:11:51] Force yourself to have the other person be navigated through it by you. And by the way, Barb thinks that Lindsay is making a horrible mistake. Or Lindsay thinks that Barb is making a horrible, let's be equal. Lindsay thinks Barb is making a horrible mistake. She does not say, stop, stop, stop, stop, let me show you how to do it.

[00:12:12] She doesn't do that. She quietly sits there, smugly.
>> [LAUGH]
>> Will Sentance: No, not smugly. She quietly sits there, goes, mm-hm, mm-hm, yeah, keep going, no, no, no. And by the way, half the time, the smugness is wiped off her face. Barb, I know you're not actually like this.

[00:12:28] I think you're charming.
>> [LAUGH]
>> Will Sentance: Half the time, actually, it turns out, Lindsay had a different approach to what Barb thought, and it kind of worked. It worked anyway. But half the time, actually, you know what? Barb's approach was totally wrong. So Lindsay's typing to Barb's approach, and Barb was totally wrong.

[00:12:44] But now Lindsay, even though she thinks she knew a better approach, they press run in the console, they see the error appear that says an undefined is not a function. And now they get to debug as a pair together as well. All right, this is a long introduction to pair programming, but anyone got questions on how to pair program effectively?

[00:13:05] We're gonna be doing it for two days. So we wanna really know, what if this happens? What if I filled it? How do people know? Don't be a dual driver-navigator. In other words, don't be typing and explaining. I'm gonna be wondering around. If I see, I wanna be clear who's driver and navigator at any point.

[00:13:23] Try and always have accountable. But also, let me tell you, it's an aspiration. And the best execution of pair programming is just if I have an idea of how to solve it, I am not gonna have my hands on the keyboard, the other person is. I'm gonna communicate them through and explain how to solve it.

[00:13:39] But any questions on how to pair?