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

You open a file, and it’s 2,000 lines of nested conditions with variables named temp, temp2, the_real_temp. Your blood pressure begins to spike. The original developer is long gone. Your rage changes nothing except your ability to think clearly about fixing the issue.

But here’s the thing: not all anger is useless.

Share

The Two Flavors of Anger

The Stoics made a distinction that every developer needs to understand. There’s destructive fury, and there’s constructive frustration.

One paralyzes you. The other refactors.

Destructive anger assumes malice or incompetence. You look at that spaghetti code and decide someone was either stupid or lazy. Maybe both. You build this whole story in your head about the idiot who wrote this shit and how they clearly didn’t give a fuck about anyone who’d have to maintain it.

That anger feels justified. It also does absolutely nothing to fix the problem.

Constructive frustration looks at the same code and says, “Okay, this is problematic.” No story about the previous developer being an asshole. No moral judgment. Just acknowledgment that this code needs work, and you’re the one who has to do it. This kind of frustration becomes fuel. It motivates systematic improvement instead of rage-driven rewrites.

Leave a comment

What Destructive Anger Actually Looks Like

I’ve been that angry developer. Early in my career, I inherited an e-commerce system that looked like it was written by someone having a stroke. My first instinct was to delete everything and start from scratch.

So I did. I spent three weeks rewriting the entire thing “the right way.” Added all these beautiful abstractions. Clean separation of concerns. Design patterns everywhere. I was so proud of myself.

Two problems: First, I broke shit that was working. Turns out some of that “terrible” code was handling edge cases I didn’t know existed. Second, my “clean” rewrite was over-engineered to hell. I’d created a different kind of mess because I was coding from emotion instead of analysis.

Rage-driven refactoring looks like this: dramatic gestures instead of pragmatic improvements. You’re not fixing problems, you’re proving a point to a developer who isn’t even there anymore. You’re writing code to show how much better you are, not to make the system actually better.

And here’s the kicker: that ecomm system I rewrote? Someone probably looked at my code a few years later and thought the exact same shit about me.

The Pause That Changes Everything

Seneca had a technique for this: catch anger in the first moments before it becomes rage. Notice the tightness in your chest when you see bad code, pause, and then choose your response.

Here’s what this actually looks like in practice:

You open that file. Feel that rage building. Your jaw clenches. Your inner monologue starts going off about what kind of person writes code like this. Right there, that’s the moment. Seneca says catch it before it catches you.

So you literally stand up. Walk to the break room. Pour some coffee. Not because you want coffee. Because you need three minutes to let your nervous system calm the down. You’re not avoiding the problem. You’re preventing yourself from making it worse.

Then you come back and refactor like a professional instead of an angry teenager.

The question isn’t “Is this code terrible?” The answer is usually yes. The real question is “Does my anger help me improve it?” And the answer to that is almost always no.

Share The Stoic Coder

Understanding Why Code Gets This Way

Here’s what I’ve learned after 25 years: all code degrades over time. Yours, mine, everyone’s. It’s entropy, not evil.

Budget constraints force shortcuts. Deadlines demand compromises. Requirements change mid-sprint. That “quick fix” becomes permanent because there’s never time to go back and do it right. The elegant architecture you planned gets demolished by reality.

The developer who wrote that nightmare code? They were probably dealing with the same shit you are now. Maybe the product manager kept changing the specs. Maybe they were told to ship it by Friday or the company loses the client. Maybe they were maintaining ten other systems simultaneously and this one got the leftover brain cycles.

You don’t know their constraints. You just know what they left you.

And here’s the humbling part: the code you’re writing today, right now, with the best intentions and all your experience: that’s someone’s future legacy nightmare. Some developer in 2030 is going to open your files and wonder what the hell you were thinking.

Because they won’t know that you were dealing with a sudden API deprecation. Or that the business needed this feature yesterday. Or that you were juggling three projects and fighting production fires at the same time.

This realization doesn’t excuse bad code. But it kills the moral outrage that makes you useless.

Channeling Frustration Into Improvement

Once you’ve let go of the anger, you’re left with something more useful: energy. Frustration that says “this needs to be better” instead of “someone messed up.”

That energy goes into systematic refactoring. Not dramatic rewrites. Not proving points. Just methodical improvement.

