Asynchronous Exercises

[00:00:00]
>> Will Sentance: So pair programming. There is no better way to grow as a software engineer. The reason being, we said at the start, as people shared resources like Pluralsight. It was Sean who shared that. Pluralsight is video driven. These resources are solid. They're excellent. Well, I don't love Pluralsight as much as Frontend Masters, one of the best resources for videos.

[00:00:27]
Well, it's the best by a long way. For real, it's clearly the best. But those are only legit if you're using them, wielding them to solve problems you're getting in your day to day work. So if you're an aspiring engineer and you're not working on tough JavaScript problems every day, then you fall into the trap of what I call easy learning.

[00:00:49]
Easy learning is learning where you don't hit blocks and therefore you don't grow. So how do you do what I call hard learning that's effective that actually is what makes you grow as an engineer? Well, you do things like tough coding challenges. You build projects. You have assignments.

[00:01:05]
But the problem with those is it's super tempting to do what? To do anything else besides that. Including, so we might be making a cup of tea. Whatever. But even if it's not that, even if the other person's like, no, no, I can actually push through them. You may still fall into two traps.

[00:01:21]
I call it the researcher versus the Stack Overflower. This is the researcher. That's my magnifying glass. I need to spell that out unfortunately because clearly I've been told nobody ever recognizes what this symbol is. And a Stack Overflower. Ideally, as a software engineer, we're always balancing these two extremes.

[00:01:42]
I wanna understand everything and how it's working, but I simultaneously gotta make it work sometimes. Just make it work without understanding every piece. We're always balancing these two needs. As a pro engineer facing tough challenges, we've hopefully learned to balance that effectively. But we could always get better at it, and the best way I know to get the balance right is pair programming.

[00:02:03]
Pair programming, by separating the concerns. On the one side we have James, on the other, we have Blessing. James and Blessing are working through a challenge together. Let's say Blessing is what's called our navigator, and James is our driver. Blessing is at no point ever allowed to type.

[00:02:21]
She's not allowed to put her hands on the keyboard. But she is responsible for the problem solving of the challenge. That is to say, Blessing is the one who is gonna verbalize and approach both an over all strategy and a line by line execution of the code that James is then gonna interpret into actual code.

[00:02:41]
She is never gonna take control of the keyboard. She's never just gonna say, James, you mind if I just show you what I mean?
>> [SOUND].
>> Will Sentance: Instead this separation concerns is gonna ensure that Blessing can't ever become a researcher for ten hours, reading every last thing about the new keyword because she's got James sitting there waiting.

[00:02:59]
But nor can she just be a Stack Overflower, make it work, plug and play script person because James needs to know a bit more about why we're doing it. What is our strategy here? What are we doing line by line? But also by her not being allowed to say, James, let me just show you, her technical communication, the ability for her to explicate her approach and make it meaningful to somebody else is vital.

[00:03:22]
It's a thing we look for in codes with interviews more than [INAUDIBLE]. We've turned down many people for Codesmith who've been JavaScript engineers for four or five years, because their technical communication is not there. And yet that is what makes a senior developer. Mid level developer, take any feature, implement it.

[00:03:39]
Even if they've never seen the concept before, because they've learned how to break through blocks. Senior developer can take any feature and they can empower a team, their colleagues, to implement it, because their ability to take their internal mental model of the code and make it meaningful to somebody else.

[00:03:57]
That is what we're training on when we pair program. All right, which means one machine between two. It means switching over role every ten minutes or so. It means, by the way, if your partner is going down a path you think's a mistake, let it get to the point where they press run.

[00:04:14]
And they see the error and then debug it together. Don't say, I think you went the wrong way here. Very, very effective. All right, people. There it is. You're gonna go to csbin.io. This is for our online focus world. You're going to csbin.io/promises. Get to it, start working through them, and we will reconvene shortly.