Learn to drive before you navigate, even if you’re not pair programming

One day when I was eighteen, I was sitting in a little lecture theatre with twenty-nine other boys. It was the first morning of our computer science degree at Melbourne Uni. A man — gaunt, a bit haggard — walked in, stood at the lectern, scanned our faces, heaved a big sigh and said “Learn to type. Learn vim.” He started to say something else, but then just shook his head and walked out of the room. We only found out much later that he was the head of the department.

I remember thinking “I can type, and don’t you dare tell me what text editor to use.” And I typed and edited text well enough to get through the next three years. I never even thought about actively getting better at it.

It’s been over a decade since I sat in the Shortest Ever Lecture, and I think I understand now a bit more about what he motivated him to say what he did. This is my attempt at doing it better.

Part one: how I almost lost my first programming job

A few days after my final exam I booked a one-way ticket to London and started sending out my resume, which listed my experience stacking shelves, doing data entry and working the phones at a call centre. I also linked this little web app I’d made called Geektar. It had about fifty users. One of the pages took at least five seconds to load because it wasn’t made to support such an enormous user base.

The job market for devs was good in London, and within a couple of weeks I was a salaryman. On good days, I liked my job, and everyone relevant seemed glad they’d hired me. But I had terrible sleep habits. I’d stay up all night playing computer games. When you’re stacking shelves, it doesn’t matter much if you go in as a no-sleep zombie, but for some reason it was absolute hell for me as a programmer — and not in the sense that I got reprimanded, it was how it felt.

Part of the reason was pair programming, which was all the rage in London in 2011, and hopefully still is. One person would “drive” the computer, and other would “navigate”. The driver had has hands on the keyboard, running commands, editing code, refreshing the browser, and so on. The navigator’s job was less clearly defined, kind of as “everything else that goes into software development”, which is a lot. The sacred ritual at all the places I worked, and what everyone talked about at meetups (my terrible strategy for meeting new people was to go to tech meetups, which is probably part of the reason I had so little sex for such a long time) was to alternate roles every half an hour or forty-five minutes.

You have to talk a lot when navigating, explaining to the driver what you want them to do, and justifying it — especially when you’re new to the craft and barely know what you’re doing. Most senior devs will have an extremely hard time silently obeying the instructions of a twenty-one year-old, for good reasons.

When I don’t get sleep, my ability to speak plummets, and my thoughts seem to slow down. On those days, I felt hugely anxious when it was my turn to navigate. I wasn’t thinking of it in those terms back then, it was more that I’d get this overpowering impulse to run away. A lot of times I’d tell my coworkers I was sick and go home. I tried coding solo. But now I was having to navigate and drive inside my own head, without any help or advice from experienced devs. It was super unproductive. Pretty soon, if I’d slept poorly I just wouldn’t go into the office at all. I wanted everyone to think I was a whiz kid, and going in at a fraction of my capacity would shatter the illusion.

But this isn’t a sustainable strategy. I was alone in a strange, hard city with no friends and an expensive fixed-term lease. If you stop showing up, eventually they stop paying you money, or so I’d heard.

It took a while, but eventually I realised that I didn’t get so anxious when I was driving, on those bad days. There’s less talking, less abstract theorising, and more muscle memory. So I asked my pairing partners if they would mind if I just drove. I also changed how I did it. I love arguing, and I love thinking about how software is written, so for the first few months when the navigator would say “let’s do this” I’d say “ooooh, but why?” and derail us for five minutes, partly out of curiosity but probably more because a) I wanted to show that I was clever and b) I wanted to be more involved in the creative process, to put my stamp on the codebase.

When I stopped doing this, we’d get more stuff done, without a noticeable drop in the quality of our output. I also came out of the day way, way less taxed. Don’t get me wrong: wielding a computer is not an easy thing (and I’ll get more into the specifics in a minute), but it sure is less draining than designing and debugging software while typing while arguing with smart people. And there was plenty of opportunity to debate when we’d stop to make a cup of tea.

I used the extra energy and willpower that saved to start going to the gym, which helped me sleep, and I fretted less at night about letting down my team or losing my job, because I was showing up every day and making myself useful.

Part 2: How this early focus on driving helped my career