Write tests first. Document what the current behavior actually is, bugs and all. Then improve incrementally. One function at a time. One responsibility at a time. Make it work, make it right, make it fast—in that order.

This is anger transformed into discipline. Into craftsmanship. Into code that’s actually better instead of just differently broken.

The Hard Truth About Your Own Code

You know what kills the rage cycle? Genuine humility about your own imperfect work.

Go back and look at code you wrote a year ago. Hell, six months ago. You’ll find stuff that makes you cringe. Because you’ve learned since then. Because you see the problem differently now. Because the requirements changed and your beautiful solution became technical debt.

The legacy code you’re cursing today is your own future legacy code tomorrow. The same pressures that created that mess you’re fixing right now are creating tomorrow’s mess in what you’re writing today.

That’s not defeatist. That’s reality. And once you accept it, you can stop taking bad code personally and start treating it as what it actually is: a problem to solve, not a villain to vanquish.

From Rage to Refactor

Marcus Aurelius said you have power over your mind, not outside events. You can’t control that some developer three years ago wrote shit code. You can’t change that you’re the one stuck fixing it. You can’t even guarantee that your fixes will be better in the long run.

But you can control whether you let rage make you stupid. You can choose to pause instead of react. You can acknowledge frustration without letting it drive your decisions.

The code is what it is. Your job isn’t to be mad about it. Your job is to make it better.

That’s the Stoic move. Transform the anger into action. Let the frustration fuel discipline instead of dramatic rewrites. Fix the problem instead of fighting ghosts.

Because at the end of the day, the only code you can truly control is the code you’re writing right now. Make it count.

Quote of the Day:

“The greatest remedy for anger is delay.” - 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

Have you ever had one of those days where everything goes to shit and you just want to walk away from your keyboard? Production’s on fire, stakeholders are breathing down your neck, and that “quick fix” you deployed yesterday just created three new bugs. You’re sitting there thinking, “Why the hell did I become a developer?”

The difference between developers who burn out after five years and those who build sustainable 20-year careers isn’t talent. It’s not even luck. It’s having a system that keeps your head straight when everything around you is chaos.

Share

The Philosophy That Actually Works

I used to think Stoicism was just old dead guys saying “don’t worry, be happy” in fancy language. Then I actually started practicing it daily, and I realized it’s more like having a mental framework for not losing your shit when things go sideways.

Marcus Aurelius didn’t write his Meditations for publication. He wrote them as daily reminders to himself because being Emperor of Rome was probably stressful as hell. Every morning, he had to prep his mind the same way we prep our environments before a deploy. Because without that prep, you’re just reacting to whatever chaos the day throws at you.

And that’s where most of us live, in reactive mode. Something breaks, we scramble. Someone criticizes our code, we get defensive. A project gets cancelled, we spiral. We’re constantly dodging bullets instead of actually controlling anything.

The Practice Nobody Wants to Hear About

Here’s what I do, and fair warning: it’s not sexy. There’s no productivity hack that’ll make this effortless. It’s just consistent, daily work that compounds over time.

Every morning, before I even look at Slack, I spend five minutes asking myself one question: What can I actually control today?

Not what I wish I could control. Not what I think should be in my control. What’s actually within my power.

Leave a comment

I can’t control if the product owner changes requirements mid-sprint. I can’t control if a dependency breaks with a new update. I can’t control if my PR sits in review for three days while everyone’s “too busy.”

But I can control how I respond to all that shit. I can control whether I write clean code or hack together something that’ll haunt me in six months. I can control if I speak up in stand-up or just keep my head down. I can control whether I focus on deep work or let myself get pulled into every Slack thread.

This sounds simple. It’s not. Because your brain will fight you every single morning, trying to convince you that you need to worry about all the other stuff. That you should be anxious about the deploy. That you should be pissed about that feedback in yesterday’s PR. That you should be stressed about whether the company’s going in the right direction.

I still fail at this constantly. I’ll be three messages deep into a Slack argument about code standards before I catch myself and realize I’m fighting about something that doesn’t really matter. But the difference between now and five years ago is that I actually notice when I’m doing it.

At the end of each day, I write down three things:

1. What went well (even if it’s just “the build didn’t break”)

2. What went wrong and what I can learn from it.

3. What’s in my control tomorrow?

