Continuous Improvement —4 min read
From the message queue:

How can a team of two work in small batches from different timezones?

Code Review —2 min read
"Readability" is subjective

Ask yourself: Will the least experienced developer likely to read this code be able to understand it?

Career Advice —33 min watch
Go Code Roast #2: readability.js port

In this video, I roast a port of a Mozilla Javascript library, readability.js to Go.

Career Advice —33 min watch
Go Code Roast

In this video, I roast some Go code! That is, I review it as if it were submitted as part of a job application screening. I talk about what I like, what I don't like, and how I would do things differently.

Code Review —7 min read
10 Methods for In-Depth Code Review

For many of us, code review is like eating broccoli: We know it's good for us, but we hate it. Here are my 10 tangible tips to improve the value of code reviews, and hopefully make them less distasteful.

Code Review —1 min read
When is a pull request too big?

Smaller pull requests are faster to write and easier to review. Here are 4 tests to see if your PR might be too big.

Code Review —2 min read
The one code review method to rule them all

Find the method that works for you, and don't let anyone guilt you into thinking your way is "wrong".

Code Review —1 min read
Responding to “No code reviews by default”

Every team is different, but one thing is the same: all want to build the best product in the shortest time. There are different ways to achieve this.

Code Review —1 min read
Code review isn't just about code

When you review a pull request, what do you look for? Bugs? Misspelled words? Broken error handling? Missing unit tests? That’s all fine and good. But there’s one aspect of pull request review that I think usually does not get enough attention: Metadata The pull request title and description, as well as the individual commit messages (and each commit’s contents) are all important parts of a pull request, and deserve attention during a review.

Code Review —2 min read
Can pair programming replace code review?

It’s almost inevitable that when I participate in a conversation about pull requests and code review, someone suggests pair programming as an alternative. For those unfamiliar: Pair programming is an agile software development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer or navigator, reviews each line of code as it is typed in. The two programmers switch roles frequently.

Code Review —2 min read
Pull requests aren't about mistrust

Lately I’ve seen several people reacting against the idea of pull requests, on the basis that pull requests are a mechanism to safeguard against untrusted code. Consider this post from LinkedIn: [Pull requsts are] about distrust. Apparently people don’t trust their team mates to do the right (enough) thing. A similar sentiment can be found in Kief Morris’s article Why your team doesn’t need to use pull requests. I’m willing to accept as granted that pull requests can be useful in low-trust situations, such as vetting code changes from a stranger on the Internet.