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

You’re in a meeting. Three different approaches to solve the same problem are on the table. The junior dev is pushing for the shiny new framework they just learned. Your tech lead wants to refactor the entire module first. The product manager is tapping their fingers because the deadline was yesterday.

Everyone’s looking at you.

You’re supposed to be the senior developer here. The one with the answers. But you’re sitting there thinking, “I have no clue which option is right.” Analysis paralysis sets in. You’re afraid of picking wrong and looking incompetent. You’re exhausted from always having to make these calls. And somewhere in the back of your mind, that imposter syndrome voice is asking, “Who do you think you are to be making this decision?”

Share

The Sage: A Thought Experiment That Actually Helps

Here’s where ancient philosophy gets surprisingly practical. The Stoics had this thought experiment called the sage: a hypothetical person of perfect wisdom, courage, justice, and self-discipline. They knew damn well no one would ever achieve it. That wasn’t the point.

The sage exists as a north star. A reference point to orient yourself when you’re lost in the weeds of technical decisions, team dynamics, and the daily chaos of software development.

So instead of freezing up in that meeting, you ask yourself: What would a perfectly virtuous developer do with this codebase? How would they handle this toxic team dynamic? What choice would they make about this technical debt?

The sage isn’t about judging yourself for falling short. It’s a decision-making tool. When you’re stuck between options and your brain is screaming at you, the sage cuts through the noise. The question isn’t “Can I be perfect?” It’s “Am I moving in the right direction?”

You’ll never become the sage developer. But every decision that moves you closer to that ideal makes you better. Let’s break down what that actually looks like.

Leave a comment

Perfect Wisdom: Long-Term Over Short-Term (Even When It Hurts)

Perfect wisdom means making technical choices based on long-term sustainability, not short-term convenience or padding your resume with buzzwords.

We all know we should think about projects from a value perspective. What’s the thing we can do to make this better? Not just slapping on a Band-Aid, but considering the actual solution. But when you’re under deadline pressure and your manager is breathing down your neck, the Band-Aid is so damn tempting.

I dealt with this recently trying to handle atomic operations in a codebase that had database calls scattered everywhere like confetti. My first instinct was to reach for something complex—maybe a saga-like pattern or custom rollback logic. It felt clever. It felt like what a “real” engineer would do.

But after spending more time actually looking at what was there and simplifying instead of adding, it became clear we could consolidate these calls and do a minimal refactor to support a proper transactional approach. Less code. Less complexity. Better solution.

The sage developer would have seen that immediately. I took the scenic route through my own ego first.

Here’s the thing: sometimes wisdom looks boring. It’s choosing the unsexy solution that works over the impressive one that might. It’s writing documentation instead of moving to the next feature. It’s admitting “I don’t know” instead of bullshitting your way through a design review.

What would the sage do? Probably the thing you know you should do but don’t want to because it’s harder right now.

Share The Stoic Coder

Perfect Courage: Saying the Hard Thing Out Loud

Courage in development isn’t about heroic all-nighters or single-handedly saving production. That’s actually often ego disguised as dedication.

Real courage is pushing back on unrealistic deadlines. It’s admitting in standup that you messed up and introduced that bug. It’s asking the “dumb” question in the architecture meeting because you genuinely don’t understand why we’re going down this path. It’s calling out a senior dev’s bad decision when everyone else is nodding along.

You know that moment when you’re in code review and you see a glaring issue, but it’s from someone more senior than you? Your cursor hovers over the comment box. Your heart rate picks up. You think about just approving it. Not your problem, right?

The sage developer leaves the comment. They do it respectfully, but they do it.

Or when management asks for an estimate and you know the real answer will piss them off. You can give them what they want to hear, or you can give them the truth. The sage tells the truth, even when it’s uncomfortable.

This is where courage and wisdom intersect. The wise choice requires the courage to actually make it, especially when it’s going to make you unpopular.

Perfect Justice: Fairness When No One’s Watching

Justice is about how you treat other developers, especially when there’s no external benefit to you.

It’s conducting fair code reviews regardless of seniority. That junior dev’s code gets the same thoughtful feedback as the principal engineer’s. No rubber-stamping because someone has “senior” in their title. No nitpicking because someone’s new.

It’s mentoring generously. Not just when your manager is watching or when it helps your promotion packet. When that confused developer asks you a question at 4:45 PM on Friday and you actually want to leave, you still take the time to help.

It’s giving credit where it’s due. When your junior teammate found the solution to that gnarly bug, you don’t present it as “we figured it out.” You say their name. In the email to stakeholders. In the retrospective. You make sure everyone knows.

Justice is also about not throwing people under the bus. When production breaks, there’s always pressure to find the guilty party. The sage developer focuses on fixing the system that allowed the mistake, not punishing the person who made it.

This one’s hard because it often costs you something. Your time. Your credit. Your chance to look good by making someone else look bad.

The sage pays that cost anyway.

Perfect Temperance: Knowing When Enough Is Enough

Temperance is about maintaining a sustainable pace over hero sprints. It’s choosing appropriate complexity over over-engineering. It’s knowing when to stop optimizing.

You know that project where you spent two weeks building an incredibly flexible, abstracted solution for a problem that had one use case? Yeah. The sage wouldn’t have done that.

There’s this trap we fall into where we build for imaginary future requirements. “Well, what if someday we need to support seventeen different authentication providers?” What if you just solve the actual problem in front of you first?

Temperance means recognizing that simplicity beats cleverness. Sometimes you need to carefully consider edge cases. Sometimes you can’t predict an edge case until it happens. You build for what you know it needs to do right now, rely on best practices, and deliver the best you can.

It also means knowing when you’re done. When the code works, the tests pass, and it’s readable—stop. That refactor you’re thinking about can wait. That micro-optimization that might save 2ms? Probably not worth it. Ship it and move on.

The sage developer doesn’t confuse perfectionism with quality. They know the difference between good enough and gold-plating.

The Gap Is the Point

Here’s what makes the sage useful: you’ll never close the gap. You’ll never be perfectly wise, courageous, just, and temperate. There will always be times when you take the easy path, keep your mouth shut when you should speak up, take credit you shouldn’t, or over-engineer because it’s fun.

And that’s fine. That’s actually the whole point.

The gap between you and the ideal isn’t cause for shame. It’s a measurement tool showing where growth is needed. When you catch yourself about to make a decision based on ego instead of value, and you course-correct, that’s growth. Small movements toward the ideal compound over time.