I worked at a few different places in London, with a bunch of different devs, but thankfully never in a place that forced you to pair with a specific person. I like choosing who to work with. Plenty of the older guys liked to be left alone, because that was what they were used to, and in jobs where they’d been forced to mentor junior developers it’d been a burden, and they generally like getting things done quick so they can get home to their wife and kids. (By the way, if the way I’m talking about all of these developers as men is weirding you out, it’s because I literally didn’t work with a programmer who was a woman the entire time I was in London.)

So, a lot of the best programmers were surly and didn’t want a punk university graduate sitting next to them all day, let alone an Australian who hadn’t quite learnt proper English manners. But I was fascinated with them, the greybeards. It seemed like there was all this accumulated wisdom that had either been passed down from the early days of computing from craftsman to craftsman, or won through decades of painful lessons.

“Gimme some of that”, thought the now twenty-two year-old me. And I got some of it. But a quick aside:

Calling it “driving” makes it sound easy

Programming involves talking with a computer. But have you ever seen Rain Man? Remember how Tom Cruise would give Dustin Hoffman basic instructions and he’d take them too literally or just ignore them and run off to do inconvenient things, and Tom Cruise would get in a huff, chase after Dustin, fix the mess, and then yell at him, which only seemed to make him curl up into a ball and say weird things repeatedly? That’s what it’s like talking with a computer, except Tom Cruise had it easy.

Because in reality you’re not in dialogue with “the computer”, you’re actually interacting with myriad different tools, little Rain Men, who each have their own idiosyncratic ways of interpreting you and making messes and sometimes doing their jobs. They all have different names for the same things, or or the same name for things that are subtly or wildly different. These programs change significantly over time as their developers release new versions. And they’re not just talking to you, they’re all communicating with each other on your computer, and even on computers on the other side of the planet.

Now, say your name is a Matt and you’ve been a developer for thirty years. You get in on a typical morning, and start to make a coffee (you’ve already had a couple since waking, just working up the motivation to commute). Your manager (who for some reason is called a “scrum master” now) tells you there are these reports coming in from a few different users about weird errors on the website you help run. Which is a bugger, because you spent your commute thinking about the problem you were working on yesterday, loading that whole thing into your brain, and now you’re going to have to unload it and load other stuff, and also anything that’s described as “weird” is usually going to take all day at least to solve.

Immediately you start collecting information. What exactly did these users say? What timezone are they in, and were they on their phone or laptop? Are there errors reported in the log files of any of the computers that might be involved? Can you make the problem occur again, in a controlled way that doesn’t mess with your users? Which parts of the code will be relevant to this problem, and when you eyeball them are there any obvious problems? Have things like this happened before?

These are just some of the questions you can ask straight away, and the answers to each of them themselves raise more questions.

In an ideal world you could ask these questions of an AI and have the answers instantly. We’re not in that ideal world just yet, so you need to do various things on your computer to find the answers yourself. The things that you need to do involve “talking” with many of the little aforementioned Rain Men, by typing and sometimes clicking. The Dustins most familiar to everyone are browsers, and let’s emphasise the plural, because if you think Firefox and Chrome (etc., etc.) have the same ways of telling you about stuff, you’re in for a world of pain, and that’s before you even consider that the thing that calls itself Safari on your Mac is not at all the same Hoffman who lives on your iPhone.

And that’s just browsers. By the end of the day, if it’s a tricky bug, Matt will have talked with different operating systems, shells, HTTP APIs, file systems, “activity monitors” (for want of a better term), window managers, authentication systems, bug trackers, and so on and so forth. Please don’t stop reading if you don’t know what each of those things are, just know that they’re only some of the kinds of tools that Matt needs to know how to work in order to answer questions so that he can stop users complaining. It’s a lot of clicking and typing and knowing exactly what to click and type.

And this is just for debugging! The set of things to know changes when you’re talking about designing and writing new software.

Now, on the day of the weird bug, the real skills that distinguish the decades-of-experience Matt (if he’s worth his salt) are his ability to collate the information from these various Rain Men in his head and start formulating hypotheses and knocking them down one by one until he arrives at what could tentatively be called the truth. This is an application of the scientific method in one of its purest forms, and when you have easy access to the data that you need, it can be an enthralling activity, the kind of thing where you hit lunchtime and you’re hungry but you actually want to keep working because you’re curious, and you’re using the best parts of your brain. You get in flow, and it’s better than the best computer games, and afterwards people pat you on the back and give you money.

