If you clicked on this, you’re probably a developer. Or you’re in the process of becoming one.
Either way, welcome. You’re about to go through the same painful, slightly embarrassing, weirdly universal experiences every developer goes through.
At some point, I realized we all collect the same stories. Different languages, different stacks, different jobs, same pain. It’s almost funny how predictable it is.
So here’s a ranking of 10 developer canon events, from S tier all the way down to C tier, based on how common they are and how deeply they scar your brain.
1. “I’ll add tests later.”
The deadline is tomorrow.
The feature works.
And “later” feels like a reasonable plan.
It never is.
Every developer has said this at least once, and most of us have said it more than once. Untested code has a way of surviving just long enough to become someone else’s problem, and then eventually your problem again.
Somewhere in almost every codebase, there’s a little graveyard of comments like:
TODO: add tests
Nobody is coming back for them.
I’m putting this in B tier. Very common. Very real. But somehow still not as destructive as some of the others.
2. “It’s just a small fix” on Friday afternoon
It’s 4:30 p.m. on a Friday.
You have one tiny fix. Two lines. Maybe three. You tell yourself it’ll be quick. You push it, close your laptop, and mentally leave work.
Then later that night, Slack starts lighting up.
This is one of those lessons developers usually only need once. After that, the rule gets burned into your nervous system:
Do not push on Friday unless you absolutely have to.
There’s a reason this is basically engineering folklore.
S tier. No debate.
3. Debugging for hours, only to find a typo
You rewrote the function twice.
You pasted the error into ChatGPT. Then Claude. Then Cursor. Maybe even Gemini too.
Still nothing.
Three hours later, you finally spot it.
A variable was named receive in one place and recieve in another.
That’s it. That was the entire problem.
Debugging is already hard enough, but what makes it worse is how often the final answer is completely stupid. Not “complex.” Not “architectural.” Just stupid.
And honestly, that’s part of being a developer.
A tier.
4. “We should just rewrite it from scratch.”
The old codebase is messy. It’s ugly. It makes weird decisions. Half the naming feels cursed.
So naturally, you think:
“We should rebuild this properly.”
This idea is incredibly seductive, especially when you’re newer and still believe clean starts solve messy systems.
Usually, they don’t.
A few months into the rewrite, you realize the old code wasn’t random. A lot of those weird decisions existed for a reason. Not always a good reason, but still a reason.
This is one of those mistakes that makes you respect legacy systems a little more, even when you still hate them.
I’m putting this in B tier. Painful, common, and humbling.
5. “Works on my machine.”
You build the feature.
You test it.
It works perfectly.
Then your teammate pulls the branch and nothing works.
Different Node version. Missing environment variables. Hidden dependency. Local config that never made it into the repo. Some mystery setup step nobody documented because you assumed everybody “just knew.”
These five words may be the most famous excuse in software:
It works on my machine.
And to be fair, sometimes it really does.
That doesn’t help anyone else.
S tier. This is one of the most universal developer experiences on earth.
6. Accidentally committing your API key
This one hits fast.
You push your project to GitHub, feel good for about ten seconds, then notice your API key is sitting there in public like it pays rent.
Immediate panic.
Now you’re rotating credentials, deleting commits, checking logs, and promising yourself that from this day forward you will absolutely use environment variables like a responsible adult.
This is the kind of mistake you make once, and if you’re smart, never the same way again.
B tier.
7. Forgetting one await
Nothing crashes.
Nothing throws an error.
The function just quietly returns undefined.
You stare at the code forever because everything looks correct. And that’s the worst part. It looks correct.
Then you add one word:
await
Suddenly everything works.
Losing an entire afternoon to one missing word is such a specific kind of developer pain that I almost have to respect it.
A tier.
8. Looking at your old code and feeling embarrassed
You open a file you wrote last week.
And somehow it already feels like it was written by a stranger.
Why is the variable called data2?
Why is there a function named finalFix?
Why did you think this made sense?
It’s uncomfortable, but it’s also a good sign. If your old code makes you cringe, it usually means your standards improved.
That’s growth. Annoying growth, but growth.
B tier.
9. Getting woken up because production is down
This one feels different from the others.
Your phone goes off in the middle of the night. Production is broken. You’re half asleep, opening logs with one eye and trying to remember how your own system works while your brain is still basically dreaming.
Every developer who’s been through this remembers their first time.
It’s the moment you realize code is not done just because you stopped looking at it. Systems stay alive after you close your laptop, and when they break, they drag you back in.
It’s not fun. But it definitely feels like a real milestone.
A tier.
10. Thinking something will take two days
You look at a ticket.
It seems manageable.
You think, “Yeah, probably two days.”
It is never two days.
There’s always something. Edge cases. Setup problems. Random blockers. A weird issue in a library nobody has touched in three years. A missing requirement. A bug that only appears in staging for reasons known only to the gods.
We all know estimates are bad. We still give them anyway.
That’s what makes this one so funny.
C tier only because it’s less dramatic than the others, even though it happens forever.
Final thoughts
If you’ve done all of these, you’re either experienced, unlucky, or working in software long enough that those two things have become the same thing.
The funny part is that none of these moments really mean you’re bad at your job. They mostly mean you’re doing the job for real.
That’s something I wish more developers understood early on.
A lot of the pain in software isn’t a sign that you don’t belong here. It’s the opposite. It means you’re in it. You’re shipping, breaking things, fixing things, learning the hard way, and slowly building better instincts.
That’s the actual path.
Messy commits, bad estimates, forgotten awaits, Friday deploy trauma and all.
And if you’re building your own project, portfolio, or little side app while collecting these canon events, here’s one thing that may actually help:
I’d only add links like this sparingly, but if it helps support your work, fair enough.
Top comments (0)