intro-to-pair-programming.Rmd

---
title: Introduction to pair programming
output:
  beamer_presentation:
    theme: metropolis
---
```{r config, include=FALSE}
library(knitr)
opts_chunk$set(echo=FALSE, message=FALSE, results=FALSE, cache=TRUE)
read_chunk("R/mythical-man-month.R")
read_chunk("dot/pair-programming.gv", label = "pair-programming")
```

# What is pair programming?

```{r pair-programming, engine="dot"}
```

# Why pair programming is terrible

- Coding in front of someone else is terrifying.
- Typing on someone else's computer is frustrating.
- Explaining everything takes too much time.
- Watching and understanding nothing is a waste.

**We think pair programming is terrible because we think it is inefficient.**

# Why pair programming is worth it

- Pairing is a customized learning environment.
- Interactive learning is better than passive.
- Pair programming solves "unknown unknowns".
- People over processes ([Agile Manifesto](http://agilemanifesto.org/)).

# Agile principles relevant to pair programming

- "Welcome changing requirements, even late in development."
- "Build projects around motivated individuals."
- "Working software is the primary measure of progress."
- "The best architectures, requirements, and designs emerge from self-organizing teams."

# Productivity in programming

**It's not what you think it is!**

1. The mythical man-month
2. The cathedral and the bazaar

# The mythical man-month (Brooks, 1974)

```{r brooks-1974-cover}
crotchet::draw_image("img/brooks-1974-cover.png", height=0.3)
```

# The mythical man-month (Brooks, 1974)

```{r mythical-man-month}
```

# The cathedral and the bazaar (Raymond, 2001)

```{r raymond-2001-cover}
crotchet::draw_image("img/raymond-2001-cover.png", height=0.3)
```

# Is pair programming actually inefficient?

## Strengthening the case for pair programming

Williams, Kessler, Cunningham, & Jeffries (2000). _IEEE Software_.  

> Teams solved problems faster than individuals with better algorithms and with higher satisfaction.

## Evaluating pair programming with respect to system complexity and programmer expertise.

Arisholm, Gallis, Dyba, & Sjoberg (2007). _IEEE Transactions on Software Engineering_.  

> No overall gains in productivity, but junior programmers were better able to solve complex problems, and senior programmers were faster at solving simpler problems.

# Madpy Pair Night

```{r pair-night-logo}
crotchet::draw_image("logo.png")
```

# Why come to Pair Night?

* **Student-Teacher.** To learn something you don't already know, or practice a skill you need to improve.
* **Teamwork.** To do something together you could not have done on your own.

# Goals for pairs

* **Student-Teacher.** Student learns from Teacher, Teacher gets better at teaching ([rubber duck debugging](https://en.wikipedia.org/wiki/Rubber_duck_debugging)).
* **Teamwork.** Teammates play to each other's strengths and accomplish something together.

# What are we going to work on?

## Pairs should be working to solve some problem.

"Working software is the primary measure of progress."

* **Practice problem.** Take a problem off the shelf together.
* **A real problem.** Work on a problem that will be used beyond the Pair Night.

# Practice problems

- [Exercism.io](https://exercism.io)
- [Advent of Code](https://adventofcode.com/)
- [Nifty assignments](http://nifty.stanford.edu/)
- [Code golf](https://codegolf.stackexchange.com/)
- [Kaggle competitions](https://www.kaggle.com/competitions)
- Example project (e.g., from a book)

# Real problems

- Find the expert!
- GitHub issues
- Make a thing you both want to exist