But the key part of that previous sentence is “when you have easy access to the data”. Because most of the time it’s not in your head, it’s shared among various incarnations of Dustin Hoffman, and it’s hard to remember exactly how to calm each of them down, and you have to look up the magic words in poorly written manuals or inspect their code, which might be written in a language you’ve never used. It wrecks your flow. You were so close to finding the solution to the puzzle, but then you had to unload everything from your mind and load up the docs for a tool you almost never use.

Become the AI programming assistant we wish we had

Put yourself in Matt’s shoes in the scenario above. What if there was an eager young graduate next to you who knew a bunch of these tools and was willing to type and click for you? Who, when you encounter said tool whose manual you need to re-read, reads the manual and extracts the relevant info while you make a cup of tea and chew over what you know so far? Someone who lifted the cognitive overhead imposed by Dustin Hoffman so you could put those hard-won abstract problem solving skills to good use? A kid who seemed to speed you up rather than slow you down.

It might make the difference between a good day and a bad day, both for you and the users who were getting weird errors.

I wasn’t that ideal eager graduate in that hypothetical scenario, but I eventually became more like him, and it meant that good developers actively wanted to pair with me, and teach me things, and share war stories with me down at the pub. On tea breaks, I’d ask the questions I’d been building up about the higher level aspects of the job. I stored up all of those “but why do it like that?” thoughts I’d had while driving and ask them at a time when it wouldn’t break our flow.

Whenever the person I was pairing with gave me an instruction I didn’t understand (“ssh into the server”) and had to explain it in more explicit terms (“go to the terminal. type in ssh 185.199.109.153. press enter.”) it gave me information about where the gaps were in my driving skills. I didn’t have to ask the question “What should I learn next to be better?” because I was getting hit in the face with answers to it daily.

I could visibly see when I was slowing us down, because my pairing partner wouldn’t be going “hmmm”, looking up at the ceiling and thinking — he’d be waiting patiently (or drumming his fingers irritably, depending on who it was). That was my cue to spend some time later practising, say, my keyboard skills (by the way, classical typing tutors are not the best way to get better at wielding a keyboard in the tech world, but that’s a topic for another time), or learning more about my text editor, or tiling window managers, or keyboard shortcuts for … everything, or all the other ways that could massively speed up my interactions with Rain Men.

It’s famously hard to know if you’re getting better at the high level parts of software design. It takes decades to do it, the feedback loops are long, and no one really knows how to effectively teach it. But osmosis seems to help. You want to get lots of high-bandwidth exposure to people who’ve proven their skills by building valuable, well-maintained complex systems.

And you can get that by taming your ego (I’m still working on that) and doing the less glamorous tasks for these people so they genuinely want you around. It’s not sexy or cool or high status to spend time learning that hitting ctrl-a at the terminal will move you to the start of the line, but if you’re still a fairly junior dev it’s more likely to help you out than reading yet another debate about dynamic vs static typing, or doing yet another Coursera course on deep learning, or even reading the classic books about software design.

And it’s not just about getting more experience to level up faster, it’s a good way to make more money. When you’re not there, you want them to feel like they’ve lost a limb. Amputees are willing to pay a lot of money for prosthetics.

Concerns you might have with the above

No one pairs at my workplace, or at least not with me :(

Convince someone to. Level up your driving skills, ask them politely if you could try driving for them (or if they would mind coming over and helping you code on something), and show them that you genuinely speed them up. If you don’t speed them up, you’ll quickly work out why, and that’ll give you something to work on. Get better, and ask again.

If they’re not even willing to give you a chance to work with them, consider trying to find a different place to work.

I’m a solo coder. There is literally no one around for me to pair with. This advice is useless to me.

Try imagining that there’s two people in your head: the driver and navigator. There’s a good chance that the navigator is bored because you’re taking ages to answer their questions (which might be, e.g. “How does that function look if I split part of it into a seperate function?”). They might start to tune out or start thinking about other things (e.g. I wonder if there’s something interesting on Hacker News?), or they might just give up and not even bother answering the question, and leave your codebase worse off for it.