I still choose convenience over sustainability sometimes. I still chicken out of hard conversations. I still optimize things that don’t need optimizing because I’m avoiding the actual hard problem. But I catch myself doing it more often now. The sage is that voice asking, “Is this really what you want to do here?”

The Reality Check

Look, we operate in the real world. There are trade-offs. We deal with deadlines and pressure from management. We work with teammates who have different priorities. We’re trying to find the simplest path from point A to point B while also not building garbage.

Sometimes we get caught up in overdoing things or using patterns just for the sake of using them. Sometimes we cut corners we shouldn’t cut. Sometimes the “right” answer isn’t clear, and any choice is going to have downsides.

The sage developer framework doesn’t make these tensions disappear. It gives you a lens to evaluate them. When you’re stuck between equally shitty options, asking “What would the sage do?” often clarifies which option is less shitty and why.

It won’t always give you the answer. But it’ll usually get you unstuck.

The next time you’re facing a technical decision and you feel that familiar paralysis creeping in, try asking: What would the sage developer do?

Not to beat yourself up for falling short. To clarify the right direction.

The gap between you and the ideal isn’t a judgment. It’s a compass. Use it.

Quote of the Day:

“It is not because things are difficult that we do not dare; it is because we do not dare that they 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 8 PM on a Friday. Everyone else logged off hours ago. You’re staring at a payment processing module that works fine, no bugs, no complaints, no tickets. You could close the laptop right now and start your weekend.

But you don’t.

Instead, you’re refactoring error handling that’s been bugging you all week. You’re cleaning up variable names. You’re adding defensive checks for edge cases that’ll probably never happen. And here’s the kicker: there’s a pretty good chance no one will ever notice this work. Not your manager. Not your teammates. Hell, this entire module might get replaced in the next architectural pivot.

So why do we do this to ourselves?

Share

The Recognition That Never Comes

Let’s be real about how this usually plays out. You spend three days building a comprehensive logging system for transaction reconciliation. You document every edge case. You make the error messages actually helpful for whoever gets paged at 2 AM. You write it like someone’s going to read it, because someone will, eventually.

Three months later, that logging catches a payment mismatch that would’ve taken weeks to track down manually. Your manager mentions it in passing: “Good job finding that bug quickly.” Nobody asks how you found it so fast. Nobody notices the logging infrastructure that made it possible. They just see that you solved a problem.

Meanwhile, the developer who ships fast and messy just got promoted. Their code breaks constantly, but they’re “high velocity.” They’re “getting shit done.” And you’re sitting there wondering if you’re the only one who actually gives a damn about code quality.

This is where most of us hit that wall. That moment where we think, “Why am I even trying?”

The Trap of External Validation

Here’s the thing that took me way too long to figure out: if you’re writing good code for recognition, you’re playing a game you can’t win.

External validation—promotions, praise, those little dopamine hits from code review approvals—they’re all outside your control. You can write the most elegant solution possible and still get passed over for a promotion. You can refactor a critical system and have it go completely unnoticed. You can do everything right and still have clients be unhappy, projects go over budget, or your carefully crafted code get deleted in the next rewrite.

The Stoics figured this shit out two thousand years ago. They called it the dichotomy of control: you don’t control outcomes, you only control your effort and approach. Marcus Aurelius was literally running the Roman Empire, dealing with wars, plagues, and political backstabbing. If anyone had reasons to expect external validation for good work, it was him. But he kept coming back to this same idea: the value is in doing the work with integrity, not in who notices.

And I’m not telling you this as some philosophical thought experiment. I’m telling you this because it’s the only thing that’s kept me from burning out over 25 years in this industry.

Leave a comment

What You’re Actually Building

When you write clean code that no one’s watching, when you add those defensive checks, when you document the “why” and not just the “what”, you’re not building a feature. You’re building yourself.

Every shortcut you take, every “I’ll fix it later” that you don’t fix, every time you ship code you know is questionable, that’s not just technical debt. That’s erosion of your own standards. You’re training yourself to accept mediocrity. You’re teaching your brain that quality is optional, that it only matters when someone’s looking.

And here’s what that leads to: developers who can’t tell the difference anymore. Who genuinely don’t see the problem with nested try-catches seven levels deep. Who think “it works” is the same as “it’s done right.” Not because they’re bad developers, but because they’ve spent years optimizing for speed over quality, and their internal compass is screwed up.

The opposite is also true. Every time you do the work right, especially when no one’s watching, you’re strengthening that internal standard. You’re building the kind of developer who can look at code and just know it’s wrong, even if it passes all the tests. You’re developing instincts that become your competitive advantage.

The Work That No One Sees

Some of my best work has been completely invisible. I once rebuilt the error handling in a legacy .NET payment system that had been held together with duct tape and prayers for years. Spent two weeks on it. Made sure every exception was caught at the right level, every error message actually helped diagnose the problem, every failure mode was logged with enough context to figure out what went wrong.

You know how many times that error handling prevented catastrophic failures? I have no frickin idea. That’s the point. Good defensive code prevents problems that never happen. No one writes you a thank-you email for the database deadlock that didn’t occur because you properly implemented transaction isolation. There’s no Slack message celebrating the race condition that never materialized because you understood thread safety.

But I sleep better knowing that code is out there. And when shit does hit the fan, because it always does eventually, I know I’ve given whoever has to debug it the best chance of actually understanding what went wrong.

Building Intrinsic Motivation

How do you maintain standards in an environment that often doesn’t reward them?

You have to find satisfaction in the craft itself. Not in some precious, artisanal bullshit way, but in the basic human satisfaction of doing something well. The same satisfaction you’d get from cooking a good meal even if you’re eating alone, or fixing something around the house that no one else will notice.

Here’s how I think about it: Every line of code I write is a choice about what kind of developer I want to be. Not what kind of developer I want others to think I am, what I actually want to be when no one’s looking.

When I’m tempted to ship something I know is questionable, I ask myself: Is this the standard I want to live with? Not “will anyone notice?” Not “will this come back to bite me?” Just: Is this acceptable to me?

Most of the time, that’s enough. Not always—sometimes the deadline is real and the tradeoff is necessary. But even then, I’m making a conscious choice, not taking a shortcut out of laziness or because I think quality doesn’t matter.

