Talk in English - US at PHP Tek 2026
View Slides: https://wkdb.yt/lgtm
Short URL: https://joind.in/talk/b3ee8
(QR-Code (opens in new window))
It's easy to tell when peer code review fails: a minor one line change is blocked with a dozen comments; a massive pull request with hundreds of files is approved with just "LGTM"; a critical requirement is missed; a production-breaking bug slips through; your reviewer is being a pedantic jerk; the reviewee thinks *you* are a pedantic jerk. Giving good code reviews is a skill just as creating good code and writing good tests: it takes practice.
This talk will mostly skip over the theory and various reasons why you should be doing peer code reviews. Many companies don't have a choice: code review is required explicitly or implicitly (as a standard secure coding practice) by many compliance frameworks, like SOC 2, HIPAA, PCI-DSS and GDPR.
What we will cover are practical, real-world strategies for successfully reviewing code, including:
- How to think through the code while reviewing it and finding issues
- When to approve versus when to block a pull request
- Writing review comments without being a jerk
- Pair peer code reviews versus traditional peer code reviews
- How to make the review process beneficial to both the reviewer and reviewee
- What parts of code review can be outsourced to code quality and AI review tooling
- How to review code in an unfamiliar language (e.g. Python, Rust, or Go)
Comments
Please login to leave a comment
Another fantastic talk from Mr. Andy Snell. I really appreciated that he took the time to break down must/should/could/etc. for reviews, as well as addressing the technical aspects *and* social contract.
It was a little AI-heavy for my taste, but that's not exclusive to this talk (it's an industry-wide issue).
You SHOULD see this talk, while you COULD do code review without it, there are plenty of MUST have insights Andy delivers that are relevant to what developers are working with right now.
But seriously, it's a great talk and I know that his insight has been practically tested and validated and shown to be incredibly valuable. It's not a 'well, it would be nice if we did it this way' theory, it's 'this is what I've found to be successful working on a high performing team'.
LGTM 👍
MUST: The content is excellent — lots of great advice. Keep all of it.
COULD: Add a proper introduction of who you are before or towards the start of the talk.
SHOULD: You jumped right into the talk. Since you were the first speaker of the day: it would have been good to check that people could hear you.
COULD: Give a general overview of the talk before jumping in. That said, I liked your opening — perhaps keep it, then add a quick overview after.
COULD: Slow down. You spoke a little too fast, especially at the beginning, though you did ease into a better pace as the talk went on.
Thank you for the talk, it "clarified" a couple of things I've been thinking about and will definitely be bringing back to my team.