{"success":true,"data":{"title":"Getting Started With Code Reviews","slug":"getting-started-with-code-reviews","excerpt":"Advice for junior developers on building confidence in code reviews. Covers common misconceptions about what reviewers are responsible for, what code reviews actually are — collaborative discussion, an opportunity to learn, a tool for catching bugs before they reach production — the 30/60/90 feedback framework for giving the right kind of feedback at the right stage, and why asking for clarification on code you don't understand is one of the most valuable contributions a junior reviewer can make.","has_code_sample":false,"published_at":"2022-12-07T14:45:00.000Z","content":"\u003cp\u003eI’ve had a consistent question from most of the junior developers I’ve worked with — it centres around code reviews. When you’re relatively new to software development, commenting on someone else’s work, especially when they’re more senior than you, is intimidating. How can you be helpful in code reviews when you’re just starting your development career?\u003c/p\u003e\n\n\u003cp\u003eI wanted to share some things I, and the various people I’ve worked with, have found helpful. If you’re reading this as someone struggling to review other people’s code, I hope they can help you in some way.\u003c/p\u003e\n\n\u003ch2 id=\"know-what-code-reviews-arent\"\u003eKnow what code reviews aren’t\u003c/h2\u003e\n\u003cp\u003eIt helps to clarify what code reviews are not (and conversely — what they are). Remember that code reviews are not one developer taking responsibility for another’s work. This thought gets in the way of people reviewing work because “what if I miss a glaring security hole or a bug”?\u003c/p\u003e\n\n\u003cp\u003eFirstly, I hope you’re learning to write code at a place that uses mistakes as a learning opportunity. Being in a supportive environment can help build comfort with this one. Learning is what being a junior is all about, and mistakes are a great way to learn — seniors make them all the time too. Trust me.\u003c/p\u003e\n\n\u003cp\u003eBut let me ask you a question — when you approve a piece of code do you expect to take credit for its positive outcomes? If not, should you anticipate taking responsibility if something goes wrong?\u003c/p\u003e\n\n\u003cp\u003eReviews are also not tests, and you aren’t getting judged on whether or not you know something. It’s OK to admit you don’t understand something and ask for clarification. It’s easy to overthink and not question or make a suggestion because you think your peers will judge you for not knowing something. Admittedly this behaviour can be challenging to overcome, but try to be mindful of it and get into the habit of asking or commenting anyway. One practical way of helping with this is to start by talking privately with another trusted developer on your team — their reaction will help build confidence that it’s OK to ask.\u003c/p\u003e\n\n\u003ch2 id=\"know-what-code-reviews-are\"\u003eKnow what code reviews are\u003c/h2\u003e\n\u003cp\u003eCode reviews invite discussion from everyone on your team, no matter geographical location, timezone or accessibility requirements. They are an effective way to discuss approaches, spot edge cases and squash bugs before they make it to production. Reviews allow contextual discussion and provide specialized tools to explain thoughts (GitHub’s code suggestions are a great example of this).\u003c/p\u003e\n\n\u003cp\u003eThey’re a second brain giving code extra consideration. They provide an opportunity for quality assurance, to spot issues to address, clarify any unclear code and discuss the approach taken.\u003c/p\u003e\n\n\u003cp\u003eThey help businesses meet security requirements. For example, ISO 27001 is “\u003ca href=\"https://www.iso.org/isoiec-27001-information-security.html\"\u003ethe world’s best-known standard for information security management systems\u003c/a\u003e”. ISO 27001 describes having “secure system engineering principles”, and whilst it’s not a specific requirement, code reviews can be considered a contributory factor.\u003c/p\u003e\n\n\u003cp\u003eCode reviews are not only for providing constructive criticism — comments can praise clever solutions too. They’re a way of letting someone know that you like what they’ve done, perhaps that it’s helped you or taught you something.\u003c/p\u003e\n\n\u003cp\u003eMost importantly, code reviews are a huge chance to learn. Some of the most valuable improvements to how I approach and write code have come from the feedback I’ve received in reviews, and \u003ca href=\"/2019/11/new-job-new-programming-language\"\u003ethey were invaluable when I changed the programming language I was using\u003c/a\u003e.\u003c/p\u003e\n\n\u003ch2 id=\"give-the-correct-feedback-at-the-proper-time\"\u003eGive the correct feedback at the proper time\u003c/h2\u003e\n\u003cp\u003eThe \u003ca href=\"https://blog.trello.com/avoid-the-seagull-effect-30/60/90-feedback-framework\"\u003e30/60/90 feedback framework\u003c/a\u003e helps guide the kind of feedback an author seeks, and it’s a tool for both those seeking and giving feedback. As a brief overview of what these different stages are:\u003c/p\u003e\n\n\u003cul\u003e\n  \u003cli\u003e30% is for feedback on the approach itself. At this point, you have a good idea of how you’d like to solve the problem, but you’d like other thoughts to avoid any later course corrections.\u003c/li\u003e\n  \u003cli\u003e60% is for when you’ve finalized the approach, and a draft of the implementation is ready. You’re looking for things you’ve missed, potential improvements or alternative methods.\u003c/li\u003e\n  \u003cli\u003e90% is for final tweaks and seeking final approval. It’s the last feedback step, and at this stage, all of the feedback you received at the 60% stage will have been addressed.\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003cp\u003eWhen doing a code review, use this kind of language to understand the feedback you should be giving. Ideally, this will come from the code’s author (perhaps using labels) — if it doesn’t, then there’s no harm in asking.\u003c/p\u003e\n\n\u003cp\u003eGiving the right kind of feedback at the right time is essential. Imagine you’re at the 90% stage, and it’s decided the approach needs to change. You could have to re-work everything you’ve done. It’s hard to receive that feedback as the author; it’s difficult to give it too. That doesn’t mean you shouldn’t — it can be unavoidable — but always try to avoid it by feeding back (and asking for feedback) early and often.\u003c/p\u003e\n\n\u003ch2 id=\"ask-for-clarity\"\u003eAsk for clarity\u003c/h2\u003e\n\u003cp\u003eCode reviews are not just for enabling more experienced developers to provide feedback on more junior developers’ software. Juniors can and should give feedback in the other direction, which can significantly improve the code. We’ve already said this, but — when reviewing code, you should ask if you need clarification about what a piece of it does or how it works. There are many reasons why asking questions about things you don’t understand is a good thing to do; for code reviews, I want to pick out two key reasons:\u003c/p\u003e\n\n\u003cul\u003e\n  \u003cli\u003eIt’s an opportunity to cement some understanding.\u003c/li\u003e\n  \u003cli\u003eIt could result in more readable code.\u003c/li\u003e\n\u003c/ul\u003e\n\n\u003cp\u003eOccasionally we all need help understanding a piece of code. We pick up ways of writing software that we know but may still be unclear to others. Asking for clarification will, at worst, teach you something new. Still, it may prompt a rewrite to more self-documenting code, improving it for everyone.\u003c/p\u003e\n\n\u003ch2 id=\"encourage-discussion\"\u003eEncourage discussion\u003c/h2\u003e\n\u003cp\u003eAsking for an explanation of code you need help understanding will invite discussion, which will (sometimes) act as a prompt to make changes. That’s what a code review fundamentally is — a discussion. As a junior, you can encourage discussion because of your fresh viewpoint. You don’t have years of habits subconsciously biasing the work software you write, and you can use that to help all of your colleagues. The perceived reasons for not being able to contribute to code reviews are the best reasons to do so.\u003c/p\u003e\n\n\u003ch2 id=\"in-summary\"\u003eIn Summary\u003c/h2\u003e\n\u003cp\u003eGetting into the habit of doing code reviews and building confidence in your ability to do them takes a lot of work. Still, I’d encourage you to keep trying. Start small if it helps, lean on the developers around you to build that confidence and make sure, as much as possible, to give the proper feedback at the right time. It will get more accessible, and you, and the people you work with, will be much stronger developers because of it.\u003c/p\u003e\n","tags":["Code Reviews","Juniors"]}}