Pair Programming

[00:00:00]
>> Will Sentance: pair programming, the most effective way for us to grow as engineers. All of these mental models, these weren't mental models, these were, you know, new tools, all of these mental models, people, are only so good as when we test them by actually solving problems. And so, at least for folk online and hopefully sometime for all of you, within lunch, you're going to be in pairs working through some problems.

[00:00:25]
And the point of pair programming, yes, look at that. You've got friends being made in the audience already. The point of pair programming is the chance to fight the two instincts that we have as early stage engineers, but we honestly still have, well, it is about getting really good at this balance, and that balance is between two instincts that we've all known, I'm sure. One is the researcher. And especially even if we're experienced engineers and we're taking on a new domain, we can be very prone to this.

[00:00:54]
It's not a bad thing. They're both good things, but they're things that have to be balanced. One is the researcher, the person who takes on a new topic, the new keyword, and spends the next 4 days researching every last element of the new keyword. The other is the, I'm calling it vibe coder now, oh dear, but I used to call it the Stack Overflower. It's the, I'm going to make it work, I don't know why it's working, I'm just going to keep pressing that button.

[00:01:21]
I used to say that it was, which is essentially what, you know, ChatGPT in a sense does at a much faster rate, but it was the go to Stack Overflow, post the problem, hope that no one attacks you for just posting the problem. And then get the solution, it doesn't quite work, repost that, and then iteratively, that was the original prompt engineering, the Stack Overflow. But neither are wrong, making stuff work is part of being, where you don't understand it is part of being an engineer.

[00:01:49]
Understanding stuff deeply is part of being an engineer. The trick is getting really good at calibrating both of those. Both of those are avoidance of the thing that actually in a given problem will best serve you, which is methodical, steady, careful, walking through your code, verbalizing it line by line, tracking your steps. State, that's a fancy word for your data live in your application. Tracking what is being called, executed, invoked at that moment.

[00:02:20]
Yes, it may not be as simple as just JavaScript runtime, it may be that you're calling some API call off on another server that you're also developing. It may be that that's calling a lambda function that's also being hosted on a platform that's got to be configured. That's all those still tracking. A runtime or collection of places where code is running and the data as it trawls through the different threads across those different environments.

[00:02:47]
It's all still that, and that process when you're pair programming, you have to make it explicit, because your job is going to be to turn to your neighbor and explain to them in response to a task, a challenge, a coding challenge, a building challenge, explain to them how they're going to actually go about typing the code. Verbalize to them the explicit steps, you can't give them the actual text, you can't say what we heard earlier from Michael, I think, I think it was Michael, function, 10 2.

[00:03:17]
Was it you, Michael? Was that you, Joe, sorry, Joe. We can't be doing just the explicit description of the code word for word, we've got to describe the how and why of it. We're going to declare a function here in order to do this task. We're going to make a call to this API and when it breaks, you're not going to say, hey, let me try and figure that out for you. Instead you're going to say ah, so I suspect that what's happened here is, and then you're going to describe it, and maybe make a suggestion about the doc they're going to go and look at, maybe make a suggestion about the tracking in the console or the dev tools that they're going to refer to.

[00:03:54]
Maybe even make a suggestion about the prompt they're going to write to the Copilot to say, you know, here's what I'm not understanding, here's what's breaking, which is all still part of that engineering debugging process. So one of you is therefore the navigator, hands off the keyboard, describing the approach, the other is the driver, hands on the keyboard, implementing the approach. It works for small challenges as a way of testing that balance of the researcher and the vibe coder.

[00:04:27]
And it works for yourself as you go into vastly complex codebases that need to take a complex problem, work out exactly its flow, and from that identify what is breaking, what your goal was, and it all ties more and more into what it is to be an engineer today. When you hear people in engineering teams using the term vibe coding, what they're typically describing really is very explicit definition, so not vibe coding as I mean here, they're describing very explicit definition of their goals, the engineering constraints.

[00:04:59]
Defining exactly what, if they are working with an AI Copilot, exactly what they want to have happen, exactly what they consider the engineering constraints to be, exactly where the configuration files are, all these sorts of things, that is quality technical communication. So this becomes even more pertinent as you go into engineering as it evolves in the years to come. So, yeah, pair programming tackle blocks with a partner, it prevents you from seeing the problem and going, I'm going to go research for 3 days.

[00:05:28]
First time I pair programmed, somebody, I've shared this story because it, I still remember it. I wanted to go and understand the topic perfectly, and they're like, after 10 minutes, which even then was quite a while, they said, do you mind if we get started? And I was like, oh my goodness, I need to understand it perfectly. I do consider it slightly ironic that I've then gone on to build programs that are about me understanding it fully, to be able.

[00:05:50]
Anyway, but that's a separate matter. Refine the technical communication and collaborate to solve interesting problems. So there we go, people. I think now we take a break, we'll go, you can go through these for folk online, you can go through these, 9 questions. Have you created a function before? Have you implemented reduce from scratch? Do you understand the event loop? Can you handle collisions?

[00:06:14]
Give yourself a score, a total out of 9, and typically if you're online and you do want to pair up, pair up based on a similar sort of score, and then, people, we're going to expand our higher-order functions from functions that took in another function to a function that returns out another function, one that is profoundly powerful, and my favorite concept in all of JavaScript, closure.