Developers speak English. Mostly. But there's a second language running underneath it, one that every project manager, designer and client slowly learns to decode, usually the hard way.

After nine years of speaking it fluently, I think it's time someone wrote the dictionary. Entries are in no particular order, because sorting them was "a quick task" and I estimated it at five minutes.

The dictionary

"It's a quick fix."

Means: I know which file the problem is in. I have not opened it yet.

❌ Quick fixes are quick right up until you find the second place the same bug lives, and the test that was secretly depending on the bug.

"It should work."

Means: I have not run it. I have, however, looked at it with great confidence.

"Should" is doing an enormous amount of heavy lifting in this sentence. Its cousin, "it works", means I ran it once, on my machine, with perfect data.

"Minor refactor."

Means: I touched 47 files and renamed a concept everyone was used to. The diff is long but, I promise, emotionally small.

"Legacy code."

Means: code that makes money and that nobody wants to touch. Sometimes it means code written by someone who left. Occasionally it means code I wrote, but we don't say that out loud.

"It's not a bug, it's a feature."

Means: the system is doing exactly what the code says, which is not what anyone wanted. Sometimes, to be fair, users really do love it, and then it becomes a feature for real and nobody is allowed to fix it ever again.

"That's a known issue."

Means: I have seen this before, felt bad about it, and moved on. There may or may not be a ticket.

"I'll clean it up later."

Means: this code will outlive several phones, at least one framework version, and possibly the company's logo.

"Let me take a look."

Means: please give me 20 minutes to figure out what you're talking about before I admit I don't know.

"It's done, I just need to test it."

Means: it is roughly 60% done. The other 60% is testing.

"Works on my machine."

Means: the problem is somewhere in the difference between my machine and every other machine on Earth. I wrote a whole article about this one. It deserved one.

"Nobody will ever enter that."

Means: a user will enter that within the first week, probably an emoji, possibly in the phone number field.

"It's just a small change to the design."

This one is from the other side of the table, but developers have learned to translate it too. Means: it's a small change to the picture. The data model underneath is a different story.

Why we talk like this

It's easy to laugh (and we should), but the dictionary exists for a reason. Most of these phrases come from the same place: we're asked for certainty about work that's full of unknowns, so we answer with the best case and quietly hope.

"Quick fix" is usually an honest guess about the part we can see. The problem is everything we can't see yet: the second bug, the missing test, the edge case, the deploy, the review.

The useful bit: estimates people actually trust

The one habit that has improved my estimates more than any formula is to stop giving one number. Give a range, and say what the range depends on:

"If it's only the validation, an hour. If the same logic is copied into the mobile API, closer to a day. I'll know which within thirty minutes of looking."

That sentence does three things a single number can't:

• ✅ It's honest about the unknown instead of hiding it.
• ✅ It tells the other person what would change the estimate.
• ✅ It promises a quick update, so nobody is surprised two days later.

And if all else fails, "it should work" is still available. Just run it first.

Which phrase would you add to the dictionary? I'm sure I've missed a few classics.