At some point in every career, someone asks you to predict the future. Not literally. Nobody hands you a crystal ball in a meeting. But the question shows up in disguise, over and over: what’s going to happen to this role, this industry, this skill you’ve spent a decade building. And underneath the question is a hope.

If you could just get the prediction right, the fear would go away.

It won’t.

Share

After twenty-five years, I’ve seen developers ask about outsourcing. They also wonder about the cloud and no-code platforms. Each new trend brings fears that their jobs might disappear. A different decade brings the same question and hope: if I knew what was coming, I could stop my fear now.

That hope is a category error. Knowing the outcome in advance was never going to tell you what to do today. It only felt like it would.

Epictetus spoke about this clearly, avoiding the usual comforting quotes people share. He talked about how Romans practiced divination. It was common. You would visit a diviner, pay for a reading, and receive answers about how your plans might turn out. Epictetus didn’t tell his students to stop going. He told them to notice what the diviner could and couldn’t actually give them.

The diviner can tell you the event. He cannot tell you whether the event is good or bad for you, because that was never his to know. It was already decided, before you walked in, by what kind of decision you were prepared to make in response. If duty calls you to stand by a friend in danger, Epictetus says, and the reading comes back unlucky, you go anyway. The forecast doesn’t change the action. It was never going to.

Share The Stoic Coder

That’s the part people skip when they reach for prediction as a cure for anxiety. They imagine that if they could just see far enough ahead, they’d know what to do. But you already know what to do, or you know how to find out, using the same judgment you’d use whether the news is good or bad. Seeing the future in advance doesn’t hand you that judgment. It just moves the moment you’d need it. You’d still have to decide how to respond, on the other side of knowing, with the same self you have right now.

I think this is worth saying plainly for people in this field specifically, because our industry has a forecasting habit baked into it. We’re trained to estimate, to plan sprints, to model out what a system will need in six months. That instinct is useful for software. It’s close to useless for a career, because a career isn’t a system you’re designing from a spec. Nobody hands you the requirements in advance. You find out what the requirements were by living through them, the same way everyone before you did.

So what do you actually do instead of forecasting.

You do what Epictetus emphasized: decide ahead of time how you will respond, no matter the outcome. Not the outcome itself. The response. That’s the only part that was ever available to you before the fact, and it’s the only part that was ever going to matter.

This means the questions we should focus on aren’t “What’s going to happen to this skill?” or “Will this role still exist?” Those questions have no answer you can act on today, and chasing one is just anxiety wearing a research hat. The questions to consider are: If my fear happened tomorrow, what would the best version of me do next? Would I know how to learn. Would I know how to start over on something smaller than my ego wants. Would I still recognize good work when I did it, even without the title that used to certify it for me.

Answer those, and you’ve done the only preparation that was ever real. You haven’t reduced the uncertainty by one percent. You’ve made yourself into someone who doesn’t need it reduced.

Leave a comment

This isn’t resignation. People often hear “stop trying to predict the future” and think it means being passive. They believe it’s about just waiting for things to happen. It’s the opposite. Forecasting is actually the passive move, dressed up as diligence. You’re outsourcing your peace of mind to information you don’t have and can’t get. Deciding your response in advance is active. It’s the only thing in this whole equation that was ever yours to build.

I’ve watched this play out both ways across a career, in myself and in people I’ve worked with. Developers who focused on guessing future technologies often struggled when changes hit. The ones who did best were those who quietly developed the ability to be useful, no matter the direction. That capacity didn’t come from a correct guess. They decided ahead of time what kind of worker and person they would be, no matter what the news was.

You don’t need to see it coming. You need to already know who you’ll be when it arrives. Those are different problems, and only one of them was ever solvable.

👉 If you enjoy reading this post, feel free to share it with friends!

Or feel free to click the ❤️ button on this post so more people can discover it on Substack 🙏

You can find me on X and Instagram.

There was a time I worked as a team lead, still a developer but also closer to the customers. Basically, I was involved with feature requests as well as first in line for complaints.

The mechanics of that job are simple. Someone tells you the feature will be done in three weeks and the budget will hold.

So you take their word. Then you turn around and give that word to the customer.

A chain of people taking each other at their word, because the alternative is verifying everything yourself, which means the chain does not exist and neither does the work.

The word travels. What gets said in a standup does not stay in the standup. It gets carried into a room you are not in, by someone who has to keep facing the people in it long after you have moved on to the next ticket.

Share

The Break

Sometimes three weeks becomes five. Sometimes the budget was never going to hold.

I have been in the meeting after that. You explain it to the customer. You give them the reasons, and the reasons are usually real. Something was harder than it looked. A dependency moved. The requirements were less settled than everyone had been pretending. None of it is a lie.

But you are the one saying it, and the person who made the commitment is not in the room. They are back at their desk, working. From where they sit, the outcome was a date that moved. From where you sit, something got spent that does not come back.

Missing the date is frequently nobody’s fault. I have said before that an estimate was never a promise about a future you control, and I still think that.

The failure is somewhere else.

The Gap

In almost every one of these, the person doing the work knew before I did.

Not with certainty. Not with a new number. But they knew.

There is a day, usually well before the deadline, when the person building the thing stops believing their own estimate. They do not announce it. They keep working. They tell themselves they can make it up, and sometimes they do.

That gap, between the day you stop believing it and the day you say so, is the whole subject.

Because during that gap the number is still circulating. Somebody is still repeating it. Still planning against it. Still telling a customer it is on track. Still declining to line up a fallback, because as far as they know there is no reason to.

Every day of that silence is a day somebody else spends credibility on your behalf, out of an account you do not own and cannot see the balance of.

You were not idle during that gap. You were working hard. That is what makes it so easy to miss. It feels like effort, because it is effort, aimed at the wrong obligation.

The miss was never fully in your control. The gap was entirely in your control. It is the only part of this that ever was.

Leave a comment

The Other Side

I have been on the other side of it.

I have held a number past the point I believed it. Not out of dishonesty. It felt like loyalty to the work. Saying something early feels like quitting early, like asking to be let off before you have really tried. So you stay quiet and you push, and staying quiet feels like the more committed thing to do.

It is not. It is the cheaper thing to do. Speaking up early costs you something immediately, in the moment, in front of people. Staying quiet costs somebody else, later, out of your sight.

Every incentive you can actually feel in your body points at the second one.

Epictetus noticed that we only count a loss when it is material.

Money, property, a limb. Then he asked whether fidelity is not also something a person can lose, and whether losing it is not also damage.

Nothing material moves when a date slips. The retro finds a process cause. The estimate gets called optimistic.

Every measurement comes back clean, because nothing measures the thing that actually got spent.

Share The Stoic Coder

What It Costs to Fix

The practice is small.

Tell the person repeating your number on the day you stop believing it.

Not the day it comes due. Not once you have a recovery plan, or a root cause, or a version of the story where you come out reasonable. The day the belief changes. On that day you usually have nothing useful to offer except the fact itself.

Say it anyway. I said three weeks. I no longer think three weeks is right. I do not have the new number yet. That is a complete message. It is enough for somebody downstream to stop spending.

You will be wrong sometimes. You will say it, then make the date anyway, and feel like you raised an alarm over nothing. Take that trade. The cost of being early and wrong lands on you, in one uncomfortable conversation you will forget inside a month. The cost of being late and right lands on somebody who trusted you and never got told there was a decision being made.

Right now somebody is repeating a number you gave them, to a person they have to face again next week.

Whether it is still true is something you know and they do not.

👉 If you enjoy reading this post, feel free to share it with friends!

Or feel free to click the ❤️ button on this post so more people can discover it on Substack 🙏

You can find me on X and Instagram.

I cannot point to one person. That is the first problem with writing this down.

There is no single developer I can name, no particular afternoon I can put a date on. It happened often enough over twenty five years that the faces run together. Someone came to me stuck, I looked at what they were stuck on, and I built enough of it to get them moving. Then I went back to my own work feeling like I had done the right thing, because I had.

One of them still surfaces, though.

Share

We had a client with a public website we had built for them. Product catalog, entity model we had designed a year or so before, all of it stable and working. They had another internal system holding the authoritative product data, and they wanted that data on the site. The export came out as CSV. A decent number of fields, each one needing to land somewhere in the entities we had already built.

The work was a parser. Read the file, map the columns, build the objects, handle duplicates, validate that the required fields were actually there. Straightforward in shape, fuzzy in the details, the kind of ticket that looks small until you are inside it.

The developer assigned to it was junior. Solid for his experience, the sort you hand real work to because he would finish it.

This was years before anyone was pasting a CSV into a model and asking for a parser back. If he got stuck, he was going to Google it, or read the docs, or find a Stack Overflow answer from 2009 and work out which parts still applied.

I had written a lot of file parsers by that point. So I sat down and knocked out a start. A few hours. The file was open, the stream was reading, three or four fields were mapped into the entity, and I wrote one validation check as an example of the pattern. Not tested properly. Not finished. Deliberately not finished. I left most of it for him.

Then I sent it over and went back to my own work.

He finished it. It worked. The import ran, the products showed up on the site, and nobody mentioned it again.

A few hours of my time against what would have been a few days of his. The client had a date. I knew this problem cold and he did not.

And I did not hand him a finished routine. I want to be clear about that too, because it is the part I was quietly proud of at the time. I held back on purpose. I left him the bulk of it.

Here is what I actually left.

The remaining fields, which were the same operation as the first three, repeated thirty times.

The duplicate handling, which was the one genuine open question in the ticket, except the database already had a constraint on it. So the answer was not something he had to reason toward. It was going to arrive as an exception at insert time and he was going to catch it. That is debugging. Debugging is a fine thing to learn. It is not the same as deciding what a duplicate means for this client’s product data and then going to find out whether the schema agreed with you.

The validation was closed by the example I wrote. One instance of a pattern turns every remaining case into copying.

The entity mapping was closed by the three fields I had already mapped, which said, in effect, these go here.

And the question of what the ticket even was, whether this was a parsing problem or a modeling problem or a business rules problem wearing a parser costume, was closed before he opened the file. Because a file already open and a stream already reading answers that question. It says: this is typing. Follow the pattern.

So he typed.

Share The Stoic Coder

I left him the bulk of it, and the bulk of it was grunt work. Every question in that ticket that could have taught him something had already been answered by the time he saw it. Some of them by me, one of them by the database, and the largest one by the shape of what I sent.

That is the part I got wrong, and it is not the part I would have guessed.

What I could have sent instead was smaller and would have cost me fifteen minutes. A link to the docs for reading a file in C#. A note that there was a stream API worth understanding before he picked an approach. And a question: which of our entities do these columns belong to, and what makes a row a duplicate here?

That version takes him longer. Days, probably, and some of those days are him going in a direction that does not work and coming back. From the outside, those days look identical to being stuck. They are not. They are the only part of the ticket that was going to leave anything behind.

I have written a lot about choosing difficulty. Doing the hard version on purpose. Staying in the confusion instead of reaching for the thing that ends it. All of it aimed inward, at myself, or at you doing it for yourself.

That handoff was a decision about somebody else’s difficulty. His formation, his hours, his chance to hit the edge of what he knew and go find out. I spent all of it and it cost me nothing. I was not even the one who would have had to sit through the slow days. He was.

That is a strange kind of authority to hold over another person’s week, and I did not know I was exercising it.

The feature shipped. The client was satisfied. He finished the work and I imagine he felt fine about finishing it, and I felt fine about having unblocked him. Every visible signal available said this went well.

Compare that to the mistakes that actually teach you something.

Years ago I built one feature in a stable system using a framework nobody else on the project used, because the standard approach felt boring. That one buckled under production load, cost weeks to rebuild, and cooled a client relationship in a way I could feel in meetings for months afterward. I learned it immediately, because it hit me in the face.

This one thanked me.

Leave a comment

I still do not know what it cost. Maybe nothing. Maybe he wrote five more parsers and the sixth one taught him everything mine skipped. Maybe he is better at this than I am by now. I am not going to claim a harm I cannot demonstrate.

But the absence of a bad outcome is not evidence that the call was right, and a mistake that produces no evidence in either direction is one you can go on making for twenty five years without anything ever stopping you. No test catches it. No review raises it. No retro has a column for it. And the person on the other end cannot see what he was not given, because you cannot see the shape of an absence when the absence is all you have ever worked in.

I wrote that sentence once about my own first four years, working without a senior developer anywhere near me. It points in both directions.

The whole thing came down to a single seam, and I cut it in the wrong place. I kept the decisions and gave away the typing.

None of this had anything to do with AI, which is exactly why it is worth writing down. This was one person with a few hours and good intentions, deciding by hand where to divide a task, and dividing it in the place that removed everything worth having. The tools did not invent this failure. They inherited it. What I did occasionally, for one developer, while trying to leave something behind, is now available instantly, to anyone, on request, with no intention behind it at all and nobody on the other end deciding which half to keep. The seam has not moved. It just gets cut a thousand times a day now, by something that is not thinking about it.

