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

Between the Slack notification and your angry reply, there is a gap. In that gap lives your entire career trajectory.

Your PR just got torn apart. Not gently, either. Someone went line by line, questioned your architecture, and did it in a public channel where half the team can see it. Your face goes hot. Your fingers are already moving toward the keyboard. You’ve got a response locked and loaded, and it starts with “Well, actually...”

Stop. Don’t send it.

I’ve been there. Early in my career, I’d fire back almost immediately. I was convinced that defending my code was the same thing as defending my competence. Looking back now, I can’t even remember what half those arguments were about. The thing that felt like a five-alarm crisis on a Tuesday afternoon? Gone from my memory entirely. But the reputation I was building, that part stuck around a lot longer than the debate.

Here’s what Epictetus figured out a couple thousand years before Slack existed: events themselves are neutral. It’s our judgment about them that creates the suffering or the peace. Your PR getting reviewed isn’t an attack. It’s a process. The attack is a story your brain invented in about 300 milliseconds flat.

Share

Your First Reaction Is Almost Always Wrong

That defensive surge you feel when someone questions your technical decision in front of the team? That’s not your professional instincts kicking in. That’s evolutionary firmware running on code that was written for a very different threat environment. Your nervous system genuinely cannot tell the difference between a critical comment on a pull request and a predator in the bushes. It fires the same way either time.

The Stoics called this the “first impression”, the automatic, unchosen reaction that happens before your brain has had time to actually think. The goal isn’t to kill that reaction. You can’t. The goal is to create a gap between the impression and your response, and then actually use that gap.

Even three seconds is enough to shift from defensive to curious. That sounds insultingly simple, and it is. But simple doesn’t mean easy. The pause is a trained skill, not a personality trait. And most of us have spent years training the opposite habit.

The Story You’re Telling Yourself

When someone pushes back on your technical decision, your brain immediately starts constructing a narrative. It’s not just processing the feedback; it’s assigning motive, predicting consequences, and scoring the whole thing against your sense of self-worth. By the time you’re ready to respond, you’re not responding to the comment anymore. You’re responding to the movie your brain made about the comment.

So before you fire off that reply, ask yourself one question: what else could this mean?

What if they’re trying to prevent a production bug? What if they caught something you genuinely missed? What if they see the codebase from a different angle? Not a better angle, not a worse one, just different. And that perspective is actually useful to you?

Maybe you introduced a feature that already exists somewhere else in the codebase and someone’s pointing it out. That’s not an insult, that’s someone doing their job. The difference between receiving that as an attack versus receiving it as information is entirely in your head.

And entirely in your control.

Leave a comment

The Practical Tools

The Stoics weren’t just philosophers. They were incredibly practical. Here are three things that actually work:

The draft folder rule. Before you hit send on that “well actually” message, save it as a draft and come back in an hour. You’ll delete 80% of them. The other 20% you’ll rewrite into something that doesn’t make you look like an asshole. This works for social media too. Write the response, feel the satisfaction of having written it, then let it sit. Most of the time, it never needs to leave your drafts.

The three questions. Before reacting, run the comment through a quick filter: Is my interpretation actually true? Is my response necessary? Is it going to move things forward or just make me feel better for thirty seconds? Most knee-jerk reactions fail at least one of those tests. Usually all three.

The timeline check. Will this matter in ten minutes? Ten months? Ten years? I’ve lost sleep over feedback that I legitimately cannot recall today. That’s not me being zen about it, that’s just how it played out. The things that feel like career-ending disasters during a sprint rarely survive contact with next week’s stand-up.

Share The Stoic Coder

Emotions Are Data, Not Orders

Getting angry about a management decision or a brutal code review tells you something real about your expectations and your values. That’s useful information. It’s not a command to act on the anger.

Stoics feel emotions. They’re not robots. They just don’t take orders from them.

There’s a time to push back and a time to let it go. Not every technical decision is worth the argument. Sometimes the smarter move is to take the feedback, consider it honestly, and ask whether your approach was actually the right one. Sometimes you’ll decide it was and you’ll make that case clearly and calmly. Sometimes you’ll realize they had a point you missed. Both outcomes are fine. Neither of them requires you to go to war in a Slack thread.