This is what the Stoics meant by virtue ethics. Virtue wasn’t about being a good person so others would praise you. It was about having internal standards that didn’t depend on external validation. It was about being able to look yourself in the mirror and know you’re living according to your own principles.

Share The Stoic Coder

The Long Game

The beautiful thing about intrinsic motivation is that it makes you sustainable. You can’t burn out from lack of recognition when recognition was never the point. You can’t be demoralized by office politics when you’re not playing the political game. You can’t have your motivation destroyed by a bad manager when your motivation doesn’t depend on their approval.

This doesn’t mean you become some zen master who doesn’t care about anything. You still get frustrated. You still wish people noticed your good work. You still want the promotion and the raise. But those things become bonuses, not the foundation of your motivation.

And here’s the thing nobody tells you: over the long term, this approach actually tends to work out better career-wise too. Because the developers who consistently do good work, who have strong internal standards, who can be trusted to do the right thing even when no one’s watching—those developers become valuable. Maybe not immediately, maybe not as flashy as the person who ships fast and breaks things, but over years? That reputation matters.

But even if it doesn’t work out that way, even if you end up at a company that truly doesn’t value quality, you’ve still built something they can’t take away from you. You’ve built your own skills, your own standards, your own sense of what good work looks like. That’s portable. That stays with you.

Conclusion

This is hard. It’s hard to care about code quality when you’re the only one who seems to give a shit. It’s hard to maintain standards when the team is cutting corners and shipping faster. It’s hard to write good code when the entire codebase is a dumpster fire and your contribution feels like pissing on a forest fire.

The code you write shapes who you become as a developer. Every decision, every shortcut, every moment of “good enough”, it all adds up. You’re either building the kind of developer who can take pride in their work, or you’re building the kind who’s just collecting paychecks until retirement.

Your internal standards are the one thing in this entire industry that you actually control. The recognition, the promotions, the perfect codebase, the appreciative users, it’s all outside your control. But how you approach the work? That’s yours.

Quote of the Day:

“Make the best use of what is in your power, and take the rest as it happens.” - 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 just spent three weeks building the perfect abstraction. Clean interfaces, thoughtful error handling, documentation that doesn’t suck. You’re proud of this one. Your tech lead reads it for thirty seconds and says, “Let’s just add another if statement to the existing function.”

Or maybe it’s the junior developer you spent six months mentoring, the one you stayed late helping debug their first production issue, the one you vouched for in their performance review. They just accepted an offer at another company.

Or it’s Friday afternoon, and leadership just killed the project you’ve been pouring your soul into for the past year. “Shifting priorities,” they say. Your code will never see production.

This hurts.

Share

The Problem with Caring

Here’s the thing about being good at what you do: you care. You care about writing clean code. You care about doing things right. You care about the craft.

And that caring makes you vulnerable.

Because in software development, effort and outcome have this frustrating habit of not lining up. You can write brilliant code that gets rejected. You can build something beautiful that gets shut down for business reasons. You can invest in people who leave. You can do everything right and still watch it all fall apart.

So what do you do?

The obvious answer is to protect yourself. Stop caring so much. Phone it in. Write the shitty code they’re asking for and collect your paycheck. Become the cynical developer who responds to every suggestion with “whatever, it’s all getting rewritten anyway.”

And you know what? I get it. I’ve been there. There are days when cynicism feels like the only rational response to the chaos.

Why Cynicism Doesn’t Actually Work

But here’s what happens when you go down that road: you lose the thing that made you good in the first place.

The cynical developer stops learning because “what’s the point?” They stop mentoring because “people just leave anyway.” They stop suggesting improvements because “no one listens.” They write code that works today and becomes tomorrow’s technical debt.

And worst of all? They’re miserable. Because humans aren’t wired to spend forty-plus hours a week doing something they don’t give a shit about. The armor you built to protect yourself becomes a prison.

The Stoics saw a different way through this. And it’s not about caring less, it’s about caring differently.

Leave a comment

The Dichotomy of Control (or: Stop Fighting Battles You Can’t Win)

Marcus Aurelius spent a lot of time thinking about what was in his control versus what wasn’t. As emperor of Rome, you’d think everything would be under his control, right? But even emperors can’t control whether their policies succeed, whether their generals stay loyal, or whether the barbarians decide to invade.

What he could control was his own thoughts, actions, and effort.

Same deal in software development.

You control:

• The quality of code you write

• The thoroughness of your reviews

• The clarity of your documentation

• The patience you show when mentoring

• The integrity you bring to technical decisions

• Whether you refactor that mess or add to it

You don’t control:

• Whether your PR gets approved

• Whether your project gets greenlit

• Whether your carefully considered architecture gets adopted

• Whether the people you mentor stick around

• Whether your code survives the next reorg

• Whether anyone appreciates the extra effort you put in

Your sphere of control ends at the PR button. After you hit submit, you’ve done your part. Everything after that? Not yours.

What the Reserve Clause Actually Means

The Stoics had this concept called the “reserve clause”, basically adding “fate permitting” to your intentions. Not as a cop-out, but as a mental tool.

So instead of “I’m going to get this architecture approved,” you think “I’ll propose this architecture, fate permitting it gets adopted.”

This isn’t lowering your standards or half-assing your proposal. You still do the research, write the compelling RFC, make the case. You give it your best shot. But you’ve mentally prepared yourself for any outcome.

Here’s what this looks like in practice:

Without the reserve clause: You spend a week on an RFC for microservices migration. You’re convinced it’s the right move. The architecture review meeting rolls around. They reject it. You’re furious. You take it personally. You spend the next month bitter and checked out.

With the reserve clause: Same RFC, same effort, same conviction. But you go in thinking “I’ll make the best case I can, and whatever happens happens.” They reject it. You’re disappointed, sure. But you move on. Because you did your part. The decision is out of your hands.

The difference isn’t in the outcome, it’s in how much of your peace of mind you’ve tied to things you can’t control.

Share The Stoic Coder

Impermanence as Freedom

Everything we build in tech is temporary. That codebase you’re maintaining? It’ll be replaced or rewritten. The framework you just learned? It’ll be legacy in five years. The project you’re grinding on? Might get cancelled next quarter.

This used to depress the hell out of me. Why bust my ass if it’s all going to be thrown away?

But here’s the reframe: impermanence is freedom.

