Hypercare and Pull requests versus pair programming: Difference between pages

From ym2149.org
(Difference between pages)
Jump to navigationJump to search
No edit summary
 
No edit summary
 
Line 1: Line 1:
* period of a few weeks after the [[Big bang release]] when users do your testing for free
== Pull requests ==


[[Category:Waterfall]]
* 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
 
== 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
 
[[Category:Programming]]

Latest revision as of 21:16, 20 March 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

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