Love your Pull Request (PRs)Love your Pull Request (PRs)

Nasir Jamal

@_nasj

We are hiringWe are hiringwww.housetrip.com

What this talk is not about!

1

2

Git Commands / process flow

Technical issues around PR issue / merging

Before issuing PRs

1

Take a break and go through your code once again to keep things clean and tidy or any obvious refactoring you need

As Uncle Bob says:*keep the ground cleaner than you found it

Before issuing PRs (cont..)

2

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

Before issuing PR (cont..)

3

Keep your PRs smallMax 200 - 400 LOCsIf possible 50-100 LOCs or less

- easy to review, spot errors, minimal comments, etc

After issuing PRs

1

Do not merge until all the comments have been addressed

- if you have comments from more than one person then make sure they all have been taken care off

After issuing PRs (cont..)

2Keep your ego away, comments are feedback about your code learn a trick or two

After issuing PRs (cont..)

3Seek to understand reviewers perspective

When reviewing PRs

1

Go at an easy pace because faster is not better

- 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

When reviewing PRs (cont..)

2Look for code maintainability and robustness

When reviewing PRs (cont..)

3

Avoid sarcasm or making demands instead suggest

- when suggest, give an example

- 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

When reviewing PRs (cont..)

4Remember you are giving a feedback or clarifying things that you are not sure

When reviewing PRs (cont..)

5

Your purpose is to find defects and issues but never show that someone is inferior or you are …

- if you really want to do it, do it in private - and most probably you will have your arse kicked

When reviewing PRs (cont..)

6Communicate your ideas clearly

- Find ways to make code better

When reviewing PRs (cont..)

7

Be humble, explicit and if required talk in person, clarify and discuss

- to the point & precise without sugarcoating- be careful with icons or with your WTFs (do not offend another person)

When can't agree

1Know when to continue and stop the debate and accept one or the other point of view

When can't agree (cont..)

2 If required take the discussion offline and make a decision quickly

When can't agree (cont..)

3If you can't decide bring in some mediation and just go with the majority unless you can convert the majority

Things to remember

2 Issuer: Be thankful for the reviewer for taking the time out

1 there is no best solution, just better

Things to remember (cont..)

3Use it as a means of learning, growing, communication, team building and keeping the code sane and bug free

4Issuer/Reviewer: Don't take anything personally, the comments are about the code and not about you