Pair Programming

[00:00:00]
>> Will Sentance: Let's go into Pair Programming folks, we're gonna start encountering these things first, and then, afterwards, actually resolving them and seeing how they work. So you're gonna start seeing high order functions first, and then we're gonna start actually resolving them ourselves. So, we're gonna use Pair Programming to do so, this is by far and away the most effective way to grow as an engineer.

[00:00:22]
If you've done it before, you probably already know this, but we're going to do it in a really effective way here. Take a look at this, if you are building yourself as an engineer, you fall into often two very risky traps. One is the researcher and one is the Stack Overflower, both are avoiding what it really is to be an engineer, which I'll tell you in a second.

[00:00:39]
The researcher avoids what it is to be an engineer, which is to be able to hit a whole block and somehow resolve through it, that is all it is to be an engineer, how do we actually do that? I should have figured out, here's how we do it, here's how we actually resolve hitting a whole block we go through the code.

[00:00:59]
When we on that bit that's blocking us line by line and understand the data, they call it the state, the live data as you go through line by line, that is debugging. It's hitting a block and assuming the code, and then console logging essential using some other debugging tool, the data as you go through, line by line.

[00:01:19]
We love to avoid doing that though, we will do anything to avoid doing that process, we gonna get in that habit of doing so we'll do anything we can, including one or two these things here. We become the researcher, that block, we look at the mystery bit, maybe it's a new key word.

[00:01:36]
And we spend the following three days reading every last thing about the new keyword, and about all aspects of the prototype chain, and wonderful. And yet we don't write a single line of code, we avoid the block, the other approach is to grab snippets of code to fix a bug from Stack Overflow.

[00:01:54]
And when that one when we plug it in, doesn't work, take that snippet plus the bit we added. Put it in the Stack Overflow, and say, how do these bits, stick together? Neither is effective in its own isolation, both are necessary to being an engineer, you've done this in the first year of your careers, both of these.

[00:02:10]
That's probably, yeah, that's how it is, but you've gotta get better at balancing those two and the really important bit which is just going through. And analyzing the code yourself line by line by line with the help of console logs or the help of some sort of debugging tool.

[00:02:24]
And then yes, going to understand and building your underlying principles understanding that's the researcher. And yet taking snippets that sometimes you just go, I don't know how it works, is magic but it works, that’s part of being an engineer but you gotta get that balance right. And the route to do so is Pair Programming, you get to tackle tough blocks and you got a partner in crime alongside you.

[00:02:45]
You get to stay focused on the problem at hand because you can’t run away. To make a cup of tea, because they're literally sitting there right beside you, and you also can't spend too much time doing these things. So the researcher, I still remember my first time pair programming with a guy called John.

[00:03:00]
And he sits next to me, and he's like, do you mind if we do some sort of reading up on this first. And I said of course, and then like eight minutes he then says, do you mind if I get started, and I was like I wanted to read up on every, I wanna understand it all first, right?

[00:03:14]
I couldn't, my partner was waiting for me they were ready to run, I also couldn't just give them a code snippet. I remember a time I was working with paper and someone called Alice and I couldn't just give them a code snippet. Because they were like, won't talk me through why we're using this, how it's solving the problem.

[00:03:31]
We are fools when we pair programming to verbalize and explain our code and therefore not just make it work alone some element of that but understanding as we go. And that's the other big piece here, it's gonna refine our technical communication, the way we pair program is this.

[00:03:49]
If I'm navigator, I'm looking at the prompt and I'm seeing it says, I make it cool to Twitte API. I'm now going to lead my partner their hands are on the keyboard typing and actually executing the code itself and then verbally explain a strategy that they must turn into actual code.

[00:04:07]
They can't get off, they can't do it their way they have to take my explanation and implement it and if they're not understanding my explanation, that's all in me. I can't say, hey, actually, let me just show you how to do it, I've got to be able to verbalize with such clarity and precision intuitive style, that my partner can actually turn it into real code.

[00:04:27]
That is remarkable, it's gonna refine my technical communication beyond measure. Why pair programming is so important as a team doing these industry reviews with, you know, engineering managers and folks in industry for our curriculum. This new curriculum is what makes us do it, but whatever they make us review the new curriculum, because it's government agency that we're doing it with.

[00:04:48]
So there you go, it's astonishing to hear them talk about their senior engineers that they are may be frustrated with. Who cannot verbalize their code well, that is a massive hindrance to a company. So even if you're very seasoned, this is a huge opportunity to verbalize your code effectively.

[00:05:08]
So there we go, as I say, you're gonna take a challenge, a prompt, and one of this'll mean navigator. I'm gonna be explaining a strategy verbally, verbal pseudocode, so to speak to a partner who's gonna be executing it in actual code. Okay, you're going to do it for, you know, five minutes navigator, five minutes driver and witch over.

[00:05:26]
If you do think by the way, your partner's going off on a bad route, don't block them, don't say I think that's not gonna work. Let it happen, press Run, you're gonna see a bug is not a mistake, the bug is something that you now know can be used to identify what the problem was.

[00:05:39]
That's awesome, you get to be a debugger with them where you already know what's broken. And something that weird error that's like, you know, token whatever, now, it's not a mystery. It's something you actually can, you know, what's behind the scene's wrong, that's pretty nice actually. Okay, and by the way, half the time that may be right and according to the strategy, there we go people.

[00:05:57]
We're going to pair program and we are going to do the old style and we're going to go through this list of nine things, have reached thing that you see here. Give yourself a point to get a total of between one and nine, yes, so if you've done all of these before, you've covered all of these, your score is, total out of, nine.

[00:06:18]
I don't know how that got cut off, a total out of nine, if you've done all of these, you've got a score of nine. If you've done three of them in any order, score of three, five of them in any order, score of five. Okay, once you know your tally, people, we are back to the old school Harry Potter style.