The Gap Is the Whole Game

Change is the one constant in this field. Priorities shift mid-sprint. Architecture decisions get revisited. Someone’s going to question your code in a public forum again, probably next week. That’s not a bug in the system. That’s the system.

What separates the developers who grow through that process from the ones who get ground down by it isn’t talent or experience. It’s the ability to create that gap. Act between the notification and the reply. Shape your impression into a thoughtful response.

Your career isn’t built in the moments when everything goes smoothly. It’s built in the moments when someone tears your PR apart and you respond like a professional instead of a cornered animal.

The gap is where that happens.

Quote of the Day:

“It’s not what happens to you, but how you react to it that matters.” - 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

You own your career. The job is just a rental.

That distinction sounds simple, but most developers never actually internalize it. Instead, we treat every career decision like it’s a life sentence: agonizing over spreadsheets, running endless pros-and-cons lists that somehow never resolve, and letting fear and greed drive choices that should be driven by something a hell of a lot more solid.

The Stoics figured this out a long time ago. The best decisions don’t come from calculating every possible outcome. They come from asking one question: what does virtue demand of me right now?

I know that sounds abstract. Let me make it concrete.

Share

The Moment the Spreadsheet Fails You

A few years back, I was still building Flash applications when the writing was on the wall. Adobe was circling the drain, and every developer I knew was either panicking or pretending nothing was happening. I made a bet on .NET and enterprise. Not because the numbers were perfect, but because it felt like the right long-term play. Was it scary? Absolutely. But staying put felt like a different kind of scary. The slow, comfortable kind that eventually swallows you whole.

That decision wasn’t made on a spreadsheet. It was made on instinct that had been sharpened by asking the right questions.

The Stoics had a framework for this. Four virtues (wisdom, courage, justice, and temperance) that they believed could guide any decision, in any situation. And honestly? They hold up remarkably well when a recruiter is blowing up your LinkedIn with a shiny new offer.

Wisdom: Fear vs. Prudence

Are you staying because you’re genuinely building something valuable, or because change terrifies you?

Those are completely different things, and your brain will lie to you about which one is operating. It’ll dress up fear as loyalty. It’ll call avoidance “being strategic.” Wisdom is what cuts through that noise.

Ask yourself: if fear weren’t a factor at all, what would you do? The answer that surfaces is usually the one you already know. Wisdom isn’t about eliminating uncertainty, it’s about making the best call with the information you have, and trusting that you’ve prepared yourself to handle whatever comes next.

The unprepared developer panics when layoffs hit. The one who’s been building their skills, their network, and their reputation? They’re already thinking about the next move before the severance check clears.

Leave a comment

Courage: Comfortable Isn’t the Same as Safe

Here’s what courage is not: it’s not blindly jumping at every shinier opportunity because you’re bored. Recklessness isn’t brave. It’s just impatient.

Real courage sometimes looks like staying. If you’re the only senior dev holding a crumbling codebase together and you know the team collapses without you, walking away might be the easy move, not the courageous one. Fixing what’s broken from the inside, having the hard conversation with leadership, pushing for the changes that actually matter. That can take more guts than handing in your notice.

But courage also means not letting a stable paycheck become a cage. If money is the only reason you’re staying, you’ve already mentally checked out. You’re just waiting for your body to catch up. External rewards — salary, title, perks — can’t manufacture internal satisfaction. The Stoics were relentless on this point, and they were right.

Layoffs happen. Pay cuts happen. Companies pivot, get acquired, implode. Nothing is permanent. The courage isn’t in pretending the floor is solid , it’s in staying ready to move when it isn’t.

Justice: Don’t Be a Selfish Jackass on Your Way Out

Seneca had a lot to say about using people as stepping stones, and it wasn’t complimentary.

If you’re leaving, how you leave matters. Are you giving your team enough runway to absorb the transition? Are you being honest with the people who trusted you? Burning bridges might feel satisfying for about thirty seconds, but this industry is smaller than you think, and your reputation follows you everywhere.