So the question I did not ask then, and try to ask now, is not whether I have time to help.

It is whose difficulty this is, and which half of it I am about to spend.

👉 If you enjoy reading this post, feel free to share it with friends!

Or feel free to click the ❤️ button on this post so more people can discover it on Substack 🙏

You can find me on X and Instagram.

You write the function, run the suite, watch it go green.

I have argued before that the compiler is the one judge you cannot talk past. A tired reviewer can be worn down. A manager against a deadline can be managed. A failing test cannot be negotiated with. I still believe that, and I left out half of it.

The judge answers one question: Is this correct?

It has never once answered what the correct thing does to anybody.

Nothing else in the pipeline answers it either.

Share

Hierocles Drew Circles

There was a Stoic in the second century named Hierocles. Nearly all of him is lost. One image survived.

Picture yourself at the center of a set of rings. You, then your household, then relatives, then neighbors, then the city, and at the far edge everyone else. Strangers you will never meet.

Drawing the rings was not the point. He wanted you to pull the outer ones inward, to treat someone further out the way you would treat someone a ring closer. His method was oddly specific. Change what you call them. Address the cousin as a brother, the uncle as a father. Fix the language and let the feeling arrive behind the name.

He is not asking for impartiality. Closer stays heavier. The instruction is narrower than it sounds and it is achievable. Move one ring.

Now put a deployment in the middle of that diagram.

In his world, distance and effect traveled together. The stranger sat at the far edge because your life did not reach them. The rings measured closeness and consequence at the same time, because those were the same measurement.

They are not the same measurement anymore. The person at the outer edge of your rings is living inside a decision you made in ninety seconds and never revisited. The distance held. The effect collapsed. You reach the last ring hourly, at volume, feeling about it exactly what anyone feels about the last ring.

I am not standing outside this. Code I wrote years ago is still running and I could not name one person who runs it. Not a name, not a job, not a room they sit in. That does not make me negligent, it makes me a working developer. The job is built that way.

And our word for them is users. A container you can put a million people into and carry with one hand. Hierocles would have recognized immediately what that word is doing.

Leave a comment

You Don’t Pick the Features. That Was Never the Obligation.

You did not choose the product. You did not write the requirements. You were handed a ticket with acceptance criteria attached, and the decisions that determine what this software does to people were made in rooms you were not in. Push back hard enough and often enough and you get managed out, and the thing ships anyway with somebody else’s name on the commit.

All of that is accurate. It is also the most load bearing excuse in this profession, and it is covering for a pile of decisions nobody made you make.

The timeout you picked without thinking, which decides whether someone on a bad connection finishes the form or loses everything they typed into it.

The error message you left as “An error occurred. Please try again,” read at eleven at night by somebody with no idea whether their money moved.

The validation rule you tested against your own name, which rejects a real one for having an apostrophe in it.

The retry that quietly swallowed a failure, so someone believes their submission went through.

Nobody assigned you those. No reviewer will comment on them. They take under two minutes each, and they are the parts of the system a stranger actually has to stand inside.

That is the obligation, and it is smaller than it sounded. Not the roadmap. The ninety-second decisions, and what you are willing to say out loud before the thing ships.

Share The Stoic Coder

Nothing Will Prompt You

There will never be a ticket that says a human being is on the other end of this. The suite will not check for it. The linter has no rule. The retro will not get to it. Every prompt this job gives you points at the machine, because the machine is the part that answers in seconds.

So it has to be deliberate, and small enough to survive a normal week.

Before you close the ticket, take one pass through it as one person. Not users. One. Somebody with a bad connection, an unusual name, a reason to be doing this at eleven at night, and no idea what any of your words mean. Then read your own work back and ask what the next five minutes look like for them.

That is the practice. It costs a minute and it will not always change anything.

You still will not learn their name. That part is permanent. The rings do not close.

You pull anyway.

👉 If you enjoy reading this post, feel free to share it with friends!

Or feel free to click the ❤️ button on this post so more people can discover it on Substack 🙏

You can find me on X and Instagram.

I spent my first four years without a senior developer.

The first three were at a startup. I was hands on with everything, learning whatever I could get in front of, figuring things out because there was nobody else to figure them out. Year four was an agency. Strict, fast, the kind of place where a lot of your energy goes into not getting hit by whatever is coming next. I learned a great deal in both places.

What I did not learn was what I was missing. That part does not announce itself. You cannot see the shape of an absence when the absence is all you have ever worked in. I thought I was doing the work, and I was doing the work.

Year five was another startup, and this time there was Terry.

I picked up a project he had started, and early on he walked me through his build and testing setup. It did not make sense to me. Writing code to test code looked like a tax on getting anything done. You can see the application. You can click through it. Why build a second system to tell you what your eyes are already telling you.

Then the dev cycle did what dev cycles do. Changes went in. One small change, in a place that looked unrelated, broke something that mattered. Not visibly. The screens came up. Everything worked the way it was supposed to look. Underneath, a value was wrong, and that wrong value went downstream and became a data problem nobody would have caught by clicking around.

The tests caught it. That was the moment the whole thing turned over.

What Terry handed me was not a testing framework. It was the understanding that a system appearing to work and a system being correct are two different claims, and only one of them can be verified by looking. Four years of hands on experience had not gotten me there. One person, one project, one afternoon of being walked through something I was sure was overhead.

I never paid Terry back. I could not have. At the time I did not know the size of what I had been given.

Share

Marcus Kept A List

Marcus Aurelius opens Meditations with an inventory.

Not a meditation on gratitude. A list. His grandfather, his mother, his teachers, the emperor who adopted him, each one named, each one credited with something specific. From this one, how to read carefully rather than skim and call it reading. From that one, not to be taken in by nonsense. The most powerful man alive began his private notebook by accounting for which parts of himself were not self-made.

He settles none of it. Most of the people on that list were dead by the time he wrote it. There is no plan in Book 1 to repay anyone, because repayment was not available. The purpose of the list is not sentiment, it is accuracy.

A Favor Closes. A Debt Does Not.

A favor is optional, and it flatters whoever grants it. You did something you did not have to do, the other person says thank you, and the ledger closes. That is how most of this industry thinks about mentorship. A generous thing a senior does when there is bandwidth for generous things.

A debt is a different instrument. It is a fact about your position whether you acknowledge it or not. It did not require your consent and it does not close when you say thanks.

So do the accounting. Separate the parts of your judgment you built alone from the parts that were handed to you. Not facts. Facts are available anywhere, that is what documentation is for. Judgment: what you weigh before you commit, what makes you slow down, what you refuse to ship. A meaningful share of it came from people who got nothing back for giving it to you.

The Company Is Not The Counterparty

I have spent two years writing that employment is transactional, and none of it gets walked back here. The company will drop you in a quarter if the numbers say so. Hold your career accordingly, without illusions and without loyalty nobody paid for.

That has nothing to do with this.

The debt to Terry never sat on the company’s books. The company could not settle it, could not cancel it, and had no standing in it. Quitting does not clear it. A bad employer does not void it. Those are transactions with the entity signing the checks, and this is a separate account entirely.

Confusing the two is how a lot of good developers arrived at the conclusion that they owe nobody anything, when the true version is narrower: you owe the company nothing.

Leave a comment

“Why would I train my replacement”

The objection shows up on schedule, and in this market it is not stupid. Junior roles are thinning. Companies are asking out loud whether they need the position when the tools cover the output. The pressure is real, and it makes refusing look like prudence.

Here is what it misses.

Terry had the same option. He was a senior developer at a startup with somebody else’s junior on his project, and the arithmetic of spending an afternoon on my testing education instead of shipping was not favorable to him. Nobody paid him extra. It did not go on a review. He did it anyway, and he did it well enough that I am still describing it twenty some years later.

The obligation was never contingent on the math working out. That is exactly what separates it from a transaction. A debt payable only when convenient is a favor, and we have already been through what a favor is.

A thinning pipeline does not lighten what you owe. It makes you one of a shrinking number of people still able to pay it.

What Paying Looks Like

Mostly it is unglamorous, and mostly it costs time you would rather spend shipping.

It looks like walking someone through the thing they are certain is overhead, and staying in the conversation past the point where they nod, because Terry did not stop at my first nod.

It looks like letting confusion sit instead of resolving it for them. Answering with the wrong amount of help is the most reliable way to spend the time and transmit nothing.

That is most of it. The cost is real, and the return does not come back to you.

Share The Stoic Coder

The Chain Only Runs One Direction

Epictetus never wrote anything down. Everything we have from him exists because Arrian, a student, took notes and kept them.

Musonius taught Epictetus. Epictetus taught Arrian. Arrian wrote it down, and a copy of that reached Rusticus, and Rusticus handed it to Marcus, who read it and started a notebook of his own, which reached you.

Not one of those debts ran backward. Marcus never repaid Rusticus and could not have. What he did instead was become the kind of emperor Rusticus made possible, and then write it down for whoever came next.

You are on that chain whether you intended to be or not. Somebody put you here.

The payment only goes forward.

👉 If you enjoy reading this post, feel free to share it with friends!

Or feel free to click the ❤️ button on this post so more people can discover it on Substack 🙏

You can find me on X and Instagram.

A while back I was building an iOS app and hit a spot where I needed user data to sync automatically across a person’s devices. In Apple’s world that means wiring your data layer up to CloudKit. I was using SwiftData, the current way to handle persistence, so I asked the model how to connect the two.

The first session, it handed me a solution built on Core Data. Core Data is the older framework, the one SwiftData was designed to succeed. The code was not wrong, exactly. It would have run. It was just the previous decade’s answer to a question I was asking this year, and nothing in the response mentioned that.

I asked the same thing again in a separate session. This time it surfaced Apple’s own documentation and walked me straight to the current SwiftData approach, the one I had been looking for in the first place.

Same question. Two sessions. Two different answers, and the gap between them was not noise. It was years of framework design. If I had only ever run the first session, I would have built on the old way and never known the clean one was sitting right there.

Share

The First Tool That Samples

I have used a lot of tools in twenty-five years. Compilers, debuggers, linters, editors, build systems. Every one of them had a property so basic I never once thought about it: it did the same thing twice. Feed it the same input and it hands you back the same output, today, tomorrow, on the machine in the next room. That sameness is the reason I could trust a tool without watching it. I never had to sort my instruments into ones I could rely on and ones I could not, because none of them had ever surprised me.

The model is the first tool on my desk that samples.

Ask it the same thing on Tuesday and Thursday and you may get two different answers, both fluent, both confident, one of them wrong. It draws from a distribution instead of returning a fact, and the interface is careful not to remind you of that.

A deterministic tool can be wrong. A compiler with a bad flag will be wrong the same way every time, and you can find the pattern and route around it. What the model takes away is reproducibility. The wrongness moves. You cannot build a stable relationship with an instrument that will not hold still, and reproducibility was the quiet thing that let you off-load to every tool you ever trusted. Pull it out and the tool does not get less useful. It gets differently useful, in a way most developers have not accounted for.

Operating Is Not Controlling

The trap is not that the model is unreliable. You can plan around unreliable. The trap is that it does not feel unreliable while you are using it.

You prompt it. You refine the prompt. You do not like the answer, so you re-roll, steer, add a constraint, try again. The whole loop feels like driving. Your hands are on the wheel the entire time, and a thing you are steering feels, in the moment, like a thing you control.

Epictetus opens the Enchiridion by cutting the world in two. Some things are up to us and some are not.

Up to us: our judgments, our choices, what we assent to.

Not up to us: everything else, no matter how close it sits to our hands.

The whole of the philosophy runs on sorting each thing into the right column and then spending your energy only in the first one. Get the sort wrong and you pour yourself into things you were never going to govern, and call the exhaustion that follows bad luck.

Operating a thing is not the same as controlling it. You operate the market when you place a trade. You do not control where it goes. You operate the weather in the sense that you decide when to walk out into it, and you control none of it. And you operate the model when you prompt it, but what comes back is not up to you. It is a sample. You did not produce it. It happened to you, dressed up as something you made.

That is the misclassification, and almost everyone is making it. The output arrives, it is articulate, it appeared in response to your keystrokes, so it files itself under mine, produced, up to me before you have thought about it. Then you stake real weight on it, because that is what you do with things you made yourself.

Leave a comment

The Question Changes

Put it back where it belongs. The model’s answer is not up to you. File it under the same heading as the weather and the market and every other external that does not check with you first, and watch what changes.

The question stops being do I trust this. Trust is the wrong frame for an external that samples, the same way trust is the wrong frame for a coin. The question becomes how much am I willing to build on an answer I cannot reproduce. That is a question with a real answer, and the answer moves case by case. A throwaway script, build on it freely, the cost of a bad draw is nothing. A date calculation in a payments path, verify every line yourself before you stake a cent of your judgment on it, because the confident wrong answer costs the same whether a person or a distribution handed it to you.

You start treating the model the way a Stoic treats anything that will not behave. You plan around its behavior instead of trusting its consistency. It is the brilliant contractor who is sharp on Tuesday and wrong on Thursday and never tells you which day it is: you use the work, and you check it, and you do not hand him the keys. You do not fire the weather for raining. You bring a coat.