That’s it. No fancy journaling prompts. No gratitude exercises that feel forced. Just a quick reality check on my day.

The wild part is going back and reading entries from months ago. You start to see patterns. Like, I get stressed about the same types of things over and over. I make the same mental mistakes. I waste energy on the same uncontrollable bullshit.

It took me years to recognize some of these patterns. I can look back at decisions I made 10, 15 years ago—like sticking with Flash development way too long, or how I handled certain production incidents—and I cringe. But that’s the point. I can’t change those decisions. All I can do is not repeat them.

Share The Stoic Coder

The Part That Saved My Ass

Before any major deploy or release, I spend five minutes imagining everything that could go wrong.

Not in a doom-spiral anxiety way. More like a disaster recovery drill for my brain. What if the database migration fails? What if there’s a permissions issue we didn’t catch? What if traffic spikes and the new endpoint can’t handle it?

Then I mentally walk through: Okay, if that happens, here’s what I’d do. Here’s who I’d notify. Here’s the rollback plan.

I had a perfect example of this recently. We pushed a deploy, everything looked great. All tests passed, smoke checks came back clean. I felt good about it.

Next day? Production issue, the API broke. We had to push a hot fix that night.

Old me would’ve panicked. Would’ve felt like I fucked up, like I should’ve caught it, like everyone was judging me for breaking production. But because I’d already mentally prepared for the possibility of things going wrong, I just... handled it. Reset, refocused, figured out the issue, fixed it.

That’s what negative visualization does. It’s not about being pessimistic, it’s about removing the shock factor when shit inevitably goes wrong. Because it will go wrong. Your code will break. Your estimates will be off. Your assumptions will be wrong. That’s not failure, that’s just software development.

Why This Is So Hard (And Why That’s Okay)

Look, we live in a world where everything is instant. You want food? DoorDash. Need a ride? Uber’s there in five minutes. Want to learn something new? Here’s 47 YouTube tutorials right now.

But Stoicism? Philosophy? Mental resilience? That takes years.

You don’t read Marcus Aurelius once and suddenly have unshakable calm. You don’t journal for a week and cure your imposter syndrome. This is daily practice that compounds slowly over time, and there’s no fucking shortcut.

The philosophy itself is simple. Brutally simple, actually. Focus on what you can control. Let go of what you can’t. Show up consistently. That’s like 90% of it.

What makes it hard is doing it every single day. When you’re tired. When you’re frustrated. When you’re off work and just want to decompress. Every moment becomes a choice: Am I going to react to this, or am I going to respond intentionally? Am I letting anxiety control me, or am I taking ownership?

I’m not perfect. I still have days where I’m completely reactive, where I let small frustrations derail my focus, where I worry about shit I can’t control. But I have fewer of those days than I used to. And when they happen, I recognize it faster and course-correct.

The Bottom Line

Ten minutes of daily practice beats reading philosophy for six hours once a month. Make it routine like your morning coffee. Simple practices, done consistently, over years.

That’s it. That’s the whole thing.

No magic bullet. No life-changing epiphany. Just showing up every day and doing the work of staying aligned with what actually matters and what you can actually control.

Now I want to hear from you:

What’s your biggest struggle with staying focused on what you can control?

Do you have any daily practices that help you build resilience?

What’s a time when you completely lost perspective and how did you get it back?

Drop your thoughts in the comments. Because chances are, whatever you’re struggling with, someone else here is too. And sometimes just knowing you’re not the only one fighting this battle makes it a little easier to keep going.

Quote of the Day:

“We suffer more often in imagination than in reality.” - 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

You’ve just taken down production. Your Slack notifications are exploding. Your heart is doing that thing where it feels like it’s trying to escape through your ribcage. And somewhere in the back of your panic-soaked brain, a voice is screaming, “Everyone thinks I’m an idiot. I’m getting fired. My career is over.”

Let’s talk about that voice.

Share

The Panic Brain vs. The Problem-Solving Brain

Here’s what happens in those first few seconds after you realize you’ve screwed up: your brain goes into full catastrophe mode. It’s not thinking about rollback procedures or database transactions. It’s writing your termination letter, imagining the disappointed looks from your team, and probably planning your new career as a barista.