Justice in career decisions isn’t about being a martyr. It’s not about staying in a toxic situation because you feel guilty leaving. It’s about making sure that however you move, you move with integrity. Transition with honesty. Don’t ghost your team. Document what you know. Give your notice with respect, even if the place didn’t always deserve it.

What goes around comes around. And I don’t mean that in some vague karmic sense. I mean it practically: the developer you screw over today might be interviewing you in three years. Act accordingly.

Share The Stoic Coder

Temperance: Know When Enough Is Enough

Not every opportunity that pays more or sounds shinier is actually better. This is the one developers get tripped up by constantly, especially when the market is hot.

Temperance is the ability to look at a 30% raise and ask: what’s the actual cost of this? More hours? A worse team? A tech stack you hate? A company culture that’ll grind you down in six months? Better compensation, a fancier title, a sexier tech stack. Those things are nice to have. They’re not a decision framework.

The real questions are: Will you regret working more for making more? Is there an opportunity where you can do something genuinely valuable, even if the money is roughly the same? What changes in your life (your flexibility, your time, your sanity) and is the trade worth it?

Consider what you actually want your life to look like, not just your bank account. Temperance isn’t about settling. It’s about not letting the shiny object override your judgment.

Trust the Work You’ve Already Done

The delay isn’t confusion. It’s just your emotions catching up to your reasons.

We all know, deep down, whether something is right. When a decision keeps nagging at you, when something feels off even though the numbers look good. That signal is real. Don’t ignore it. The Stoics called this the alignment of reason with nature. I call it your gut having done the work your spreadsheet hasn’t.

The goal isn’t to eliminate the uncertainty of career decisions. The goal is to make them from a place of clarity instead of fear. Filter your choices through wisdom, courage, justice, and temperance. This makes the path ahead clearer, rather than letting anxiety and money guide you.

Your career belongs to you. The job is just where you happen to be standing right now.

So here’s what I want to know: when you’ve faced a major career decision, what actually drove the call? Was it data, or was it something harder to name? Drop it in the comments — your experience might be exactly what someone else needs to hear right now.

Quote of the Day:

“It is not because things are difficult that we do not dare; it is because we do not dare that things are difficult.” - 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

It’s 11pm. Xcode is open. You’re staring at Swift syntax you’ve never written in your life, and some voice in the back of your head is telling you to close the laptop and come back when you “know more.”

Instead, you type a prompt.

That’s vibe coding. And yeah, traditional developers lose their minds over it.

Share

“That’s Not Real Programming”

I get it. I’ve been writing software for 25 years. I understand the instinct to protect the craft. But let’s be honest about what’s really happening when experienced developers dismiss AI-assisted development as “not real programming”, they’re not protecting quality. They’re protecting identity.

Stoics would recognize this immediately. Marcus Aurelius didn’t waste energy fighting things outside his control. He focused on what he could actually influence. AI’s advancement? Not in your control. Market disruption? Not in your control. Your willingness to learn, adapt, and leverage new tools? That’s yours. All of it.

The dichotomy of control isn’t just a philosophical concept, it’s a survival skill for developers right now. Clinging to the idea that your value lives in syntax you memorized is like a blacksmith in 1910 insisting that anyone who uses a power tool isn’t a “real” craftsman. Meanwhile, the guy with the power tool is building three times as much.

Vibe coding (describing what you want and iterating with AI until it exists) isn’t the end of real software development. It’s a new tool that reveals something uncomfortable: who’s been coding for the joy of creation, and who’s been hiding behind gatekeeping complexity.

Leave a comment

My Experiment: Building an iOS App in a Language I Barely Know

Here’s where I put my money where my mouth is.

I’ve done iOS development before, mostly in Objective-C. Swift? Not my world. But I had a clear idea for a savings rate dashboard app, something genuinely useful, something I wanted to exist. So instead of waiting until I’d done six months of Swift tutorials, I started building it. With AI as my co-pilot, breaking down the work into pieces I could actually manage.

This isn’t theory. This is me, right now, figuring it out as I go.

And here’s what I’ve learned: the AI doesn’t care that I’m rusty on Swift. It handles the boilerplate. It handles syntax I’d otherwise have to look up a dozen times. What it can’t do is decide what to build, why it matters, or whether the architecture makes sense for the long haul. That part is still on me. That part will always be on me.

