VS Code Liveshare sessions allow you to join your colleague's VS Code to do an over the shoulder code review. Really recommend it for pairing and for some code reviews.
Pycharm also has a similar service if you use Pycharm.
Ask HN: Over the shoulder Code-Review in remote settings
21–29 of 29 posts
Re: Ask HN: Over the shoulder Code-Review in remote settings
#22Generally, it’s been useful for my teams to have open discussions about establishing coding standards amongst themselves. We’ve also made code reviews mandatory as part of pull requests although it’s not as effective for smaller teams that want to be more agile.
Re: Ask HN: Over the shoulder Code-Review in remote settings
#23Use a screen share or collaborative code editor.
Re: Ask HN: Over the shoulder Code-Review in remote settings
#24Use a screen share or collaborative code editor.
For screen share, I loved Tuple[0] when I tried it out.
Re: Ask HN: Over the shoulder Code-Review in remote settings
#25I’ve found that pull request size solves a lot of the issues that people have with code reviews and quality. When people see a very large pull request, there is a tendency to skim and then slap on an Approval. Keeping pull requests small typically leads to a more thorough review because it’s much easier to parse the changes and build a mental model. This usually leads to better feedback. This also helps prevent less…
Alternatively, as small PRs can be hard (depending on codebase, language, etc), you can try to do small commits.
Aiming for each commit telling a logical part of the story, that together make a PR that is easy to review.
Why is this easier than small PRs? Typically PRs can’t break anything. Whether it’s CI or breaking the build on the main branch or breaking the workflow of other devs, normally main needs to be stable and PRs are the unit of stable addition to that. However, each commit does not necessarily need to be so, especially if you squash or merge so that there are clear working points to revert to on the main branch.
In many cases my commits might not even compile, but this frees me up to do things like: put bulk renaming or code moves in commits that can mostly be ignored, keep business logic changes in small commits that are easily reviewed, write all test function definitions before filling them in to help summarise the testing that is done, etc. thankfully over the last 4 years or so GitHub’s handling of commit level review on PRs has improved a lot.
Small PRs should still be the goal for many reasons, but when it’s going to take way too much work to do, small commits that lead the reviewer through a story of the change being made can be very effective.
Re: Ask HN: Over the shoulder Code-Review in remote settings
#26Earlier quoted context omitted.
> My team posts their PR reviews in our team slack channel. Which bothers the totally async purist in me, but we’ve found it to be a good middle ground between waiting for reviews requested via GitHub email and actually pinging someone. Why don’t you install the GitHub Slack application? It will tell you immediately when somebody asks for a review and it has other useful functionality as well.
Oh, I guess some additional context is that by convention we use Slack emoji to indicate whether we approve, comment or request changes. Then again when it’s merged/deployed. Reviews aren’t specifically requested of individuals, usually just the entire team. That way, if it’s a channel everyone is in, other people can see at a glance whether they should still review the PR.
The github slack integration would post a message in a slack channel and then your team can use emojis to react to it just like you do.
Re: Ask HN: Over the shoulder Code-Review in remote settings
#27What was the point of "over the shoulder?" Did you do that to avoid blame? Or avoid someone outside the team seeing code review comments? This smacks of cultural fear.
Can you pop open an un-audited video session and have the reviewer drive while they inspect and talk about what they see?
Re: Ask HN: Over the shoulder Code-Review in remote settings
#28Earlier quoted context omitted.
Oh, I guess some additional context is that by convention we use Slack emoji to indicate whether we approve, comment or request changes. Then again when it’s merged/deployed. Reviews aren’t specifically requested of individuals, usually just the entire team. That way, if it’s a channel everyone is in, other people can see at a glance whether they should still review the PR.
The github slack integration would post a message in a slack channel and then your team can use emojis to react to it just like you do.
Will have to check that out then, thanks!
Re: Ask HN: Over the shoulder Code-Review in remote settings
#29ssh tunneled VNC clients.
The best programming I’ve done is remote with the other person staring at the same screen as me. We also had the same size screen so there was no scaling and such.
Makes switching between drivers seamless. Unfortunately my current team uses screen share on video chat apps. It’s the worst.