This is where Marcus Aurelius has something useful to tell us about our broken deployment. He called it “the view from above,” and it’s not some woo-woo meditation thing. It’s a mental zoom-out that strips away the panic and lets you see what actually matters.

From the vastness of space, your failed deploy is invisible. Not because it doesn’t matter, but because your catastrophic thinking about it matters even less.

Think about it this way: Will this outage matter in a month? A year? At your retirement party? Most production incidents fade into forgotten anecdotes. The ones you remember become the war stories you tell over beers. “Remember that time I accidentally deleted the production database?” (Please tell me you have backups.)

Leave a comment

What’s Actually Happening vs. What You Think Is Happening

The production issue is real. Your anxiety about your reputation? That’s imagination masquerading as urgency.

Your panic brain says: “Everyone thinks I’m incompetent. I’m going to get fired. I’ll never get another job in this industry.”

The view from above says: “Okay, production is down. Who’s impacted? What’s the rollback plan? What do we need to do to get this back up?”

See the difference? One is spiraling. The other is problem-solving.

Here’s the thing most people don’t talk about: your ego isn’t the problem. Your users’ inability to check out? That’s the problem. Separating these two things, actual user harm from your fear of looking incompetent, is the skill that separates developers who thrive under pressure from those who crumble.

Building the Muscle Before You Need It

You can’t wait until production is on fire to practice this mental shift. That’s like trying to learn to swim while you’re drowning.

I always look at deployments, no matter how simple the change, with the understanding that something can drastically go wrong. Not because I’m paranoid, but because I’m prepared. How do I set up the deployment? What’s the rollback plan? What’s the monitoring look like? What’s the communication plan if things go sideways?

It’s about removing the surprise factor so when shit hits the fan, your brain doesn’t treat it like a five-alarm catastrophe.

Try this: Pick a current problem or deployment you’re working on. Now imagine you’re looking at it from a year from now. How big does it seem? What actually mattered about how you handled it? It probably wasn’t whether you panicked, it was whether you solved it.

Do this weekly. Build that muscle memory. Because when the real crisis hits, you want that zoom-out to be automatic, not something you have to remember to do while your hands are shaking.

Share The Stoic Coder

What This Actually Looks Like in Practice

Let me tell you about how this plays out in real life. I’ve always looked at troubleshooting as one of those things where you get so locked in that nothing else matters. Once you’ve zoomed out and gained that perspective, you can zoom back in with clarity instead of dread.

You approach the problem with what I call “calm urgency.” You’re moving fast, but you’re not moving in panic. You’re checking logs, reviewing recent changes, verifying assumptions. Your brain isn’t wasting cycles on “what if I get fired” because you’ve already dealt with that noise.

Things break. They will break at the most inopportune times, that’s kind of how it works. But how you respond matters way more than the fact that something broke.

Every senior developer you work with has taken down production at least once. The difference between them and the junior who’s currently freaking out isn’t that they never make mistakes. It’s that they’ve learned to separate the problem from the panic.

The Bigger Picture

This view from above thing, it’s not just about production incidents. It’s about how we approach challenges in general.

We live in an industry that moves fast, where stakes feel high, where impostor syndrome is practically a job requirement. It’s easy to catastrophize. It’s easy to treat every bug like it’s a referendum on your competence.

But you’re not building life-saving medical equipment (unless you are, in which case, maybe panic a little). You’re solving problems. Some are small. Some are big. All of them are solvable.

The view from above doesn’t dismiss your problems. It gives you the space to solve them without drowning in self-inflicted drama.

So next time production goes down and your heart starts racing, remember: zoom out, see the real stakes, then zoom back in and fix the damn thing. Your future self will thank you.

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’ve been writing React for three years. You know the patterns. You’ve got your component library memorized. Pull requests practically write themselves at this point. You’re comfortable.

That comfort? It’s the problem.

Here’s what “too comfortable” actually looks like: You haven’t touched a language outside JavaScript in two years. Your terminal commands are limited to npm install and git push. When someone mentions systems programming or database internals, you zone out because “that’s not my job.” You rely on your IDE and AI assistant for everything, including shit you used to know cold.

And then one day, your entire lane disappears.

Share

The Thing Nobody Tells You About Tech Careers

