Merge first, suggest changes later

Augusto Galego - Sep 12 - - Dev Community

An all too common occurrence that slows us down in the async world is

you make a PR, wait a day to get reviews

reviews come in, your code is good and works, but there are suggestions to make it better.

you refactor the code, re-write tests, etc, ask for reviews again, wait another day again.

This can go on for two or three iterations. My suggestion is simple, if it works decently well, you merge immediately, and create another WIP PR to make improvements (you have to create the PR and start working on it, otherwise it's just tech debt). Your new PR will include all good changes suggested by your team.

This will do two things.

1) It allows the code to reach the user and deliver benefits faster.

It may even validate/invalidate the entire feature. It may reveal a wrong approach, etc. Code on the IDE provides little information, code on prod reveals more information. The faster you receive information, the more feedback you have, the more agile you are. In the traditional sense of the word agile

2) Your next PR, the one fixing the tech debt, will be smaller, and different from the first one. It'll be easier to read and review. Sometimes you had good working code, and a well meaning suggestion could break your code or introduce hidden bugs. In that case, your original code is already on prod and working, and this single PR (the one adding the suggested changes) can be reverted.

Aim for fast feedback, increase surface area. Godspeed

. .
Terabox Video Player