The Oldest Competence

None of this is a new practice you have to install. This is the oldest competence the philosophy has. Stoicism was never built for a world that behaves. It was built for weather, markets, other people, the body, luck, every force that acts on your life without consulting you. Two thousand years of the discipline is one long training in living well next to things you do not control. The non-deterministic tool is just the newest member of that ancient family.

What is new is only this: it is the first one that lives inside your workflow and wears the costume of something you own. The market is honest about being outside you. The weather never once pretended to be your idea. The model does pretend, every time it answers in your voice to your prompt, and the pretense is the whole of its power to pull you into the wrong column.

So do the thing the philosophy has always asked. Sort it correctly. The output is not yours and never was. Once it sits in the right column, it loses the one thing it had going for it, which was the illusion that you made it and can therefore trust it like you trust your own reasoning. You cannot. You did not do the reasoning. Something drew a sample.

That is the entire move. Not a habit, not a checklist. Just putting a thing back where it belongs, which is the first thing the Enchiridion ever asked anyone to do, applied to the strangest tool a developer has ever been handed.

Share The Stoic Coder

👉 If you enjoy reading this post, feel free to share it with friends!

Or feel free to click the ❤️ button on this post so more people can discover it on Substack 🙏

You can find me on X and Instagram.

The system ground to a halt on a slow query. A table I owned had grown too big to scan the way the query was scanning it, and I had never added the index that would have kept it fast. Under light load, nobody would have noticed. Under real load, it fell over, and everything behind it fell over too.

We fixed it. That is almost never the hard part. The hard part is the meeting afterward, where everyone sits down to work out what happened. My turn came, and there was nothing to work out. I knew exactly what it was. So I said it. That was me. Then I gave them the detail: I missed the index.

Three words. They should be the easiest three words in the room, and they are the hardest, because most people cannot make themselves say them clean.

Share

The Reflex That Is the Real Failure

Watch what happens when a mistake has an owner and the owner starts to talk. The admission almost never comes alone. It comes with reasons. There was a lot going on that sprint. The ticket didn’t mention the growth projections. Nobody flagged it in review. The staging data was too small to catch it. Every one of those might be true. None of them is the admission.

Those reasons are not lies. They are a way to put distance between you and the mistake, because in that moment the two feel like the same thing. If I broke it, then I am the guy who breaks things. So the explanation comes first, to take the hit before the admission lands.

That reflex is the real failure in the room. Not the outage. The outage was a missing index, a known, boring, solvable thing. Spreading a mistake around until no one quite holds it, that is what makes a post-mortem useless. A mistake that belongs to everyone belongs to no one, and nothing that belongs to no one gets fixed.

Owning It Flat

Here is where the oldest idea in Stoicism does real work. The mistake is already in the past. It happened. It is done. It is no longer one of the things you can act on. You cannot un-ship it. You cannot argue it back into staging. It is outside your control now.

What is still yours is your response to it. That is the part you control, and it is the only part you were ever going to control. So the clean sentence is not you exposing yourself. It is you being accurate. “I made a mistake” describes something that happened. “I am the mistake” is a claim about who you are. They are not the same claim, and the practice is keeping them apart.

Once you see that, the flat sentence costs almost nothing. That was me. I missed the index. Nobody’s character is on trial. There is a cause, and there is a person who is going to help make sure it does not happen again. You say it the way you would report the query time. It is just another fact about the system.

Leave a comment

What the Flat Sentence Does to the Room

I used to think owning a mistake cleanly was a personal thing, a matter of not being a coward. It is more than that. It is the most useful thing you can do for everyone else at the table.

Marcus Aurelius kept coming back to a distinction that turns on a single letter. In Greek, he wrote, you can call yourself a limb of the body of rational beings, melos, or just a part of it, meros. A part sits next to the other parts. A limb belongs to them. When one limb takes a hit, it takes the hit so the body keeps working. (Meditations 7.13.)

That is what clean ownership does in a post-mortem. When you take the mistake plainly and completely, you end the search before it starts. Nobody has to work out whose fault it was. Nobody has to defend themselves. Nobody has to avoid saying your name while everyone in the room already knows it. You said it. There is nothing left to sort out, so the room stops looking and starts fixing. One limb took the hit. Everyone else keeps working.

People treat accountability as a cost they pay. It is not a cost. It is the fastest way to get the room to the only conversation worth having, which is how to stop this from happening again.

Share The Stoic Coder

Why Process Over Person Actually Works

The best post-mortems I have sat in did not spend their time on people at all. They went straight to the process. Why did staging data not look like production? Why was there no check on query time before a table shipped? What guardrail would have caught this without anyone having to be a hero? The failure was treated as a condition to design around, not a moral event.

It is tempting to credit that to everyone agreeing to be kind. That is not what makes it work. A room stays on the process because someone shows them how first. When the person closest to the mistake owns it flat, with no excuses and no spiral, everyone else sees that owning it is survivable. You can say it was you and still be standing, still trusted, still useful. After that, people stop bracing. The thing they were afraid of, being named, already happened to someone, and he is fine.

You cannot get that from a policy. Blamelessness is not a rule you put on the wall. It is something a senior person creates, in real time, by how they handle their own mistakes in front of everyone. A junior who watches you own the index this cleanly learns more about the job in that moment than in a month of code review.

The bug was a missing index. That got fixed the same afternoon. The thing worth practicing was never the fix. It was the three words, said flat, that let the room get to it.

👉 If you enjoy reading this post, feel free to share it with friends!

Or feel free to click the ❤️ button on this post so more people can discover it on Substack 🙏

You can find me on X and Instagram.

The application was built in 2005. WebForms, the way everything was built then. It was a work order automation system I’d helped build, and by the time this happened it had been running in production for years. Large, stable, understood. Every screen worked the way every other screen worked. A developer who had never seen a particular corner of it could still find their way around, because there were no particular corners. It was all one thing.

Share

I had been writing software for ten years.

The feature itself was small. A new piece of the workflow, the kind of thing the system absorbed a few times a year without anyone noticing. I could have built it the way the rest of the application was built. I knew how. I’d done it a hundred times, and that was most of the reason I didn’t want to.

The standard approach would have worked, and it would have taken an afternoon. Some part of me had started to read that as the problem rather than the point. Doing the known thing felt like going through the motions. Reaching for something new felt like doing real work. I told myself the feature would be better for it, more responsive, more capable, and there was a version of that I could have defended. It wasn’t the version I was actually running on.

I reached for Ember. It was new then, one of the first JavaScript frameworks promising to make the browser behave like an application instead of a document. I wired it into the feature. I added a build step to our process to minify the JavaScript, tooling that had never existed in our pipeline because nothing in the pipeline had ever needed it. On my machine it was clean and fast. It felt like the right kind of modern, the kind you can point at. I was pleased with it.

It went to production and could not carry the load.

This was an intranet system. We controlled the browsers. We controlled the machines, the network, the whole environment end to end. There was no hostile variable, no user on some ancient laptop to point at. It was a closed room, and inside that closed room the feature buckled under the volume of data the real workflow ran through it. The thing that moved fine against a handful of test records would not move against what the job actually required.

The load problem was immediate. The other one took longer to surface.

Leave a comment

The application had been consistent, and now it wasn’t. There was a single feature that didn’t work like the others, built on tooling nobody else had a reason to know, sitting inside a system whose whole value was that you never had to relearn it from one screen to the next. Anyone who needed to touch that feature had to stop first and learn a framework, a build step, a set of conventions that lived nowhere else in the codebase and served nothing except the feature I’d decided to make interesting. Every hour someone spent in there was an hour the rest of the system had never charged anyone.

So I took it out. I rebuilt the feature the way the rest of the application worked, on the tooling the whole team already knew. It did the job.

The people who had signed off on the timeline were not glad to spend weeks rebuilding something that had already shipped once. The client, who I’d had a good relationship with, was cooler with me afterward than before.

The rebuild took the better part of a few weeks, and at the end of it the feature worked exactly the way everything else in the application had worked the entire time.

Share The Stoic Coder

👉 If you enjoy reading this post, feel free to share it with friends!

Or feel free to click the ❤️ button on this post so more people can discover it on Substack 🙏

You can find me on X and Instagram.

You can talk your way past almost anyone.

You can talk your way past a code reviewer who is tired and trusts you. Past a manager who wants the ticket closed more than he wants it right. Past a stakeholder who cannot read the diff and is nodding because the demo looked fine. You can talk your way past the part of yourself that is sure, completely sure, that the logic is sound.

You cannot talk your way past a failing test.

Twenty-five years in, that is still the thing I trust most in this work. Not a person. The build. It does not care how confident I was. It does not care how late it is or how badly I need to be right. It tells me I am wrong, flatly, and it does not soften the blow. I have spent a good part of my career being corrected by a machine that holds no opinion about me at all, and it has made me better than feedback from any person ever did.

I want to talk about why that is, because I think it is the closest thing developers have to a daily spiritual practice, and almost nobody names it as one.

Share

The Order That Does Not Need Your Permission

There is a word at the bottom of Stoicism that the productivity version always skips. Logos.

The Stoics took it from Heraclitus, who used it to mean something like the rational order running underneath everything. His complaint, twenty-five centuries ago, was that people sleepwalk past it. He wrote that although all things come to pass according to the logos, men prove uncomprehending of it, both before they hear it and after they have heard it. The order is there whether you grasp it or not. Most people, he said, live as if they had a private understanding: their own little version of how things work, never checked against how things actually are.

The Stoics built their entire ethics on top of that. Zeno said the goal of a life was to live in agreement with nature, and by nature he meant this same rational order. Your own reason is a fragment of it. Wisdom is not inventing your own truth. It is getting your mind to agree with a structure that was already there before you showed up.

That sounds abstract until you realize you do it for a living.

Strip away the metaphysics and logos is just this: reality has a structure, your reasoning is either aligned with it or it isn’t, and you are not the one who gets to decide which. You can believe the null check is unnecessary. The null pointer disagrees, and the null pointer wins. Every single time.

Code is Where the logos is Legible

In most of life you never find out whether you reasoned well. You make a decision and the result comes back months later, tangled up with luck and other people and a hundred things you did not control. You can be wrong for years and never know it, because nothing ever told you cleanly. You parented well or badly, you bet on the right company or the wrong one, and the feedback is so slow and so noisy that you can believe almost anything about yourself and never get caught.

Code does not work like that. Code answers.

You hold a belief about how the system behaves. You run it. It tells you, immediately and without mercy, whether your belief matched reality. Then you do it again. And again. A working developer runs that loop thousands of times a year. Thousands of small confrontations between what you thought was true and what is actually true, each one settled on the spot by a judge that cannot be charmed, cannot be worn down, and does not know your name.

Epictetus said the rational faculty is the only one we have that examines itself and everything else. It is the faculty that judges the other faculties, the one that asks whether a thing is true before accepting it. He said the first task of a philosopher is to test every impression and admit none untried. Accept nothing just because it arrived in your head looking confident.

That is not a meditation exercise to a developer. That is Tuesday. Testing impressions and admitting none untried is the literal description of the job. An impression arrives: this function is correct. You do not get to assent to it because it feels right. You run it. You let the indifferent judge rule. The compiler is Epictetus with a stack trace.

So this is the part I actually believe, the part that is more than a clever overlay. You have been running a logos practice your entire career. Every time you reasoned through a hard problem by hand, got it wrong, felt the friction, and corrected, you were doing the exact thing the Stoics spent their lives trying to train. You were dragging your private understanding into agreement with the way things really are, and you had an honest judge keeping you honest the whole time. Most people never get that. They live whole lives without a single domain that tells them the truth that fast.

Leave a comment

What the Green Check Used to Mean

The replacement story is loud. The story I care about is the one where the judge is still there but you have stopped letting it judge you.

When you generate code you did not reason through, you still get the green check. The tests still pass. The build still goes green. But that signal used to mean something specific. It meant your reasoning aligned with reality. It was a verdict on your thinking. Now it can mean that some reasoning aligned with reality, and you honestly do not know whose, or how, or whether you could reconstruct it when the thing breaks at two in the morning.

You keep the artifact of logos. You quietly lose the practice of it.

This is not the vague worry that your skills will rust. It is more precise than that. The specific thing you lose is the honest feedback loop. The thousands of small corrections that were sharpening your reason go away, because you are no longer the one reasoning. The confrontation between your belief and reality does not happen, because you never formed the belief. The judge is still ruling. It is just no longer ruling on you.

And here is the cruel part. It feels like progress. The green check still appears. The work still ships. Nothing tells you cleanly that you have stepped out of the loop, for the same reason nothing in ordinary life tells you cleanly that you reasoned badly. You have traded the one domain that always told you the truth for one more domain where you can be wrong for years and never find out.

Share The Stoic Coder

Keep letting it judge you