I started heavy into Flash development. Made good money. Got really damn good at it. Then I jumped ship before Adobe even got involved, convinced that .NET was the smart long-term play. Microsoft platform. Enterprise dominance. This was supposed to be the safe bet, the career move that would set me up for decades.

And you know what? It worked. For a while. But here’s the kicker: even the “safe” enterprise tech evolves. .NET today looks nothing like the .NET I bet my career on. The entire paradigm shifted: cloud, containers, cross-platform, open source. If I’d stayed comfortable with what I knew in those early years, I’d be just as obsolete as if I’d stuck with Flash.

That’s how technology works. The framework you’re betting your career on right now? Give it five years. Maybe less. React won’t last forever. Neither will whatever comes after it. Even the supposedly stable enterprise platforms transform into something unrecognizable.

The Stoics had a practice called voluntary discomfort, deliberately choosing hardship to build resilience. Seneca slept on a hard floor. Cato walked barefoot in winter. They weren’t masochists. They were training for the inevitable moment when comfort wouldn’t be an option.

For developers, our version isn’t physical. It’s that Rust codebase you’ve been avoiding. That systems programming deep dive that feels too hard. That open-source contribution where you’ll look like a beginner again. That infrastructure project where you don’t know what the hell you’re doing.

The question isn’t whether discomfort is coming. It’s whether you’ll choose it on your terms or let career stagnation choose it for you.

Leave a comment

What Controlled Discomfort Actually Looks Like

This isn’t about randomly throwing yourself at every new framework that hits Hacker News. It’s about strategic discomfort that compounds into real capability.

Tackle unfamiliar codebases. Pick a project in a language you don’t know. Not to become an expert, but to remember what learning feels like. That humiliation of being the worst person in the room again? That’s where growth lives. It kills the toxic ego that convinces you you’re too senior to struggle with basic syntax.

I deal with legacy codebases constantly. Code I didn’t write, decisions I don’t understand, patterns that make me want to throw my laptop. It’s easy to blame whoever came before. But adapting to unfamiliar code, especially code that challenges your assumptions, is one of the most valuable skills you can build.

Side project the scary stuff. Better to struggle with Kubernetes on a side project than during a production incident at 2 AM. Even if you think you’ll never need it, if it sounds interesting or intimidating, try it. I can’t count how many times some random thing I played with on the side translated into a job requirement or helped me solve a problem I didn’t see coming.

You don’t need to become a DevOps engineer. You need to understand enough to not be helpless when your comfort zone doesn’t have the answer.

Context switch deliberately. Set up a weekly practice: one afternoon working in a language or domain outside your main stack. Doesn’t matter what. The discomfort of constant context switching is exactly what makes you valuable. Specialists are great until their specialty becomes obsolete. Developers who can move between stacks, pick up new tools without melting down, and contribute even when they’re not the expert? Those are the people who survive industry shifts.

I’ve watched developers get locked into a single mindset, a single field. When the industry moved on, they couldn’t. Not because they weren’t smart, but because they’d lost the ability to be uncomfortable.

Share The Stoic Coder

The Payoff Nobody Talks About

Small discomforts compound into massive confidence. That intimidating PR you forced yourself to submit in an unfamiliar codebase? It makes the next scary thing less scary. Then the next one. Then suddenly you’re the person who can jump into anything without panic.

Here’s a real example: At my current gig, most developers want absolutely nothing to do with our payments system. It’s complex, it’s high-stakes, and screwing it up has real consequences. So when the opportunity came up, I jumped on it. Not because I knew what I was doing, but because nobody else wanted to touch it.

My goal wasn’t to become the payments guru overnight. It was to learn as much as possible and provide the value that was needed. And you know what happened? I became the go-to person for something critical that everyone else avoided. That’s not bragging, that’s what happens when you’re willing to be uncomfortable while everyone else runs the other direction.

Market value flows to the uncomfortable. Companies don’t pay top dollar for developers who can only work in their exact comfort zone. They pay for people who can handle whatever gets thrown at them.

Controlled failure is cheaper than real failure. Way cheaper. Every time you struggle with something on a side project, you’re building muscle memory for when it actually matters.

The Alternative Isn’t Pretty

You know what happens to developers who stay comfortable? They get comfortable right into obsolescence. Their skills rust. The industry moves. And when they finally need to learn something new. Not because they want to, but because they have to: they’ve forgotten how.