Not knowing Swift became irrelevant when I could prototype, test assumptions, and ship an MVP in days instead of months. Note: I’m about a week away from submitting version 1 to the app store.

Share The Stoic Coder

Aimless Prompt Thrashing Is Not a Strategy

Let me be clear about something, because I see this mistake everywhere: you cannot just wing it.

The idea that you can magically build something by dumping vague prompts into an AI is naive, and it leads to a chaotic mess of half-working code you don’t understand.

What actually works is treating AI the way you’d treat a capable junior developer. You wouldn’t hand a junior a vague task and disappear. You’d give them a clear objective, a defined scope, and enough context to succeed. Then you’d review their work and course-correct.

Before I type a single prompt on this iOS project, I have a build plan. Clear goals. A tech spec. Tasks broken into pieces small enough that the AI can actually shine on them. That preparation is what separates productive AI-assisted development from burning three hours to produce garbage.

The AI handles the heavy lifting. I handle the vision and the judgment. That’s the deal.

The Anxiety Tells You Everything

If reading about AI replacing developers makes your stomach drop, that anxiety isn’t about AI. It’s a signal that you’ve tied your professional identity to syntax memorization instead of problem-solving ability. And that’s worth sitting with for a minute.

Think about what you’re actually afraid of losing. Is it your ability to solve hard problems? To understand systems, architecture, business logic, user needs? Because AI isn’t touching any of that. Or is it the ability to write a for-loop faster than a junior dev, or recall the exact method signature without checking docs?

Because one of those things matters. The other one never really did.

Software engineering has always been about solving problems, understanding what the business needs and delivering something that works. The language was always just the vehicle. Developers who lose sight of that are the ones who’ll struggle, not because of AI, but because they were already optimizing for the wrong thing.

Epictetus had a line that applies here: it’s not things that disturb us, but our judgments about things. AI isn’t the threat. The judgment that your value is tied to irreplaceable technical obscurity—that’s the threat.

The Developers Who Will Thrive

They’re not the ones who know the most languages.

They’re the ones who solve valuable problems regardless of the tools available. They adapt. They stay curious. When a new tool shows up, they ask “how can I use this?” instead of “why is this bad?”

As a solo developer, I’m juggling marketing, product development, customer support, and feature building all at once. Leveraging AI to handle some of that load while I stay focused on long-term strategy isn’t laziness, it’s leverage. It’s the same reason senior engineers use frameworks instead of writing everything from scratch. You use the tools that let you build more, faster, without compromising on what actually requires your judgment.

This savings rate app isn’t just a side project. It’s proof that your ideas can become real without waiting for perfect knowledge. It’s proof that “I don’t know Swift well enough” is a story you’re telling yourself, not a fact about the world.

So Where Does That Leave You?

Fighting AI’s role in development is like resenting gravity. It’s here. It’s changing things. The only real question is whether you’ll adapt with curiosity or resist with fear.

You can’t control what AI does to the industry. You can control whether you pick up the tool and figure out how to use it well.

I’m still figuring it out. The Swift app isn’t done (although it is really close). Some days the AI output needs serious rework. Some days it nails exactly what I needed in thirty seconds. That’s the process. And honestly? I’m having more fun building than I have in a while, because I’m back to focusing on the part that actually matters: the problem, not the syntax.

So here’s what I want to know from you:

What’s the AI fear you’re still holding onto and what would it take to let it go?

Drop it in the comments. You might be saying exactly what someone else needs to hear.

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

We obsess over technical debt. The messy code, the shortcuts, the “we’ll fix it later” promises that quietly compound into a maintenance nightmare. We track it, we argue about it in sprint planning, we write long Confluence pages about it that nobody reads.

But there’s another form of debt accumulating in the background, one that doesn’t show up in code reviews, static analysis tools, or your backlog. One that’s a hell of a lot more expensive because it doesn’t just slow down your codebase.

It slows you down.

It’s called cognitive debt, and there’s a solid chance it’s already wrecking your output without you even realizing it.

Share

What Is Cognitive Debt, Exactly?