Logos, for a developer, is not a poster on the wall about rational order. It is the daily willingness to put your own reasoning in front of a judge that does not care how you feel about it, and to let the verdict land. That willingness is the whole practice. It is what Heraclitus was begging people to stop sleepwalking past. It is what Zeno meant by living in agreement with something larger than your own preferences. It is what Epictetus meant by admitting no impression untried.

The compiler does not care what you think. That was always the gift. It is an honest judge in a world that mostly hands you flattery and delay, and it has been making you sharper for as long as you have let it.

So the only question worth asking is whether you are still letting it. Are you putting your reasoning in front of the judge, or are you handing the test to something that takes it for you and brings back a passing grade you did not earn?

Keep doing the reasoning in the one place reality can still tell you that you are wrong. It is the most honest relationship you have at work. Do not automate your way out of it.

👉 If you enjoy reading this post, feel free to share it with friends!

Or feel free to click the ❤️ button on this post so more people can discover it on Substack 🙏

You can find me on X and Instagram.

You’re in the middle of something and you hit a wall. A function that won’t behave. An error that makes no sense. A concept you were sure you understood and clearly don’t.

There’s a fork right here, and it lasts about two seconds.

One path: you paste it into the AI and read back the answer. The other: you sit in the confusion and start taking it apart yourself. Most people never experience this as a choice. The hand moves before the mind weighs in. That reflex is the whole thing I want you to notice.

Share

Because the answer was never the point. In those two seconds, something is being built or skipped: your ability to work a problem when there is nothing and no one to hand you the result. Each instance is tiny. You will never feel the one you skip today. They compound anyway, in whatever direction you keep choosing.

I am not telling you to close the tab. AI is not the villain here. The order is the only thing that matters. After you have wrestled with the problem, the tool is a sharp check on your thinking. Before you have wrestled with it, the same tool is a quiet substitute for the thinking. Same input, opposite result, and the only variable is what you did in those two seconds.

So this week, watch your own hands. The next time you get stuck, notice what reaches for the keyboard before you have decided anything at all.

Then tell me: the last time you hit something you didn’t understand, what did you reach for first?

Leave a comment

👉 If you enjoy reading this post, feel free to share it with friends!

Or feel free to click the ❤️ button on this post so more people can discover it on Substack 🙏

You can find me on X and Instagram.

Twenty-five years in, the numbers stop being abstract. You can count the systems you have left in you. Not precisely, but closely enough. A handful more big builds, some number of years of maintenance and review and the slow work of handing things off, and then the count runs out. The runway is visible from here in a way it never was at year 10.

The thing nobody mentions when they talk about finding your purpose: most of the hours you have left are going to be spent on work that does not matter very much. The CRUD app. The migration nobody will remember. The ticket that closes another ticket. You are going to die, and a large share of your remaining finite time is going to go to the unremarkable middle of the job.

So the honest version of memento mori is not the inspirational one. It is the uncomfortable question the inspirational version skips. You will die. Should you really be spending a Tuesday on this?

Share

The answer that’s true but not enough

There is an answer to that question that I have given before, and it is true. Your time is finite and nonrefundable. If the work is hollow all the way down, if you are trading your one life for a paycheck and calling it safety, then the running out of time is the argument to leave. To go do the work that is actually yours. I stand by that. I am not going to walk it back here, because walking it back would be a lie, and most people sitting in a job they have outgrown already know it.

But it is not the whole truth. The clean version, just leave, assumes an escape that is not always available and not always right. You have obligations. You have people who depend on the paycheck landing. You are good at something the world pays for and indifferent to most of what it would pay you to be passionate about. The follow-your-passion promise, the one where the work stops feeling like work, is mostly sold by people who already escaped, to people who cannot. For most working developers, most of the time, the ordinary work is not a phase to be exited. It is the job. It is going to stay the job.

You can’t make it permanent

So if you cannot reliably escape the ordinary work, the next move people reach for is to redeem it. To make it matter by making it permanent. To build something that outlasts them.

I have made the case elsewhere that this does not work, and I will not relitigate it. Your code dies. The framework you mastered will go obsolete, the clever system you are proud of will be deleted or rewritten by someone who curses your name, and the monument you are quietly trying to build out of source code has the structural integrity of a sandcastle at high tide. Permanence is not on the menu. If the meaning of your work depended on it lasting, the work would be meaningless, because none of it lasts.

Which seems to leave nothing. You cannot escape the ordinary hours and you cannot immortalize them. That looks like a dead end. It is actually the whole point.

Leave a comment

Occupied is not the same as alive

Seneca put the diagnosis better than anyone has since. The problem was never that we get a short life. The problem is that we waste most of the one we get. He had a word for the people who fill their days with motion and call it living: occupatus. Occupied. Busy with everything, present for none of it, mistaking the volume of activity for the substance of a life. The occupied man, he observed, is the least equipped of all to die, because he has not yet gotten around to living.

You have had this day. The one where you went heads-down at nine and looked up at six and could not name a single thing you would defend. Standup, then three meetings, then forty Slack threads, then a dozen ticket comments and two context switches per hour, and somewhere in there your actual work waited and did not get done. That day felt full. It was the emptiest kind of day there is. That is occupatus, and the modern toolchain is a machine for manufacturing it.

We have never had more ways to be busy and call it work.

The Stoic move out of it is the one the whole tradition turns on, and it is not the bumper-sticker version about staying calm. It is a sorting. The outcome of your work, whether the system ships, whether anyone notices, whether it survives the next reorg, is not up to you and never was. It is a preferred indifferent. Nice to have, not the thing of value. What is up to you is the quality of attention and judgment you bring to the hours while you are inside them. That is the only part death does not get a vote on.

This is where it stops being abstract. Marcus Aurelius told himself to perform each action as if it were the last of his life, with dignity and full focus, free of the desire to impress anyone and free of resentment at his own circumstances. Read that as a productivity hack and you miss all of it. He was not talking about doing more. He was talking about how you occupy the present action, including a boring one, including one nobody will ever praise. The CRUD app does not become important. Your conduct inside it is the only place your character actually exists.

How you spend the hours is not the preparation for the life. It is the life. There is nothing else it is made of. A career is not the few significant projects with the forgettable work in between. It is the forgettable work, almost all the way down, and the only open question is whether you were present and honest and careful inside it, or whether you were merely occupied, waiting for the part that mattered to finally arrive.

The only thing that survives

That still leaves the legacy question, the one that gets sharper the closer you get to the end of the count. If the code does not last, what does?

The only thing I have watched survive is the people.

Not in a sentimental way. In a specific, observable one. The judgment you built over a long time, the thing that catches the missing null check in twelve seconds, the instinct for which corner of the system is about to rot, you cannot ship that in source code. But you can hand it to a person. Working next to someone, slowly, the way it was once handed to you. Debugging out loud so a junior watches how you think instead of just what you typed. Letting someone sit in the confusion long enough to form the muscle, instead of handing over the answer because it is faster and the sprint is ending. Most of what your best mentors gave you was not information. It was a way of seeing, transmitted through proximity, and it outlived every system the two of you ever touched.

That is a legacy precisely because it was never yours to keep. You do not own it once it is transmitted. It walks out of the building in someone else’s head and surfaces years later in a decision you will never see, made by someone who may not remember where they learned it. The code was always going to die. The person carries it forward, and does not need your name attached for it to have been worth doing.

Share The Stoic Coder

The hours pass either way

None of this resolves the first question, and I am not going to pretend it does. The CRUD app may still not be worth your one finite life. If it is hollow all the way down, leave, the way I said before. That tension does not close, and you should be suspicious of anyone who tells you it does.

But for the ordinary work you are not going to escape, the work that is simply the job, mortality does not make it significant and it does not hand you permission to phone it in until something better shows up. It clarifies the only thing that was ever in your hands. The hours are going to pass either way. You will spend them lived, or you will spend them merely occupied. Death decides the number. You decide the rest.

Quote of the Day:

“It is not that we have a short time to live, but that we waste a lot of it.” - Seneca

👉 If you enjoy reading this post, feel free to share it with friends!

Or feel free to click the ❤️ button on this post so more people can discover it on Substack 🙏

You can find me on X and Instagram.

There is a particular silence in an architecture meeting when the senior person finally speaks.

People stop typing. The junior who was mid-sentence trails off. Someone writes down what you said almost before you finish saying it. Your offhand preference about a queue becomes the design. Your shrug about a library becomes a six-month commitment.

And inside, where nobody can see, you are running a different read entirely.

You are thinking: I am guessing.

Not wildly. Not irresponsibly. The guess is educated, shaped by a few thousand similar moments. But it is still a guess, and you know exactly how much of it is pattern and how much is certainty, and the ratio is not what these people seem to believe it is.

That gap, between the confidence everyone grants you and the uncertainty you actually feel, is senior imposter syndrome. And almost everything written about imposter syndrome will steer you wrong about it, because almost everything written about it is written about the junior version.

Share

It Is Not The Same Feeling That Grew Up

The junior version is simple. You do not know enough yet, and you are afraid someone will notice. The fix is also simple, even if it takes years: you learn more, the gap closes, the fear quiets.

The senior version is the opposite shape.

You do not feel like a fraud because you lack knowledge. You feel like a fraud because you have enough knowledge to see, in high resolution, how much of senior work is judgment under uncertainty. You can see the part you are sure about. You can see the part you are inferring. You can see the part you are flat-out hoping holds. And you are aware that everyone in the room is treating all three as the same color.

The junior thinks, “I do not know enough.”

The senior thinks, “I know exactly how much I am guessing, and the stakes just got a lot higher.”

Same name. Completely different animal. And the standard advice, the “believe in yourself, you earned this” pep talk, is useless here, because the senior is not suffering from a distorted view of reality. The senior is suffering from an accurate one.

Leave a comment

The Edge of What You Know Gets Longer, Not Shorter

Competence does not shrink the unknown; it expands your view of it.

At year three the field looks small. You can see most of the map, and the blank spots feel like personal failures you will eventually fill in. At year twenty the map is enormous and most of it is blank, and you understand that it was always enormous, you just could not see the edges before. Every domain you actually master hands you a clear view of ten adjacent domains you will never touch.

So the feeling intensifies with experience, and people read that as a malfunction. It is not. It is calibration.

The Stoics had a name for the thing the junior is missing and the senior has too much of. Wisdom, in the Stoic sense, is not a stockpile of answers. It starts with an honest accounting of the boundary between what you know and what you do not. Epictetus said it is impossible for a person to learn what he thinks he already knows. The whole project begins with seeing the edge clearly.

Which means the discomfort you are calling fraud is not the symptom. It is the diagnosis working correctly.

The actual fraud was earlier. The fraud was the clean confidence you had at year three, when you did not know enough to know how much you were missing. You were not more competent then. You were just less aware. If anyone in your career has been an imposter, it was that guy, and everyone loved him because he gave clean answers.

Their Deference Is Not Yours to Earn

People quote you. They defer. They build on your guess as if it were bedrock. And some part of you keeps trying to deserve it, to close the gap between the authority they grant and the certainty you feel. You cannot close it. You will never feel as sure as a room of juniors needs you to look.

This is where the oldest Stoic tool actually earns its keep, not as a fridge magnet but as a sorting mechanism.

What other people think of you is not in your control. Their deference, their quoting, the reputation that walks into the room before you do, all of it lives in their heads, not yours. It is a preferred indifferent. Nice to have. Not the thing.

What is in your control is narrow and concrete: the next decision, made as well as you can make it, with the information you actually have. That is the entire job. Not deserving the reputation in some cosmic sense. Just doing the next thing well, and then the next one.

Marcus Aurelius ran an empire and spent his private mornings reminding himself, in writing, that he did not have it figured out, that he might be wrong, that he was still working on himself. The most powerful man alive kept a notebook of his own uncertainty. He was not performing humility for an audience. There was no audience. He was managing the exact gap you are managing, between the authority everyone handed him and the doubt he carried inside, and he managed it by refusing to confuse the two.

You are not responsible for feeling as certain as you look. You are responsible for what you do next.

Share The Stoic Coder

Wisdom or Just Calcified?

You watch the company “discover” microservices. Again. You watch the third rewrite of the monolith that the second rewrite was supposed to fix. You watch a new framework arrive promising to solve the problem the last new framework created. And you feel the skepticism rise, and right behind it comes the real fear.

Is this wisdom, or have I just calcified?

Am I the person who has seen this fail three times, or am I the old man yelling at the clouds, mistaking my own fatigue for insight?

You cannot answer that from the inside by feel. The calcified person and the genuinely wise person experience identical confidence. The feeling is no guide at all. This is exactly the moment prosoche, disciplined attention, stops being abstract. The work is to catch yourself reacting and ask one question: am I responding to this proposal, in front of me, with its actual specifics, or am I responding to a memory of the last two times something wore the same clothes?

Sometimes the answer is that the pattern holds and your skepticism is earned. Sometimes the answer is that this time is different and you are about to dismiss something good because it pattern-matches to old pain. You only find out by looking, every time, at the specific thing.