They scramble. They panic. They realize they’ve been coasting for so long that the basic act of struggling with new concepts feels impossible.

That’s the real career killer. Not lack of talent. Not bad luck. Just years of choosing comfort over growth until comfort is all you know.

Start Small, Start Monday

You don’t need to overhaul your entire career this week. Pick one thing that makes you uncomfortable. One language you’ve been avoiding. One type of problem you’ve been delegating. One codebase that intimidates you.

Spend two hours with it. Not to master it. Just to remember what it feels like to not know what you’re doing.

Then do it again next week. And the week after.

It’s on you to take ownership of your career and the decisions you make. Your company won’t do it. Your manager won’t do it. If there’s stagnation in your learning, that’s on you to fix.

The good news? Staying uncomfortable means this career never gets old. Even if you’re stagnant at your current job, you don’t have to be stagnant in learning and building skills.

Discomfort today prevents desperation tomorrow. That’s the deal. Choose your hard now, or have it chosen for you later.

I know which one I’d rather deal with.

Quote of the Day:

“Difficulties strengthen the mind, as labor does the body.” - 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

You know that side project you’ve been planning for two years? The one where you’ve got the domain name, a Trello board full of features, and maybe even a half-finished wireframe buried in your files somewhere? Yeah, that one. The React developer portfolio that’ll showcase your skills. The SaaS idea that could actually work. The blog where you’ll share everything you’ve learned.

It’s still sitting there, isn’t it? Right next to “learn Rust,” “contribute to open source,” and “finally understand machine learning beyond copying TensorFlow examples.”

Here’s the thing nobody wants to hear: you have maybe 40 productive coding years if you’re lucky. And you’ve already used some of them.

Share

The Math Nobody Wants to Do

Let’s talk about time, because the Stoics were obsessed with it for a good reason. They called it Memento Mori: remember you must die. Sounds dark as hell, but it’s actually the most liberating concept you can internalize as a developer.

If you’re 30, you have fewer working years ahead than behind. At 40, the math gets brutal fast. Not because you’re washed up but because time is the one resource you can’t earn back, can’t refactor, and can’t optimize with a clever algorithm.

That career pivot you’re waiting for? That application to the dream company you’re putting off? That conference talk you’ll submit “next year”? The clock’s ticking whether you’re watching it or not.

I’m not saying this to be depressing. I’m saying it because awareness of death isn’t depressing, it’s liberating. It obliterates the illusion that you have infinite time to become who you want to be.

Leave a comment

The “Someday” Trap

Take Sarah. She’s been a backend .NET developer for eight years. Good at it, too. But she’s been talking about pivoting to machine learning since 2021. She’s got bookmarks saved. She bought three Udemy courses on sale. She even started one, got through the first two sections before “work got busy.”

Every year, she tells herself this is the year. She’ll carve out the time. She’ll work through the math. She’ll build the portfolio projects. And every year, December rolls around and she’s in the exact same spot, just one year older.

Someday is a place you’ll never arrive.

That’s the brutal truth. That app idea, that technical blog, that conference talk proposal: they die with you unless you start before you’re ready.

Every sprint you’re not learning, you’re not just standing still. You’re falling behind.

Technology moves whether you do or not. The junior dev who started learning Go two years ago while you were “waiting for the right time”? They just got the job you were thinking about applying for.

Standing still is moving backwards.

The Perfect Moment is a Lie

You’re waiting for the perfect moment, right? When work calms down. When you’ve saved up more. When you feel more confident. When you have fewer responsibilities.

You’ll never have more energy, fewer responsibilities, or better circumstances than right now. That’s just reality.

It’s easy to procrastinate. Hell, it’s the default mode for most of us. We tell ourselves we’ll start tomorrow, next week, after this project ships, after the holidays, when things settle down. But once we get to that “next day,” there’s more stuff on our plate. Now it becomes even harder to start, even easier to procrastinate.

Think about it. You put off learning that new framework because you’re busy with work stuff. Next month rolls around, and now you’ve got work stuff PLUS that production bug that won’t die PLUS your manager wants you to mentor the new junior PLUS your spouse is planning a vacation. The responsibilities don’t decrease, they compound.

The moment you’re thinking about making a change, about doing something drastic, about taking that leap? That’s exactly when you need to do it. Not when it’s convenient. Not when you’re ready. Now.