Think of your brain like a bank account. Every context switch, every poorly named variable, every undocumented system you have to reverse-engineer from scratch, every Slack notification you haven’t dealt with. Those are all withdrawals. And unlike technical debt, you can’t refactor your way out of this one. You can’t open a ticket for it. There’s no sprint dedicated to paying it off.

Every time you switch between projects, meetings, or mental models, research suggests you pay a swap cost of roughly 15-20 minutes just to get back to full capacity. Let that sink in. Every “hey, quick question” Slack message, every context switch between a PR review and the feature you were actually building, that’s 15-20 minutes of your best thinking, gone.

And it compounds.

The Ways You’re Racking Up the Bill

Bad naming and unclear code forces you to hold translation layers in your working memory constantly. Instead of just reading the code, you’re playing mental archaeology.

“okay, so x2 is probably the processed transaction amount, and tempFlag is... I think the validation state?” That overhead adds up across an entire codebase.

Your notification backlog is creating background anxiety you’re probably not even consciously aware of. Those 47 unread GitHub notifications, the Slack threads you’ve been “meaning to get to,” the email you flagged and forgot, they’re not just sitting there quietly. They’re fragmenting your attention every time you sit down to do real work.

Undocumented systems are the worst offenders. Every system that lives only in someone’s head, or worse, nobody’s head, requires you to actively reconstruct it from scratch every single time you touch it. That’s not a one-time cost. You pay it over and over.

Share The Stoic Coder

Why It Wrecks Your Estimates

Cognitive debt makes you terrible at estimating, and most people have no idea that’s what’s happening.

An example, you’re deep in a complex feature. You’ve got the whole system model loaded in your head. The edge cases, the data flow, the three other services it touches. Your manager pops in and asks for an estimate on something completely unrelated.

What happens?

You throw out a number just to get back to what you were doing. Of course you do. You can’t fully context-switch, so you’re estimating with maybe 40% of your actual capacity applied to the problem. Then two weeks later when you’re staring that feature in the face, you realize you either sandbagged it or, more painfully, you’re in over your head on timeline.

That’s not a planning failure. That’s cognitive debt coming due.

You Can’t Code Your Way Out of This One

Cognitive debt only clears through genuine rest, reflection, and unstructured time. That’s it. There’s no shortcut.

This is where remote work makes things genuinely harder. When you worked in an office, your commute home was a natural decompression chamber. By the time you walked in your front door, a lot of that mental load had already started to fade. Not fully, but enough.

Now? The “office” is twenty feet from your bedroom. There’s no physical leaving. The context never fully switches off because the environment never changes. You eat lunch in the same space where you debug production incidents. That’s a problem.

One thing that actually helps: treat your workspace like it’s a different location. Keep work physically contained to a specific room or space. When you close that door, you’re leaving. Protect that boundary like it’s a critical system, because it is. It’s the system that keeps you running.

Beyond that, it comes down to the basics we all know but consistently underinvest in. Actual breaks. Time that isn’t secretly “thinking about work time.” Sleep. Hobbies that have nothing to do with your job. The stuff that feels indulgent when you’re behind on a sprint but is actually the only thing that keeps you sustainable long-term.

Leave a comment

Paying It Down

You can’t eliminate cognitive debt, but you can stop letting it run unchecked.

• Name things properly. Future you (and everyone else on your team) will thank you.

• Document the weird stuff. The undocumented edge case that only you know about? Write it down today.

• Triage your notifications on your schedule, not theirs. Batch them. Don’t let them interrupt flow state.

• Protect context blocks. Deep work and shallow work shouldn’t share the same time slot. When you’re in the zone, be in the zone.

• Estimate when you’re fresh. If someone asks for an estimate while you’re heads-down in something else, buy yourself time. “Let me circle back on that in an hour” is a complete sentence.

And most importantly, take the rest seriously. Not as a reward for finishing your work. As part of the work.

Your team can track velocity. They can monitor build times and deployment frequency. But nobody’s tracking how much mental bandwidth you’re actually operating with on any given Tuesday afternoon.

That’s on you to manage.

You wouldn’t let technical debt accumulate indefinitely and expect your codebase to stay healthy. Don’t do it to your brain either.