When you know your code is temporary, you can stop clinging to it desperately. You can stop getting defensive in code reviews because someone dared criticize your precious abstraction. You can actually listen to feedback because your identity isn’t wrapped up in whether this specific implementation survives.

You’re a steward, not an owner. The company can cancel your project like the library can recall a book. That’s not a tragedy, that’s just how it works.

What matters is that you do your best work right now, with what you know right now, for the situation you’re in right now. Not because it’s going to last forever, but because that’s what being good at your craft means.

Measuring Yourself by Internal Standards

When you tie your self-worth to external outcomes, you’re fucked. Because outcomes in software development are chaotic. Market conditions change. Leadership changes. Priorities change. Budgets change.

But you can always measure yourself by internal standards:

Did I think clearly about this problem? Did I act with integrity in that meeting? Did I give honest feedback in the code review? Did I help that struggling teammate instead of just being annoyed? Did I do my best with what I knew at the time?

These things are always in your control. And they’re what actually matter.

I’ve written code that got deleted six months later, and I’m still proud of it because I know it was good work. I’ve mentored people who left, and I don’t regret a minute of it because I know I showed up for them. I’ve had projects cancelled, and I can still look back at the craftsmanship I brought.

The work has value independent of the outcome. The virtue is its own reward.

What This Actually Looks Like

The rejected PR: You spent hours refactoring that god-awful service. Made it testable, removed the global state, cleaned up the error handling. Senior dev rejects it: “Too risky right now, let’s just fix the bug.”

Old you: Seethes with resentment. Stops suggesting improvements. Becomes the “I told you so” person when technical debt inevitably bites the team.

Stoic you: Disappointed, but you know you did good work. You learned from the refactoring. Maybe you salvage parts of it for future PRs. You continue caring about code quality because that’s who you are, not because you need approval.

The cancelled project: Six months of work. Dead. Leadership pivot.

Old you: Bitter spiral. “They never finish anything around here.” Updates resume, checks out mentally.

Stoic you: Process the disappointment, then ask: “What did I learn? How did I grow? Was I a good teammate?” The skills you built aren’t wasted. The relationships you strengthened remain. The work had value while you were doing it.

The junior who leaves: You invested time, energy, patience. They got better. Now they’re gone.

Old you: “Never again. Not worth it.”

Stoic you: You helped someone grow. That’s good in itself. The fact that they left doesn’t negate the value of the mentorship. Maybe you stay in touch. Maybe they come back someday. Maybe you never hear from them again. You still did the right thing.

The Long Game

Software development isn’t about necessarily completing projects. It’s about doing your best with what you have at the time. Understanding that what you’re building today will probably be replaced in five years. Hell, maybe next year.

But at this moment, at this time, you make it as good as you can make it.

Not because you’re guaranteed a return on that investment. Not because management will definitely appreciate it. Not because it’s going to last forever.

Because excellence in your craft is how you show up in the world. Because integrity matters more than outcomes. Because you can’t control what happens to your work, but you can control the work itself.

Love the work, not the outcome. When your identity is in the craftsmanship rather than the results, you become resilient to the inevitable disappointments of software development.

You’ll still care deeply. You’ll still fight for what you believe is right. You’ll still feel disappointed when things don’t work out.

But you won’t be destroyed by it.

Because you’ve learned to put your effort and excellence into the things you control, and hold everything else with an open hand.

That’s not resignation. That’s freedom.

Your Turn

I’m curious about your experience with this:

What’s a time you did great work that didn’t get the outcome you hoped for? How did you handle it?

Do you struggle more with caring too much or protecting yourself by caring too little?

What helps you stay committed to quality when the external rewards aren’t there?

Drop your thoughts in the comments. Because chances are, your experience is exactly what someone else needs to hear right now.

Quote of the Day:

“Make the best use of what is in your power, and take the rest as it happens.” - 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 just got feedback on a PR and your chest tightens. Your heart rate kicks up a notch. The reviewer’s tone feels harsh, their suggestions seem to completely miss the point of what you were trying to accomplish, and there’s this part of you (maybe a big part) that wants to defend every single line you wrote. You want to type out a paragraph-long comment explaining why they’re wrong, why your approach is actually brilliant, and why they clearly don’t understand the problem you were solving.

Been there? Yeah, me too. More times than I’d like to admit.

Share

The Real Source of the Pain

Here’s the thing the Stoics figured out a couple thousand years ago, and it still holds true when some senior dev is tearing apart your pull request: that discomfort you’re feeling right now? It’s not actually coming from the criticism itself. It’s coming from your judgment that you’ve been wronged. That your competence is being questioned. That this must mean something about your worth as a developer.

And that’s where we screw ourselves over.

Because the truth is, most code review feedback, even the harshly delivered stuff, contains something useful. But we can’t see it because we’re too busy nursing our wounded pride and mentally drafting our defensive response.

Mining for Gold in a Pile of Shit

What if you could extract every ounce of value from harsh feedback while discarding the emotional poison that comes with it? That’s the skill we need to develop.

First thing: you have to learn to separate the messenger from the message. A rude delivery, or even what you perceive as rude delivery, doesn’t automatically invalidate true insights. I’ve gotten feedback from people who had the communication skills of a brick, but their technical points were solid. Your job is mining for gold, not judging the miner’s manners.

Ask yourself this: is any part of this criticism true? Even 10% true? Because here’s the thing, even 10% accuracy in criticism is a gift. It’s information you didn’t have before. It’s a chance to improve your code before it hits production. Dismiss nothing until you’ve honestly examined it against reality.

I know how easy it is to get caught up in the emotions. To feel like your code’s being attacked. Like your self-worth is being questioned. I’ve been there, sitting at my desk, feeling that heat rise in my face, already mentally preparing my rebuttal. But that’s when you need to pause and ask: is there something here I can actually learn from? Is there a point buried in this feedback that, if I’m being honest with myself, is actually valid?

Maybe this person has a point. Maybe there is a better way to structure this. Maybe my first instinct wasn’t actually the best approach.

Leave a comment

Your Critics Are Your Trainers

Here’s a reframe that’s helped me: view your critics as personal trainers for your code. They’re adding resistance that makes you stronger, even when it’s uncomfortable as hell. You don’t go to the gym expecting the trainer to tell you you’re perfect, you go expecting them to push you harder than you’d push yourself.

Same thing with code reviews.

