LinkedIn - https://www.linkedin.com/in/syedakauserinamdar/ | Twitter - @codealatte Top takeaways * How improving your code review cycle helps to 'ship it' or get approved faster * How to integrate python tooling to automate parts of your review * How to perform a review (both submitting and giving feedback) with a learning mindset Conference Link - https://connectdigital.womenwhocode.dev/day-1/ https://www.slideshare.net/SyedaKauserInamdar/level-up-your-python-code-reviews-to-ship-it-faster-wwcodedigital-2020

1. Level Up Your Python
Code Reviews to
‘Ship It’ Faster
Syeda Kauser Inamdar
Software Engineer, LinkedIn
Tweet @codealatte
June 5, 2020

2. Agenda
1 Automate code review
2 Create a great pull request
3 Give effective feedback

3. What is code
review?

4. Benefits of code review
Find bugs early Share knowledge Maintain consistent
code

5. Comic from https://www.monkeyuser.com/2018/tech-debt/

7. Chaotic code

8. Black Hole
Wasted cycles going back
and forth about code style
and format

9. Style Guide
• Start off with PEP8,
which is a style guide
used within the Python
Community
• Helps maintain
consistent coding style
for the team
• Teams need to agree
on the style guide

10. flake8
• Wrapper which checks
for PEP8 compliance
against various python
linting tools
• Runs all tools in a single
command and displays
warnings per file

11. Result of applying flake8 on the code snippet

12. black
• The uncompromising
python code formatter
which auto-formats
code to make code
review faster
• Note that black is a
strict subset of PEP8
(except default line
length)

13. Result of applying black on the code snippet
With better
formatting,
the
submitter or
reviewer
should now
notice
there’s a
typo which
needs to be
fixed!

14. isort
• Library that sorts imports
alphabetically by default
adhering to specific
sections (standard library
imports, third-party
imports, own project
imports. . . )
• Improves import
readability

15. Result of applying isort on the code snippet

16. Integrate it into your workflow

17. pre-commit
• Manages installation and
execution of each hook
configured to automatically
apply every commit
• Tip – Apply black plugin first
and then flake8
• Enforces style consistency
before code is committed to
the repository

18. Setting up pre-commit

19. Running pre-commit

20. Failing pre-commit

21. Passing pre-commit

22. Code style is now enforced
with python tooling and
automation!

24. pre-commit
framework

27. pre-commit
framework

28. Negative review

29. Possible approach to respond to this negative review
Explain why you added
that functionality with
a comment and get
their feedback again.
This makes the decision
seem more inclusive
instead of single sided.
“I got feedback from multiple customers to include this option. I feel it helps for better user
experience if they can pick their two meals with the single script. How does that sound to you?”

30. Possible approach to respond to this negative review
“I believe we had discussed to have this option in our team meeting but I don’t see the decision listed
in the team meeting notes. Can we sync up to confirm the options then?”
If you don’t agree with
a reviewer’s decision,
have a discussion
within the pull request
and/or in person.Then
document the results of
that discussion within
the PR so it is tracked.

31. Pull Request
Submission
Checklist
A more complete submission
helps make for a more efficient
review!
1
Ensure you’ve
looked over the
code just before
creating the PR
as if you’re a
reviewer to catch
issues

32. Pull Request
Submission
Checklist
A more complete submission
helps make for a more efficient
review!
1
Ensure you’ve
looked over the
code just before
creating the PR
as if you’re a
reviewer to catch
issues
2
Ensure your code
is properly
formatted to
have a consistent
slate

33. Pull Request
Submission
Checklist
A more complete submission
helps make for a more efficient
review!
1
Ensure you’ve
looked over the
code just before
creating the PR
as if you’re a
reviewer to catch
issues
2
Ensure your code
is properly
formatted to
have a consistent
slate
3
Provide a clear
summary of
change in the
title and
description and
add tests where
needed

34. Pull Request
Submission
Checklist
A more complete submission
helps make for a more efficient
review!
1
Ensure you’ve
looked over the
code just before
creating the PR
as if you’re a
reviewer to catch
issues
2
Ensure your code
is properly
formatted to
have a consistent
slate
3
Provide a clear
summary of
change in the
title and
description and
add tests where
needed
4
Add
context/motivatio
n for the change
with supporting
documentation
where needed