Quote of the Day:

“Nowhere can man find a quieter or more untroubled retreat than in his own soul.” — 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

Comfort is the slowest career killer in software development. It doesn’t look like failure, that’s what makes it dangerous. You’re shipping, you’re contributing, the work feels manageable. But underneath that feeling of productivity, your actual capabilities are quietly collecting dust. And the gap between what you think you can handle and what you can handle grows a little wider every time you play it safe.

Most of us spend our careers quietly optimizing for exactly that. We grab the familiar tickets. We stick with the technologies we already know. We find reasons to stay out of the messy legacy system nobody wants to touch. It feels productive. But here’s what’s actually happening: you’re building the illusion of competence while your real capabilities stagnate. And the worst part? You won’t know it until the moment it matters most.

Seneca put it plainly: “It is not that I am brave, but that I know what is not worth fearing.” Most of the tickets that make us hesitate aren’t actually dangerous to our careers. They’re just uncomfortable. There’s a difference, and learning to tell them apart is where growth actually starts.

Share

Choosing Hard on Purpose

The Stoics had a practice called voluntary hardship, deliberately putting yourself in uncomfortable situations not because you enjoy suffering, but because it reveals things about yourself that comfort never will. This isn’t masochism. It’s a diagnostic tool.

Challenging work shows you your real limits, your actual knowledge gaps, and your emotional triggers more accurately than any self-assessment or performance review ever could. You don’t discover that you’re weak in UI work by thinking about it. You discover it by taking the UI ticket, grinding through it, struggling, and coming out the other side with a clear picture of where you actually stand.

That’s how you figure out what you’re made of. Not by reading about it. Not by watching conference talks. By doing the work.

And the flip side is just as true. You take something that scared you, push through it, and realize you’re actually pretty good at this. That’s a discovery you never make from the safe end of the ticket queue.

Leave a comment

The Problem with Waiting Until It’s Forced on You

There’s a big difference between choosing difficulty and having it dropped on you without warning.

When you voluntarily seek out hard problems, you have agency. You have time to prepare. You’re building the muscle before the game is on the line. But if you spend years avoiding everything uncomfortable and then suddenly the business is on fire, the system is down, and you’re the one holding the keyboard, you’re facing a five-alarm situation with zero reps under your belt.

That’s a terrible place to be.

Stress-testing systems is standard practice in software. You push load on the system before the traffic spike because you need to know where it breaks before it breaks in production. We are no different. Until we’re actually under pressure, we don’t know what we’re capable of. And building that pressure tolerance is something you have to do deliberately, over time, not in a crisis.

What the Hard Ticket Actually Costs You (Hint: Less Than You Think)

I work on a payment processing system. It’s not exactly the ticket people are lining up to grab. Complex business rules, serious compliance requirements, zero room for “oops.” A lot of people on the team have zero interest in it. But I took it on, and I’ve been building major functionality in it, functionality that actually matters to the business.

Here’s what that cost me: some uncomfortable weeks of ramping up. Some moments of genuine uncertainty. A few late nights tracing through code I didn’t write.

Here’s what it gave me: visibility. Credibility. The kind of hands-on understanding that you simply cannot Google your way to. When you’re the person willing to go where others won’t, the organization notices. The contribution becomes more valuable precisely because the barrier to entry is high.

That’s the visibility paradox. The problems that scare everyone else are the ones that make your contributions stand out.

Share The Stoic Coder

Good Stress Is a Thing

Most of us are wired to avoid stress wherever possible, and that makes sense on the surface. But there are two kinds of stress, and collapsing them together is a mistake.

Distress, the kind that grinds you down and burns you out, is worth avoiding. But eustress, the productive pressure of a hard deadline or a challenging problem, is actually where some of your best work happens. Deadlines force hyper-focus. Pressure strips away the noise and forces you to solve the actual problem in front of you rather than the abstract version of it. Some of the cleanest, most elegant solutions I’ve ever written came out of “we need this working by end of day” situations where I had no choice but to think clearly and move fast.

That kind of pressure builds a tolerance. And once you’ve shipped something real under real stakes, every future high-pressure situation feels a little more manageable.