And here is the quiet reassurance buried in the fear: the developer who still asks the question is not the calcified one. The discomfort you feel about possibly being the old man is the precise thing that keeps you from becoming him.

Stop Trying to Make It Go Away

You do not resolve the feeling; you stop treating it as a problem to be solved.

The uncertainty is not a flaw in your competence. It is what competence feels like from the inside once you can see clearly. Acting well inside that uncertainty, deciding without the certainty you wish you had, is not a workaround for judgment. It is the whole of what judgment ever was. Nobody up here is operating with more than that. The ones who look like they are have simply stopped noticing the gap, and that is not a state you should envy.

Seneca wrote his letters near the end of his life, about as accomplished as a person gets, with readers across the empire treating him as the authority. He kept refusing the role of the doctor. He cast himself as a patient in the same ward as the person he was writing to, comparing symptoms, passing along whatever had helped him that week. He never claimed to be cured. Only that he was a little further into the same treatment, and willing to say so out loud.

That is the only kind of senior worth being. Not the one with answers. The one who is honest about which parts are answers and which parts are still guesses, and who keeps making the call anyway.

You are not a fraud.

You were a fraud at year three, when you were sure.

Quote of the Day:

“As long as you live, keep learning how to live.” — Seneca

👉 If you enjoy reading this post, feel free to share it with friends!

Or feel free to click the ❤️ button on this post so more people can discover it on Substack 🙏

You can find me on X and Instagram.

You used to spend an afternoon fighting a bug, and somewhere in that fight something got built, not just the fix, but you. Now you describe the bug to a model and it hands you three options before your coffee’s cold. Faster. Cleaner. And somehow you end the day more wiped than you did when the work was slower and dumber.

Here’s why: the tool took the friction, not the load. The slow part, the part that used to double as recovery, the staring-out-the-window-while-it-compiles part. That’s gone. What’s left is decision after decision after decision, at a pace set by something that never needs a weekend. Plus the low hum that you’re already behind, because another model shipped Tuesday and half of what you knew expired with it.

So you’re exhausted. And if you’ve been reading my newsletter for any length of time, you probably feel a little guilty about it.

That’s on me.

Two years I’ve told you your comfort zone is where dreams go to die. Burn the safety net. Stay in the discomfort. Do the work nobody wants to do. I stand by every word of it. But I’ve said it so many times, and so loudly, that I think some of you have walked away with a conclusion I never meant: that the answer is always more. That if you’re tired, you just haven’t earned the right to stop yet. That rest is the enemy.

Rest is not the enemy. It never was. The point was always to push and recover, I just spent two years with the volume cranked on the first half.

Share

Rest And Comfort Are Not The Same

The Stoics had a clean way to think about this, and it’s the thing that keeps “rest is fine” from collapsing into “comfort is fine”, because those are very different claims.

To a Stoic, comfort is a preferred indifferent. Nice to have. Not the point. Not the good. And so is rest. Neither one is virtue. But neither one is the villain, either. The villain is never rest. The villain is mislabeling: calling one thing by the other’s name.

Seneca didn’t treat leisure as a reward for the weak. He treated it as maintenance for the strong. The mind has to be given some relaxation, he argued, fields that get cropped every single year without a break go barren, and a bow kept always bent will snap. He called it otium: not the absence of work, but the soil work grows back in. Rest wasn’t the opposite of the disciplined life. It was part of the equipment.

The Problem: Rest And Avoidance Feel Identical

Rest and avoidance feel exactly the same.

Both feel like relief. Closing the laptop because your brain is fried feels identical, in the moment, to closing the laptop because the next ticket scares the hell out of you. You cannot tell them apart by how good it feels to stop. They both feel like getting off your feet. And the modern version is sneakier still: letting the machine do the part you’re afraid of also feels like relief. Like efficiency. Like rest. It isn’t. It’s the comfort zone wearing an efficiency badge. Frictionless is not the same as rested.

So if the feeling lies, what’s the tell?

This one: real rest restores your capacity to come back to the hard thing. Avoidance removes the hard thing so there’s nothing left to come back to.

A field lies fallow so it can be planted again. That’s rest. A field that’s been abandoned just goes to weeds. That’s avoidance. From a distance, on any given Saturday, they look the same. Nobody’s working either one. The difference doesn’t show up in the moment. It shows up in whether you return.

Leave a comment

What Real Rest Actually Looks Like

Watching tutorials on your day off is not rest. That’s work you forgot to bill for. “Productive rest” is mostly a story we tell ourselves so we never have to fully stop: keep the anxiety, just slap a productivity label on it. Real rest is the kind where the thing actually powers down. Where you’re unreachable and the build can wait until Monday, because it will, in fact, wait until Monday.

And then the hard one: sometimes, rest means saying no to the stretch project.

There’s a difference between not now and not ever.

“I don’t have the capacity for that this quarter; I need to recover first” is rest. “I’ll never be ready for that” is the comfort zone, and it’s the precise thing I’ve spent two years telling you to burn down. Almost the same words. Opposite move. The fallow field gets planted in spring. The abandoned one is just a decision you’re lying to yourself about.

Share The Stoic Coder

Then Go Back

That’s the entire test, and you can carry it in your pocket: am I going back?

Rest so you return to the difficulty sharper. That’s discipline too. Maybe the hardest kind, in a year when the pace is set by a thing that never sleeps and never has to.

Because here’s the one difference between you and the machine that actually matters: it doesn’t get tired, and it never has to come back to anything. You do. You’re allowed to. You’re built to.

Take the weekend. Then go back.

Quote of the Day:

“Our minds must relax: they will rise better and keener after a rest.” - Seneca

👉 If you enjoy reading this post, feel free to share it with friends!

Or feel free to click the ❤️ button on this post so more people can discover it on Substack 🙏

You can find me on X and Instagram.

Early in my career, I watched a developer do something I’ve never forgotten.

He inherited a codebase that was, by any honest measure, a mess. Years of rushed deadlines, mid-sprint requirement changes, and the particular brand of creative improvisation that happens when good developers are under constant pressure. The kind of code that tells a story. Not a flattering one, but a real one.

He was talented. Genuinely good. And he was furious.

Within a week, he had decided to rewrite the entire e-commerce system from scratch. The right way, this time. Clean architecture. Proper separation of concerns. The kind of code you’d be proud to show in an interview. He was meticulous about it. He worked longer hours than anyone on the team. He was, in his own estimation, fixing what was broken.

What he actually did was break what was working.

The original system, for all its ugliness, had accumulated years of edge case handling. Weird discount logic that reflected real customer behavior. Payment processing quirks specific to their merchant processor. The kind of institutional memory that doesn’t live in documentation, it lives in code that’s been in production long enough to absorb the real world.

His rewrite was architecturally beautiful and practically broken. It took months to untangle.

When I think about that developer now, what strikes me isn’t the technical failure. The technical failure was just the outcome. What strikes me is what he never saw: that his internal state was doing the work. He thought he was making an engineering decision. He was executing an emotional one. The system he shipped was organized by anger, and it looked clean, and it didn’t work.

He treated it as a technical problem. It wasn’t.

In 25 years, I have watched that pattern in a hundred forms. The developer who can’t hear feedback because their certainty is load-bearing. The architect who solves every problem with another abstraction layer because abstraction feels like intelligence. The senior engineer who stopped learning at year seven and mistakes comfort for mastery. Different symptoms. Same root.

The root isn’t technical. It never was.

Share

The Wrong Question

Most developers spend their careers asking one question: how do I get better at this?

It’s a good question. It has real answers. Deliberate practice on hard problems. Working alongside people who are better than you. Reading widely, not just documentation, but systems, histories, postmortems. Staying curious about the craft itself, not just the tools. These things work. They produce competent developers.

They don’t produce wise ones.

The technical question optimizes for a specific kind of output. You get faster. You accumulate patterns. You build intuitions about architecture, about performance, about where bugs tend to hide. All of that matters. All of that is real.

But past the journeyman stage, and you reach that stage earlier than you think, more of the same returns less. The developer who grinds harder on the technical question past that inflection point isn’t getting sharper. They’re just staying busy. They’re adding syntax to a foundation that isn’t the problem.

The developers who don’t plateau, don’t burn out, don’t lose the plot at year twelve, they found a different question. Not consciously, for the most part. Nobody sat them down and assigned it. But somewhere along the way, they started asking something else.

The question isn’t how do I get better at code?

It’s what kind of developer am I becoming through this work?

That sounds like a soft question. It isn’t. It’s harder than any technical problem you’ll face, because it has no Stack Overflow answer and no framework that solves it for you. And ignoring it, which most developers do, because the technical question is so much more tractable, doesn’t make it go away. It just means the answer accumulates silently, in the background, until you’re that developer rewriting working systems out of ego and calling it engineering.

What Stoicism Actually Is

I want to be direct about something before going further, because this is where people tend to check out.

Stoicism has a branding problem. Most of what circulates under that name is a thin self-help product: control what you can control, don’t sweat the rest. It’s not wrong, exactly. But it’s the philosophy stripped of everything that makes it worth practicing. It’s the bumper sticker without the argument.

The actual practice has real load-bearing pieces, and three of them apply to software development with uncomfortable precision.

The first is what Epictetus called prosoche: a sustained, disciplined attention to your own internal state. Not a journaling practice. Not meditation, though those can serve it. The actual discipline of noticing, in real time, what is happening inside you before it becomes behavior. The anger before it becomes a rage rewrite. The anxiety before it becomes an architectural decision made from fear. The certainty before it calcifies into an inability to hear what someone is actually saying to you.

Marcus Aurelius’s Meditations are, essentially, prosoche in written form. A daily record of a man watching himself think, catching his own patterns, trying to close the gap between his values and his behavior. He was the most powerful person on earth and he spent his mornings doing this work. That’s not incidental.

The second is askesis: what Seneca and Epictetus both described as voluntary discomfort, the deliberate choice to stay with what’s hard rather than reach for what’s easier. Not punishment, but training. You don’t stumble into deep competence by accident. You choose difficulty repeatedly, especially when you don’t feel like it, because the struggle is where the actual formation happens. Seneca recommended periodically living as if poor, not out of asceticism, but to prove to himself that what he feared losing wasn’t actually what sustained him. The principle scales: every time you skip the painful debugging session by asking someone else, every time you reach for an abstraction before you understand the concrete, you’re making a small choice against formation.

Those choices compound.

The third is the dichotomy of control. And I want to rescue this one from its bumper sticker version, because it’s a sorting tool, not a coping mechanism. Epictetus opens the Enchiridion with it for a reason: some things are up to us, some things are not, and wisdom begins with correctly sorting everything in your life into one of those two categories. The question isn’t how do I feel okay about things I can’t control? The question is where exactly is my sphere of genuine agency, and am I actually working there?

Most developers are working outside it constantly. Reacting to code someone else wrote as if it’s a personal affront. Anxious about market forces they cannot move. Performing competence for stakeholders who don’t understand what they do. That’s not bad character, it’s what happens when nobody gives you the sorting tool. The work is scattered across the uncontrollable, and it feels like effort, and it produces very little.

These three practices are two thousand years old. They were developed by people who had nothing like software in mind. They fit the specific conditions of software development. The uncertainty, the pace, the fragile ego that the industry somehow both produces and exploits, with an accuracy that still surprises me.

Leave a comment

The Right Question

Go back to that developer and the e-commerce rewrite.

What he lacked wasn’t technical knowledge. He had more than enough of that. It was, in fact, his technical knowledge that made the failure possible. He could see clearly everything that was wrong with the original system. He had the skills to fix it. What he didn’t have was prosoche. The self-awareness to notice that his certainty about the right answer was being generated by his anger at the wrong one. His internal state was the variable. He never looked at it.

The right question, what kind of developer am I becoming through this work?, is a prosoche question. It requires watching yourself over time. Not in a self-absorbed way, but in the way that Marcus Aurelius watched himself: practically, unsparingly, with the goal of closing the gap between who you are and who your work requires you to be.

What does that actually look like at year five? At year fifteen? At year twenty-five?

At year five, the right question starts to reveal that technical skill is not the ceiling you thought it was. You’ve watched junior developers who are technically sharper than you produce worse outcomes, and you’re starting to understand why: they can’t hear feedback, they can’t operate in uncertainty, they can’t estimate honestly because their ego is on the line. You realize that you are also doing all of these things, just with more years behind you. The question starts to feel urgent.

At year fifteen, the right question sounds different. You’ve accumulated enough judgment to walk into an unfamiliar codebase and know, within an hour, where the real problems are. Not from technical inspection alone, from pattern recognition that lives somewhere below the explicit, built from thousands of situations where you paid attention to what was actually happening, not just to the code. You can hear a requirements meeting and catch what’s not being said. You can feel the moment a technical decision is actually a political one wearing technical clothing.

That capacity doesn’t come from solving more tickets. It comes from having practiced prosoche across thousands of decisions. Having paid attention to your own internal state often enough, honestly enough, that your read of a situation now includes what you’re bringing to it.

