LGTM
el-jee-tee-EM
"Looks Good To Me" -- a code review approval indicating the reviewer is satisfied with the changes.
LGTM stands for "Looks Good To Me." It is the standard approval signal in code review. When a reviewer comments "LGTM" on a pull request, they are saying: I have reviewed this code and it is ready to merge. It is the green light.
In most teams, one or two LGTMs are required before code can be merged. GitHub formalizes this with "approved" reviews. GitLab has similar approval rules. The LGTM is the shorthand that predates these formal systems, dating back to Google's internal code review tools.
The term carries an implicit responsibility. An LGTM means you actually read the code, understood the changes, and believe they are correct. A drive-by LGTM without reading the code is a trust violation. Some teams distinguish between "LGTM" (I reviewed it casually) and "LGTM with comments" (approved but please address these minor points before merging).
Examples
A straightforward bug fix gets reviewed.
The PR changes three lines to fix a null pointer exception. The reviewer reads the change, checks that the fix handles the edge case, and comments 'LGTM.' The developer merges immediately. Total review time: 5 minutes.
A rubber-stamp LGTM causes a production incident.
A 600-line PR sits unreviewed for two days. Under time pressure, a teammate comments 'LGTM' after scanning the first 50 lines. The PR contains a race condition in line 450 that causes data corruption under concurrent writes. The incident takes 18 hours to diagnose. The team adds a policy: PRs over 200 lines require two reviewers.
A team establishes LGTM conventions.
The team agrees on three review signals. 'LGTM' means approved and ready to merge. 'LGTM with nits' means approved but the author should fix minor style issues. 'Needs work' means the reviewer found substantive problems. These shared conventions eliminate ambiguity about what an approval actually means.
In practice
Read more on the blog
Frequently asked questions
How many LGTMs should be required before merging?
One for most changes at small teams. Two for large or critical changes. Google requires one LGTM from an owner of the affected code. The right number depends on team size and risk tolerance. More reviewers catch more bugs but slow down delivery. Find the balance where review adds quality without becoming a bottleneck.
What are other common code review abbreviations?
PTAL means 'Please Take A Look,' used to request a review. NITS are minor style or preference comments that do not block approval. WIP means 'Work In Progress,' signaling a PR is not ready for review. SGTM means 'Sounds Good To Me,' used in discussions rather than code reviews. TL;DR means 'Too Long; Didn't Read,' sometimes used when a PR description is overly verbose.
Related terms
The practice of having other developers examine code changes before they are merged.
A proposal to merge code changes from one branch into another, with review.
Combining code changes from one branch into another, integrating the work.
Slang for deploying code to production. An expression of confidence that the code is ready for users.
Spending disproportionate time debating trivial details while ignoring important decisions.
Want the complete playbook?
Picks and Shovels is the definitive guide to developer marketing. Amazon #1 bestseller with practical strategies from 30 years of marketing to developers.