I have a pretty serious fear of public speaking.

I start yawning a lot. My heart rate becomes elevated. I'm pretty sure my face turns red. It's gotten a lot better with age – but still, it's not great.

Anyway.

About two years ago, while I was working at Aereo, I had the enlightened idea that we should start doing a Lunch & Learn once a week. I sent out an email to see if anyone was interested, and the response was overwhelmingly positive.

I'm sure you can see where this is going.

Since I was the one who made the suggestion, it was decided that I should present first.

Now, this was going to be a relatively small group of my peers. Maybe 20 people or so, most of whom I had know for about 2 or 3 years. To call this "public speaking" would be a stretch, but still, I was kind of nervous about it.

A little bit of context

I had recently participated in AngelHack Boston with some people I "met" on Twitter, and it was my first real exposure to using pull requests on a project. The other guys on my team were all at the same company, and they used PRs for everything at work – so we adopted them on the hackathon team as well.

The process really struck a chord with me, and I was curious how it might work for my team at Aereo. So I decided to pretend like I had some sort of authority on the matter, and I chose pull requests as my Lunch & Learn topic.

Nope. Nope nope nope nope nope.

The day of my little presentation arrived, and I remember sneaking into the kitchen to grab a beer from the fridge about 30 minutes before we were supposed to get started to calm my nerves. It didn't really work.

Eventually, everyone packed into the conference room, pizza in hand. Waiting.

I took a deep breath, tried not to make eye contact with anyone, and got started. At the time, I has almost zero actual experience with pull requests. So everything I said over the next 40 minutes was, shall we say, "speculative".

#aintsobad

About 5 minutes into my talk, I started feeling more comfortable. People seemed genuinely interested. A couple of them laughed at my bad jokes. Questions were asked and answered. The conference room was filled with the smell of slightly above-average pizza.

I was gaining confidence.

Pull Requests are a way to start a discussion about new code

That was my thesis. I repeated it several times, with a level of conviction that I think is unique to people who are completely and utterly full of shit.

BUT HERE'S THE THING.

It's now two years later, and I think I was actually right.

Why I wasted your time with that dumb story

I'm about to list a few of the reasons why I think your team should use pull requests. These are the exact same things that I wrote in my slide deck two years ago. When I had pretty much never used pull requests before.

My point is: most of these reasons are actually kind of obvious if you take a minute to think about them. They just make sense. You can imagine a scenario where your team begins using pull requests, and intuitively, you know these things are likely to happen.

But still, here you are. Reading this article. Not using pull requests.

So I'll leave you with the same points I made in my bullshit presentation two years ago. Except now, I know they're true.

Discussion

At their core, I think pull requests are just a way to start a discussion about code. Or at least that's how I'd encourage you to think about them.

But why is talking about code a good thing?

ALLOW ME TO TELL YOU...

Learning

Pull requests give the engineers on your team an opportunity to receive constructive feedback – which is a really, really efficient way to learn. I noticed pretty dramatic changes in the overall quality of code being submitted within about a week from when we started using PRs at Aereo. And things just kept getting better and better.

Ownership

At Aereo, we had a rule that any member of the team could merge a PR except for the person who submitted it. This meant that everyone was responsible for reviewing new code, not just leads.

This greatly increased the sense of collective ownership over the codebase. It set an expectation that all new code needed to meet a certain standard, and my experience was that people actually took that pretty seriously. In a way, the codebase almost became a thing to be defended. It was something we were all proud of, and we wanted to preserve the level of quality we'd been working toward.

Shared Knowledge

I think this one is really important.

As engineers, we have a tendency sometimes to carve out little niches for ourselves. We put our headphones on, tune everything out, and we work on "our part" of the code.

And a lot of the time, we end up with an app that's basically 3 or 4 different apps all mashed together. Nobody knows how the "other parts" work.

When you embrace pull requests, you force people to review code that they may not have otherwise been exposed to. As a result, you end up with a lot of overlapping knowledge.

Wrap-up

If you're interested in using pull requests on your team, here are some basic "rules" to try out. Keep what you like, and drop the stuff you don't.

1. All new code must be submitted via pull request.
2. Every PR must contain tests and documentation (when applicable).
3. A pull request can be merged by any member of the team except for the person who submitted it.
4. Each pull request must include a meaningful description.
5. Large PRs or PRs with breaking changes should be approved by multiple team members or a lead. We use checkboxes in the description for this.

The important thing is to just try it. Call a quick meeting with the whole team, explain what you want to do, and do it.

I guarantee you'll be super glad that you did.

Follow me on Twitter or Medium for more posts. I'm trying to write once a day for the next 30 days.

And if you're in the Boston area and want to come submit pull requests and work on crazy, top-secret things with me at Project Decibel, shoot me an email. I'm hiring.