At year twenty-five, the question has become something close to habitual. You don’t ask it explicitly every day. But the practice of asking it, over decades, has changed what you notice and how quickly you notice it. You sit with a hard problem differently. Not with less uncertainty, with more comfort in uncertainty. The willingness to stay in the not-knowing until the actual shape of the problem becomes clear, rather than reaching for the nearest pattern that fits.

That capacity, to sit with a hard problem rather than execute the first solution that reduces the discomfort of not-knowing, is askesis applied. It is the compounding return on having practiced voluntary discomfort. You stay with what’s hard because you have trained yourself to stay with what’s hard, and staying has become less costly than it used to be.

Here’s what doesn’t produce this: solving more tickets. Accumulating more frameworks. Getting faster at the technical parts of the job. Those things are real and they matter, but they are not the thing.

The thing is philosophical. It has always been philosophical.

Share The Stoic Coder

What Actually Compounds

Technical skill has genuine diminishing returns past the journeyman stage. This is observable. Every senior engineering team has watched it: the brilliant junior who peaks at year five because they stopped choosing difficulty. The mid-level developer running the same three architecture patterns on every problem because those patterns work and nothing hurts enough to require something new. The staff engineer who can solve any technical problem put in front of them and cannot, for the life of them, figure out why they feel irrelevant.

It’s not that their skills degraded. It’s that their skills stopped growing in the direction that matters, because they were still asking the first question (how do I get better at this?) long after the ceiling on that question became visible.

What compounds differently is judgment. And judgment, I want to be clear about what this actually is, is not instinct. It is not talent. It is not something you either have or don’t.

Judgment is developed attention, over time.

The developer at year fifteen who can walk into an unfamiliar codebase and feel, within an hour, where the bodies are buried. They’re not magic. They have been practicing prosoche. They have been paying disciplined attention to their own read of situations, to the patterns in their own perception, across thousands of instances. They’ve been getting fast at noticing what they’re noticing.

They will tell you they have good instincts. They don’t. They have something better: a calibrated relationship with their own attention, built through practice. The difference matters because instincts can’t be transferred and can’t be improved. Developed attention can be both.

The practical consequence: the questions that feel most important at year three, which framework should I learn, is this the right stack, am I behind?, are almost entirely technical questions with technical ceilings. They are worth answering. Answer them. And then start asking the question underneath them, before you reach year seven and find yourself wondering why the work that used to feel like growth now just feels like effort.

There is a version of a software career that is twenty-five years of accumulating syntax. And there is a version that is something else entirely. Something harder to name and much harder to acquire, because it requires a different kind of attention than the industry teaches you to pay.

The developers who figure out which version they’re building, early enough to do something about it, are not smarter. They found the right question sooner.

Where This Goes

Three practices. Not a philosophy lecture, three concrete things that take fifteen minutes each to learn and a career to get right.

The morning sequence: before the day’s first Slack notification, before the standup, before anything external has a claim on your attention, take fifteen minutes to set an intention grounded in what you actually value. Not what you need to ship. What kind of developer you want to be today. It sounds soft. It is structurally the most important fifteen minutes of the day, because everything else follows from what it surfaces.

The evening review: Seneca did this every night. He described it in De Ira: “I examine my entire day and go back over what I’ve done and said, hiding nothing from myself, passing nothing by.” Five questions. Where did I fall short? What went well? What was outside my control and am I still holding it anyway? What did I learn? What is my intention for tomorrow? Fifteen minutes. The compounding effect, over years, is not theoretical.

The Stoic pause: in the moment before you respond to the critical code review, the impossible deadline, the Slack message that made you feel what you felt, stop. Physically. Close the laptop screen. Apply the sorting tool: what here is actually in my control? Respond from there. It is the smallest practice and, in the daily conditions of developer work, the one with the most immediate return.

These are the frameworks I’ve built The Stoic Coder around. Not because Stoicism is the only lens on this, but because it’s a 2,000-year-old technology for exactly the problem I’ve spent 25 years watching developers fail to name: that the work is harder than the technical parts suggest, and the reason is philosophical, and there are actually answers.

You’re in the right place to find them.

Quote of the Day:

“First say to yourself what you would be; and then do what you have to do.” - Epictetus, Discourses

👉 If you enjoy reading this post, feel free to share it with friends!

Or feel free to click the ❤️ button on this post so more people can discover it on Substack 🙏

You can find me on X and Instagram.

Also, I just launched a new YouTube channel - Code & Composure

The software industry has been on a mission to remove its bottlenecks. Slower developers. Code review. Human judgment. The painful friction between “here’s what the ticket says” and “here’s what actually ships.”

AI makes this mission feel achievable. Finally, we can get the bottlenecks out of the way.

There’s one problem with that goal: the bottleneck is the point.

When a senior developer reviews a pull request and stops cold with a “wait, what is this doing?” that pause is not a failure of the process. It’s the process working. Confusion is data.

The fact that something took twenty minutes to understand when it should have taken two means something is wrong with what was written.

Share

Pain is information.

A developer who reads code and feels nothing, who zips through review at the same speed regardless of what the code actually contains, is either reviewing code they can read in their sleep, or they’ve stopped seeing it.

The friction of reading someone else’s code: the slowness, the occasional what the hell were you thinking. That’s not inefficiency. That’s the quality signal. You need it. Your team needs it. Your production environment at 2am really needs it.

Now remove the human.

Automated agents don’t feel confusion. They don’t slow down when something is wrong. They don’t stop at a function name that seems slightly off, or a comment that doesn’t quite match the implementation, or a change that seems fine in isolation but is going to blow up the integration test they can’t see from here.

They ship. Confidently. Quickly.

And when it breaks, nobody can read the codebase, because nobody wrote the codebase.

Leave a comment

The industry heard “bottleneck” and heard problem. They heard slow. They heard blocker. They heard something to engineer around.

What they missed is what every developer who’s debugged anything already knows: the moment you finally understand the bug is the moment the pain stops. You weren’t stuck because you were bad at your job. You were stuck because the system was telling you something. The confusion was trying to hand you information. The moment you stopped fighting the friction and started listening to it, that’s when you found it.

Removing friction from the development process isn’t removing inefficiency. It’s removing the feedback loop that tells you when something is wrong.

That’s a different problem. A worse one.

The Stoics weren’t advocating for suffering as an end, they were observing that difficulty is how you build the capacity to handle difficulty.

This is not abstract philosophy. It’s a practical observation about how human beings develop judgment.

A developer who has spent five years fighting confusing code. Writing it, breaking it, fixing it, reading other people’s worst commits at the worst possible moments, has built a model of software systems that lives in their head. It’s not in any book. It’s in the scar tissue.

That model is what catches the null check at code review before it becomes the null check in production.

AI didn’t form the model. You did. Through years of friction.

You are the bottleneck. The bottleneck is the model. The model is the thing no one can replace.

Share The Stoic Coder

Here’s what worries me about the current trajectory.

We’re building a generation of developers who are going to miss the formation that produces the model. Not because they’re lazy. Because the environment removed the conditions that produce it.

You can’t shortcut the frustration. The frustration is where learning happens. Every hour a junior developer spends confused by a codebase they didn’t write is an hour they’re building the mental map they’ll spend the next twenty years navigating by.

Pull AI into that loop too early, and the confusion disappears. Not because the developer understood it. Because the AI resolved it before the confusion could do its work.

That’s not a win. That’s a generation of developers who reach senior titles without ever building the model that makes the title mean something.

I’m not arguing against using AI. I use it. I’ll keep using it.

What I’m arguing is this: understand what you’re the bottleneck for.

You’re not the bottleneck because you type slowly. You’re the bottleneck because your judgment, earned through years of watching things go wrong in predictable and completely unpredictable ways, is the mechanism that catches problems before they compound.

Voluntary discomfort isn’t just a Stoic practice. In this context, it’s professional maintenance. Writing code by hand when you could have AI write it. Reading unfamiliar codebases when you could have AI summarize them. Staying in the difficulty long enough to understand it instead of optimizing the difficulty away.

Because the moment you outsource the hard reading, the slow thinking, the uncomfortable pauses.: you’re quietly maintaining less of the thing that makes you valuable.

You don’t feel it for a while. And then you need the model and it’s not there.

The bottleneck is the feature.

Pain is information. Confusion is data. The friction in the development process—the human kind, the slow kind—is what separates shipped from good.

Own being the bottleneck. It’s the best thing about you.

Quote of the Day:

“The impediment to action advances action. What stands in the way becomes the way.” - Marcus Aurelius

👉 If you enjoy reading this post, feel free to share it with friends!

Or feel free to click the ❤️ button on this post so more people can discover it on Substack 🙏

You can find me on X and Instagram.

Also, I just launched a new YouTube channel - Code & Composure

There’s a specific kind of frustration that only developers know. It’s not the frustration of a bug you can’t track down, or a stakeholder who keeps moving the goalposts. It’s the frustration of shipping something you know isn’t right.

2014 - Enterprise CMS rebuild. The whole promise of the project was better performance, better UX — and buried in that promise was search. Search was the thing that mattered most to the client. Search was the thing that was supposed to actually get fixed.

It didn’t get fixed. It got band-aided. And we shipped it anyway.

I led that project. That’s on me. And I’ll be honest, it wasn’t relief when we finally shipped it. It was frustration. Because delivery is always expected of us. But there’s a difference between delivering and delivering shit. Somewhere along the way, we stopped feeling that distinction as sharply as we should.

What I didn’t have a name for back then, we have a name for now: enshittification.

Share

The Pattern Has a Name

Enshittification, coined by writer Cory Doctorow, describes the gradual decay of digital products. It usually gets applied to platforms: how they start by serving users, then pivot to extracting value from them. But the same pattern plays out in how we build software, sprint by sprint, shortcut by shortcut.

Timeline and promise drive decisions that quality should be driving. You know it’s happening. You feel it. But the deadline is real, the stakeholders are waiting, and so you ship the band-aid and tell yourself you’ll come back and fix it.

You don’t come back and fix it.

The next sprint has its own shortcuts. And the one after that. Each one feels manageable in isolation. Collectively, they compound into something that embarrasses you. Slow apps, inconsistent behavior, features that technically work but don’t actually serve anyone.

We’ve been doing this for years. We just got really good at normalizing it.

Here’s the uncomfortable truth: the client in my 2014 project was initially happy with the delivery. The cracks didn’t show up right away. They never do. That’s what makes this pattern so easy to fall into. The consequences are delayed, but they’re never cancelled.

AI Didn’t Create This Problem. But It’s Making It Worse

Let’s be fair: AI is genuinely changing what’s possible for developers. Codex, Cursor, Claude. These tools are real, and the productivity gains are real. I’m not here to tell you to throw them out.

But here’s what I’m watching happen: we’ve taken a profession that already had a speed problem and handed it a turbocharger. We’re moving faster. We’re also making mistakes faster. And instead of using AI to close the gap between what we promise and what we deliver, a lot of us are using it to build more elaborate scaffolding around the wrong problems.

Agentic workflows. Autonomous pipelines. Multi-model orchestration. Some of it is genuinely useful. Some of it is us chasing the next shiny thing while our customers are still waiting for the thing we promised them two quarters ago.

The question worth asking is simple: what are we optimizing for? If the answer is “a faster dev cycle,” that’s not good enough. A faster dev cycle that produces the same shortcuts at higher velocity isn’t progress.

It’s just enshittification with better tooling.

Leave a comment

The Complexity Tax

Frontend development is a decent example of where this gets out of hand. HTML and CSS have evolved into webpack configs, Vite setups, package.json files that look like they need their own documentation. To be clear, modern tooling exists for real reasons. Polished, functional UIs require it. But it’s worth occasionally asking whether the complexity we’ve introduced is serving the customer or serving our preference for a particular stack.

When the tools become the product, something has gone wrong.

Share The Stoic Coder

Coming Back to Center

None of this means slowing down to the point of paralysis. It means being honest about what “done” actually means. It means asking, before you ship the band-aid, whether you’re solving the customer’s problem or just closing a ticket.

The rebuild I led in 2014 promised search that worked. We delivered search that barely limped along. The client felt it eventually. That gap between what you promise and what you deliver, customers always feel it eventually. The apps that feel sluggish, the features that half-work, the UX that technically functions but clearly wasn’t thought through. That’s the accumulated weight of a thousand decisions where speed won and quality lost.

We can use better tools. We can run tighter sprints. We can build smarter workflows. But none of that matters if we’ve accepted a definition of “shipped” that means “it works well enough that no one will complain today.”

The Challenge

Here’s what I’m putting in front of you: the next time you’re about to ship something you know isn’t right, stop for a second. Not to blow up the timeline, just to be honest about what you’re actually doing.

Are you solving a real problem for a real customer? Or are you closing a gap between a promise and a deadline and hoping no one notices?

We have to stop accepting shit as good enough. Not because some blog post told us to. Because we’re better than that, and our customers deserve better than that.

The bar we set for ourselves is the bar our software lives up to. What’s yours?

👉 If you enjoy reading this post, feel free to share it with friends!

