60 Code Review Jokes Every Software Engineer Knows

LGTM is short for I did not read it.

I opened a PR. A reviewer left one comment. The comment was nit. The PR has been open for six days.

The PR was 800 lines. It got two comments. The first PR I opened that week was three lines. It got nineteen.

Reviewer A approved. Reviewer B requested changes. Reviewer A requested changes on the changes from Reviewer B. I am now a hostage negotiator.

Someone left a comment that said consider extracting this. No suggestion. No example. Just consider. I have considered. I am still considering.

I once approved a PR without reading it. It deleted the database. I learned to read PRs. My blame still shows my approval. The blame is forever.

The reviewer was on PTO. They were the only reviewer on the file. The file required two approvals. The PTO was three weeks. The bug was in production. The fix shipped after the vacation.

I left 47 nit comments. The author asked if I wanted to pair on it. I said no. I wanted to nit on it.

The CI passed. The reviewer asked for tests. I added tests. The CI passed again. The reviewer asked for more tests. I added more tests. The CI passed a third time. The reviewer left for lunch.

I asked a senior to review. She asked why the function existed. I deleted the function. The PR is now negative 40 lines. This is the best review I have ever had.

I rebased and force-pushed. The reviewer's comments lost their anchor. They asked me to leave the comments in place next time. I do not know how to do that. I have not figured it out in five years.

Someone bikeshedded the variable name for three days. The variable was used once, in a private function, that ran twice a year.

The comment said this is a personal preference, feel free to ignore. The comment was from the staff engineer. I changed it. I have a mortgage.

Resolved was a button. The reviewer un-resolved it. I re-resolved it. They un-resolved it again. We have been doing this for an hour. The PR is still open.

I approved a PR that broke production. The author approved a PR of mine that broke production a week later. We are now friends.

The PR description said small refactor. It touched 84 files. The CI passed because the tests were also part of the refactor.

I asked for screenshots. They sent a Loom. The Loom was 18 minutes long. The change was one CSS rule.

The author marked the PR as draft. It has been a draft for four months. The branch is six thousand commits behind. We agreed it was load bearing draft.

I left a comment that said this needs a comment. They added a comment that said see PR review for context. The context is the PR I am asking them to put in a comment.

The senior approved with a single emoji. It was a thumbs up. I have analyzed it for an hour. I think it means ship it. I am 70 percent sure.

I marked a comment as resolved. The reviewer wrote a follow-up that said please do not resolve my comments. I resolved that one too. The PR is still open.

There is a rubber-stamp approver on every team. There is also a stop-energy reviewer on every team. The trick is to learn which one is which before you tag them.

The author rewrote the function as a one-liner. The one-liner used three new operators I had never seen. The reviewer approved it. The on-call had to read it at 3am. The on-call did not approve.

I asked for a code review. I got a code rewrite. The reviewer pushed a commit. The commit is now in my history. I have to defend it forever.

The PR title was wip. It was merged. The title is now the commit message. The release notes pulled from the commit message. The release notes say wip.

I rebased to clean up the history. The history is now perfect. The CI failed on every intermediate commit. Bisect cannot use any of them.

I once left a comment that said I disagree but I will not block. They did the thing anyway. It broke the thing I said it would break. The blame is on me. I left the comment. I did not block.

Self-approval is on for hotfixes. Everything is now a hotfix. The team has not done a code review since November.

The PR was up for ten days. The author wrote a Slack message that started with friendly bump. The reviewer was on a different team. The reviewer left the company last week.

I commented on a line. The author moved the line. The comment now anchors to a blank line. The conversation is still about the moved line. The blank line has feelings.

Two reviewers approved. A third reviewer self-added and requested changes. The change request was about formatting. The formatter had not run. The formatter is a CI step. The CI was green.

I write better PR descriptions than commit messages. I write better commit messages than my code. I write better code than my tests. The tests are perfect.

