Pull requests versus pair programming: Difference between revisions
From ym2149.org
Jump to navigationJump to search
(Created page with "* I believe pull requests can be a cheaper way of achieving the same benefits as pair programming * But this requires a lot of discipline from the developer and the reviewer == Good article == * https://mtlynch.io/code-review-love/ of which i 100% agree with most points * writing a description should be a simple case of linking back to the Jira ticket * put cosmetic changes (if absolutely necessary) in their own commit so reviewers don't have to consider them * the rev...") |
No edit summary |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
* I believe pull | == Pull requests == | ||
* I believe [[pull request]]s can be a cheaper way of achieving the same benefits as pair programming | |||
* But this requires a lot of discipline from the developer and the reviewer | * But this requires a lot of discipline from the developer and the reviewer | ||
* nitpicks are like 30 million dollars for the perverted arts | |||
== Pair programming == | |||
* by far the best way to transfer knowledge between senior and junior | |||
** and it goes both ways e.g. junior will share some sick modern tricks | |||
* keyboard shortcuts, cli tricks and so on stick in the mind much more readily when learned by doing with guidance | |||
** similarly, a knowledge transfer session is much more effective when the audience does the steps guided by the presenter | |||
== Good article == | == Good article == | ||
* https://mtlynch.io/code-review-love/ of which i 100% agree with most points | * https://mtlynch.io/code-review-love/ of which i 100% agree with most points | ||
* writing a description should be a simple case of linking back to the | * writing a description should be a simple case of linking back to the ticket | ||
* put cosmetic changes (if absolutely necessary) in their own commit so reviewers don't have to consider them | * put cosmetic changes (if absolutely necessary) in their own commit so reviewers don't have to consider them | ||
* the reviewer may have fresh eyes, but none of the context, and should appreciate the author has made decisions based on much more knowledge of the situation | * the reviewer may have fresh eyes, but none of the context, and should appreciate the author has made decisions based on much more knowledge of the situation | ||
[[Category:Programming]] | [[Category:Programming]] | ||
Latest revision as of 11:29, 19 April 2024
Pull requests
- I believe pull requests can be a cheaper way of achieving the same benefits as pair programming
- But this requires a lot of discipline from the developer and the reviewer
- nitpicks are like 30 million dollars for the perverted arts
Pair programming
- by far the best way to transfer knowledge between senior and junior
- and it goes both ways e.g. junior will share some sick modern tricks
- keyboard shortcuts, cli tricks and so on stick in the mind much more readily when learned by doing with guidance
- similarly, a knowledge transfer session is much more effective when the audience does the steps guided by the presenter
Good article
- https://mtlynch.io/code-review-love/ of which i 100% agree with most points
- writing a description should be a simple case of linking back to the ticket
- put cosmetic changes (if absolutely necessary) in their own commit so reviewers don't have to consider them
- the reviewer may have fresh eyes, but none of the context, and should appreciate the author has made decisions based on much more knowledge of the situation