35. Pull Request
Submission
Checklist
A more complete submission
helps make for a more efficient
review!
5
Identify concerns
around design or
implementation
you want
feedback on

36. Pull Request
Submission
Checklist
A more complete submission
helps make for a more efficient
review!
5
Identify concerns
around design or
implementation
you want
feedback on
6
Keep changes as
small as possible
within a single
PR. For example,
1 PR should solve
a single problem.
Otherwise, break
that PR to make it
more
manageable to
review

37. Pull Request
Submission
Checklist
A more complete submission
helps make for a more efficient
review!
5
Identify concerns
around design or
implementation
you want
feedback on
6
Keep changes as
small as possible
within a single
PR. For example,
1 PR should solve
a single problem.
Otherwise, break
that PR to make it
more
manageable to
review
7
Tag specific
people you’d like
to review the PR

38. Pull Request
Submission
Checklist
A more complete submission
helps make for a more efficient
review!
5
Identify concerns
around design or
implementation
you want
feedback on
6
Keep changes as
small as possible
within a single
PR. For example,
1 PR should solve
a single problem.
Otherwise, break
that PR to make it
more
manageable to
review
7
Tag specific
people you’d like
to review the PR
8
Proofread the PR
before submitting
to see if it makes
sense and
everything there
is as expected.
Then submit!

39. Things to
aim for as
an author
1 Acknowledge every review
comment

40. Things to
aim for as
an author
1 Acknowledge every review
comment
2
If you’re feeling overwhelmed with
comments, you can try to identify
those themes to improve on next
time. Alternatively sync up with the
reviewer in person to go through
the comments you need more
clarity on

41. Things to
aim for as
an author
1 Acknowledge every review
comment
2
If you’re feeling overwhelmed with
comments, you can try to identify
those themes to improve on next
time. Alternatively sync up with the
reviewer in person to go through
the comments you need more
clarity on
3
If the reviewers cannot come to a
consensus on the change, create a
meeting to discuss the change in
person and track the result in the
PR

42. Things to
aim for as
an author
1 Acknowledge every review
comment
2
If you’re feeling overwhelmed with
comments, you can try to identify
those themes to improve on next
time. Alternatively sync up with the
reviewer in person to go through
the comments you need more
clarity on
3
If the reviewers cannot come to a
consensus on the change, create a
meeting to discuss the change in
person and track the result in the
PR
4
Embrace reviews as a learning
opportunity – critical reviews are
inevitable, it’s all about how you
respond to them

44. What do you think of when you think of a code reviewer?
Supervillain Robot Facepalmer

45. What do you think of when you think of a code reviewer?
Supervillain Robot Facepalmer

46. What do you think of when you think of a code reviewer?
Supervillain Robot Facepalmer

47. How we should perceive a reviewer
Thinker Technologist Teacher

48. How we should perceive a reviewer
Thinker Technologist Teacher
Student Human

49. Negative review
Comment sounds
passive aggressive and
doesn’t explain why
that functionality isn’t
needed

50. Negative review
Even if ”burger” was
not an agreed upon
option, the phrasing is
a little harsh. Direct
language is part of
code review since we
want to “get to the
point”, but within this
comment’s context, it
could have had
reference to
documentation or
meeting notes which
solidified the point as
well.

51. Positive review
Asking a question
opens it up for
discussion.

52. Positive review
If unsure about
something, asking for
documentation is really
helpful.
Also explaining the why
behind something also
helps the submitter and
other reviewers get
more context around it.
Using “we” is highly
encouraged as it’s a
more collaborative
word.

53. Remember to give positive feedback too!

54. Code
Reviewer
Checklist
A high-level checklist- feel free
to add to it for your own
reviews!
1
Ensure you
understand
context of the
change. Simply
approving with a
“LGTM” without
having context
can have
unfortunate
consequences

55. Code
Reviewer
Checklist
A high-level checklist- feel free
to add to it for your own
reviews!
1
Ensure you
understand
context of the
change. Simply
approving with a
“LGTM” without
having context
can have
unfortunate
consequences
2
Ask questions around
the content of the
change (some
suggestions below)
• Does the feature
need to be
implemented?
• How does this
change impact the
larger scale
(team/organization/
company)?
• Does the code do
what it says it does?
• Is that the right way
to do it? Is it
following best
practices?
• Can we optimize it?