I’ve learned to practice what I call “the grateful opposite.” Instead of getting defensive, I try to thank people for catching bugs, architectural flaws, or blind spots before they become production problems. Because at the end of the day, that’s what matters, producing the best quality code possible. It’s not about satisfying our own egos or proving we’re the smartest person in the room.

It’s very easy to get caught up in that. Trust me, I’ve dealt with ego battles over a long career. But over time you start to understand: I’m here to do a job. I’m here to do it well. My job is to produce the best quality product I can deliver, and if anyone can help me do that, even if they’re kind of an asshole about it, I’m going to take full advantage of that opportunity.

Not All Feedback Is Created Equal

Now, let’s be real for a second. You do need to distinguish between preference and principle. Some feedback is subjective style preferences; tabs versus spaces, this naming convention versus that one. And some reveals actual defects in your reasoning or approach.

I’ve had plenty of situations where feedback was just nitpicky bullshit. Someone commenting on variable naming when the real issue is whether the algorithm is efficient. In those cases, I don’t focus on it too much. But even in those nitpicky comments, I look for whether there’s something being pointed out that I could do a little better. Is there a better way to execute this, even if the specific suggestion isn’t quite right?

Epictetus said it best: if someone criticizes you unjustly, that’s their problem. But if it’s justified, thank them for the free education.

Share The Stoic Coder

When We Get Too Close to Our Code

Here’s what happens to me all the damn time: I get blinded by my own work. You get into that tunnel vision of coding where you’re locked in, cranking out line after line, building this thing in your head. And then somebody comes along and points out that maybe you’re overthinking it. Maybe you’re writing too much code. Maybe there are things you could better reuse or ways to eliminate code versus actually creating more of it.

And they’re right. But it stings because you were so deep in your own solution that you couldn’t see the simpler path.

Use criticism as a mirror. When you have a defensive reaction, that reaction reveals where your ego is attached. That’s big data about yourself that’s worth examining. Anytime something triggers you, and I mean really triggers you, makes you want to write that defensive comment, you should evaluate why.

Is it really because this person has it out for you? Or is it because you’re too emotionally attached to the code you wrote?

Nine times out of ten, it’s the latter.

The “Try It First” Approach

Here’s something I’ve started doing that’s been genuinely helpful: implement the suggested approach first, even if you disagree with it. Just try it. Because sometimes your resistance isn’t actually technical judgment, it’s pride masquerading as technical judgment.

I’ve had situations recently where I look at a suggestion and think, “I don’t necessarily 100% agree with this approach.” But at the same time, it’s not really worth fighting over either. It’s very easy to get caught up in this subjective battle, this ego-driven mindset of “my way is the best way and this person doesn’t know anything because I’ve been doing this for 15 years and they’ve only been doing this for 3 years.”

Who the hell cares?

If their approach makes sense when you really think about it, when you set your ego aside and evaluate it objectively, just make the change. There’s no sense fighting that battle. There are so many things we should be focused on trying to be better at. There are some things you just need to learn to let go of.

The Culture That Feeds Our Defensiveness

Let’s zoom out for a second and talk about why this is so hard for us as developers. We’re operating in a culture that constantly reinforces ego-driven behavior.

Tech Twitter is full of hot takes about the “right” way to do things. There’s this mythology around “10x developers” who supposedly produce perfect code and never need feedback. We see conference talks from people making everything look effortless. GitHub stars and follower counts become weird proxies for technical competence.

All of this feeds into an environment where admitting you might be wrong, where accepting that your first approach wasn’t perfect, feels like weakness. Like you’re not one of the smart ones.

But that’s BS. The smartest developers I know are the ones who actively seek out criticism. Who treat every code review like an opportunity to level up. Who check their ego at the door because they understand that the goal is shipping great software, not proving they’re right.

What This Actually Looks Like in Practice

So what does this look like day-to-day? For me, it’s a constant practice. I still have that initial defensive reaction, I don’t think that ever fully goes away. But I’ve learned to recognize it and pause.

When I get feedback that makes my stomach clench, I take a breath. I read it again, this time looking specifically for what might be valid. I ask myself: “If my best friend gave me this exact same feedback over coffee, how would I receive it differently?”

Sometimes I’ll even sleep on it. Let the emotional reaction fade a bit before I respond. Because responding while you’re still in that defensive headspace? That’s how you write comments you’ll regret, or dig in on positions that aren’t actually defensible.

And when I do find myself getting into a back-and-forth debate in PR comments, I try to remember: this isn’t a courtroom. Nobody’s keeping score. The goal isn’t to win the argument; it’s to end up with better code than what I started with.

The Payoff

The more you practice receiving feedback without ego, the better feedback you get. People are more willing to give you honest, detailed reviews when they know you won’t get defensive. They’ll point out subtle issues they might have otherwise let slide because they didn’t want to deal with pushback.

And that makes you better. Faster. Your code improves more quickly because you’re not wasting energy on defending your choices. You’re using that energy to actually evaluate and implement better approaches.

Plus, and this is huge: it makes code review way less stressful. When you’re not treating every piece of feedback as an attack on your competence, when you’re genuinely curious about what you might learn, the whole process becomes less painful. Sometimes even enjoyable.

Your Turn

I want to hear from you because I know I’m not alone in struggling with this:

What’s your biggest challenge when receiving code review feedback? Is it certain types of criticism, or feedback from specific people, or just the general feeling of being judged?

Have you ever had feedback that initially pissed you off but later realized was actually spot-on? What made you come around?

What strategies have helped you separate your ego from your code? Any mental tricks or reframes that work for you?

Share your thoughts in the comments. Because honestly, we all need to get better at this. The developer who can receive feedback without getting defensive is going to grow faster, ship better code, and probably enjoy their job a hell of a lot more than the one constantly defending their territory.

At the end of the day, the person most likely to hold you back isn’t your code reviewer—it’s you.

Quote of the Day:

“If anyone can refute me—show me I’m making a mistake or looking at things from the wrong perspective—I’ll gladly change. It’s the truth I’m after, and the truth never harmed anyone.” - 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

Remember that time you convinced yourself the new JavaScript framework was the right choice? You wrote up the whole technical justification. You presented it to the team. You spent two weeks setting it up. And then, about three months in, you’re staring at the documentation at 2 AM, debugging some weird edge case, and you realize the truth: you picked this thing because it looked good on your resume, not because it was right for the project.

Yeah. We’ve all been there.

