Every engineering leader eventually inherits a codebase they would not have designed.
Not a clean architecture diagram.
Not a greenfield project.
A real system.
Coupled in weird places. Missing tests. Full of decisions that made sense to someone under pressure three years ago.
Your reaction matters.
You can walk in disgusted. You can roll your eyes at every table name, every 1,000-plus-line class, every missing abstraction, every strange deployment process, and every decision that violates the standards you would have applied.
That feels righteous.
It is usually useless.
The stoic engineering leader starts somewhere else: reality.
The codebase exists. It works. It powers a business. It pays salaries. It serves customers. It is imperfect, sometimes deeply imperfect, but it got the organization this far.
That deserves respect.
Not approval.
Respect.
And grace.
Grace for the people who came before you does not mean lowering the bar. It means acknowledging that you were not there for the constraints that shaped the system. You were not in the room when the deadline moved, when the budget got cut, when the customer escalation hit, or when the engineer who understood the data model left.
Playing armchair quarterback does nobody any good.
Your job is not to sneer at the past.
Your job is to improve the future.
”Some things are in our control and others not.”
“Some things are in our control and others not.”
Epictetus, Enchiridion
You do not control the codebase you inherited.
You do not control the deadlines that shaped it. You do not control the shortcuts that were taken. You do not control the staff turnover, the budget decisions, the rushed releases, or the customer pressure that made the current system what it is.
You control what you do next.
That is where stoic leadership gets practical.
The stoic leader does not waste energy resenting what cannot be changed. They get to work on what is within practical grasp.
Not everything can be fixed this quarter, or even this year.
Not everything should be.
Your job is to identify what can be improved now without pretending you have unlimited time, unlimited budget, or a greenfield system.
Practical grasp matters.
Can you improve the next story?
Can you add the missing guardrail while you are already touching the code?
Can you rename the confusing method?
Can you pull one behavior out of the bloated class?
Can you document the rule everyone keeps forgetting?
Can you make the next change cleaner than the last one?
Start there.
Leadership is not proved by seeing every flaw in the system. Anyone can do that. Leadership is proved by choosing the next responsible improvement and making it real.
”Men are disturbed, not by things…”
“Men are disturbed, not by things, but by the principles and notions which they form concerning things.”
Epictetus, Enchiridion
The codebase is not what creates contempt.
The story you tell yourself about the codebase does.
There is a difference between judgment and contempt.
Judgment says, “This table design creates duplication.”
Contempt says, “Whoever built this had no idea what they were doing.”
Judgment says, “This class has too many responsibilities.”
Contempt says, “This whole thing is garbage.”
Judgment is useful. Contempt is lazy.
You need technical standards. You need taste. You need the ability to look at a system and see where it is weak.
But you also need humility.
I was not there for the constraints that shaped this codebase. I was not in the room when the decision was made. I do not know which deadline moved, which customer was escalating, which engineer left, which vendor integration failed, which executive changed direction, or which tradeoff looked reasonable at the time.
Playing armchair quarterback does nobody any good.
The old code is not a punching bag.
It is a classroom.
Use the failures and misses of the past to educate the future. Show junior developers why the data model creates update anomalies. Walk them through how the database could move toward fourth normal form. Show them how a giant class can be decomposed into clearer responsibilities. Explain why the shortcut created risk without turning the person who took it into a villain.
That is how a team develops standards without developing shame.
The lesson matters.
The sneer does not.
”Don’t demand that things happen as you wish…”
“Don’t demand that things happen as you wish, but wish that they happen as they do happen, and you will go on well.”
Epictetus, Enchiridion
You do not get to lead the system you wish existed.
You lead the one that exists.
That means leveraging what you can.
If the architecture is imperfect but stable, use that stability.
If the team has strong domain knowledge but weak test coverage, use that conscientiousness while you improve the safety net.
If the system is ugly but powers a successful organization, respect the result while raising the standard.
Acceptance is not surrender.
It is the beginning of useful action.
The immature reaction to an inherited system is fantasy: “If only we could rewrite it.”
Sometimes you can. Usually you cannot. Even when you can, the rewrite will cost more, take longer, and preserve fewer business rules than the team expects.
The mature reaction is leverage.
What still works?
What has to keep working?
Where is the risk highest?
Where can one small change make the next ten changes easier?
What existing team strength can carry the improvement effort?
Stoic leadership is not pretending the system is fine.
It is seeing the system clearly enough to move it.
And being disciplined enough to select the few places where movement matters most.
”A hindrance to a given duty becomes a help…”
“A hindrance to a given duty becomes a help, an obstacle in a given path a furtherance.”
Marcus Aurelius, Meditations
The obstacle tells you where the work is.
It does not tell you the priority.
That distinction matters.
Engineers are trained to see flaws. We see missing unit tests, duplicated logic, poor naming, leaky boundaries, manual deploys, dead code, outdated dependencies, and database designs that should have been fixed years ago.
Seeing the flaws is easy.
Choosing the order is leadership.
Lack of unit tests is not great. But if the system works, your developers are conscientious, and the highest business risk is somewhere else, unit tests may not be your first move.
That sentence will bother some people.
Good.
Books give general principles. You lead a specific system.
The right next move might be the deployment process that blocks releases. It might be the data model that corrupts reporting. It might be the class everyone is afraid to touch. It might be the manual process that burns ten hours every sprint. It might be the subsystem only one developer understands.
Do not optimize for what makes you feel technically virtuous.
Optimize for the next meaningful gain.
The stoic leader does not chase every flaw.
They attack the highest-priority, biggest-gain item within reach.
That is how improvement compounds.
Field note: At my current employer, some of the data that drives web pages is stored across multiple tables and fields in very interesting ways, including space-delimited lists.
The current code has to merge some of that data and manipulate it based on position and index. That logic exists in multiple applications in slightly different forms.
The result is predictable.
Data corruption.
Manual intervention.
The same business rule implemented slightly differently in different places.
The technically pure fix would be a full database refactor.
It would also touch internal applications, external-facing applications, reporting, existing workflows, and every piece of code that depends on the current shape of the data.
Huge blast radius.
So my team is taking a smaller, more disciplined path.
We are building a small library that serves as a serialization and deserialization layer between the applications and the database. All the logic goes in one place. Each application can be reworked to use that library.
Is the platform perfect after that?
No.
Is it better?
Yes.
The blast radius is smaller. The corruption risk goes down. The team gets one place to fix, test, and understand the rule.
That is stoic leadership.
Not best.
Better.
”While we are postponing, life speeds by.”
“While we are postponing, life speeds by.”
Seneca, Moral Letters to Lucilius
Small changes lead to big shifts.
Grand rewrites feel clean because they let you imagine a future without the mess.
No brittle old code.
No strange schema.
No awkward boundaries.
No accumulated compromise.
Just a clean system built the right way.
That fantasy is powerful.
It is also where many engineering organizations lose years.
Grand rewrites often fail. When they do not fail, they usually take far longer than expected. Meanwhile, the old system keeps running, the business keeps changing, and the team keeps paying interest.
The stoic leader improves the real system.
Small seams.
Small decompositions.
Small schema improvements.
Small tests around high-risk behavior.
Small reductions in deployment pain.
Small standards applied consistently from this point forward.
That does not sound dramatic.
It works.
One cleaned-up story does not transform a codebase. One better boundary does not change the architecture. One test around a critical behavior does not create comprehensive coverage.
But repeated small improvements change what the team believes is normal.
That is the shift.
The codebase gets better.
The standards get clearer.
The team gets sharper.
The shame goes down.
The discipline goes up.
That is stoic leadership in software: calm enough to see reality, humble enough to respect how it got here, and disciplined enough to improve it anyway.