Peer Review Everything
As software engineers, we should be comfortable getting and giving feedback on code. Feedback can challenge our approach, our preconceived ideas, and expose us to new viewpoints. Peer review forces us to explain our thinking and examine our assumptions. It prevents us from delivering sloppy work and makes us all better developers.
There are no limits on what can be reviewed
On all of Kilterset's projects it's a requirement that at least one person reviews code before merge. After years of cultivated practice, become an ingrained habit for us. We make a point of teaching new hires how to give good feedback too. Skills cultivated during code review are not limited to the development process.
The Kilterset team writes a lot. We write internally & externally. You may be unsurprised to learn that we peer review this work too. And guess what? It improves the end result. Reviewers find spelling mistakes, suggest better phrasing, funnier lines, and help ensure the content is clear. We've found improvement through peer review to be true time and time again no matter what the subject – ideas, code, mockups, interpersonal interactions, plans, meetings, presentations, decisions, wiki pages, and blog posts to name a few. I bet you can think of a time where you had a candid conversation about something you were working on and a peer steered you to a better result. That is the outcome we strive for in all things.
A habit to cultivate
Make asking for feedback a habit, and watch the quality of your work improve. For our team members, almost everything we do is shared with at least one other person first. The earlier the feedback the better. The more frequent the better. Often times, we find the only regret we have is when we don't ask for review. Peer review isn't just for code, it's a universal tool that can improve any work.
And when somebody asks you for feedback – make time for it. Reciprocate. Learn how to give non-judgemental feedback. Learn how to accept it, too. Go deeper when you get conflicting feedback and seek to understand the thought process. Build trust in reviewing each other’s work.
Try for a minimum of two pieces of feedback
Not everyone is used to giving feedback. We've found this to be especially true when asking for feedback in a context that a person may not be used to providing. Blog posts are a good example. Some people struggle to give feedback, feeling more comfortable with a code base or a presentation. If your reviewer is having trouble, try scoping the problem for them. For example: “What do you think about this area? Does this makes sense? Can you think of another way I could do this?” Or you can simply ask, “Can you think of at least a couple of ways I can improve this?” Nothing is ever perfect, though, and there are always improvements that can be made, even if it's only a couple of minor tweaks.
Give it a shot. Peer review something you haven’t previously asked for feedback on. You may just find a new insights from familiar places.