Share The Stoic Coder

When Impostor Syndrome Meets Mortality

We’ve all got impostor syndrome. Every developer I know has that voice whispering “Who are you to apply for that senior role? You barely understand Docker. Real developers don’t Google basic syntax.”

But impostor syndrome loses its power when you hold it up against mortality.

“What if I fail?” becomes trivial compared to “What if I never try and run out of time?”

Do you want to be the developer who plays it safe for 40 years and retires with a resume full of maintenance work on legacy systems? Or do you want to look back and know you actually went for the things that scared you?

You don’t want to live with regrets. You don’t want to be 55, sitting in yet another sprint planning meeting, thinking “I could have built that startup. I could have learned that specialty. I could have become a tech lead if I’d just applied.” The “what could have been” is a special kind of torture.

Your Job is Not Forever (And That’s Actually Good)

Let’s talk about that comfortable salary. That job where you know the codebase, the team likes you, and the work is... fine. Not exciting, not challenging, but safe. The benefits are good. The 401k match is decent. Why rock the boat?

Here’s why: that comfortable job at your company might not exist in five years.

I’m not trying to freak you out, but look around. How many developers do you know who got comfortable, stopped learning, stopped growing, and then got blindsided by a layoff? They thought they’d coast to retirement at BigCorp, and BigCorp decided to “restructure” or “pivot” or whatever euphemism they’re using this quarter.

Comfort is a trap. It feels great in the moment, like sinking into a warm bath after a long day. But that same warmth that relaxes you can make you soft. And in tech, getting soft is dangerous.

We have no control over layoffs, over market shifts, over some executive deciding your entire department is getting outsourced. What we DO control is staying sharp. Keeping one foot out the door. Always looking at that five-year plan, hell, even a two-year plan.

A job is transactional. You’re trading your time and skills for salary and benefits. That’s it. It doesn’t define your worth. It doesn’t determine your identity. It’s what you’re doing now, not who you are.

The senior developer who spent ten years at the same company, doing the same type of work, never learning anything new? When that job ends, and it will end, they’re screwed. They’ve traded their growth years for comfort, and now they’re competing with developers half their age who have twice their curiosity.

Don’t be that person.

Five Years Pass Whether You Ship or Not

Here’s a thought experiment: think back five years. What were you working on? What were your goals? What were you planning to learn?

Now look at where you are today. Did those five years move you closer to who you want to be? Or did they just happen to you while you were busy being comfortable?

Because the next five years are going to pass whether you ship something or not. You can spend them wishing you’d started that project, built that skill, made that pivot. Or you can spend them actually doing it.

Death makes mediocrity unacceptable. When you truly internalize that this is your one life. Not a practice run, not a rough draft. Tolerating work you hate becomes impossible.

We only get one shot at this. It doesn’t make any sense to wait until tomorrow, wait until next year, wait until you feel ready.

So What Do You Actually Do?

If you really want to make a change, here’s what it takes:

Look at what you hate about your current situation. Not the surface stuff—not “I don’t like my manager” or “meetings suck.” Dig deeper. What’s actually keeping you up at night? What’s making you browse job boards at lunch?

Then look at what you’d need to change it. Not everything at once. Not the perfect plan. Just the next step.

Want to pivot from frontend to backend? Stop buying courses you won’t finish. Spend this weekend building one API. Just one. Make it terrible. Make it work. Then make another one.

Want to escape that toxic job? Stop complaining to your coworkers and update your LinkedIn. Like, actually update it. Today. Then apply to three places. Any three. Even if you think you’re not qualified. Especially if you think you’re not qualified.

Want to build that side project? Stop planning and write one function. Then another. Then another. Who cares if the architecture’s wrong? You can refactor later. You can’t refactor code that doesn’t exist.

The Stoics had this concept right: understanding that our time is finite shouldn’t paralyze us. It should energize us. Every day you wake up is another chance to move toward who you want to become.

You have to take those steps. You have to make those reps count. Because we only get one shot at this.

And once it’s done, it’s done.

Quote of the Day:

“It is not that we have a short time to live, but that we waste a lot of it. Life is long enough, and a sufficiently generous amount has been given to us for the highest achievements if it were all well invested.” - 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