Node Pair Programming Setup

[00:00:00]
>> Will Sentance: We are now gonna be the developers on this computer writing JavaScript code after turning node on by writing the terminal node, turning on the node engine that includes turn on the JavaScript engine. We're then gonna be saving JavaScript code into a file that we're gonna run in this node application here.

[00:00:23]
And they're going to be testing what, hopefully, we're gonna open a socket in our computer on the network card to listen for inbound requests. Do we need another computer to send those messages? No, we're gonna go on the same computer, open the web browser, use this built-in special pseudo domain name, that's gonna send a message right to our own computer.

[00:00:45]
We're gonna listen on the right port, and we're gonna send it to the right port, and we're gonna start writing code. Okay, now the code is at bit.ly/femnode. You are and you're gonna go to that, download the zip file, open it, make sure you've installed Node. Please go to Node.org, probably.

[00:01:15]
[LAUGH] [INAUDIBLE] Search Node on Google, download it, install it, then download the zip file, open it, it's a folder. First, open the readme, open the readme and start following the instructions in there. You're going to be building out this code here to be able to send back the right data to your client, which is also you.

[00:01:41]
There we go. We’ve got to do it in pairs. I’m not going to dwell on how to do pair programming but here is the essence of it. Yes, I have thoughts on this. Pair programming is two of you working from the same machine, one of you interpreting the challenges being posed and offering an overall strategy to how to solve it.

[00:02:03]
You might need to go to documentation to understand what's being asked better to come up with a strategy. But your partner, she or he has their hands on the keyboard and they're going to interpret your overall strategy into actual code. It's remarkably effective, people, for so many reasons.

[00:02:21]
One, when we are solo learning, we found the two bad traps. One, researching way too much, we want to read everything before we write any code. We want to build a total understanding of something before you write any code. You may be able to tell which one I'm prone to do.

[00:02:37]
Or with a person who just grabbed snippets of code to make it work and have no idea how it's working. Our job as developers is to be a bit of both of those for the rest of our careers. But we want to train ourselves to land in the middle whenever we're learning a new thing and the best way to do that is pairing.

[00:02:54]
Let's say we've got Zach and Sarah Rose pairing. Sarah Rose is our navigator, she's looking at the prompt and figuring out what is being asked, and she's giving Zach an overall code strategy. She can't wonder off to read for three hours, he's sitting there waiting. But nor can she just give him a snippet of stack overflow because he wants to know kind of how to do it and why.

[00:03:18]
So she's got to give a precise strategy. Fantastic for getting you right in the right balance between making it work and understanding it all. But on top of that is so many more benefits of pair programming. Two, Sarah Rose's technical communication, that means her way of verbalizing the code that she thinks Zach should write, has to be exemplary.

[00:03:40]
She has to be able to communicate to Zach such that he understands exactly what she's asking him to do. Because she can't say, Zach, no, sorry. What I meant was [SOUND] move your hands up, typy-type. She can't do that. She's not allowed to touch the keyboard. And now, you may think, it's not that interesting, why do I need to ask you?

[00:03:59]
If you can communicate so well that Zach can implement his code from your communication, you have a golden scenario for a senior developer. Mid-level, junior developer, can take any new feature, build it, if they've seen the technology before. Mid-level developer, any new feature, build it, even if they haven't seen the technology before.

[00:04:19]
Senior developer take any new feature on the app and enable others to build it by explaining and communicating how to solve it, even if they've not seen the feature before. It is a key senior developer characteristic to be able to communicate code and strategy effectively, very powerful. Final reason I love pair programming.

[00:04:39]
If Sarah Rose notices that Zach's doing something wrong, he missed the semi colon or he missed the curly brace, she doesn't tell him. She lets it happen. They press run. They see the error. She now knows what the error is and they're gonna debug it together. And as the best pair programming partner, she's gonna kinda lead him to it.

[00:05:03]
For the first time, an error is not this mystery. She knows what the mistake is. So when she sees the unexpected token, rather than going, what the hell? Why would you, also, these error names? What do I do? She knows that he missed a curly brace. So she goes, that's why it's saying unexpected token closing parenthesis because he's missing an earlier open curly brace, so that's what unexpected token means.

[00:05:32]
Suddenly, error messages become enhancers rather than confusers. Really, really effective. Okay, there we go, navigator driver switchover after 5, 10 minutes. That's it. Take it away, folks. Any other questions on pairing? Those are the key things. One other thing for technical communication. Your job, Sarah Rose, is give an overall strategy, but also, you want to then give line by line, not word for word.

[00:06:00]
Not saying, right the word function, and now the name of the function in parenthesis. You're gonna say, declare a function. But you all are gonna give a line by line strategy to execute the challenge. And if you hit a block, encourage your partner to verbalize their confusion or you to verbalize your confusion with, here's what we expected to happen, we hope the function would return our tweets.

[00:06:27]
Here's what actually happened, it returned undefined. Here's what we suspect might be the reason. Here's what we're gonna try to see if we can adjust it. Here's what we're console log to sort of introspect the function. And now, we can start taking that next step. Still doesn't work, follow the same process of debugging again, and again, and again, communicating that debugging each time.