I asked the reviewer how long the PR would take. They said end of day. The day was Wednesday. The year was unspecified.

The reviewer left a thread of 23 comments. They all said the same thing in slightly different words. The author addressed the first one. The reviewer marked the others resolved. The thread is now folklore.

I tagged five reviewers. Four ignored it. One approved. The one was the new hire. The new hire approved everything for their first month. We did not warn them.

Code review is the only meeting where one person does all the work and four people show up to disagree.

I once approved my own PR by accident. GitHub let me. The merge button lit up. The merge happened. The PR was wrong. The audit log is unkind.

The PR template asked for a test plan. The test plan said tested locally. The local environment differed from production in three ways the author had not noticed. The PR shipped. The third way found out.

I left a comment that asked are we sure about this. The author replied yes. I clicked approve. I am still not sure. They are not sure. We shipped anyway.

I once left a code review at 2am. It was lucid. The author said it was the best review they had received that quarter. I do not remember writing it. I do not want to know what I am like at 2am.

The PR closed three open issues. It opened four new ones. The math is correct. The team accepted it. We are a debt-driven organization.

The reviewer asked for a benchmark. I wrote a benchmark. The benchmark showed the change was slower. I deleted the benchmark. I shipped the change. The reviewer never asked again.

Stacked PRs sounded efficient. The base PR was merged. The stacked PRs all need rebasing. The rebase has eight conflicts per PR. I have three PRs left. I am rebasing.

Someone left a comment that said we should refactor this. The PR is a bug fix. The bug is in production. The refactor is a half day. The bug fix is two lines. I closed the comment with a thumbs up and ignored it.

I once left every comment as a suggestion block. The author clicked apply on all of them. The PR was now my code. The blame was theirs. I have done this on purpose ever since.

The PR was marked ready for review. The CI was red. The author tagged reviewers. The reviewers approved. The CI was still red. The PR merged via emergency override. It is now Tuesday.

I asked a junior to review my code. They approved in three minutes. They had not read it. I had not expected them to. We both played our parts. The PR shipped.

Conventional comments shipped. The team adopted them for two weeks. Then someone wrote a comment that started with nit:. The comment was about the nit prefix. The convention died on the spot.

I requested changes on a docs PR. The author had been on the team for nine years. I had been on the team for two weeks. The change was correct. The team is now talking to HR.

The reviewer left a comment that said see Slack DM. There is no Slack DM. The reviewer is asleep. The DM does not exist. The PR is now archaeology.

The PR is approved. The merge button is gray. There is a required check that has not run. The check has not run because the CI runner is down. The CI runner has been down since lunch.

I asked the reviewer for context. They wrote a 400-word reply. The reply made the original concern bigger. The PR is now a feature request. I closed it. I will rewrite it next quarter. I will not.

The PR description has nine bullet points. The code is one line. The disparity is the point. I am building credit for next quarter.

Two approvals required. The second approver is always the bottleneck. The first approver knows this. The first approver tags the second approver. The second approver is the first approver of someone else's PR. The cycle is the team.

I added a screenshot to the PR. The screenshot was a meme. The reviewer left a comment that said cute. Approved. I am keeping the meme strategy.

The reviewer left a 200-line comment explaining a design tradeoff. The comment was on a typo. The typo had triggered a deeper memory. The memory had been waiting eighteen months for an outlet.

I once labeled a PR do not review yet. Three people reviewed it. They all left comments. The comments were good. I addressed them. The PR was no longer the PR I had wanted. It was better.

Squash and merge erased six commits. One of those commits was the bug fix. The squash message says feature. The bug came back. The fix is now a story I tell, with no commit to point at.

Merge conflicts during review are a different bug from merge conflicts during deploy. The first is a long conversation. The second is a panic. Both end with three people in a meeting.

I have approved every PR this week. I have not read any of them. The team has shipped twelve features. None of them have broken. I am beginning to wonder what reviews are for.