Reading Time: 7 minutes

I’ve YouTube-coded a fair amount of feature development in the past. This time I thought we’d try out something different—a fun-filled debugging session with Avdi Grimm and Jessitron.

*Wait, I’m lost. What are we doing? Read about why I do live coding.

We’re debugging a cluster of socket servers that I have summoned from the code ether in an attempt to implement Raft (more on that over here). I think this recording demonstrates some great moments in pairing, debugging, and general foolishness; we had a lot of fun, and I’d definitely do social programming recordings in the future.

In this post, you’ll find:

1. An embedded coding video. Almost three hours. It’s awesome.
2. A link to the commit on github with the changes we made, so you can review the code yourself.
3. An outline of the topics we talk about in the live stream, with links to time stamps on the video.

You can also get a transcript or closed captioning for either of these live streams.

In this post, I explain how you can get those things in one or two clicks on YouTube.

Here’s the Video:

Outline: What we cover in this live stream

0:01 – “But we’re going to curse.” Luckily my 3 hour programming videos aren’t popular with children 😂. Shortly thereafter, I provide an introduction: who I’m pairing with, and what we’re pairing on.

6:30 – Sharing context. I explain what I have implemented. Then I demonstrate. Notice the questions Jess asks as I do this. She uses the clues I have provided so far to direct an investigation of the system, where I am the witness. She isn’t waiting for me to pass her the context; she participates in the transfer process by pulling context from my side of the screen to hers. It’s an extremely efficient way to quickly build a thorough understanding. We practiced a similar skill when we learned about active reading.

18:02 – I did not know this about the word “log.” Jess explains what the term “log” typically denotes, and then Avdi offers another word that more closely models the thing we’re trying to build: a “journal.” As it turns out, the Raft paper uses the term “log” to describe a different thing than programmers usually mean when they say “log.” This example leads to a wider discussion about naming things, with highlights including:

• Why the most insidious bugs are often one-line fixes
• A bug hunt story from Philosophy of Software Design, by John Ousterhout
• The role of names in building and curating our understanding of code
• The risk of hiding a poor name among a bunch of good ones
• Advice for naming things that we don’t fully understand yet
• The role of code review in naming things

In fact, if you only listen to one section from the whole recording, I recommend this one.

23:45 – We’re talking about this post on code review. Jess explains what she hates about code reviews, and we briefly discuss comments in a more general capacity.

36:30 – Avdi drops some knowledge on socket servers and states a hypothesis as to why the exceptions might be happening. Then we examine some variables and scopes, and Jess recommends a default assignment to see if that addresses our problem.

Listen closely to what you hear in this section. “My hypothesis is…”, “I’m asking myself two questions…,” “Yes, I know that part, but what confuses me is…”

In my experience, there are three hard things in pair programming:

1. Overcoming the fear of revealing your technical shortcomings to your pair
2. Bridging an institutional power gradient
3. Resisting the urge to go silent when you’re at the limit of your understanding.

We’ve talked about that third one before in this post on remote pairing:

Orate your thoughts and actions to a degree that feels ridiculous. If you have never seen this modeled, turn on the Food Network on TV. Take notes on how the TV chef explains every single thing they do. Notice how they don’t stop talking even for the little things, like shaking paprika onto the dish or sticking a pan in the oven.

It’s the same for programming: talk through every variable and every loop. Orate your reasoning for naming your method this or that.

Conversely, when the decisions get more complex, speak your thoughts out loud. This one is my Achilles heel: as the task approaches the limit of my current understanding, I fall silent to think. You can pause to think, but then explain what you thought. You preserve context when you talk.

This section of the video shows you programming-specific examples of developers talking to each other while developing an understanding of the code.

45:00 – Avdi teaches me something about StdOut and StdErr. Maybe it’ll be new for you, too!

1:06:48 – Starting a Debugger in PyCharm. This is not as straightforward as it could be, but you get to see us go through the whole process (in between me sometimes clicking the wrong buttons…whoops)

1:32:00 – This is the part where Jessitron catches an issue I had been glazing past, leading to the following tweet:

Dear @jessitron,

The connection closing exceptions have not been resolved. However, it appears your discovery about reassigning the client connection variable has fixed at least one issue…

The logs replicate reliably to as many servers as I want 🙂

cc @avdi

— Chelsea Troy––Yes, That One 😉 (@HeyChelseaTroy) December 27, 2019

1:41:00 – Investigating processes! You can check out this part to learn about console commands for examining your processes and navigating texts (like documentation).

“It’s all spells, man.” – JessiTRON

1:48:30 – We’re talking about IDEs (“editors”). Because what programmer jam session would be complete without this part?

2:01:00– We learn lsof together.

Avdi: “[Put a] space between the ‘i’ and the colon.”

Me:

2:06:50 – We go over the rules for Python indentation. They’re not quite what we usually imagine them to be.

2:24:40 – Avdi recommends books to read (Volume 1 in each of 3 series). Even more importantly, he recommends books to skip (the other volumes in these series). In my experience, some of the most valuable advice I have received has to do with which things aren’t worth my time.

2:31:45 – Avdi reveals how to use thick programming reference books: 

“I mean…I didn’t say I’ve read it. But when I’ve needed to look something up in there…the documentation is so much better than the manpages.”

New For this Live Code

1. I’m not alone! I have done most of my live coding solo so far. I think that both the topic substance in this recording as well as the tangents benefited from having a couple more voices in the conversation. I’d love to do more social coding streams in the future.

That’s it for this session, y’all. See you soon!

If you liked this piece, you might also like:

This post on my entree into live coding (plus, how to get a transcript of a YouTube video)

This talk about the technology and psychology of refactoring—in which you’ll hear me explain some of what you see me do when I code.

This 3 part series about time and space efficiency—In which I approach the topic of performance from the perspective of a code sample. Why make things fast? Why make them take up less space? And how do we evaluate the tradeoffs?