60 Technical Debt Jokes Every Senior Engineer Knows

"We'll clean it up later." Later was four years ago.

The TODO comment is older than the engineer reading it.

"It's a temporary fix." The temporary fix is now load-bearing.

I checked the git blame. The line was written by me. In 2019. I do not remember writing it.

"Technical debt is fine if we pay it down." We have not paid down technical debt since the company was founded.

Two kinds of teams: Those who track tech debt in a backlog, and those whose tech debt has its own backlog now.

"It's just a small workaround." The workaround has its own workaround.

The rewrite is scheduled for next quarter. It has been scheduled for next quarter since 2020.

"We'll add tests later." Later is now. There are no tests.

Every codebase has a folder called `helpers`. That folder is where dignity goes to die.

I trust new features. I just trust the bugs in old features more. At least I know their names.

"Move fast and break things." We moved fast. The things stayed broken.

The comment says: `HACK: fix this before launch`. Launch was eight years ago.

"Let's prototype it first." The prototype shipped on Tuesday.

A senior engineer is somebody who has watched a prototype become production three different ways and made peace with it.

"We can refactor in the next sprint." The next sprint has six feature tickets and zero refactor tickets, like always.

The function is doing four things. The function is named `process`. It has been like this for years.

"It's not technical debt if it works." It is. You are paying interest. You just don't see the statement.

The codebase has six different ways to handle errors. They were all introduced one sprint at a time, by different people, for different reasons.

"Just add a new column." The table has 84 columns. Forty-one of them are nullable. Twelve are nullable but populated. Three are populated only on Tuesdays.

I once wrote a one-line hotfix. The one-line hotfix is now a class.

"Why is the build slow?" Because every shortcut we took in 2018 is now a dependency.

The team agreed to allocate 20 percent of every sprint to tech debt. The team has allocated 0 percent in 18 months.

"We don't have time for tech debt." We also do not have time for the outages that the tech debt is going to cause. We just haven't scheduled those yet.

The codebase has a function called `handleSpecialCase`. It handles 14 special cases.

"What does this flag do?" It was added to fix a bug for one customer in 2017. The customer is no longer a customer. The flag is on by default.

The integration test suite passes locally. The integration test suite passes in CI. The feature does not work in production. The tests are mocking the wrong thing.

"It's a small change." The diff is 18 lines. The regression list is on its third page.

Every config file has a key called `legacy_mode`. It is set to true. It has been set to true since the option was introduced.

"Why did the deploy fail?" Because the deploy script silently assumed something that stopped being true two years ago.

I do not always document my workarounds. But when I do, the documentation is misleading.

"The previous engineer left good notes." The notes say: `see README`. The README is empty.

The codebase has three logging libraries. Nobody knows when the second and third were added. All three are required.

"We should standardize." We have tried to standardize three times. Each attempt added a new standard.

The architecture document was correct at the time of writing. The time of writing was a different product.

"How much tech debt do we have?" "How much do you have time to hear about?"

The team decided to bankrupt the legacy module and rewrite it. The rewrite is now four years old and considered legacy.

"Just delete the unused code." The unused code is referenced by a config in production. Somewhere.

There is a `deprecated_v2` folder. The code in it is still imported by three services.

"We chose this stack for velocity." We have not had velocity in three years.

I asked why the test runner has a 90-second startup time. The answer involved a fixture file from 2016 that nobody is willing to delete.

"It's idiomatic." Idiomatic in what year?

The on-call runbook has a section called `if X happens, do Y`. Nobody can remember why Y works. Y still works.

"Did anyone document the migration?" There were three migrations. The first two were undone. The third was never finished.

I read the design doc. The design doc describes a system that does not exist. The design doc is two years old.

"This was the right choice at the time." It was. It still cost us six months later.

Every team has a Slack channel called `tech-debt-discussion`. It has been quiet since Q2.

"We're going to do a tech debt sprint." The tech debt sprint got pulled in for a customer feature on day three.

The codebase has an abstraction. The abstraction has one consumer. The abstraction was written for a planned second consumer that never arrived.

"What's the latency budget?" It was 200 milliseconds. We are at 1,400. We renamed the dashboard.

The interest payment on tech debt does not show up in the budget. It shows up as new hires that are slower than the previous ones.

"We should rewrite this in Rust." The service handles 60 requests per minute. Calm down.

The CI pipeline has 14 steps. Number 9 has been failing for a year. We set it to non-blocking.

"We don't need a feature flag for this." We needed a feature flag for that.

The code review comment says: `we should refactor this`. The review is from 2019. The code is unchanged.

A new hire asked why we use the pattern. Nobody could explain it. We still use the pattern.

"We can address that in the next major version." There has never been a major version.

I do not fear horror movies. I fear opening a file named `utils.js` that is older than my career.

Some people read books. I read git blame and try to forgive my younger self.

Paying down tech debt is basically: Doing the work the previous version of the team should have done, with less context than they had, on a deadline they did not have.