I’ve learned so much in my career during code reviews. I’ve been getting paid to write software for 20 years this year. Code reviews became a standard expectation about 13 years ago, but I learned about them probably 15 years ago, starting with GitHub’s original pull request feature. I wonder what else I’d have learned with 7 years’ more time getting meaningful feedback and consensus from coworkers and fellow students. I’m glad “kids these days” are growing up with this feedback mechanism.
In the middle of last year, a teammate was curious why I’d started a branch and protected it in our GitHub project for work. They’d never worked with a dev branch, only feature/PR branches pulled into main. Then the PRs started flowing as I did my best to keep my reviews under the ~400 lines ± that Best Kept Secrets of Code Review and some other books recommend based on code review attention span research. We’re about to merge the dev branch for the new component into the main, and it’s about a 4,000 SLOC change in a Python codebase— most of it already reviewed— with another 12,000 SLOC worth of test data, most of which doesn’t need much review.
Recently, another dev on my team put up a large PR in one go, about a 1,500 SLOC change for the same codebase. No tests. If it had been broken down, I could have invested 5 minutes daily for the last two months and nudged about testing early on. Instead, the review took half a day and resulted in a block until there are tests.
I’ve learned so much in my career during code reviews. I’ve been getting paid to write software for 20 years this year. Code reviews became a standard expectation about 13 years ago, but I learned about them probably 15 years ago, starting with GitHub’s original pull request feature. I wonder what else I’d have learned with 7 years’ more time getting meaningful feedback and consensus from coworkers and fellow students. I’m glad “kids these days” are growing up with this feedback mechanism.
In the middle of last year, a teammate was curious why I’d started a branch and protected it in our GitHub project for work. They’d never worked with a dev branch, only feature/PR branches pulled into main. Then the PRs started flowing as I did my best to keep my reviews under the ~400 lines
±that Best Kept Secrets of Code Review and some other books recommend based on code review attention span research. We’re about to merge the dev branch for the new component into the main, and it’s about a 4,000 SLOC change in a Python codebase— most of it already reviewed— with another 12,000 SLOC worth of test data, most of which doesn’t need much review.Recently, another dev on my team put up a large PR in one go, about a 1,500 SLOC change for the same codebase. No tests. If it had been broken down, I could have invested 5 minutes daily for the last two months and nudged about testing early on. Instead, the review took half a day and resulted in a block until there are tests.
Review early, review often.
Related: https://conventionalcomments.org, a formatting convention for comments on, well, everything, but esp. code reviews:
E.g.
I’ve been using this convention with my team for a couple of years now, aided by the excellent Conventional Comments Web Extension by David Fournier.