The Confidence Compounds

Here’s something that doesn’t get talked about enough: the confidence you build from technical challenges doesn’t stay in the technical domain. It transfers.

You white-knuckle your way through a gnarly integration that nobody else wanted to touch, and you ship it. A month later, you’re in a room negotiating scope with a project manager who’s pushing back hard. Or you’re giving a presentation to stakeholders who are skeptical. Or you’re being asked to lead something for the first time. That reservoir of “I’ve done hard things before” is sitting right there, and it’s real. You can draw on it.

Every challenge, whether technical or personal, teaches a simple lesson: it’s just another problem to solve. You’ve figured out hard things before. You’ll figure this out too.

Stop Waiting for the Safe Moment

The comfort zone doesn’t protect you. It just makes the eventual collision with difficulty more violent because you’ve been doing nothing to prepare for it.

Adversity isn’t optional. It’s coming regardless. The only choice you have is whether you meet it with some reps behind you or whether you meet it cold. Avoiding challenges doesn’t make you comfortable, it makes you brittle. It quietly strips away your tolerance for difficulty until the day when avoidance isn’t possible and you have nothing left to draw on.

The developers who build the careers worth having aren’t the ones who avoided the hard stuff. They’re the ones who kept picking up the scary ticket, kept pushing into unfamiliar territory, kept stressing their own systems before the system got stressed for them.

Your resume tells people where you’ve been. How you handle difficulty tells them where you’re going.

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

I spent three months building a Flash application back in 2003. I’m talking late nights, weekends, the whole deal. I was proud of that thing. It was slick, it was responsive, it did exactly what the client needed. I remember showing it off to my team like I’d just built the Sistine Chapel ceiling out of ActionScript.

That application doesn’t exist anymore. Neither does the company that commissioned it. Neither does Flash.

And you know what? That’s fine. Better than fine, actually. Because the Stoics figured out something about two thousand years ago that most of us in tech are still struggling to accept: everything ends, and that’s not a tragedy, it’s the whole point.

Share

Memento Mori for Your Codebase

The ancient Stoics had this practice called memento mori, “remember that you will die.” But it wasn’t meant to be depressing. Marcus Aurelius used to meditate on his own mortality not to freak himself out, but to sharpen his focus. If your time is limited, you stop wasting it on things that don’t matter. You show up more fully for the things that do.

Now apply that to your code.

Every line you write today will be deleted, rewritten, or abandoned. Every framework you master will eventually fade into irrelevance. Every architectural decision you agonize over will be reversed by someone who thinks they know better. And honestly, they might.

This isn’t pessimism. It’s just the nature of what we do. And once you stop fighting it, something shifts. You stop writing code like you’re carving it into marble. You start writing it like it’s meant to solve this problem, for these people, right now. And weirdly enough, that makes you a better developer.

I can think back across 25 years in this industry, applications I poured myself into, systems I thought were bulletproof. Where are they now? Gone. Rethought. Reimagined. Absorbed into something else entirely. The technology moved on. The business needs changed. And the code I was so precious about? It served its purpose and then it made way for what came next.

That’s not failure. That’s the job.

Leave a comment

Stop Building Monuments, Start Solving Problems

Here’s where most of us get tripped up. We get attached. Not just to our code, but to our tools. We wrap our entire identity around being “a React developer” or “a .NET guy” or whatever framework happens to be hot right now.

I get it. I’ve been there. When I made the jump from Flash to .NET development, it felt like starting over from scratch. All that expertise, all those years of learning ActionScript inside and out, suddenly irrelevant. It stung. It felt personal, like the industry was telling me that everything I’d invested in didn’t matter.

But here’s the thing: it wasn’t personal. React, Angular, Vue — they’ll all get replaced eventually too. Some new hotness will come along and the cycle starts again. If your identity is tied to a specific tool, you’re setting yourself up to have an existential crisis every few years.

The Stoics called this apatheia. Not apathy in the way we think of it, but freedom from being jerked around by things outside your control. You don’t control which frameworks survive. You don’t control which languages the industry decides to adopt next. What you control is your ability to think clearly, learn quickly, and solve problems regardless of the tools in front of you.

