Want to be a better teammate? Want to get your work merged faster?

For a lot of devs (especially newer ones) the important part of a PR is the code, not the PR itself. However, the way commits in a PR are put together to guide another dev through the review can be massively impactful. This talk looks at how to effectively craft that review experience.

Aims of a PR

At a superficial level, the aims of a PR are to get code checked for bugs, and to allow it to get merged and deployed. On a deeper level, it's also where a lot of mentoring and learning happens. I will make the argument that both of these are massively improved by ensuring one thing: the PR is crafted for the convenience of the reviewer.

Specific tips

I'll then look at some of the specific processes and tips that I've found most useful when putting together PRs. These include creating modular commits, laying the groundwork at the start of the PR, how to best comment the code, using conventions and automatic formatters, and reviewing your own PRs.

Dealing with feedback

Finally I'll look at how to deal with feedback. This will touch on both the human aspect of getting feedback, as well as how to best show changes made in response to comments.