Or feel free to click the ❤️ button on this post so more people can discover it on Substack 🙏

You can find me on X and Instagram.

Also, I just launched a new YouTube channel - Code & Composure

My company just went all in on agentic AI workflows. Full automation: code, tests, the whole pipeline. The Slack channels lit up immediately. Pure excitement, people sharing demos, optimism everywhere you looked.

I get it. The first time you watch it work, it genuinely is impressive as hell.

But here’s the thing, I’ve been using AI as a coding assistant on my own projects for a while now. I wrote about building a real iOS app with it here, so I won’t rehash all of that. The short version: it’s useful, it’s not perfect, and working through the imperfections taught me a lot about what these tools actually are versus what people think they are. So while everyone else was marveling at the demo, I was sitting there thinking “we haven’t found the sharp edges yet”.

This isn’t a hit piece on AI. I think it’s genuinely useful. But there’s a big difference between useful and ready. And right now, I’m not convinced everyone in that Slack channel knows what they don’t know yet.

Share

From Side Projects to the Main Stage

There’s a big difference between experimenting with AI on a side project and dropping it into a large, complex, legacy fintech system with real customers on the other end.

On side work, the stakes are low. If something goes sideways, you fix it, you learn, you move on. But I work on a loan origination and servicing system. We’re talking about a codebase that’s been around long enough to have its own mythology. Every piece of logic in there exists for a reason, sometimes a reason nobody fully remembers anymore. That context matters. The domain knowledge matters. The history of why things were built the way they were matters.

Most of my colleagues are brand new to this space. They haven’t had the chance to work through the rough edges on lower-stakes stuff first. They’re jumping straight from zero to full agentic, and the only frame of reference they have is a demo where everything worked perfectly. That’s a dangerous place to start forming expectations.

The Slack Channel Problem

Here’s what happens in every Slack channel when a shiny new thing lands: the optimists are loud, and the skeptics are quiet.

Nobody wants to be the person who kills the vibe. So the channel fills up with “🔥🔥🔥” reactions and screenshots of AI generating code in seconds, and anyone with a more measured take keeps it to themselves. Over time, that silence starts to look like consensus. And before you know it, you’re treating a tool that’s been in the building for six weeks like it’s a solved problem.

I’m not saying the enthusiasm is wrong. Excitement about new technology is a good thing. It drives adoption, it drives experimentation, it drives progress. But excitement without skepticism is how you end up in a mess you didn’t see coming. The people who’ve actually put time into these tools know they can hallucinate, stray from the task, produce code that looks right but isn’t, and confidently walk you in the wrong direction. That knowledge changes how you work with them. If you skip that learning curve, you’re setting yourself up.

Leave a comment

We’re All Orchestrators Now

One of the things I keep hearing is that developers won’t be replaced, we’ll just become orchestrators. We’ll manage the AI, review the output, steer the direction. Sounds reasonable on the surface.

But think about what that actually means over time.

The less code you write, the harder it becomes to evaluate the code being written for you. It’s a feedback loop that works against you. Right now, an experienced developer can look at AI-generated code and spot the problems. The awkward logic, the edge cases it missed, the place where it technically compiles but violates how the rest of the system is supposed to work. That skill exists because of years of writing code, breaking things, and fixing them.

If we hand off the writing entirely, that skill atrophies. And when it does, who’s actually reviewing the output? Another automated process? At some point “human in the loop” becomes a formality, not a safeguard. In a fintech system where a bad calculation can have real consequences for real people, that’s not a theoretical concern, it’s a very practical one.

The LOC Flex That Isn’t

Let’s talk about metrics for a second, because this one drives me insane.

You’ve seen the posts. “AI generated 10,000 lines of code in 30 seconds.” It’s always framed like that’s obviously a good thing, like raw volume is the goal. Spoiler: it isn’t. It never was.

Lines of code has always been a garbage metric. It doesn’t tell you anything meaningful about productivity, quality, or value delivered. The question isn’t whether AI can write 10,000 lines in 30 seconds. The question is whether you needed 10,000 lines to solve the problem. The question is whether those 10,000 lines actually do what the business needs them to do. The question is whether you’d want to maintain that codebase in two years.

Bragging about volume is the AI equivalent of a junior dev who’s proud of a 500-line function. More code is not better code. Coding has always been a means to an end. The real value is in the decision making, the architecture, the problem solving. Syntax is the easy part. It’s always been the easy part. AI being good at the easy part isn’t the revolution it’s being sold as.

Share The Stoic Coder

Tests That Pass Aren’t Always Tests That Matter

This one keeps me up at night more than anything else.

AI is pretty good at generating tests. The problem is it’s also pretty good at generating tests that pass without actually validating anything meaningful. I’ve seen it produce tests that check whether a function runs without throwing an error and call it coverage. Technically green. Completely useless.

In most systems, that’s annoying. In a fintech system, it’s a genuine liability. If your tests aren’t asserting the right things, if they’re not tied to actual business rules, you’re not testing anything. You have a false sense of safety. If an AI produces bad tests, what’s to stop it from subtly adjusting logic elsewhere to make those bad tests pass? It’s optimizing for green, not for correct. Those aren’t always the same thing.

This is where human judgment can’t be replaced with another automated step. Someone who understands the domain has to look at the assertions and ask whether they actually reflect reality. That requires knowing the business rules. It requires caring about what the code is supposed to do, not just whether it compiles.

Where I Actually Land

I’m not out here saying AI is useless. I use it. It speeds things up. It’s a legitimately good assistant when you keep it focused and stay in the driver’s seat.

But there’s a canyon between “useful assistant” and “autonomous agent running your production pipeline,” and right now we’re treating that canyon like a curb. The tooling is early. The integration patterns are still being figured out. Most teams haven’t had enough time with these tools to develop the instincts for when to trust them and when to push back.

My honest take: we need to slow down, let the tools mature, and build experience before we hand over the keys. Let people get comfortable with AI as an assistant first. Let them find the edges, make the mistakes in lower-stakes environments, and develop judgment. Then talk about agentic workflows.

Maybe I’m wrong. This stuff is moving fast, and I’m planning to keep writing about it as I get deeper into the process. I’m genuinely open to being surprised here.

But “open to being surprised” and “uncritically buying the hype” aren’t the same thing; one of them keeps you out of trouble.

So I want to hear where you’re at with this. Have you been pushing AI into production workflows, or are you still in the assistant phase? And if you’ve gone deeper into agentic territory, what have you learned that the demos didn’t show you?

Drop it in the comments. The more real-world experience we can put in the same room, the better off we all are.

👉 If you enjoy reading this post, feel free to share it with friends!

Or feel free to click the ❤️ button on this post so more people can discover it on Substack 🙏

You can find me on X and Instagram.

Also, I just launched a new YouTube channel - Code & Composure

Everyone’s got an opinion on AI in software development. Half the internet wants to tell you it’s going to replace developers. The other half is convinced it’s an overhyped toy that writes garbage code and calls it a day. The truth? It’s somewhere in the middle. And most people writing about it have never actually shipped anything with it.

I have. I built a real, live iOS app using Claude Code as my primary coding partner. It’s in the App Store right now. And I’m here to tell you it was both more impressive and more frustrating than I expected.

Share

The Project: Svngs+

I work as a software engineer in fintech, dealing with legacy loan origination and servicing platforms all day. Heavy C#, TypeScript, SQL. Complex problems. I genuinely love it. There’s nothing quite like getting lost in a mind-bending problem and finally having that “aha” moment.

Best part of the job.

But spending that much time in financial systems got me thinking about my own finances. I wanted a simple way to track my savings rate, just log your net income and how much you saved each pay period. That’s it. No fancy dashboards, no bank integrations, no giving a third-party app access to your financial life.

So I built Svngs+. A native iOS app. Privacy-first. No third-party APIs, no cloud storage I control. Your data lives in Apple’s CloudKit, only you can see it. And I used this as the perfect opportunity to push Claude Code and see what it could actually do on a real project, not just a throwaway demo.

The Decision That Made Everything Else Work

Before writing a single line of code, I made one call that I think saved the whole project: I decided to use Claude as a pair programmer, not a full agentic solution.

This might sound like a small distinction. It’s not.

Going fully agentic means handing over the wheel. Let the AI run, generate, commit, and iterate on its own. Some people swear by it. My take? That’s a great way to end up with a codebase that works until it suddenly, catastrophically doesn’t. I wanted to review every piece of code Claude generated in real time. I managed the git workflow myself. I stayed in the driver’s seat.

That decision shaped everything about how the build went, including knowing when to trust the output and when to throw it out and do it myself.

Leave a comment

The Framework: Four Parts Before You Write Any Code

One thing I’d recommend to anyone trying this workflow: don’t just fire up Claude Code and start asking it to build things. You’ll get slop. I broke the project into four phases before touching the IDE.

Part 1: Product Definition. What does this app do, what problem does it solve, who’s it for? Nothing technical yet. Just the idea, the scope, and a rough version breakdown so I could define a real MVP.

Part 2: User Flow. Every screen, every interaction, the full onboarding experience. Map it out before you build it.

Part 3: Tech Spec. This is where the nuts and bolts live. Architecture decisions, dependencies, data layer. For Svngs+, that meant Swift, SwiftUI, SwiftData for local storage, CloudKit for cross-device sync, StoreKit for an in-app purchase that unlocks unlimited history, and biometric authentication via Face ID, Touch ID, or passcode.

Part 4: Build Plan. This is the heart of working with Claude Code. Break the MVP into phases, break those phases into hyper-focused tasks. Every task is its own session. I also generated a CLAUDE.md file that set up ground rules: patterns to follow, where code should live, what to avoid.

That structure kept Claude on track. Without it, you’re just prompting into the void.

Where Claude Actually Impressed Me

Five weekends. One App Store submission. Let’s give credit where it’s due.

Claude was genuinely strong with Swift. Modern Swift, not legacy Objective-C patterns dressed up in new syntax. Best practices around SwiftUI were solid. The component structure it generated was clean, readable, and maintainable. For a lot of the standard UI work and business logic, I was reviewing code and thinking “yeah, I’d have written it pretty much like this.”

The in-app purchase flow with StoreKit? Handled it well. Local notifications for reminders? Clean. The biometric authentication setup? Worked first time.

When Claude was in its lane, building against well-documented, modern Apple frameworks, it was a legitimately good pair programmer. Fast, consistent, and it didn’t complain when I told it to redo something.

Where It Fell Apart

Here’s the part that doesn’t make it into most of these “I used AI to build an app” posts. Because there were real failures, and they’re worth talking about.

The SwiftData / CoreData confusion.

SwiftData is Apple’s modern ORM framework. CoreData is the older one SwiftData is built on. They’re related but they are not the same thing, and Claude kept reaching for CoreData patterns when it should have been thinking in SwiftData. Early sessions I was catching these before they caused problems. But it was a consistent friction point that required me to course-correct repeatedly. If I hadn’t known the difference, if I’d been a less experienced developer leaning on AI to fill knowledge gaps, this would have quietly poisoned the codebase.

The CloudKit disaster.

This one’s the best example of why you cannot go fully agentic and walk away.

CloudKit sync through SwiftData is largely automatic. Apple built it that way. You configure the container correctly, and it just works. There’s no custom sync model to write. Claude did not believe this. It kept trying to build me a sync manager, custom code to handle something the framework already handles natively. I kept redirecting it. It kept reverting.

Eventually I had to configure the CloudKit container myself, following Apple’s own documentation. Here’s the kicker: Claude found that documentation. It surfaced the right Apple dev docs during our session. Then apparently decided the docs were optional and did its own thing anyway. I ended up coding that piece entirely by hand.

The AI found the correct answer and ignored it. Without my experience to recognize the problem and my willingness to step in, that feature would have shipped broken or over-engineered. And I might not have even known why.

The StoreKit abstraction it ignored.

Before building the in-app purchase flow, I had a decision to make: StoreKit directly, or RevenueCat. For the MVP I kept it simple and went with StoreKit, but I wanted the flexibility to swap in RevenueCat later if I add subscriptions down the road. The right move in Swift is to define a protocol that the rest of the app talks to, then inject whichever implementation you’re using. Clean, future-proof, easy to swap.

Claude built the protocol correctly. Built the StoreKit class correctly. Then went ahead and injected StoreKit directly throughout the app, completely bypassing the abstraction it had just created. It did the hard part right and then ignored it. I caught it, fixed the injection, and now the app talks to the protocol the way it should. But if I hadn’t been reviewing in real time, I’d have a codebase that works today and becomes a pain in the ass the moment I want to make a change.

The fastlane screenshot setup.

Minor compared to the others, but Claude had real trouble with seed data for automated App Store screenshot generation. I got it across the line myself, but it took longer than it should have.

Share The Stoic Coder

The Honest Take

Here’s where I land after five weekends and one App Store submission: AI is a legitimately powerful tool in the right hands. But “in the right hands” is doing a lot of work in that sentence.

You still need to know what good code looks like. You still need to know when to trust the output and when to throw it in the trash. The slop code problem is real. It might not bite you today, but it will eventually. Technical debt is sneaky like that. You feel fine right up until you don’t.

