Kardashians of Code: The Perfect Life of Pull Request Influencers

There you are scrolling down through your feed and you spot another one of Kim’s. Oh my, it’s gorgeous, fabulous even. The perfect beauty of it…

The first commit in the pull request is just documentation changes… I say just, but we’re talking the user-facing documentation and the support guide… placeholders for the screenshots too. Then there’s a comment with a TODO list of the screenshots that need to be taken and updated. All the check marks are ticked, of course.

The second commit, this one is all the test cases describing what the new feature should do… and the CI reports that commit had test failures… naturally, because this is the true meaning of test first.

The third commit, with its simple commit message of "Implements ELENDUR-2436"… well who could ever doubt it, the commit has the green checkmark of glory, reversing the red X introduced by the test cases in the second commit.

And finally, the pièce de résistance, the fourth commit replaces the placeholder screenshots with the real deal… followed of course with the comment "Ok, I think this is ready for review now".

You swipe right to the diff view and admire the beauty, no stray white space changes, only required imports touched, doc comments on all the new methods… and the names of the methods, fields and variables introduced they are a joy to read, Your eyes well up, and you type :heart: in the review comments and click approve, how could you not.

"Ok! That’s enough code review for now, time to do some coding" you say to yourself… and so you turn to your work for ELENDUR-2756.

You push your changes to GitHub and open the create pull request screen… and then the depression hits.

Your pull request is a mess, twenty commits, lots of noise in the diff screen… you start to read through the pull_request_template.md checklist… ok, I’ll have to write some tests… "Damn documentation, I hate writing that"… and finally it dawns on you.

"I will never be as good a developer as Kim."

You’ve tried to write the test first, but you end up having to refactor them as you go… Kim just distilled the tests out of thin air perfectly formed, all failing until the feature landed.

Let’s not even get started on documentation first development… yes, it sounds wonderful, the documentation describing exactly what the feature is and how it should work… but that’s obviously a skill that is far beyond your abilities.

Well, I’m here to tell you: "Don’t be so hard on your self!"

All those pull request influencers cheat. You do not know how many attempts they made at implementing the feature, perhaps even hundreds of little tweaks left and right. When we look at our own development, we see the hundreds of changes we make as we try to get something working. Just like on Instagram which only shows you the photo that they decided to post and not the hundreds of deleted shots until they looked just right.

Photo credit: George Dolgikh

It doesn’t stop there, once they have something working, they can then use the IDE refactoring tools to make the changes look better. Rename variables from i , j , k to something more meaningful. Extract functions and give them names that reflect their function. Write more tests. Write the documentation. These are the Instagram filters for the pull request influencers.

And now for the big open secret:

They all use git rebase to touch up their pull requests and set the stage of a compelling story.

git rebase is the Photoshop for pull requests.

Once you have that perfect story, well then you push the first commit only and create the pull request. You can then push a commit at a time, waiting for the CI server to start building your changes. That’s how the Kardashians of code create their beautiful pull requests.

So don’t feel bad about yourself because your pull requests don’t look perfect on your first attempt, and don’t feel you have to make your pull requests look that good either.

But, it does no harm to tidy up your changes and organize them a bit better before you push… because it will help you get the changes reviewed.

Everyone can use the filters of IDE refactoring tools to make their pull requests look better, and a really ugly pull request can benefit from a little bit of git rebase touch-ups… just don’t judge yourself against the one picture (out of a thousand deleted), air-brushed and carefully staged Instagram view of a perfect life.