The Stoic Developer

Marcus Aurelius never had to explain why the build only fails in CI. He still wrote the best manual for dealing with it.

Stoicism has a bad reputation among developers because it sounds like “suck it up and keep quiet”. That’s not it. It’s a mental technology for separating what you control from what you don’t, and stopping the energy burn on the second category. Anyone who has spent a sprint arguing over whether it was the backend’s fault or the frontend’s knows exactly how much energy lives there.

The dichotomy of control, engineering edition

You don’t control: the priority the PM changed on Tuesday, the provider’s latency, the client asking for “something like ChatGPT but simple”, the infra team getting to your ticket two weeks from now.

You do control: the quality of your diagnosis, whether your PR is reviewable, whether your log says anything useful at 3am, whether you documented the why or only the what.

The trap is that the first list feels urgent and the second feels optional. It’s exactly the other way around. The first list is noise with a calendar; the second one is your job.

Amor fati applied to legacy

“Love your fate” sounds like something printed on a mug. In practice it means: that 2014 system with jQuery, three layers of inheritance and a cron nobody dares touch is not a cosmic injustice, it’s the terrain. You can spend the quarter grieving or you can map it, wrap it in characterization tests and cut off one leg at a time.

The developer who complains about the legacy and the one who dismantles it get paid about the same. Only one of them sleeps.

Premeditatio malorum, or postmortems before the incident

The Stoics practiced imagining disaster before it happened. We call it “failure analysis” when we want to sound serious and “what if this goes down on a Friday?” when we’re being honest.

A concrete exercise, 15 minutes before merging something big: write the postmortem of the incident it’s going to cause. What went down, which alert didn’t exist, what data was lost, who lacked the permissions to fix it. Half the time you’ll go back to the code to add a guard, a metric or a rollback. The other half you’ll merge with a clear conscience, which counts for something too.

What Stoicism is not

It’s not swallowing everything. The Stoic isn’t the one who endures a broken process in silence, it’s the one who says “this is broken” once, with data, in the right place, and then acts according to the answer they get. Passive resignation isn’t a virtue, it’s quitting with extra steps.

It’s also not never getting angry. It’s not writing the passive-aggressive comment on the PR. Seneca would have told you that anger is a terrible reviewer: it finds culprits, not causes.

The only KPI that matters

At the end of the day the Stoic question is simple: was this up to me? If the answer is no, you already spent too much. If it’s yes, stop typing in the Slack channel and go fix it.

Everything else is conference philosophy.