56. Code
Reviewer
Checklist
A high-level checklist- feel free
to add to it for your own
reviews!
1
Ensure you
understand
context of the
change. Simply
approving with a
“LGTM” without
having context
can have
unfortunate
consequences
2
Ask questions around
the content of the
change (some
suggestions below)
• Does the feature
need to be
implemented?
• How does this
change impact the
larger scale
(team/organization/
company)?
• Does the code do
what it says it does?
• Is that the right way
to do it? Is it
following best
practices?
• Can we optimize it?
3
Try to save nit-
picks until after
you’ve addressed
architecture and
design of the
submitted code

57. Code
Reviewer
Checklist
A high-level checklist- feel free
to add to it for your own
reviews!
1
Ensure you
understand
context of the
change. Simply
approving with a
“LGTM” without
having context
can have
unfortunate
consequences
2
Ask questions around
the content of the
change (some
suggestions below)
• Does the feature
need to be
implemented?
• How does this
change impact the
larger scale
(team/organization/
company)?
• Does the code do
what it says it does?
• Is that the right way
to do it? Is it
following best
practices?
• Can we optimize it?
3
Try to save nit-
picks until after
you’ve addressed
architecture and
design of the
submitted code
4
Can sometimes
phrase
suggestions as
questions to
open discussion
and give the
code submitter
more ownership
of the change

58. Code
Reviewer
Checklist
A high-level checklist- feel free
to add to it for your own
reviews!
5
Don’t just gloss
over test code

59. Code
Reviewer
Checklist
A high-level checklist- feel free
to add to it for your own
reviews!
5
Don’t just gloss
over test code
6
Support points
with
documentation
where
appropriate. For
example, when
trying to make a
piece of code
more pythonic,
you can put a link
to online
documentation
or even write a
simple code
snippet to
illustrate your
point

60. Code
Reviewer
Checklist
A high-level checklist- feel free
to add to it for your own
reviews!
5
Don’t just gloss
over test code
6
Support points
with
documentation
where
appropriate. For
example, when
trying to make a
piece of code
more pythonic,
you can put a link
to online
documentation
or even write a
simple code
snippet to
illustrate your
point
7
Re-read the PR
and your
comments before
publishing

61. Code
Reviewer
Checklist
A high-level checklist- feel free
to add to it for your own
reviews!
5
Don’t just gloss
over test code
6
Support points
with
documentation
where
appropriate. For
example, when
trying to make a
piece of code
more pythonic,
you can put a link
to online
documentation
or even write a
simple code
snippet to
illustrate your
point
7
Re-read the PR
and your
comments before
publishing
8
Remember to
sometimes offer
positive feedback
as well

62. Things to
aim for as
a reviewer
1
Provide timely feedback. Done in a
constructive manner, will help make
the review more efficient

63. Things to
aim for as
a reviewer
1
Provide timely feedback. Done in a
constructive manner, will help make
the review more efficient
2
Try to use more
collaborative/empathic language
where possible. It’s ok to be direct
to be efficient but language should
not be accusatory or degrading

64. Things to
aim for as
a reviewer
1
Provide timely feedback. Done in a
constructive manner, will help make
the review more efficient
2
Try to use more
collaborative/empathic language
where possible. It’s ok to be direct
to be efficient but language should
not be accusatory or degrading
3
There’s a balance between being
constructive and overly critical/nit-
picky. Try to find the balance for
you and the team

65. Things to
aim for as
a reviewer
1
Provide timely feedback. Done in a
constructive manner, will help make
the review more efficient
2
Try to use more
collaborative/empathic language
where possible. It’s ok to be direct
to be efficient but language should
not be accusatory or degrading
3
There’s a balance between being
constructive and overly critical/nit-
picky. Try to find the balance for
you and the team
4
Embrace reviews as a learning
opportunity – you may learn
something new from the submitted
code or other reviewers

66. Summary
Set your review up for success Submitters and reviewers are human Ship It Faster

67. Resources
1 http://bit.ly/pycoderevie
ws
2
https://ljvmiranda921.githu
b.io/notebook/2018/06/21/
precommits-using-black-
and-flake8/
3
https://www.michaelagreiler
.com/code-review-best-
practices/
4
https://hackernoon.com/wh
y-you-should-do-code-
review-e2642cfd1667

68. Thank youhttps://linkedin.com/in/syedakauserinamdar
Tweet @codealatte