You're Overthinking Every Decision
The Sage Developer Method
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?”
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.
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.
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