Here’s the thing though: deep down, you probably knew it was the wrong choice from the beginning. But you talked yourself into it anyway. You rationalized it. You built a case for it. You convinced yourself and everyone else that this was the smart technical decision.

But it wasn’t. It was the decision you wanted to make, dressed up in logic.

Share

The Problem With Making Decisions in Our Heads

As developers, we make decisions all day long. Which library to use. How to structure this module. Whether to refactor now or ship first. When to push back on a deadline. Whether to take that new job offer. Some of these decisions take five seconds. Others keep us up at night.

Most of them happen entirely in our heads, influenced by whatever we read on Reddit last night, that one bad experience we had three years ago, or just the general anxiety of “what if I’m wrong about this?”

The problem is that our brains are really good at lying to us. They’re excellent at taking what we want to do and reverse-engineering logic that makes it seem like the right thing to do. We’re basically running compiler optimizations on our decision-making process, and sometimes those optimizations introduce bugs.

You know what I’m talking about. You’ve felt it. That moment where you’re justifying something to yourself and there’s this little voice in the back of your head going, “Really? Really? Is that why you’re doing this?” And you just... ignore it. You rationalize a little harder. You find one more reason. You keep moving forward.

And then months later, you’re dealing with the consequences of a decision you knew was questionable from the start.

Leave a comment

What Marcus Aurelius Knew That We Keep Forgetting

Marcus Aurelius was arguably the most powerful person on Earth. Emperor of Rome. Controlled the biggest military force in the known world. And every night, he sat down and wrote to himself.

Not proclamations. Not decrees. Not things that would be read by historians. Just... thoughts. Questions. Reflections on his day, his decisions, his fears, his motivations.

Why would someone with that much power spend time writing in a journal that nobody else would read?

Because thinking on paper made him wiser.

That’s it. That’s the whole secret. When you write down your thinking, you can actually see it. You can examine it. Test it. Question it. You can’t do that when it’s just rattling around in your head, mixing with anxiety and ego and whatever you ate for lunch.

Writing is like running your thoughts through a debugger. It makes them visible. And once they’re visible, you can spot the bugs.

Share The Stoic Coder

How to Actually Do This (Without It Feeling Like Therapy Homework)

Look, I get it. “Philosophical journaling” sounds like something a life coach would try to sell you in a webinar. It sounds touchy-feely and vaguely pointless.

But here’s what it actually is: it’s debugging your decision-making process before you commit the code.

When you’ve got a decision to make, especially a big one, here’s what you do:

Write down your gut reaction first. Before you start rationalizing, before you start researching, just capture that initial instinct. Often your gut knows something your conscious mind hasn’t articulated yet. I can’t tell you how many times I’ve written down that first thought, spent a week talking myself into the opposite, and then ended up right back where I started. Save yourself the detour.

List what’s actually in your control versus what isn’t. This is straight from the Stoics, and it’s stupidly powerful. You’re agonizing over whether the tech lead will approve your approach? That’s not in your control. What is in your control is how well you document your reasoning and present the alternatives. Focus on the actions you can actually take. Everything else is just mental masturbation.

Examine your real motivations. This is the uncomfortable part. Are you choosing that new framework because it’s genuinely the best fit? Or because you’re bored with the current stack? Or because you want to pad your resume? Or because you read a blog post that made you feel like you’re falling behind?

There’s no judgment here. I’ve picked technologies for all of those reasons. But you need to be honest with yourself about why you’re leaning a certain direction, because that changes everything about how you should evaluate the decision.

Play devil’s advocate against yourself. Force yourself to write the strongest possible case for the opposite choice. Not the strawman version. The actual best argument. This is where you catch your blind spots. This is where you realize, “Oh shit, I’m ignoring this pretty significant downside because I don’t want to deal with it.”

Set a review date. For big decisions, write down when you’re going to revisit this and see if your reasoning held up. “I’ll check this in three months and see if I still think this was the right call.” This creates accountability to your past self. It’s like leaving comments in your code, except for your life choices.

What You’ll Actually Discover

Here’s what happens when you start doing this regularly: you begin to see your patterns.

You’ll notice you’re consistently over-optimistic in your time estimates. Or that you avoid having difficult conversations until they become crises. Or that you have a serious case of technology FOMO that makes you want to rewrite everything every six months.

These patterns are always there. But when they’re just in your head, they’re invisible. When you write them down over and over, they become undeniable.

I started noticing that every time I was excited about a new tool or framework, I had this whole internal narrative about “learning opportunities” and “staying current” and “becoming a better developer.” And you know what? Sometimes that was true. But a lot of times, I just wanted the dopamine hit of something new. I was bored. I wanted to feel smart again.

Once I saw that pattern written out in black and white, I couldn’t unsee it. And now when I feel that pull toward the shiny new thing, I know to ask myself, “Is this actually the right choice, or am I just bored?”

That’s the power of making your thinking visible.

The Journal Becomes Your Personal Database

After a few months of this, something cool happens: you’ve got a record of your decision-making process. You can look back and see what you were thinking when you made similar choices in the past.

Deciding whether to take a new job? Go read what you wrote the last time you switched roles. What were you hoping for? Did you get it? What did you undervalue? What surprised you?

Choosing between technical approaches? Look at what happened the last three times you made similar calls. What did you miss? What held up? What would you do differently?

You’re building a personal decision-making database. And unlike Stack Overflow, it’s specifically tailored to your biases, your context, your career.

We spend so much time trying to learn from other people’s experiences. Blog posts. Conference talks. Twitter threads. And that’s valuable. But your own experiences? Your own patterns? That’s data you can actually trust, because you know all the context that’s missing from the polished retrospective.

A Few Prompts to Get You Unstuck

Sometimes you sit down to write and you just... don’t know what to say. Your brain goes blank. Here are some prompts that help me get moving:

• What am I actually afraid will happen?

• What would I tell a friend to do in this situation?

• What would this look like if it were easy?

• What am I pretending not to know?

• If I had to decide right now, what would I choose? (Then ask: why?)

That last one is particularly brutal. Because usually, you do know what you want to do. You’re just scared of committing to it. Or you’re hoping someone else will make the decision for you. Or you’re avoiding the hard conversation that comes after.

Writing it down makes that avoidance visible.

Share

The Part Where I Sound Like a Self-Help Book (But Bear With Me)

Look, I know this whole thing sounds kind of... earnest. Like something you’d find in the “personal development” section at Barnes & Noble. And I get the resistance to that.