Data structures. Algorithms. System design. Communication. How to break down a complex problem into manageable pieces. That’s the stuff that transfers. That’s what you take with you from job to job, from stack to stack, from one technological era to the next.

Learning React or .NET or whatever comes next: those are just means to an end. They’re vehicles, not destinations.

The Sh*t That Actually Scares Us

The reason impermanence in tech feels so threatening isn’t because we love our frameworks that much. It’s because it triggers something deeper, the fear that we might become irrelevant.

You’ve felt it. That moment when a junior dev rewrites your “perfect” module without even reading your comments. When you’re in a meeting defending a technology choice and you can see in people’s eyes that they’ve already moved on. When you read a job posting and half the required skills didn’t exist two years ago.

That anxiety is real. And the knee-jerk reaction is to dig in. To defend the old way. To cling to what you know because at least it’s familiar. The Stoics had a word for this kind of attachment too. They called it a passion, and not in a good way. It’s an irrational emotional response that clouds your judgment and keeps you stuck.

Think about sunk cost for a second. How many times have you watched a team defend an outdated approach not because it was the best solution, but because they’d already invested so much time in it? “We can’t switch now, we’ve spent six months on this.” Yeah, and you’ll spend six more months making it work when the right answer was to let it go three months ago.

When you accept obsolescence upfront. When you walk into a project knowing that this too shall pass, you don’t fall into that trap. You make decisions based on what’s best now, not on what justifies your past choices.

Share The Stoic Coder

The AI Elephant in the Room

And then there’s the big one. The thing that’s accelerating all of this impermanence at a pace none of us were really prepared for.

AI isn’t just another tool in the belt. It’s the impermanence engine. It’s taking skills that used to be the bread and butter of a developer’s career and commoditizing them in real time. Boilerplate code? AI handles that. Repetitive tasks? Automated. That thing you spent three years mastering? There’s a prompt for it now.

You can either freak out about that or you can see it through the Stoic lens. This is creative destruction happening at scale. The developers who thrive won’t be the ones who memorize syntax or cling to their ability to write a perfect for-loop. They’ll be the ones who know how to think. People who grasp the principles behind the code can design solutions. They can also explain complex ideas to others.

AI doesn’t replace that. It makes it more valuable.

So use the tools. Leverage AI for the grunt work. Invest your energy in timeless skills. Focus on critical thinking, problem-solving, system understanding, and the ability to learn new things.

The Beginner’s Advantage

When you know that everything becomes obsolete, continuous learning stops feeling like you’re desperately trying to keep up.

Instead, it just feels like... being alive.

Like staying curious. You’re not behind, you’re just always at the beginning of something new. And that’s actually a pretty exciting place to be.

I’ve been doing this for 25 years and I’m still learning. Not because I’m slow, but because the field demands it. What I knew a decade ago is legacy now. What I’m learning today will probably be legacy in another five to ten years. And I’ve made my peace with that.

You learn early in this career that you’ll never stop learning. You either embrace that or you burn out fighting it. There’s no third option.

Your Code Dies. Your Growth Doesn’t.

So if nothing lasts, what’s the point? Why pour yourself into something that’s just going to be replaced?

Because it was never about the code lasting forever. It was about what building it did to you. Every problem you solved made you a sharper thinker. Every failed approach taught you something about how systems work. Every late-night debugging session (as much as it sucked in the moment) added something to your toolkit that nobody can take away.

That Flash application I built in 2003? The code is long gone. But what I learned building it (how to think about user experience, how to optimize performance within constraints, how to communicate with clients who didn’t speak developer) all of that came with me. It shaped how I approach problems today, twenty years later.

The Stoics understood that external things are temporary. Your job, your title, your framework of choice: all of it can change tomorrow. But your character, your skills, your ability to adapt and grow. That’s yours. That’s what you’re really building every time you sit down at the keyboard.

Your code’s value isn’t in lasting forever. It’s in solving today’s problems and teaching you what you needed to learn to solve tomorrow’s.

Quote of the Day:

“Loss is nothing else but change, and change is nothing else but Nature’s delight.” - 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