The First Rule of Pull Requests
It's not 'don't talk about pull requests'
Today at a Glance
The First Rule of Pull Requests
Poll of the Day
The programming antihero
The First Rule of Pull Requests
Introduction
I’ve got a secret for you: regardless of how senior or experienced a software engineer is, they are not immune to silly or embarassing mistakes.
You know the kind of mistake I mean. The ‘I don’t know how that got there’ kind of mistake that instantly results in you adding another commit to the pull request.
So the question is, if experienced engineers are not immune to silly mistakes, how can it seem like they’re faultless?
Why it matters
Silly mistakes are nothing to be embarassed about! Look I’ve fixed it already! This might be the response from a frenetic, busy engineer.
However, being silly or embarassing isn’t the point. We should not be in the business of shaming colleagues. What we are in the business of is being respectful of colleagues’ time.
So really the ‘I’ve already fixed it’ response is a hollow one. By that point the code reviewer has already had to expend their time and attention.
How to apply it
The first rule of pull requests is this: read your own pull request! Before you even submit the pull request for review, go over it line by line.
On top of identifying any silly mistakes, ask yourself if the code meets your own standards. Are you proud of this code? Is it ready for review?
So to answer the question in the introduction: experienced engineers are not immune to silly mistakes, however, they are much more adept at identifying them before someone else does.
Do you have a question on this article or a topic you’d like me to write about?
Poll of the Day
Bonus Link
The programming antihero - one of my favourite gamedev stories (don’t do this)
Thank you for reading Paul Codes. If you know someone that would enjoy this newsletter feel free to forward it or refer them. Referrals earn rewards.
PS. If you’re a business and would like to sponsor this newsletter, please reach out!