Working from home - How to deal with big PRs? (Day 18)

General

Monday kicked in again. The weekend was nice, with usual up's and down's. But I'm emotionally fine with the situation. I still don't know how to handle the whole Covid-19 situation. I've realized I subscribe to NYT and other things to be up-to-date on the issue from sources I trust.

Work

This is an issue I faced at work (the truth is, I realized some was SVG code, so it was around 2k of pure JS code):

How to deal with this? I got some great strategies and feedback from former colleagues.

Based on that I realized this is how I will tackle it:

• Recommend to do a Pair Review / Programming of this Pull-Request. Show the other co-worker why certain things are an issue. And ask all the clarification questions.
• Share with them the issue of such big PR. Don't hide for months, openly share the PR (use Draft PRs from GH). Please separate this to separate smaller PRs (cherry-pick). I'm sharing that changing to smaller PRs would make it easier for me to review vs. one big. Paul suggested at least two branches with "easy to review vs. hard / complex logic". Let's see if this works.
• If we go with one big fat PR, I will share clearly that I won't be able to review easily and knowing the test in detail doesn't change the need for good code quality, naming, structure and other things.

Another tip was to have expressive commit messages like "a story" so we could go and review commit by commit. But sadly, half of commits are like this:

TIL

Don't hide your features for months. Create WIP Pull Requests and ask for feedback early on.

Also, use the full functionality of Github or other Repository Tools. Share Screenshots, tell possible Reviewers what is connected to what. Especially working from home is changing Reviews. I can't just go to your desk and ask you. I don't know the design of your solution / feature / ab-test.

The learnings for all of us:

• Small Pull Requests over Big Pull Requests
• Start sharing your PR early (use Draft PRs or WIP). Ideas need feedback, so does software solutions.
• Be expressive in your commit messages. Using Squash Merge is not an excuse to have unclear commit histories.

Cheers,

Ferit