What’s the Real Reason Programmers Work Late?

Hello, I’m Liang Xu. I often hear programmers blame product managers, bosses, or changing requirements for overtime, but those are not the root causes.

When I was an embedded developer, I routinely worked until ten p.m. and stayed on call weekends. I blamed others for endless requirement changes, incomplete docs, and last‑minute bugs.

Everything changed when a new teammate joined. He was technically average but never stayed late; he left at six p.m. and still met deadlines. Observing him for a month revealed a stark contrast: I needed three days to write a driver module, he finished in a day and a half. He didn’t waste time polishing trivial details—he used the simplest implementation that worked, whereas I repeatedly refactored for elegance.

First truth: Much overtime is self‑inflicted. Pursuing perfection often means debugging at 2 a.m., while the real work was delayed by meetings, distractions, or procrastination during the day.

Such overtime is praised as “dedication.” Managers see long hours as effort, colleagues see it as reliability, yet nobody questions the actual output. I witnessed a colleague who bragged about “fighting” every night, yet after three months his module was buggy, unfinished, and still received a performance award.

Second truth: Many programmers can’t say “no.” They accept every request, avoid confronting product managers or bosses, and end up handling all demands, turning themselves into “work dogs.”

After founding my own company, I noticed that people who constantly say “no problem, I’ll handle it” tend to work the most overtime and deliver the slowest, whereas those who question the purpose or priority of a feature are more efficient and work less late.

Third truth: Overtime often serves as an escape. Some developers stay late because they have nothing better to do after work—office air‑conditioning, free meals, and colleagues are more appealing than a lonely home.

Consequently, overtime becomes a way to avoid boredom, self‑improvement, or confronting personal issues, unrelated to actual workload.

Of course, some projects truly require extra hours due to tight schedules, but you should ask yourself how much overtime is genuinely necessary versus avoidable.

If you find yourself working late every day, the problem likely isn’t the boss or the product manager; it’s your own efficiency, planning, or resistance to change.

Now I rarely work overtime—not because I’m less busy, but because I recognize that extra hours don’t solve problems. I prefer a “good‑enough” solution in three hours over a “perfect” one in ten, freeing time to think about process improvements and team collaboration.

This, I believe, is what a mature programmer should do.