As a team grows, code ownership is distributed. Code review becomes increasingly important to support the maintainability of complex codebases. An effective code base is on that can be worked on collaboratively by a team.
In this talk we'll discuss how to introduce a successful code review culture to your development team that will foster the idea of shared ownership. This in turn will result in a happy and healthy code base.
https://webexpo.net/prague2016/talk/how-to-successfully-grow-a-code-review-culture/
10. Find Design Flaws
& Bugs
So they can be identified and remedied before
the code is complete
Case Studies on Review:
➡ bug rate by 80%
productivity by 15%
https://blog.codinghorror.com/code-reviews-just-do-it/
11. The goal is to find bugs
before your customers do.
12. Shared Ownership
We’re all in this together
👀 results in positive motivation
Overall increase in code quality
13. Shared Knowledge
No developer is the only expert
Developers gain familiarity with
different modules via review
Decrease the “Bus Factor”
25. Feature Branches?
Feature branches are merged into a
development branch, not master.
We can QA in a staging
environment that mimics production
When necessary, we can hotfix
master
27. It starts with a
Commitment
Make a commitment to always Review before
Merge
Present the Facts
Don’t force it
New ideas take time to root
28. Code Reviews need to
be Universal
Doesn’t matter how Senior / Junior you are
Only Senior Devs reviewing == bottleneck
Inequality breeds dissatisfaction
Break down old barriers and status quos
30. Consistent Code
Your code isn’t yours, it belongs to your
Company
Code should fit your company’s expectations
and style, not your own.
Reviews should encourage consistency for
code longevity
31. Style Guide
Distinguishes personal taste from
functionality
Should be agreed upon before hand
Great codebases are written by a team, but
look like they were written by an individual
33. No Blame Culture
Failure is inevitable
Mistakes become team, not
individual responsibility
Needs management support
34. Blameless Post Mortems
Meet shortly after Incident Resolved
Understand the root cause
Document how it was fixed
Identify how to prevent it in future
36. “
When code reviews are part of the
culture, people don’t expect their
changes to be reviewed, they want
their changes to be reviewed.
https://www.caktusgroup.com/blog/2014/07/28/culture-code-reviews/
51. Don’t be a Perfectionist
For big issues, don’t let perfect get in the way
of perfectly acceptable.
Prioritize what’s important to you.
Usually 90% there is good enough.
52. It’s OK to Nit-Pick
Syntax Issues
Spelling Errors
Poor Variable Names
Missing corner-cases
53. It’s OK to Nit-Pick
Save the nit-picks for last, after any
pressing architecture, design, or other large
scale issues have been addressed.
54. Avoid Burn-Out
Studies show reviewer should look at 200-400
lines of code at a time for maximum impact
https://smartbear.com/learn/code-review/best-practices-for-peer-code-review/
57. Define Done
Let the submitter know if you approve, or if
they need to make changes.
Use consistent language
LGTM or Changes Requested
Follow up when the submitter says they fixed
something
58. Have Empathy
Watch your Language
Have Clear Feedback
Give Compliments
Don’t be a Perfectionist
How to be a Great Reviewer?
67. Provide Context (The Why)
Link to the underlying ticket/issue
Document why the change was needed
For larger PRs, provide a changelog
Point out any side-effects
68. YOU are the
Primary Reviewer
Review your code with the same
level of detail you would give giving
reviews.
Anticipate problem areas
69. The Primary Reviewer
Make sure your code works, and is
thoroughly tested.
Don’t rely on others to catch your
mistakes.
74. You’re starting a
conversation.
Don’t get too attached to your code
before the review process
Anticipate comments and feedback
Acknowledge you will make mistakes
76. Submit Work in Progress PRs
Necessary for bigger features
Open them your code is 30-50% done
Don’t be afraid of showing incomplete,
incremental work
This is the right time to get feedback on bigger
issues with the code
77. When Code is Work in Progress
Feedback to expect:
Architectural Issues
Problems with Overall Design
Design Pattern Suggestions
79. When Code is Almost Done
Feedback to expect:
Nit Picks
Variable Names
Documentation & Comments
Small Optimizations
80. One Review per Issue
Solved an unrelated problem? make a new PR
with a separate diff
If you’re solving multiple problems, break
them up into multiple PRs for ease of review.
You can branch off your feature branch to
keep the diff small
81. Prevent Reviewer Burnout
Remember, reviews lose value when they’re
more than 500 lines of code.
Keep reviews small and relevant.
If submitting a big review is unavoidable, give
the reviewer extra time.
https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/bosu2015useful.pdf
90. Be Responsive
Reply to every comment
Common Responses:
Resolved
Won’t Fix
If you won’t fix, make sure you’ve come to a
mutual understanding with the reviewer
91. If there were comments, let your reviewer
know when you’ve pushed changes and
are ready to be re-reviewed.
It’s still a Conversation
100. Newbies
Not everyone has experience being reviewed.
Remember what it felt like when you
introduced the process.
Ease into it!
101. On-boarding
Start by reading recently completed reviews.
The first submitted review is always the
hardest
First review should be small.
Share the style guide
102. Everyone’s a Reviewer
Junior devs start by doing pair-reviews with a
more experienced teammate.
Use it as a mentorship opportunity.
“When your team succeeds, you succeed.”
103. “
Hiring senior engineers is hard. You
can hire junior engineers, and grow
them into functional productive parts
of your team.
Sasha Laundy
http://blog.sashalaundy.com/talks/asking-helping/
104. If you’re not doing code reviews,
you’re missing a big
opportunity.
105. Remember…
Allocate the time
Develop, don’t force the culture
Not one size fits all
Or a one stop fix
Use in addition to tests, QA, etc for maximum
impact
111. Resources & Additional Reading
Microsoft Study on Effective Code Review
https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/
bosu2015useful.pdf
Code Reviews: Just do it
https://blog.codinghorror.com/code-reviews-just-do-it/
Code Project - Code Review Guidelines
http://www.codeproject.com/Articles/524235/Codeplusreviewplusguidelines%20and
Great Example Checklist
http://insights.dice.com/2012/10/31/whats-on-my-code-review-checklist/
Best Practices for Code Review
https://smartbear.com/learn/code-review/best-practices-for-peer-code-review/
112. Resources & Additional Reading
Rebecca's Rules for Constructive Code Review
https://storify.com/ReBeccaOrg/rebecca-s-rules-for-constructive-code-reviews
My Big Fat Scary Pull Request
https://medium.com/@jdan/my-big-fat-scary-pull-request-2c8ac394540e#.yhs96vbxu
Hacker School Environment & Social Rules
https://www.recurse.com/manual#sec-environment
114. Credits
Special thanks to all the people who made and
released these awesome resources for free:
Presentation template by SlidesCarnival
Editor's Notes
Hi everyone! My name is Nina Z-
I’m a developer at braintree, and I’m particularly passionate about code quality and developer productivity
- You’re going to walk out of this room today knowing how to successfully grow a code review culture
- Before I start, I know there are designers in this room.
- Please know that I am not one of you. If my slides make you cry, please don’t throw tomatoes at me until the end.
- Firstly, Who’s the target audience?
both team leaders and developers.
Today, I’ll talk about: [*]
why we review [*]
what the benefits are [*]
i’ll tell you more about my process [*]
and we’ll learn how to grow and nurture a review culture
next, I’ll give specific examples of how to be an effective reviewer, [*] and an effective submitter [*]
lastly, I’ll share how to use these tools to build a stronger team
This talk is not one size fits all - I’m offering suggestions - You need to Adjust them to your work situation.
What are Factors?: [*] [1] team size - taking the time to review will affect a team of 2 much greater than a team of 10
[*][2] product type - if you’re an agency, you might have tighter deadlines, more incentive to try to just push code out the door.
[*] [3] What is defect tolerance? The rate of failure that’s acceptable in your software
[3] if you’re dealing w: money? medical equipment? you should have a lower defect tolerance than a web app or a game
- First, we should answer the question
- why should we bother with code review?
- On the surface, the code review process can appear really frustrating.
- Just Look at this developer.
- She is so angry at the idea of reviewing code that she’s eating her laptop!
What are some apparent code review frustrations[*]
[1] adds a time demand. this is especially noticeable on a smaller team [*]
[2] it adds process. everyone hates process, right?[*]
[3] the review process can bring up hidden tensions between team members, and can flare up egos. smart devs think they don’t need to be reviewed
- How do you get people to change the way they work?
- Inspiring change is always difficult.
- People get comfortable in routines.
- If you don’t already code review, how should you go about introducing the concept?
Start by selling the benefits.
in the short term frustrations are inevitable
When you first start, expect things to be slow going.
But, In the long term it’ll make your life easier.
Like with all things, the more practice you have the better your velocity will be over time
I’ve been on a team with reviews for over a year, it took 2+ months until it became 2nd nature for me
What’s the biggest benefit?
Design Flaws & Bugs can be found and fixed before the code is done [advance]
Multiple Case studies from IBM, AT&T Microsoft, have shown
code review can lower bug rate by up to 80%
increase productivity by up to 15%
- The goal is not to show off who’s smarter.
- The goal is to save face, and find bugs in your software before your customers do.
Reviews help us feel a sense of shared ownership.
It reminds us that we’re all in this together
When I know someone will be looking, it motivates me to write better code
This positive motivating pressure results in an increase in code quality
Reviews also help us share knowledge through the team
As a developer, you can gain familiarity with different parts of the code base by doing reviews
It also decreases the bus factor
what is the bus factor? [advance] measurement of how much specialized knowledge belongs to any individual team members
if the bus factor is too gruesome, think of the lottery factor instead.
who’s heard?“only alice works on the code for the authentication system. no one else understands how it works so they don’t want to touch it in case it breaks ”
how to Measure? [advance] in your mind, go through each person in your team and ask yourself “can the project still go on if they stopped coming into the office tomorrow?
think about what happens when alice wins the lottery
- Code reviews leave behind a paper trail
- A review can generate a wealth of knowledge about why a particular decision was made.
A good code review tool will let you review comments and dialogue that were left before a merge.
That lets you go back and answer the question “Why was a particular decision made?”
What are the benefits of code review?
we can find more bugs faster
we share ownership in the product
we share knowledge about our code
we reduce the bus factor
and we leave a paper trail about decisions
It’s not just anecdotes.
I’ve worked as a dev for many years. I used to think I knew it all.
Then I started at a company with a great review culture
as a result, i’ve grown into a better programmer
because there’s always an opportunity to learn from others
- I started anticipating what a reviewer might point out, before even getting to the review process.
Let me give you a little more insight into our process
We use github enterprise
you might hear me use the terms ‘review’ and ‘pull request’ interchangeably. [advance]
But be aware that many other tools exist. [advance]
I used to have reservations about Reviewing code on pull requests
Lucky for us, github announced new review tools in september of 2016
- Now instead of just commenting on a pull request, you can open a Formal Review.
- This lets you set a status of “approved” or “changes requested” to pull requests.
They added Threaded Inline Comments!
When multiple comments were created for one line of code, it made them really hard to track.
This is was of the most requested features of pull requests
administrators can now require Reviews before merging for protected branches.
When Reviews are required, you must have at least one approval and no outstanding requested changes before you can merge.
make feature branch
*hack hack hack* do the work
open a pull request in github
1) assign a reviewer. usually ask in slack channel, someone volunteers
2) that person completes the review, says they’re done
3) when the review is complete (the reviewer says looks good to me) we merge the feature branch upstream
- What’s the benefit of feature branches?
- master is always stable.
development might not be.
It lets us QA our changes in a staging environment that mimics production. that’s a big improvement over trying to test on our local environment.
- If we need to hotfix master, we’re not affected by untested changes from the development branch.
We talked about the benefits,
now let’s dive into how to grow the culture
You need to start with a commitment [*] to always review before merging code [*]
Present the facts:
there have been Many case studies and research papers over the past few years supporting reviews. I’ll talk about a few. [*]
Suggest it, show the research,but Don’t force it. [*]
New ideas take time to root.
code reviews need to be universal.
[1] everyone on the team should be submitting and reviewing code. no matter junior or senior
[2] if only senior dev do reviews, you’ve created a bottle neck
[3] Worked with a developer in a Java shop who insisted on formatting his code C++ style instead of Java style - diff in where starting brace goes
Made for nightmare diffs, and frustration among the team maintaining his code.
I protest. I was told “that’s OK - he’s allowed to do that” - because Bob was the most senior engineer
Many of you shaking your heads, but true story. You need to break down existing status quo for the idea to take root.
- Code review should be done by your peers, not by management.
- The end goal isn’t getting someone “in trouble”
Bugs found during the code review process should never come up in performance reviews
That’s why we do review in the first place
Review encourages Consistent Code
Need to remember an important fact:
The code you write isn’t yours. It belongs to your company. [*]
Code should fit company style and expectations, not your own. [*]
Reviews that encourage consistency make your code more robust. [*]
- Because no one stays at a company forever, code longevity is an important factor
What’s a style guide? [*]
A style guide distinguishes your personal taste from functionality [*]
style guides need to be agreed upon by the team before introducing code reviews. [*]
Because great code bases are written by a team but, they look like they were written by an individual.
I added a examples of great style guides at the end of my slides.
Python has one called PEP8, it’s a built-in part of the language.
Doesn’t matter which one you choose. Pick one and stick with it.
- Bob wasn’t in the wrong.
Maybe C++ style formatting is in fact better.
The problem was he wasn’t following convention.
Consistent code will be easier to maintain by a team.
Reviews work best in a ‘No Blame Culture’ [*]
Accept that failure is inevitable [*]
- When the team reviews code, The team becomes responsible for code quality, not an individual. [*]
Needs management support [*]
if you get in trouble for sharing your mistakes, you’ll brush them under the rug next time.
No blame culture should encourage teammates to openly talk about bugs found during review
As a bonus, I want to briefly touch on blameless post mortems, even though it’s a post-review process.
[1] What is it? A blameless post mortem meeting happens shortly after every incident.
[2] It lets you learn what the exact root cause was
[3] During the meeting document the events leading up to the issue. Create a timeline.
[4] Now you can learn from it, and figure out ways to prevent it from happening again. Don’t just talk about it, remember to create and assign tickets.
Who caused it is not part of the conversation
This process will only work if punishment is off the table
If developers think they’re going to get in trouble, they’re not going to be honest about making mistakes
if you’re encouraged to share instead, everyone on the team can learn from mistakes
Having a blameless post mortem is a great way for managers to show support of a no blame culture.
{Q} - How do we know when the culture has taken root?
{A} - When code reviews are part of the culture, developers will are not just going to expect review.
- they’re going to WANT it.
How to Grow a Culture?
Make a commitment
Code Reviews should be Universal
They should be performed by your peers
style guides encourage consistency
*It all starts with a no blame culture
- How should we code review?
- There are two steps in learning how to perform reviews.
How can we be a great reviewer?
Therapist asks:
- why do you think you’re so hostile in code reviews?
Dev laments:
- if only I had been more popular in HS
code review should not look like an appointment with your therapist.
Approach it objectively and without ego. Need to leave emotions behind.
Have empathy
- hostility is especially not necessary
Be objective. [*]
this method is missing a doctoring [*]
instead of [*]
you forgot to write a doctoring [*]
Reviews are a learning opportunity, not a chance to catch someone with their pants down.
Ask Questions, don’t give answers [*]
would it make more sense if… ? [*]
did you think about… ? [*]
Offer Suggestions [*]
say things like
it might be easier to… [*]
we tend to do it this way instead… [*]
It’s better to offer suggestions than to give ultimatums
Avoid these terms: [advance]
Simply, Easily, Just, Obviously.
They’re condescending!
If it was so obvious, the submitter would not have done it in the first place.
They might be missing context, or unaware of a concept. [advance]
Well, actually is another one to avoid. You say it when someone says something mostly correct, but you interrupt them to make a minor correction
[anecdote] I'm not sure if any of you practice yoga, but this happens in my class all the time. The teacher will twist herself into a pretzel, and then tell the students to “now simply…
[advance]
- touch your feet to your forehead”.
-I don’t think any of you would consider this simple!
To be effective, you need to have clear feedback [*]
Your opinions need to be strongly supported to have maximum impact [*]
Share how you would implement your suggestion, and why you think the change is necessary [*]
Link to blogs, documentation, and other resources that back up your opinions. [*]
Don’t feign surprise if someone doesn’t know something, even if you consider it a basic concept.
*gasp* I can’t believe Dave doesn’t know about the singleton design pattern.
this is not clear feedback
- Remember to compliment good work and great ideas
- I like to leave a thumbs up when I see:
a good refactoring, some code clean up, or a particularly elegant solution
Reviews shouldn’t be all about the bad
You don’t want to be a perfectionist.
Rebecca said it better than I can
“The goal is better code, not exactly the code you would have written”
[1] for big issues, don’t let perfect get in the way of perfectly acceptable
[2] prioritize what’s important to you
[3] usually 90% of the way there is good enough
- When you press for complete perfectionism, you take ownership away from the person who wrote the code.
It takes away their feelings of accomplishment and creativity.
Don’t be a perfectionist, but it’s OK to Nitpick the small stuff.
- [1] syntax issues
- [2] spelling errors
- [3] bad variable names
[4] missing corner-cases
You might ask:
- What’s the harm in letting a few of these pass by?
Broken window theory
- if I see sloppy code, I assume it’s OK to check in sloppy code.
Save the nit picks for last, after you’ve addressed the big stuff like
architecture concerns
or
design decisions
As a reviewer, you want to avoid getting burned out
Studies show that you should only look at 200-400 lines of code at a time for maximum impact
In practice, reviewing between 200 and 400 lines over 60 to 90 minutes will let you find 70-90% of the bugs.
So, if 10 bugs existed in the code, a properly conducted review would find between 7 and 9 of them.
Studies show after 500 lines, the ability to find bugs drops dramatically
- If the code stops making sense, you’re too tired. You might miss something.
Good rule of thumb: Do Reviews in 24-48 hours after they’re submitted.
This is especially easy when reviews are small. 500 lines of code
This lets you look at reviews incrementally, prevents buildup
Also means the code is fresh in the submitter’s mind for questions
[advance] don’t want to end up like this guy, who’s still waiting for a code review.
For good communication, Define Done [advance]
When you’re finished, say if the review is complete or if you’re waiting for the submitter to make changes [advance]
Use consistent language. when you’re done you can say My personal favorite: ship it! or lgtm.
If the submitter needs to push code based on your comments, say ‘Changes Requested’
- Make sure you follow up and actually the check code when the submitter says they pushed a fix.
How can you be a great reviewer?
Have Empathy
Watch your Language
Have clear Feedback
Give compliments for good work
Don’t be a perfectionist
Avoid Burn out. Take Breaks
But, don’t leave your teammates hanging. Finish reviews in 24-48 hours.
Lastly, define done.
- We’ve spent time talking about how to be a great reviewer
There’s 2 sides of the coin
For effective reviews, we need to learn how to be a great submitter too.
Submitter: “no need to double check this change list,
if some problems remain I’m sure the reviewer will catch them.
Reviewer: “no need to look at this change list too closely,
I’m sure the author knows what he’s doing.
[*** halfway point]
Q: What’s rubber stamping?
- When a submitted solution is so complex, the Reviewer thinks it’s obvious the author knows what they’re doing.
- They just approve the code without fully understanding it.
Don’t be too clever.
Submitting over complicated code is a surefire way of getting rubber-stamped.
- I have a developer friend who used to love showing off how smart he was by checking in complex over engineered solutions
He stopped doing it when he realized he was punishing himself. It meant that he always ended up being the maintainer of it.
Remember that readability counts.
- Russ Olsen said it best.
- Good code is like a good joke. It needs no explanation.
- If you feel like a piece of code is confusing, it is.
Leave a comment, either in code or in your review tool.
Better yet, refactor it so it’s more readable
Let’s go through the stages of a Review
0: before you submit it
1: submitted
2: (this step is optional) showing work in progress.
— at this stage the code is 30-50% done.
3: almost done.
— here, we’re 90-100% done
4: the review is completed
Now we’re at step 0
things we need to do before we even think about starting the review
- the most important thing you can do to help the reviewer
is provide context. WHY did you write this code? [*]
Link to the underlying ticket or bug report [*]
If there’s not enough context in the ticket, provide extra context [*]
For larger reviews, consider providing a change-log [*]
And try to remember to point out unintended side effects [*]
- Now that you’ve provided the context,
remind yourself that YOU are the primary reviewer
review your own submitted code as if you were giving a review
this lets you anticipate problem areas
As the primary reviewer, it’s your responsibility to make sure
your code works
and it’s throughly tested
always QA Your own changes.
Because you don’t want to rely on others to catch your mistakes
- One way you can be a better submitter is to try a checklist before you submit your code.
- What makes a good check list?
check off the small stuff [*]
did you look for reusable code or utility methods?
did you remove all your debugger statements
are your commit messages clear?
Also use the opportunity to check for the big stuff.
is your code secure?
is it going to scale?
I highly recommend a book called the checklist manifesto.
It’s a book about how having checklists helped doctors make surgery safer, and pilots deal with disaster better.
Checklists can help developers too
now we’re at step 1
you submitted the review.
At this point, you’re starting a conversation [*]
don’t get too attached to your code before the review even starts [*]
anticipate comments and feedback. [*]
lastly, acknowledge that you will make mistakes [*]
Remember that the entire point of a review is to find problems, and problems will be found.
Don’t be caught by surprise.
now, we’re at step 2 which is optional
submit work in progress
What’s the benefit of submitting work in progress?
It’s really helpful for bigger and more complicated tasks
As a rule of thumb, open them when you’re 30-50% done.
You can’t be afraid of showing incomplete work. This drives the perfectionists crazy.
This stage is the right time go get feedback on bigger issues.
- When your code is a work in progress - [*]
- what kind of feedback should you expect? [*]
architectural issues [*]
overall design problems [*]
recommendations for design patterns to use [*]
at this stage, you want to get feedback early & often.
step 3:
- we’re almost done!
- we can see the finish line
What kind of feedback can we expect with the code is almost done? [*]
nit picks [*]
variable names [*]
requests for more documentation or comments [*]
small optimizations [*]
- As the code evolves, it becomes more firm.
- No one wants to hear “change it all!” at this phase
This is the point at which you ask yourself -
Did I also end up solving an unrelated problem? [*]
“ Did I only solve one issue with my pull request?”
if the answer is no, break up the code into multiple reviews [*]
you can even branch your code off a feature branch. this will keep the diff small
- We want to keep reviews small to prevent reviewer burn-out. [*]
Remember I mentioned earlier, reviewers are not as effective when they look at more than 500 lines of code [*]
Keep it small and relevant [*]
if a big review is unavoidable, give the reviewer some extra time. [*]
We can use automated tools and static analysis to streamline the review process
What is code linting?
it’s an automated way of checking syntax
or if you want to get fancy, you can set it up to check style guide violations too
this is an example of a python linter
Linter can integrate with your code editor.
This way the reviewer doesn’t have to waste time pointing out syntax problems
Tests. [*]
Write them!! [*]
Tests need to be passing for someone new to be able to meaningfully contribute.
Because you don’t know the status of your overall code health if they’re failing. [*]
Tests help you identify problems immediately.
Not going to go into too much detail. There are many great talks and resources on testing.
If I haven’t stressed the importance of tests enough, - remember
no one wants to work with the scumbag programmer who commits untested code
don’t let this be you!
What is Continuous Integration? - automated build with every push.
run compiler
run tests
- this should happen a few times a day
- Lots of available tools, Travis, CircleCI.
- almost all of them integrate with Github pull requests
what’s coverage?
its the % of code that’s executed when a test suite runs.
- Remember we talked about fault tolerance
If you have low fault tolerance - for example (if your code fails, will someone get stuck in an MRI machine?) coverage can be a necessary tool
coverage tools integrate into github too
for python, use coverage.py
there’s also a product that works with lots of different languages called coveralls
here’s an example coveralls report integrated into github
- Automation saves everyone time.
- Now we’re at the last step
- The reviewer has finished looking at your code.
- But, we might not be done.
- If the reviewer left comments, we need to be responsive. [*]
Reply to each one [*]
Common responses: resolved, or won’t fix [*]
If you respond with won’t fix be sure you explained by [*]
- At this point, it’s still a conversation
- After the first pass, let the reviewer know when your code is ready to be reviewed again.
what is bike shedding - arguing over minor, marginal issues while more serious ones are being overlooked. i.e people arguing over what color to paint the bike shed while the house is not finished.
- If you're going back and forth more than 3 times, it's time to step away from the keyboard.
-Use your words instead.
If you're co-located, great. Stop by and have a chat. If your remote Hop on a video call.
Record the result of the conversation in the PR for posterity.
- Disagree with the reviewer's comments? No radio silence.
- Carefully Explain what the reviewer might have missed.
- Open a friendly discussion until you understand why the reviewer left the comment.
- Maybe the reviewer missed your thought process.
- But, maybe you’re just wrong.
[advance slide] Learn to admit defeat.
- Admitting that you don't know something is hard.
- Don’t take it personally.
- You are not your code.
- Use it as an opportunity to grow
Remember, we’re all working towards the same goal - to ship code.
Be grateful, offer thanks that someone spent the time to review your code.
How do we be a great submitter?
Provide the why
review your own code first
expect a conversation
submit work in progress
use automated tools
be responsive
when neccessary, accept defeat
I’ve shown you how code reviews build a stronger team
You can use that as an advantage when someone new joins
It doesn’t matter how much experience you have.
on your first day, you probably feel something like this….
[advance]
- “I have no idea what I’m doing”
The new person joining your team might not have experience being reviewed.
If you've never had someone look at your code before, it's easy to get scared. "What are they all going to think?"
Remember your first review.
Ease the new person into the process.
When you onboard:
- Encourage the newbie to read recently completed reviews before submitting their own
Remember the 1st review is the hardest.
First few reviews should be small. Don't let someone stumble around in the dark on the wrong path.
Share the style guide so expectations are set.
* expectations are good, but don't be rigid. evaluate new ideas or best practices the employee may have brought over from a previous org.
- Everyone should be a reviewer. How does this work with junior people? [*]
- A study showed that familiarity with the code was an important factor in increasing the likelihood of providing useful comments. [*]
Instead of muscling out newer or inexperienced teammates, have them do pair review with a more experienced one until they are more familiar with the code base. [*]
Use it as a mentorship opportunity. [*]
Sasha Laundy said it best during a talk on Giving & Getting Technical Help. She said:
Hiring senior engineers is hard.
Instead, you can hire junior engineers, and grow them into functional and productive parts of your team
Use your culture of review and knowledge sharing as a competitive advantage to make this process faster and easier.
- Code review is prove-ably shown to improve code quality across all kinds of organizations and code bases.
- If you’re not doing code reviews, you’re missing a big opportunity.
- Think about what’s blocking your team from trying some of the techniques we talked about
- And Figure out ways of eliminating those blockers
Remember that for a successful culture - [*]
You need to allocate the time [*]
Let the culture grow organically, don’t force it [*]
These ideas are not one size fits all [*]
And code reviews are not a one stop fix. [*] They need to be used in addition to tests, QA, and other methods for maximum impact.
- If code reviews are not already in place, anticipate stumbling blocks but in no time at all you'll say a pay off in less buggy more maintainable code.
What’s the most important thing we learned about code reviews today?
- at a minimum, code reviews decrease wtFs per minute
- [advance]
- and, as we know, this is the only valid measurement of code quality
- we all want to work with the team on the left!
when you have less WTF moments every day, you have happier developers.
- Before I leave you today, I wanted to point out that there’s bonus material at the end of my slides
- slides at bit.ly review code
Please contact me on twitter, e-mail me, and grab a copy of the slides.