1. Keep PRs small, ideally under 100 lines of code, and fully tested. Address all reviewer comments before merging. 2. When reviewing, focus on code quality, maintainability and robustness rather than personal criticisms. Suggest improvements clearly and humbly. 3. If agreement can't be reached, accept different opinions or escalate to a mediator. The goal is better code, not personal victories. Treat the process as a way to learn and improve together.

1. Love your Pull Request (PRs)
Nasir Jamal
@_nasj
We are hiring
www.housetrip.com

2. What this talk is not about!
1 Git Commands / process flow
2 Technical issues around PR issue /
merging

3. Before issuing PRs
Take a break and go through your
code once again to keep things clean
and tidy or any obvious refactoring you
1 need
As Uncle Bob says:
*keep the ground cleaner than you
found it

4. Before issuing PRs (cont..)
Do not issue a PR unless you think
your story is fully complete, i.e. specs,
integration/cucumber tests
2
- Otherwise you are just wasting other
people's time
- Don't be sloppy

5. Before issuing PR (cont..)
Keep your PRs small
Max 200 - 400 LOCs
3 If possible 50-100 LOCs or less
- easy to review, spot errors, minimal
comments, etc

6. After issuing PRs
Do not merge until all the comments
have been addressed
1 - if you have comments from more
than one person then make sure they
all have been taken care off

7. After issuing PRs (cont..)
Keep your ego away, comments are
2 feedback about your code learn a trick
or two

8. After issuing PRs (cont..)
Seek to understand reviewers
3 perspective

9. When reviewing PRs
Go at an easy pace because faster is
not better
1 - if you don't have time, don't review it
otherwise you will either end up
pissing off the dev with your comments
or you will miss obvious errors

10. When reviewing PRs (cont..)
Look for code maintainability and
2 robustness

11. When reviewing PRs (cont..)
Avoid sarcasm or making demands
instead suggest
- when suggest, give an example
3
- ask the dev what he thinks about it
or if he has any objections because you
don't know what was going on his
mind when he wrote it

12. When reviewing PRs (cont..)
Remember you are giving a feedback
4 or clarifying things that you are not
sure

13. When reviewing PRs (cont..)
Your purpose is to find defects and
issues but never show that someone is
5 inferior or you are …
- if you really want to do it, do it in
private - and most probably you will
have your arse kicked

14. When reviewing PRs (cont..)
Communicate your ideas clearly
6
- Find ways to make code better

15. When reviewing PRs (cont..)
Be humble, explicit and if required
talk in person, clarify and discuss
7 - to the point & precise without
sugarcoating
- be careful with icons or with your
WTFs (do not offend another person)

16. When can't agree
Know when to continue and stop the
1 debate and accept one or the other
point of view

17. When can't agree (cont..)
2 If required take the discussion offline
and make a decision quickly

18. When can't agree (cont..)
If you can't decide bring in some
3 mediation and just go with the
majority unless you can convert the
majority

19. Things to remember
1 there is no best solution, just better
2 Issuer: Be thankful for the reviewer
for taking the time out

20. Things to remember (cont..)
3 Use it as a means of learning, growing,
communication, team building and
keeping the code sane and bug free
Issuer/Reviewer: Don't take anything
4 personally, the comments are about
the code and not about you