Graduated in Digital Media M.Sc. now developing the next generation of educational software. Since a while I develop full stack in Javascript using Meteor. Love fitness and Muay Thai after work.
I came up with a review-based workflow with our Junior engineers: issues are discussed together via zoom (it also allows to annotate shared screen or record the session) and then I let the juniors work until the PR is ready.
Static issues (regression, lint) are catched up by the ci so we can focus we the review on what's the most important: exchange knowledge. Often the review (using GitHub review function for PR) is a two way discussion rather than me simply checking the code. It is also done via Zoom while sharing the screen with the PR review page open.
The Juniors explain what they came up with and why and I will comment on that and try to provide best practice solutions, in case there is one (design pattern, specific algorithms etc).
If the topic requires further explanation we often lookup resources together and discuss what they are about.
During all this we take comments with the review functionality on where we agree to change things. The PR is then not necessarily updated only by the juniors but also by me or both of us.
To keep things expressive we try to include many comments in the code, often we find those places that require extensive documentation during the sessions.
In the end we do a squash merge. I know this is far from classic pair programing but it turned out for us to be very effective in working on code AND exchange knowledge.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I came up with a review-based workflow with our Junior engineers: issues are discussed together via zoom (it also allows to annotate shared screen or record the session) and then I let the juniors work until the PR is ready.
Static issues (regression, lint) are catched up by the ci so we can focus we the review on what's the most important: exchange knowledge. Often the review (using GitHub review function for PR) is a two way discussion rather than me simply checking the code. It is also done via Zoom while sharing the screen with the PR review page open.
The Juniors explain what they came up with and why and I will comment on that and try to provide best practice solutions, in case there is one (design pattern, specific algorithms etc).
If the topic requires further explanation we often lookup resources together and discuss what they are about.
During all this we take comments with the review functionality on where we agree to change things. The PR is then not necessarily updated only by the juniors but also by me or both of us.
To keep things expressive we try to include many comments in the code, often we find those places that require extensive documentation during the sessions.
In the end we do a squash merge. I know this is far from classic pair programing but it turned out for us to be very effective in working on code AND exchange knowledge.