Think of it like a junior dev who’s brilliant half the time and confidently wrong the other half. You wouldn’t let that person commit without review. Same rules apply here.

Use AI as a pair programmer. Own the architecture. Review everything. And maybe don’t let it anywhere near your CloudKit configuration.

Svngs+ is live in the App Store if you want to check it out. I’m already working on the next app using the same workflow and refining the process as I go.

I’m curious where you’re at with AI in your own dev work. Are you using it as a pair programmer, or have you gone full agentic? And if you’ve been burned by slop code making it to production, I’d love to hear that story, drop it in the comments.

👉 If you enjoy reading this post, feel free to share it with friends!

Or feel free to click the ❤️ button on this post so more people can discover it on Substack 🙏

You can find me on X and Instagram.

Also, I just launched a new YouTube channel - Code & Composure

Every developer hits it eventually. That moment where you’re staring at your calendar, your codebase, your offer letter. And you genuinely don’t know which way to go.

Stay or leave. Startup or enterprise. Double down or walk away.

Both options feel right and wrong at the same time.

Several back, I was at a startup. Scrappy, fast, the kind of place where you’re wearing five hats and shipping things that actually matter. And an opportunity came along to jump ship. More stability. Bigger company. A cleaner title. On paper, it looked like the smart, grown-up move. The safe move.

So I took it.

And the comfort I thought I was walking into? It never showed up. The stability wasn’t stable. The clarity wasn’t clear. The discomfort found me anyway. It just came wearing a different outfit. I’d optimized for the wrong thing, and I paid for it.

That experience cracked something open for me. Because it forced me to ask: if the “safe” choice blows up just as badly, what the hell are you actually supposed to use as a compass?

Turns out, the Stoics had an answer, and it’s not a pros and cons list.

Share

The Problem With How We Make These Decisions

Most of us approach career forks like a debugging session. Gather the data. Weigh the variables. Pick the output with the best expected value.

Salary delta. Growth trajectory. Tech stack quality. Work-life balance score.

And look, none of that is useless. But it’s also not enough. Because you can optimize every variable and still end up feeling hollow in the new role by month three. You can turn down the “risky” option and still watch your edge dull into nothing over the next two years.

The Stoics would tell you the spreadsheet is asking the wrong question. The real question isn’t which path feels safer. it’s which path makes you better.

Not better-paid. Not better-titled. Better as a person doing the work you’re built to do.

They had a framework for this. Four cardinal virtues: courage, wisdom, justice, and temperance. Not as abstract philosophy, as practical filters for exactly the kind of decision you’re standing in front of right now.

Let’s run your fork through all four.

Courage: Is This Fear or Is This Wisdom?

Here’s the first thing you need to be honest about: are you staying because it’s genuinely the right call, or because you’re scared to leave?

These feel different in your chest if you sit with them long enough. Fear has a tightness to it. It whispers. What if you fail? What if the new stack is a disaster? What if you give up the salary and can’t get it back? Fear is always trying to protect a version of you that doesn’t exist anymore.

Courage isn’t the absence of that voice; it’s making the call despite it when the call is the right one.

Courage also means being honest when you’re chasing excitement for its own sake. Sometimes the bold move is just recklessness wearing ambition’s clothes. Jumping to a shiny new startup because you’re bored isn’t courage. It’s avoidance with better optics.

Ask yourself: does this decision require me to grow, or does it just let me escape? Courage grows you. Recklessness just relocates your problems.

Wisdom: What Are You Actually Choosing?

This is where I got it wrong with my own fork.

I thought I was choosing stability. What I was actually choosing was the idea of stability. Because I’d attached a story to the bigger company that had nothing to do with reality. The Stoics call this the trap of preferred indifferents: things like money, title, and comfort that are nice to have but are completely neutral when it comes to your actual character. They can’t make you better. They can’t make you worse. They’re just... things.

The problem is we treat them like they’re guarantees. Bigger company = more security. More money = less stress. Better title = more respect. And when reality doesn’t honor that deal, we’re blindsided.

Wisdom means seeing what you’re actually choosing, not the story you’ve wrapped around it.

So ask yourself: in five years, what does this decision look like? Not the salary. Not the title. The version of you that comes out the other side. Is that person sharper or softer? More capable or more comfortable? More themselves or less?

If you can honestly answer that staying makes you better, stay. If you can honestly answer that leaving makes you better, leave. But make sure you’re answering the real question. Not the one that makes you feel better right now.

Leave a comment

Justice: Who Else Is In This Equation?

This one gets skipped a lot. Probably because it’s uncomfortable.

Your decision doesn’t just affect you. It affects your team, your users, your family, the people depending on what you build or lead. And there’s a version of every career move that’s just dressed-up selfishness: optimizing purely for yourself while conveniently ignoring the blast radius.

That doesn’t mean you owe your employer your entire career. It doesn’t mean you have to martyr yourself to a role that’s killing your growth out of some misplaced loyalty. Justice isn’t self-sacrifice.

It means being honest about the full picture. If you’re the only one who knows how the payment processing system actually works and you’re thinking about walking out mid-sprint with zero handoff, that’s not bold, that’s just shitty. If you’re staying in a role that’s making you bitter and checked out because you feel guilty leaving, that’s not noble, it’s just slow-motion bad for everyone.

Justice asks: am I being fair? To my team. To my family. To myself. All three. Not just the one that’s loudest right now.

Temperance: Are You Attached or Aligned?

Last filter, and arguably the hardest one to apply honestly.

Temperance is about examining your grip. How tightly are you holding on to what you have — and why?

There’s a difference between staying in a role because you’re genuinely aligned with the work and the direction, and staying because you can’t stomach the idea of losing the salary, the title, the status, the daily routine you’ve built your identity around. One of those is healthy preference. The other is attachment, and the Stoics were pretty clear that attachment is where your judgment goes to die.

Try this: imagine you leave. The new thing is harder than expected. The stack is a mess. The team is chaotic. You’re six months in and wondering what you were thinking. Can you handle that? Will you survive it, learn from it, come out the other side with more than you started with?

If yes — that’s the answer you needed. Fear just lost its veto.

Now flip it. Imagine you stay. Two years pass. You’re still in the same chair, same problems, same ceiling. What does that feel like? Is that peace or is that resignation?

Whatever answer comes up first — trust it. That’s not anxiety talking; that’s clarity.

Share The Stoic Coder

The Decision Itself

Choose the path, then commit completely to walking it well.

Not to the outcome. You don’t control the outcome. The startup might fail. The big company might restructure. Your new stack might be a catastrophe in ways nobody saw coming. None of that is yours to control.

What’s yours is the quality of the choice and the integrity of how you execute it. Make the decision like it matters, because it does. Then hold your plans loosely, because the world doesn’t care about your plans.

And if you’re still stuck after running all four filters? Ask yourself this:

Which decision requires the better version of me to pull off?

That’s your answer.

The fork is uncomfortable by design. It’s supposed to be. The discomfort is the test. It’s not about which option is safer. It’s about whether you live by your values or react to your fears.

I chose the comfortable-looking path. The comfort never came. But the lesson did.

Now I want to hear from you:

Have you ever made the “safe” career move and had it blow up anyway? Or are you standing at a fork right now and can’t figure out which way to go?

Quote of the Day:

First say to yourself what you would be, and then do what you have to do.” - Epictetus

👉 If you enjoy reading this post, feel free to share it with friends!

Or feel free to click the ❤️ button on this post so more people can discover it on Substack 🙏

You can find me on X and Instagram.

Also, I just launched a new YouTube channel - Code & Composure

It’s 11:47 PM. You’re not coding. You’re on LinkedIn, watching someone from your bootcamp cohort announce their Staff Engineer promotion, and something in your chest tightens.

You tell yourself you’re just staying informed. But you’re not. You’re measuring. And right now, you’re coming up short.

I’ve been there. Doesn’t matter how many years you’ve been shipping, the peer promotion gut-punch feels the same at year two as it does at year twenty. Where shipping a feature nobody noticed felt like wasted effort. Where the question wasn’t “did I do good work?” but “did anyone see me do good work?”

That’s not ambition. That’s a trap. And the Stoics figured out how to escape it about 2,000 years before hustle culture made it a personality.

Share

The Word You’ve Been Misreading

Apatheia. If your brain jumped straight to apathy, you’re not alone. But you’re wrong.

Apatheia doesn’t mean you stop giving a damn. It doesn’t mean you coast, phone it in, or stop caring about your craft. It means freedom from destructive passions — the kind that have you refreshing your GitHub stars at midnight, spiraling when a PR gets torn apart in review, or quietly resenting a teammate’s promotion.

The Stoics weren’t lazy. Marcus Aurelius ran an empire while fighting wars on two fronts and dealing with a plague that killed millions. Seneca was one of the most prolific writers in Roman history. Epictetus built a philosophy school after being a literal slave. These weren’t people who checked out. They were ferociously committed to their work.

But here’s what separated them from the hustle-culture crowd: they didn’t let outcomes own them.

Leave a comment

The Flaw in the “10x Developer” Myth

Hustle culture has a core belief: the more you suffer for your work, the more virtuous you are. Grind harder. Sleep less. Ship faster. If you’re not burning out, you’re not trying hard enough.

The Stoics would have called bullshit on this immediately.

Frantic energy isn’t a sign of dedication. It’s usually a sign of poor judgment. When you’re chasing validation instead of craft, you make worse decisions. You over-engineer to impress. You under-communicate because slowing down feels like weakness. You build things nobody asked for because the building feeds your ego, not the problem it solves.

Here’s the thing about the 10x developer mythology that nobody says out loud: skill is morally neutral. You can be an exceptional engineer and a miserable, destructive human being. You can write the cleanest codebase your team has ever touched and still be the person everyone dreads pairing with.

The Stoics cared about virtue, not talent. And virtue shows up in how you show up for your teammates, not just your commit history.

What Indifference Actually Looks Like (It’s Not What You Think)

Here’s the distinction that matters: Apatheia is being indifferent to outcomes while being fully committed to effort.

Write excellent code because it’s the right thing to do. Not because you need the dopamine hit of a compliment in Slack. Refactor the messy module because future-you and your teammates deserve better. Not because you want credit for it. Help the junior dev debug their auth issue because that’s what a good engineer does. Not so you can mention it in your performance review.

In my fintech work, I’ve shipped payment infrastructure that processed millions in transactions without a single public-facing acknowledgment. No blog post, no conference talk, no LinkedIn announcement. The code worked. Users didn’t lose money. That’s the whole point.

When you detach your self-worth from external validation, something weird happens: the work gets better. Because you’re not optimizing for appearance. You’re optimizing for quality.

Share The Stoic Coder

Marcus Aurelius Had the Same Problem You Do

Marcus Aurelius, emperor of Rome and one of the most powerful humans who ever lived, had to remind himself daily not to get caught up in what other people thought of him.

His journal, which we now call Meditations, is basically a guy talking himself down from the ledge over and over again. Stop caring what they think. Focus on your own work. Do the right thing even when nobody’s watching.

If the ruler of an empire needed that daily reminder, you’re allowed to need it too.

Other developers’ success has zero bearing on your path. Someone else getting promoted doesn’t mean you’re falling behind. Someone shipping a viral side project doesn’t mean your side project (or your decision not to have one) is wrong. The variables driving their career are different from yours. The variables you can actually control are different from theirs.

The only scoreboard that matters is whether you’re growing, doing honest work, and treating the people around you well.

Getting Off the Cortisol Treadmill

You can still want the senior role. You can still launch the side project. You can still care about growing your skills and getting better. Apatheia isn’t telling you to stop striving.

It’s telling you to stop letting the gap between where you are and where you want to be eat you alive in the meantime.

The burnout cycle is real, and it doesn’t make you more dedicated. It makes you less effective. I’ve watched incredibly talented developers flame out because they treated exhaustion like a badge of honor. They ground themselves into dust chasing a finish line that kept moving, and eventually they stopped caring about code entirely.

That’s not the outcome anyone was aiming for.

Write clean code. Help your teammates. Keep learning. Pursue the roles and opportunities that align with the kind of engineer and person you want to be. And when marketing conditions shift, when someone else gets the promotion, when your PR gets rejected for the third time: let that be information, not an identity crisis.

The Stoics weren’t building a philosophy for people who didn’t care; they were building one for people who cared too much about the wrong things.

Sounds familiar, right?

So here’s what I want to know:

Where are you on this? Are you genuinely pursuing excellence — or are you on the cortisol treadmill, grinding because stopping feels like losing? And if you’ve found a way off it, what actually worked?

Drop it in the comments. Seriously.

Quote of the Day:

“It is not the man who has too little, but the man who craves more, that is poor.” - Seneca

👉 If you enjoy reading this post, feel free to share it with friends!

Or feel free to click the ❤️ button on this post so more people can discover it on Substack 🙏

You can find me on X and Instagram.

Also, I just launched a new YouTube channel - Code & Composure