I Thought 'LGTM' Was a Typo for Two Months
My first pull request at my new job got three comments. Two were code suggestions. The third was from a senior engineer who wrote a single line: "LGTM."
I stared at it for a while. Was it an abbreviation for something? A typo? Some internal code name I hadn't been told about? I checked Jira — no project with that acronym. I searched our codebase — nothing. I even wondered if it was a keyboard slip for "LGBTM" or something similarly unrelated.
I didn't ask anyone because I didn't want to look clueless on my second week. So I just... moved on. The PR got merged by someone else, and I assumed "LGTM" was some kind of acknowledgment. I was right about that part, at least. "LGTM" means "Looks Good To Me" — it's the standard way to approve a pull request. I figured this out two months later, when I finally overheard someone say it out loud during a screen-share.
Two months. I had received dozens of LGTMs in that time, and each time I'd treated it as a vaguely positive signal without actually knowing what it stood for.
The acronym soup of code review
LGTM was just the beginning. As I settled into the team, I encountered a whole ecosystem of abbreviations that nobody ever explained:
- WIP — Work In Progress. A PR marked WIP isn't ready for review. I reviewed a WIP PR once and left detailed comments. My colleague responded "oh, this isn't ready yet — WIP 😄". I wanted to disappear.
- PTAL — Please Take Another Look. Used after you've addressed review comments and want the reviewer to check again. I'd been writing "I have made the changes you suggested, could you please review again?" every time.
- SGTM — Sounds Good To Me. A variant of LGTM for general agreement.
- TL;DR — Too Long; Didn't Read. Used to preface a summary. I thought it was an insult the first time I saw it in a design doc ("your document is too long and I didn't read it!"). It's actually the opposite — it's a courtesy.
- AFAIK — As Far As I Know. Signals uncertainty. When a senior engineer writes "AFAIK this is thread-safe," they're saying "I believe so, but I'm not 100% certain."
- IIRC — If I Recall Correctly. Same uncertainty hedge.
- nit: — Not an acronym, but a prefix meaning "minor nitpick." A nit is a small, non-blocking suggestion. When a reviewer writes "nit: spacing," they're saying "this is trivial and you don't have to change it, but I noticed it."
None of these appeared in any onboarding document. They weren't in the company handbook. They weren't in any English textbook I'd ever used. They're part of the oral tradition of software engineering — passed down through code reviews, Slack messages, and pair programming sessions.
The cost of not asking
Looking back, I wasted time and created awkward moments because I didn't understand these abbreviations. When someone wrote "WIP" in a PR title, I didn't know it meant "don't review this yet." When someone wrote "nit:" before a comment, I didn't know it meant "this is optional" — I treated every review comment with the same urgency, which meant I spent time on trivial changes that nobody expected me to make.
The worst was "PTAL." For months, when I updated a PR after review, I'd write a long message: "Hi, I've addressed all the feedback. I changed the function signature as you suggested, and I also added the error handling you mentioned. When you have time, could you please take another look? Thank you." My colleagues wrote "PTAL." Four letters. Same result.
This isn't about laziness or saving keystrokes. Using the standard abbreviations signals that you're fluent in the team's communication style. When I started using "PTAL" instead of a paragraph, my interactions with reviewers became smoother. Less to read, less to process, faster turnaround.
Beyond code review: the developer lexicon
The acronym problem extended beyond code review. In Slack and meetings, I encountered:
- EOD / EOW — End of Day / End of Week. "I'll have this done by EOD" is a commitment. But whose end of day? In a distributed team, this can be ambiguous.
- OOO — Out of Office. Simple but I didn't know it for weeks.
- IMO / IMHO — In My Opinion / In My Humble Opinion. Used to soften a strong statement.
- RFC — Request for Comments. Not the internet standards — teams use this for internal design proposals.
- DRI — Directly Responsible Individual. The person who owns a decision.
- P0 / P1 / P2 — Priority levels. P0 is "everything is on fire," P1 is "urgent but not emergency," P2 is "important but can wait."
Each of these carries implicit meaning about urgency, responsibility, and social norms. "I'll handle this EOD" means something different from "I'll handle this EOW." "IMO we should rewrite this" is softer than "we should rewrite this" — the prefix gives the reader room to disagree.
How I caught up
Once I realized the scope of what I didn't know, I took a systematic approach. I kept a document where I logged every unfamiliar abbreviation or phrase I encountered. At the end of each week, I'd look them up — either through DevGlish, which covers developer-specific jargon, or by searching developer forums and glossaries.
I also started a habit of asking. Not in public channels at first — that still felt too vulnerable. But I'd DM a friendly colleague and say "Hey, quick question: what does PTAL mean?" Every single person I asked responded instantly and helpfully. Nobody thought I was clueless. One person said "I didn't know what it meant for my first month either."
That response taught me something: the embarrassment of not knowing is almost always worse than the actual reaction of asking. Developers are generally happy to explain jargon. Most of them remember a time when they didn't know these terms either.
Advice for new team members
If you're joining an English-speaking engineering team for the first time, here's what I'd suggest:
Ask early. Every week you spend guessing is a week of slightly less effective communication. One DM takes ten seconds and saves you months of uncertainty.
Make a glossary. Keep a personal document where you log abbreviations and phrases. Review it weekly. After a month or two, you'll have internalized most of the common ones.
Use abbreviations yourself once you know them. Don't just understand them passively — adopt them. The first time I typed "LGTM" on a PR, it felt strange. Now it's second nature.
And if you're a senior engineer reading this: consider adding a jargon glossary to your team's onboarding docs. It takes twenty minutes to write and could save every new team member weeks of silent confusion. The things that are obvious to you aren't obvious to everyone — especially not to someone who learned English in a classroom where "LGTM" never appeared on any test.