Why My Code Works Better at Night (And Other Lies I Tell Myself)

I write better code after midnight. At least, that's what I tell myself as I stare at my glowing screen, eyes dry, surrounded by the ruins of coffee cups and broken promises. Somehow, the bugs seem friendlier at 2 AM. They whisper, not scream. And I whisper back, promising to refactor tomorrow. Let’s talk about some of the deeply questionable things we developers believe. Not because they’re true, but because they help us survive. 1. “I’ll just write a quick script.” This is the original sin. It always starts simple. A little automation here, a tiny helper there. Five hours later, it has 12 flags, a YAML parser, and its own README. You start versioning it. Someone asks if they can use it, and you say yes. You are now in tech support. It was never just a script. It was the gateway drug. 2. “This is temporary.” Ah yes. The most permanent word in tech. Every TODO you leave in the codebase becomes sacred. Entire architectures are built around that “temporary” workaround you wrote in a rush. You knew it was bad. You even commented it, thinking future-you would care. Future-you does not care. Future-you has bigger fires. The worst part? Temporary code tends to be the most stable. No one touches it. It sits there, like an old god beneath the ocean, waiting. 3. “I’ll write tests later.” No, you won’t. Let’s be honest. Writing tests is like flossing. You know it's good for you. You talk about doing it. You recommend it to others. But deep down, you’re not that person. You only write tests when: Your code is in production. Something broke. You're trying to impress a senior engineer. 4. “I’ll remember why I did this.” You won’t. You’ll stare at a bizarre function six months from now with no idea what it does. The comments—if they exist—will say things like “fixes edge case” or “don’t remove this, it breaks everything.” You will debug it like it's someone else’s code, because functionally, it is. Past-you was a stranger. And possibly a saboteur. 5. “This is a learning opportunity.” This phrase gets repeated right after a major outage, a failed deploy, or a twelve-hour bug hunt that ended with “you forgot to save the file.” Yes, it’s a learning opportunity. But no one wants to learn like that. Some lessons come in the form of clean tutorials. Others show up wearing clown shoes and a flamethrower. 6. “We’ll clean it up in the next sprint.” No you won’t. That sprint already belongs to three hotfixes, a vague feature request, and a new metric someone invented during a meeting they forgot to invite you to. Refactoring is like New Year’s resolutions. Everyone wants it in theory, but the real world keeps showing up with other plans. Final Thoughts Software development is half logic, half superstition, and half caffeine-induced hallucination. If any of this feels painfully familiar, don’t worry—you’re not alone. We’re all just pushing code into the void, hoping our assumptions hold up for one more deploy. And yes, my code does work better at night. Please don’t test that.

Apr 30, 2025 - 22:12

Why My Code Works Better at Night (And Other Lies I Tell Myself)

I write better code after midnight. At least, that's what I tell myself as I stare at my glowing screen, eyes dry, surrounded by the ruins of coffee cups and broken promises.

Somehow, the bugs seem friendlier at 2 AM. They whisper, not scream. And I whisper back, promising to refactor tomorrow.

Let’s talk about some of the deeply questionable things we developers believe. Not because they’re true, but because they help us survive.

1. “I’ll just write a quick script.”

This is the original sin.

It always starts simple. A little automation here, a tiny helper there. Five hours later, it has 12 flags, a YAML parser, and its own README. You start versioning it. Someone asks if they can use it, and you say yes. You are now in tech support.

It was never just a script. It was the gateway drug.

2. “This is temporary.”

Ah yes. The most permanent word in tech.

Every TODO you leave in the codebase becomes sacred. Entire architectures are built around that “temporary” workaround you wrote in a rush. You knew it was bad. You even commented it, thinking future-you would care. Future-you does not care. Future-you has bigger fires.

The worst part? Temporary code tends to be the most stable. No one touches it. It sits there, like an old god beneath the ocean, waiting.

3. “I’ll write tests later.”

No, you won’t.

Let’s be honest. Writing tests is like flossing. You know it's good for you. You talk about doing it. You recommend it to others. But deep down, you’re not that person.

You only write tests when:

Your code is in production.
Something broke.
You're trying to impress a senior engineer.

4. “I’ll remember why I did this.”

You won’t.

You’ll stare at a bizarre function six months from now with no idea what it does. The comments—if they exist—will say things like “fixes edge case” or “don’t remove this, it breaks everything.”

You will debug it like it's someone else’s code, because functionally, it is. Past-you was a stranger. And possibly a saboteur.

5. “This is a learning opportunity.”

This phrase gets repeated right after a major outage, a failed deploy, or a twelve-hour bug hunt that ended with “you forgot to save the file.”

Yes, it’s a learning opportunity. But no one wants to learn like that.

Some lessons come in the form of clean tutorials. Others show up wearing clown shoes and a flamethrower.

6. “We’ll clean it up in the next sprint.”

No you won’t. That sprint already belongs to three hotfixes, a vague feature request, and a new metric someone invented during a meeting they forgot to invite you to.

Refactoring is like New Year’s resolutions. Everyone wants it in theory, but the real world keeps showing up with other plans.

Final Thoughts

Software development is half logic, half superstition, and half caffeine-induced hallucination. If any of this feels painfully familiar, don’t worry—you’re not alone.

We’re all just pushing code into the void, hoping our assumptions hold up for one more deploy.

And yes, my code does work better at night.

Please don’t test that.