9 Comments

Great article Akos!

In my view, PRs should also follow the single-responsibility principle. At the very least, they will be easier to roll back in case of any issues.

Expand full comment
author

Thanks, Saurabh!

Yep, rolling back useful things because they were included in the wrong PR is always meh.

Expand full comment

This is a very useful and actionable guide. Thank you for sharing!

Expand full comment
author

I appreciate it, Basma! 🫡 For the recent two articles, I focused on shrinking the newsletter and delivering more value in fewer words. I happy to see that it's working 😊

Expand full comment

I like the fact that it's more shorter. Short. Sweet. Valuable :)

Expand full comment

I feel that the guidance is where most people fall. There is an opinion that the code should explain itself, so no need for code comments or review comments, but I don’t agree with it.

I use the comments also to point the reviewer to the meatier parts, and where I want them to pay more attention.

Expand full comment
author

I love the idea of self-explanatory code! It just reads better and faster, but..., it's not always possible, and sometimes a short comment is certainly better than turning your code upside down and weirdly naming things.

Glad to hear I'm not the only one using GitHub PR review comments for guidance! 🤝

Expand full comment

Awesome tips, Akos! I try to get my mentees to do these ones too :D.

Thanks for the shout-out too

Expand full comment
author

Thanks, Jordan! I'm much more motivated to dive into PRs if they are also carefully put together. I know that following these requires extra mental cycles from the author, but in the end, they save a lot more time for them and the reviewer. Wish you many nice PRs to review! 😃

Great writing there! 🤝

Expand full comment