But here’s the reality: we’re making decisions all the time that affect our careers, our sanity, our lives. And most of us are doing it with about as much rigor as we’d give to choosing what to have for lunch.

We’ll spend three hours researching which laptop to buy, but we’ll take a new job based on a gut feeling and a good interview. We’ll meticulously review pull requests, but we won’t examine our own thinking when making decisions that will impact the next six months of our lives.

That’s backwards.

Marcus Aurelius knew this. He was making life-and-death decisions for an empire, and he still took the time to think on paper because he understood something fundamental: your decision-making process is your most important tool. If it’s buggy, everything else suffers.

You don’t have to call it “philosophical journaling” if that makes you uncomfortable. Call it debugging your brain. Call it decision docs. Call it whatever you want.

Just write down your thinking before you commit to the choice. Make it visible. Question it. Test it.

Your future self will thank you for it.

Because here’s what I’ve learned: the decisions I regret aren’t usually the ones where I made the wrong choice. They’re the ones where I made a choice I knew was wrong, but I talked myself into it anyway.

And the only way to stop doing that is to catch yourself in the act of the rationalization. To see it happening in real-time. To call bullshit on your own internal narrative before it becomes your external reality.

That’s what this practice does.

It won’t make you perfect. You’ll still make mistakes. But at least they’ll be honest mistakes, based on your actual values and actual reasoning, not just whatever story you told yourself to avoid discomfort.

And that’s worth thirty minutes with a journal.

Quote of the Day:

“Everything we hear is an opinion, not a fact. Everything we see is a perspective, not the truth.” — 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

You estimated two days for that feature. Your team lead approved it. You felt pretty good about yourself. You’ve built this kind of thing before, you know what you’re doing.

Then production explodes.

Suddenly you’re pulled into firefighting mode. Three hours of debugging turns into three days. The QA environment goes down. The designer decides – oh, by the way – the whole flow needs to change. And that “simple” API integration? Yeah, the documentation was lying. The endpoints don’t work how they say they do.

Now you’re three sprints behind on something you promised would be done by Friday. And you feel like shit about it.

Not because you didn’t try. Not because you slacked off. But because in your head, you made a commitment, and you failed. You’re a professional who can’t even estimate their own work properly. What kind of developer are you?

Share

The Weight of Broken Promises

Here’s the thing that eats at you: it wasn’t even your fault. The production incident wasn’t something you could have predicted. The designer changing requirements wasn’t in your control. The API being broken? That’s on someone else’s poor documentation.

But you still feel guilty. Because somewhere along the way, you internalized this idea that a “good developer” should be able to predict the future. That giving an estimate means you’re making an iron-clad promise. That if you can’t deliver exactly what you said, exactly when you said it, you’re somehow letting everyone down.

We put this pressure on ourselves. Management puts it on us too. There’s this whole mythology around the 10x developer who can see around corners, who never misses a deadline, who can account for every possible dependency and blocker.

It’s bullshit. And it’s making us miserable.

Share The Stoic Coder

What the Stoics Knew About Uncertainty

The ancient Stoics had a practice that would’ve saved us a lot of Sunday night anxiety. When they made any commitment, they silently added a reserve clause: “fate permitting.”

“I’ll finish this by Friday... fate permitting.” “This feature will take two days... fate permitting.” “We’ll ship this sprint’s work... fate permitting.”

This isn’t about being pessimistic or making excuses. It’s about maintaining your sanity in a job where uncertainty is the only constant.

The reserve clause is mental freedom from the guilt that comes when reality refuses to cooperate with your plans. Because here’s what every developer knows but somehow forgets when giving estimates: you’re making a prediction about a future you don’t control.

The Things You Can’t Control

Think about everything that can derail your estimate:

The production database that decides to corrupt itself at 2 AM on Thursday. The teammate who gets sick right when you need their code review. The VP who swoops in with “just one small change” that rewrites half your architecture. The vendor API that goes down. The deployment pipeline that breaks. The security vulnerability that gets discovered and suddenly becomes everyone’s top priority.

That “two day estimate” you gave? It was based on a world where none of those things happen. And that world doesn’t exist.

The Stoics, particularly Marcus Aurelius and Epictetus, were obsessed with this distinction between what you control and what you don’t.

You control your effort. You control your focus. You control how thoroughly you communicate blockers.

You don’t control dependencies failing. You don’t control requirements changing mid-sprint. You don’t control emergencies that pull you away from your work.

The reserve clause isn’t an excuse for poor planning. It’s not permission to sandbag your estimates or half-ass your work. It’s a realistic acknowledgment that between “I’ll start this task” and “I’ll finish this task” lies a vast ocean of uncertainty.

Leave a comment

How This Actually Works

Let me give you a real example. You’re planning sprint work, and someone asks how long it’ll take to build the new payment processing flow.

Without the reserve clause: “Two weeks.” (Internal pressure: “I said two weeks, so it HAS to be two weeks, no matter what happens.”)

With the reserve clause: “Two weeks, assuming nothing prevents it.” (Internal reality: “I’m committing to two weeks of focused effort, but I’m not a fortune teller.”)

See the difference? The second one doesn’t change your external commitment, you’re still saying two weeks. But internally, you’re not setting yourself up for irrational guilt when the QA environment is down for three days, or when the product manager realizes halfway through that they forgot about a critical edge case.

When those interruptions happen – and they will – the reserve clause lets you pivot without the internal narrative of “I’m a failure who can’t keep promises.” Instead, it’s just: “Well, circumstances changed. Let’s adjust.”

The Paradox of Letting Go

Here’s what’s weird: releasing that rigid attachment to guaranteed outcomes often improves your results.

When you’re not defending an estimate like it’s your personal honor at stake, you become more flexible. You communicate blockers earlier because you’re not trying to hide them. You ask for help sooner because you’re not treating the estimate as a referendum on your competence. You’re more honest with stakeholders about risks because you’re not over-promising from ego.

You stop playing this exhausting game of pretending you have more control than you actually do.

And stakeholders? They trust you more. Because instead of the developer who says “two days” and then goes radio silent when it’s taking longer, you’re the developer who says “two days, barring any surprises” and then keeps everyone updated when surprises happen.

You can commit fully to the work while releasing attachment to guaranteed results. The only thing you can actually guarantee is that you will do the work necessary to try to achieve the goal as much as possible. Everything else – the timeline, the exact outcome, the smooth sailing, that’s outside your control.

Baking in Reality

Over time, this mental habit trains you to think differently during planning. You start identifying what’s actually in your control:

Your effort. Your focus. Your communication. The quality of your code. The thoroughness of your testing.

And what’s not in your control:

Dependencies on other teams. Third-party services staying up. Requirements staying stable. Emergencies not happening. The exact amount of time something will take once you account for all the unknowns.

Does this mean you stop giving estimates? No. Does it mean you pad everything to ridiculous levels? Also no.

It means you give honest estimates based on what you know, while acknowledging, to yourself if not out loud, that there’s always some outside thing that can happen that is unforeseen. The QA environment going down. The API changing without notice. The production incident that pulls you away.

That’s not pessimism. That’s reality. And acknowledging reality is the first step to not letting it destroy your mental health.

The Only Constant

As developers, we deal with constant change. We get used to it, eventually. The framework that was hot last year is old news this year. The architecture that made sense six months ago needs refactoring. The requirements that were set in stone last sprint are somehow different now.

But we still try to plan everything like we’re building a bridge, where all the variables are known and the materials behave predictably. Software development isn’t bridge building. It’s more like trying to build a bridge while the river is flooding, people are changing the blueprint mid-construction, and someone keeps yelling about how the other bank moved.

The reserve clause – “fate permitting” – is how you stay sane in that chaos. It’s how you commit to doing great work without committing to controlling things you can’t control.

Quote of the Day:

“Do every act of your life as though it were the last act of your life.” — 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

It’s 10 AM. You’ve been “working” for two hours, but your most significant accomplishment is answering twelve Slack messages and attending a standup that could’ve been an email. The feature you were supposed to ship this week? Still zero commits.

You know you need to focus. You know context switching is killing your productivity. But there’s this nagging guilt every time you see those notification badges piling up. What if someone needs you? What if you’re being a bad team player? What if ignoring that ping makes you look like you don’t care?

That guilt is misplaced urgency, and it’s destroying your ability to do meaningful work.

Share

The Real Cost of Scattered Attention

Seneca observed that people who are everywhere are really nowhere, constantly busy at accomplishing nothing meaningful. That Slack message mid-deep work, the email that derails your debugging session, the meeting that fragments your afternoon into useless 20-minute chunks—this isn’t just productivity loss. It’s a form of self-violence, scattering your mind until you can’t recognize your own thoughts.

Each context switch costs about 15-20 minutes of recovery time. Not the seconds it takes to check Slack, but the cognitive reload required to rebuild your mental model. Think about that. Every ping, every “quick question,” every notification you respond to immediately, you’re not losing seconds, you’re hemorrhaging 15-20 minutes of focused work.

You can be busy for 40 years and accomplish less than somebody with focused months. The Stoics understood this: attention is the only currency that matters, and modern work culture has us throwing it away like it’s unlimited.

Your brain literally cannot process two complex tasks simultaneously. What we call multitasking is just rapid context switching, and you’re doing it poorly. What’s the point of starting two or three different things at the same time if you can’t finish them? Or worse, if you just do them half-assed?

Share The Stoic Coder

Why We Keep Doing This to Ourselves

The guilt is real. Someone pings you, and you feel that immediate pressure to respond. Not because it’s actually urgent, but because we’ve been trained to treat every notification like a fire alarm.

But here’s what that really is: other people’s poor planning becoming your emergency.

Those interruptions? They’re rarely as urgent as they feel. Most of the time, they can wait an hour. Or three hours. Or until tomorrow. But we’ve convinced ourselves that being responsive means being reactive, that being available means being always-on.

I remember a time before we had the internet, before cell phones, before instant notifications. You could get lost in your work, lost in whatever you were doing, and there was really no way for anybody to get a hold of you. And you know what? The world didn’t end. People figured it out. They waited.

The Stoic Solution: Own Your Time

The Stoic practice of protecting your attention starts with recognizing it’s finite and non-renewable—more precious than time itself. When it’s time to work, that’s the thing you need to focus on.

That means shutting off Slack notifications. Closing your email client. Setting your status to “Do Not Disturb” without apologizing for it.

These are things I actually do. I’ll shut off notifications, close distractions, and just focus on whatever the task is. Getting it done. If you really need me, there are ways to get a hold of me, but is it really that necessary? Probably not.

Set boundaries around deep work:

• Do not disturb mode isn’t rude, it’s professional

• Block your calendar for focus time

• Make communication async-first by default

Batch your communication:

• Check Slack three times daily instead of 300 times

• You can be responsive without being reactive

• Processing messages in batches is more efficient anyway

Preserve your flow state:

• Quality attention on one problem for two hours outperforms fragmented attention on five problems for eight

• Stoicism values depth over breadth

• That deep work session where you actually solve the problem? That’s what you’re here for

Leave a comment

What This Looks Like in Practice

When I go out in the morning for a run, I leave my phone in my vehicle. It’s just me out there. First thing in the morning, nobody’s going to bother you at 6:30 AM anyway, but I keep my phone away so I’m not distracted by emails or LinkedIn notifications or whatever. I can just focus on the run.

Same thing with deep work sessions. I’ll focus on getting tasks done for solid blocks, then spend 15-20 minutes checking and getting caught up on things before going back. Rinse and repeat.

Just because we’re always connected doesn’t mean we always have to stay connected. We can choose to disconnect. There’s nothing wrong with disconnecting, I actually recommend it.

Stop Feeling Guilty

Here’s what you need to internalize: there’s no sense feeling guilty about protecting your attention. To do your best work, you have to focus. Without focus, you’re just scattered, and what are you really accomplishing? You’re being busy for the sake of being busy but not actually accomplishing anything.

The work you’re doing is important. Your time matters. If other people need you, they can wait. That’s not being selfish or a bad teammate, that’s understanding what your job actually is.

You weren’t hired to respond to Slack messages instantly. You were hired to solve problems, write code, ship features. Everything else is just noise trying to convince you it’s signal.

So own your time. Set those boundaries. Turn off those notifications. And when that guilt creeps in, remind yourself: the person who suffers most from your scattered attention is you, and the work you’re supposed to be doing deserves better than your fragmented leftovers.

Quote of the Day:

“People are frugal in guarding their personal property; but as soon as it comes to squandering time, they are most wasteful of the one thing in which it is right to be stingy.” - 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