Skip to content
Published on

Philosophy for Engineers — Applying Stoicism and Pragmatism to Your Work

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

Introduction: Why Philosophy for Engineers?

Mention philosophy and you usually get one of two reactions. One is the cynical "that is a luxury for people with too much time." The other is the inflated hope that "somewhere in there is a secret that will change your life." I think both are wrong.

An engineer's work is fundamentally about dealing with uncertainty and things outside your control. Builds break, dependencies vanish overnight, and well-written code collapses against inputs you never imagined. A colleague's review can sting, interview outcomes are not yours to decide, and the direction of a company rarely bends to one person's effort. How you hold your mind in that environment is not an abstract question — it is a practical problem you hit every single day.

The ancient Stoics and the nineteenth-century American pragmatists lived in different worlds, but both treated "how should one live" as a matter of practice, not decoration. As tools, not ornaments. This essay picks two or three of those tools and tries to move them onto an engineer's desk. I will not promise grand enlightenment. I only want to leave you a few graspable things — the kind you might actually recall during your next sprint.

Stoicism: Focus on What You Can Control

The Dichotomy of Control

The core of Stoicism is simple. Epictetus put it this way.

"Some things are within our power, and some things are not." — Epictetus, Enchiridion, 1

Within our power: our judgment, our effort, the way we write code, the attitude we bring to a review. Not within our power: other people's reactions, an interviewer's verdict, market shifts, an outage that has already happened.

The distinction sounds trivial, but in practice most unnecessary suffering comes from drawing this line in the wrong place. Strain to control what you cannot, and you end up frustrated. Neglect what you can, and you end up powerless.

Slice an engineer's day with this lens and it looks like this.

Within your control            Not within your control
--------------------------     --------------------------
the quality of your code       when a reviewer responds
the clarity of your PR         whether the PR gets merged
whether you wrote tests        the edge case that blows up in prod
how well you prep an interview the interview result
what you say in a retro        whether the org acts on it
the hours you invest learning  the timing of your promotion

The practice is to pour energy into the left column and meet the right column with equanimity. "Do your best but do not cling to the outcome" is a cliche, but Stoicism gives it structure. The outcome was never in your domain to begin with, so judging yourself by the outcome is, strictly speaking, a category error.

A Case in Practice: A Rejected PR

Take a concrete situation. A PR you spent three days on gets rejected, with the comment "this approach does not fit our architectural direction."

The un-Stoic response: "I wasted my time. They should have told me sooner. This team's communication is broken." Anger and self-pity blend together, and that feeling trails into your next task.

The Stoic response splits the question.

Controllable:
  - next time, confirm direction before starting
  - salvage the reusable parts of this PR
  - ask back to confirm I understood the reviewer's concern

Not controllable:
  - the three days already gone
  - the fact that the reviewer did not speak up earlier

The lost time is a sunk cost. Adding anger to it only increases the loss. Stoicism does not tell you to suppress the emotion. It tells you to ask whether the emotion is aimed at something controllable. A short pause to check the direction of your anger — that is all it is, but that is what makes the difference.

Negative Visualization: Breaking It in Advance

Another Stoic tool is premeditatio malorum, negative visualization — calmly picturing, in advance, how things might go wrong. This is a mode of thinking engineers already know. We call it "design for failure" or "chaos engineering."

Imagining before a deploy "what happens if this blows up at 3am," assuming a third-party API you depend on is down and adding a fallback — that is the engineering version of negative visualization. Facing the worst in advance gives you two things. First, you actually build the contingency. Second, when it really happens, you are less shaken — you have already lived it once in your mind.

But balance matters. When negative visualization curdles into chronic anxiety, it becomes poison. The key is "calmly, once, with a contingency." Replaying the same disaster twenty times in your head is not visualization, it is rumination, and that is something entirely different.

Resilience: The Obstacle Becomes the Way

"The impediment to action advances action. What stands in the way becomes the way." — Marcus Aurelius, Meditations, 5

This line became famous when Ryan Holiday made it a book title, but its source is a Roman emperor's private journal. In engineering it is almost literally true. A stubborn bug forces a deeper understanding of the system, a tight constraint forces a more elegant design, and one big outage usually drags an organization's operational maturity up a level.

Of course, romanticizing this into "all suffering is a gift" is a problem. Burnout is not a gift, and mistreatment is not a gift. The real Stoic claim is more restrained: when you meet an obstacle you cannot control, is there room to use it as material for learning or training? It is not praise of the obstacle itself, but a search for the part within it that you can control.

Pragmatism: What Works Is True

The Cash Value of Truth

The American philosopher William James saw truth as "the concrete difference its being true makes in someone's actual life." He called this truth's "cash value." Instead of asking whether a belief is true, he asked what difference acting on it would make.

Engineers are already thorough pragmatists. We do not ask whether an architecture is metaphysically correct. We ask whether it survives our load, whether the team can maintain it, whether it can absorb next quarter's requirements. If it works, we adopt it; if it does not, we drop it.

Charles Sanders Peirce's pragmatic maxim is even blunter: the meaning of a concept reduces to its practical consequences. The claim "this abstraction is better" means something only when translated into the observable difference it makes — fewer bugs, faster changes, easier onboarding.

Arguing by Results, Not Dogma

Pragmatism shines brightest in technical disputes. Engineering debates often degrade into clashes of dogma: "REST is right vs GraphQL is right," "monorepo is correct vs multi-repo is correct," "OOP vs functional." These arguments never end, because at heart they are contests of belief.

The pragmatist reframes the argument. Not "which is right" but "in our specific context, which produces the observably better result."

Dogmatic question             Pragmatic question
-----------------------       ------------------------------------
Is GraphQL better?            Is the over-fetching our clients face
                              an actual problem? How often, at what cost?

Should we go microservices?   What exactly hurts most in the monolith
                              now, and would splitting fix that?

Is this code clean?           Can a different person safely change
                              this code six months from now?

The questions on the right are answerable. They can be measured and agreed upon. Pragmatism lets you accept that the "right answer" varies with context. This is not relativism — the results are still measured objectively. It only places the standard of those results in the situation you are actually in, rather than in an abstract principle floating outside it.

Design as Hypothesis

Pragmatism treats every belief as a provisional hypothesis. Dewey described inquiry as "a process that begins in doubt and moves toward settled belief, but stays open to new evidence at any time." This is just good engineering.

A good design doc does not declare "this is the answer." It writes "we assume X, we try Y, and if metric Z degrades we roll back." Treating a design not as truth but as a testable hypothesis — that is the pragmatic stance. A/B tests, canary deploys, and feature flags are all instruments of a pragmatist epistemology that says "test your beliefs against reality."

Essentialism: Less, But Better

Deciding What Not to Do

Essentialism, popularized by Greg McKeown, reduces to "less, but better." The core insight is that "what not to do" matters as much as "what to do."

An engineer's backlog is infinite. Bugs you could fix, performance you could improve, features you could add, debt you could pay down — it never ends. Everything looks worth doing. So the real essentialist question is not "is this worth doing" but "is this more worth doing than the alternatives."

That is the language of trade-offs, not priorities. Saying yes to everything is, in truth, saying no to the most important thing — because time is finite.

In practice essentialism shows up as questions like these.

- What does this refactor actually change for a user right now?
- Is this abstraction driven by a real need or an imagined future?
- If this meeting disappeared, what would break? (If nothing...)
- If we do not build this feature, who is inconvenienced, and how much?

The "abstraction for an imagined future" trap is the one engineers fall into most. The YAGNI principle (You Aren't Gonna Need It) is the engineering version of essentialism. Flexibility you do not need now mostly stays unneeded later, while inflating present complexity.

The Art of Saying No

The hardest part of practicing essentialism is saying no — especially in many workplace cultures. But declining need not be rude. The trick is not to reject the person but to place the request within your priorities.

A bad no: "I can't do that."

A better no:
"I'm in the middle of A and B; adding this pushes A to next week.
I'd love to decide together which is more urgent."

The latter is not a refusal but a way to make the trade-off visible. By sharing the decision with the requester, you send the message: "I am not trying to avoid work; I am trying to decide together where to spend finite time." This connects back to the Stoic dichotomy of control — how I allocate my time is squarely within my domain.

Craftsmanship: Respecting the Work Itself

Pride in Process, Not Just Outcome

Pragmatism prizes outcomes and essentialism prizes choices, but craftsmanship is an attitude toward the process of working itself. In The Craftsman, Richard Sennett defines craftsmanship as "the basic human impulse to do a job well for its own sake."

There is a subtle balance here. Pragmatism says "it works, good enough"; craftsmanship says "I want to make it well." Do they clash? Usually not. Well-made things tend to work longer, cost less to maintain, and let the next person handle them more safely. Craftsmanship's "well" is often the long-term version of pragmatism's "works."

The clash arises when craftsmanship curdles into self-indulgence: polishing code no one will read to perfectionist sheen, chasing elegance with no business value. That is not craftsmanship but ego projection. A real craftsman knows "whom this care reaches." A furniture maker sands the unseen back of a drawer because someone will run their hand over that smoothness. When there is an object for the care, it is craftsmanship; when there is none, it is compulsion.

Respecting the Boring Work

The less visible part of craftsmanship is the attitude toward repetitive, dull work. Cleaning up logging, shoring up tests, refreshing docs, sharpening error messages — unglamorous things that hold the system up.

The Stoic Marcus Aurelius told himself each morning, "today I rise to do the work." He did not see work as a special moment of inspiration but as something to carry out steadily. This is where craftsmanship and Stoicism meet. Great systems are built not by heroic moments but by the faithful repetition of ordinary days.

Handling Uncertainty: Suspending Judgment

Engineering is a continuous stream of making decisions under incomplete information. Requirements are vague, data is scarce, and the future is unknown. Tolerating that uncertainty is a large part of professional maturity.

Ancient skepticism (Pyrrhonism) offers an interesting tool here. The skeptics practiced epoché, the suspension of judgment — refusing to assert when there is insufficient ground, and deferring the verdict. This is not indecision. Indecision avoids the decision; suspended judgment honestly admits "I lack the grounds to be sure right now."

In an engineer's daily life this is very practical.

Hasty assertion                Suspended judgment
-------------------------     -------------------------------------
"This is definitely a DB issue." "It could be the DB, but I don't know yet.
                              I need to look at more logs."
"That library is bad."         "That library didn't fit in situation X.
                              Our situation may differ."
"This design is the answer."    "This design is best under current
                              assumptions. If they change, I revisit."

When debugging an incident, the most dangerous thing is premature certainty. The moment you assert "it's surely a cache problem," you start hunting only for evidence that fits the hypothesis and ignoring the rest — falling into confirmation bias. The restraint to suspend judgment briefly and ask first "what does the data say" is where skepticism and pragmatism meet.

But balance is needed. You cannot defer judgment forever. At some point you must decide even on incomplete information. The key is to "match the degree of certainty to the degree of evidence." Strong confidence for strong evidence, a provisional conclusion for weak evidence. And gladly change your mind when new evidence arrives. That is not fickleness but intellectual honesty.

The Comparison Trap and Self-Referenced Standards

One of the most common reasons an engineer loses peace of mind is comparison. A colleague who reached a higher level at a younger age, an acquaintance drawing attention with a flashy side project, a peer presenting at a conference — in the age of social media, the material for comparison is infinite.

Stoicism applies the dichotomy of control here too. Other people's achievements are not within my control. And more importantly, what I see is the "highlight reel of their output," not the struggle, failure, or luck behind it. We play an asymmetric game, comparing our own backstage (the chaos, doubt, failure) to someone else's finished stage.

Seneca wrote:

"If someone is ahead of you, remember you are not competing with yourself but with that person." — Seneca, a variation on the Moral Letters

The remedy is to shift to a self-referenced standard. Not "am I better than that person" but "am I better than last year's me." The former is uncontrollable and endless; the latter is controllable and meaningful. Pragmatically, this is better too. Comparison with others produces no action (envy will not write your code), but growth against your own standard points to a concrete next step.

Of course, not all comparison is bad. Used as motivation to learn from a better person, it is healthy. The key is whether the result of the comparison ends in "self-deprecation" or leads to "concrete learning." If the former, stop comparing; if the latter, go up to that person and ask.

Guarding Against the Self-Improvement Trap

I have introduced philosophical tools, but here we must hold the balance. The modern "Stoicism influencer" culture often distorts these philosophies dangerously.

First, the personalization trap. The teaching "focus on what you can control" can be abused to blame structural problems on the individual. Burnout is often caused by unrealistic schedules, understaffing, and bad management. That is not a problem of "your lack of resilience" but an organizational problem. Stoicism is not a philosophy of enduring injustice. Accepting what you cannot control and neglecting a structure you could change are entirely different things.

Second, the emotion-suppression trap. "Do not be ruled by emotion" gets misread as "do not feel emotion." Real Stoicism does not deny feeling. It says: notice the feeling, but briefly defer the impulsive judgment built on it. Feeling sadness is not weakness. Working through it while ignoring it is not strength.

Third, the productivity-fetish trap. The self-improvement industry urges you to "optimize" every hour. But essentialism's real message is the opposite. Doing less, resting, leaving things empty — these are essential choices too. Cramming all twenty-four hours is not essentialism but its inverse.

Use philosophy as a tool, but do not let the tool become a stick to flog yourself with. Every concept in this essay should read as "how to hold your mind amid uncertainty," not "pressure to become a better person."

Applying It to Learning and Growth

These philosophies apply not only to everyday crisis management but to long-term learning and career. An engineer's career is an endless stream of learning. New languages, new frameworks, new paradigms keep appearing, and it is easy to be overwhelmed by the pace.

The Stoic dichotomy of control gives peace of mind here. Keeping up with every new technology is not within your control. It is impossible, and making it your goal leads to chronic anxiety. What is within your control is "choosing what to learn deeply" and "the habit of learning steadily." Understanding the essentials deeply is — from an essentialist view too — more valuable than knowing everything shallowly.

Pragmatism sets the priority of learning. "What observable difference does learning this make to my actual work and growth?" Learning something just because it is trendy is inefficient. Conversely, the fundamentals — data structures, system design, debugging, clear writing — have high cash value in almost every context. Trends change, but the cash value of the fundamentals does not.

Applying philosophy to learning

  [Stoic] Don't try to keep up with every technology.
          What's controllable is "choice" and "consistency."

  [Pragmatist] Set learning priority by "what difference this
              actually makes." Value, not trend.

  [Essentialist] Know the essentials deeply over knowing all
                shallowly. Focus on "the learning with the most leverage now."

  [Craftsman] Enjoy the learning itself. Find satisfaction in
             deepening understanding, not in results (certificates, recognition).

The craftsman's view especially makes learning sustainable. See learning only as a means to external reward (promotion, salary), and when reward is slow, you tire quickly. But take the joy of learning itself — the small delight of the moment the unknown becomes understood — as your fuel, and learning becomes something to enjoy rather than an obligation. And paradoxically, the person who learns by enjoying it that way goes further in the long run.

Finally, the connection to the growth mindset. Just as pragmatism sees a design as a hypothesis, see your own ability not as fixed but as a hypothesis that can change — the "yet" in "I can't do this yet" meets the Stoic belief aimed at the controllable domain (effort, time).

Applying It at Work: An Integrated Framework

Let me weave the three philosophies into one practical flow. You can run any situation through this sequence.

1. [Stoic] What in this situation can I control?
   Set down the parts I cannot, for now.

2. [Pragmatist] Among the controllable options, which
   produces an observably better result? Judge by
   results, not dogma.

3. [Essentialist] Of those, which is the one that truly
   matters? Say no to the rest.

4. [Craftsman] Do that chosen work with care, thinking
   of the person it will reach.

5. [Stoic, again] The outcome is not my domain. If I
   did my best, I meet the result with equanimity.

Apply this flow to a code review. You see a problem in a colleague's PR. (1) What I control is "how I give feedback," not "how they take it." (2) Between an accusatory tone and a questioning tone, which actually produces improved code? In my experience, the questioning one. (3) Between ten minor style nits and one important design concern, which is essential? (4) I write that one piece of feedback with care, so they understand and grow. (5) Whether they agree is not my domain.

Morning and Evening Rituals: Philosophy as Habit

If philosophy is a tool, a tool is useful only when you pick it up regularly. The Stoics did not merely contemplate abstractly; they kept concrete daily rituals. Marcus Aurelius's Meditations was itself a record of daily self-examination, and Seneca recommended the habit of reviewing each day at night.

Move this onto an engineer's day and it becomes two small rituals.

The Morning Check

In the morning (5 minutes, with a coffee):

  1. What is outside my control today?
     (e.g., interview results, reviewer responses, meeting decisions)
     -> Set it down in advance. Don't tie my emotions to it.

  2. What is the one thing that truly matters today?
     (Essentialism: the one thing where "if I did only this,
      the day was a success")

  3. What difficulty will I face today, and how will I respond?
     (Negative visualization: calmly picture the thorny meeting,
      the bug that will get stuck)

The core of Seneca's negative visualization is this: before starting the day, admit in advance that "someone may be rude today, work may get stuck, plans may go sideways." Then when such things actually happen, they become "things I expected," and you lose less of your composure.

The Evening Reflection

In the evening (5 minutes, before sleep):

  1. What did I do well today? (recognition, not self-blame)
  2. Of the controllable things, what could I have done better?
     (learning, not blame. A small adjustment for tomorrow.)
  3. One thing I'm grateful for today.

There is an important balance here. If the evening reflection becomes a time of self-criticism, it backfires. The key is to focus only on "what was controllable." Blaming yourself for things you could not control is the opposite of Stoicism. And the reason to add one gratitude is that, the darker the season, the more our attention is pulled toward the negative. Deliberately recalling what was good is not mere positivity but a practice in balancing attention.

These rituals need not be grand. Five minutes each is enough, and you need not do them perfectly every day. The point is to turn philosophy from knowledge in your head into a habit in your hand. Philosophy you only know is a decoration on a shelf; philosophy you use daily is a tool.

Dialogue Examples: Applying Philosophy to Real Situations

Abstract principles tend to go limp in front of a concrete conversation. Let us see how this framework works through two real situations.

Situation 1: An Unfair Performance Review

In your year-end review you got a lower rating than you expected — even though, in your view, you did well enough.

Step 1 [Stoic] Controllable: my reaction, next quarter's
   behavior, clearly asking my manager for feedback.
   Not controllable: the rating already given, the
   manager's perception.

Step 2 [Pragmatist] Which reaction produces a better result?
   Venting anger vs concrete questions. The latter is more
   likely to improve the next review.

Step 3 The actual conversation:
   Bad approach: "This review is unfair."
   Better approach: "I'd like to understand the basis for this
     rating. Could you tell me specifically where I fell short
     of expectations, and what I might do differently next
     quarter?"

The latter is not an attempt to overturn the review (that is outside control) but to improve future behavior (within control). And the skeptic's suspended judgment works too — before asserting "this review is obviously wrong," first hear whether there is a perspective you missed.

Situation 2: A Technical Dispute with a Colleague

A colleague strongly argues for an architecture you believe is wrong.

Bad approach: "That approach is wrong. Mine is right."
   -> Dogma vs dogma. Degrades into a clash of belief.

Better approach: "Shall we lay out the trade-offs of both?
   Let's look together at which is better in which situation,
   and which our actual requirements are closer to."
   -> Argue by results. Move to a measurable standard.

Essentialism works here too. You do not need to fight every disagreement to the end. First ask "is this decision really important, or is it a reversible one?" If it is easy to reverse, trying the colleague's approach and judging by data may be faster than arguing. Not mistaking ego for the essential — that is maturity.

A Practical Checklist

Concrete, small practices to try over the next week. You do not need to do all of them — remember essentialism.

[ ] In a moment of frustration, ask once: "Is this controllable?"
[ ] In a technical debate, swap "is it right" for "what result does
    it produce in our context."
[ ] Pick three "will not do" items from this week's backlog.
[ ] Decline one request — but decline by making the trade-off visible.
[ ] Before the next deploy, calmly imagine "what if this blows up at
    3am" once, and check your contingency.
[ ] Do one boring-but-important task (tests/docs/logging) with care,
    picturing the person it will reach.
[ ] Once a day, deliberately make ten minutes of doing nothing.
    (An antidote to the productivity fetish.)

Closing: Philosophy as a Tool

Philosophy is not magic that makes you a better person. Nor should it be. Stoicism, pragmatism, essentialism, craftsmanship — these are tools you keep in a desk drawer. Pull them out when needed; if one does not fit, use another.

An engineer's work is a continuous stream of uncertainty and uncontrollability. What these tools promise is not to remove that uncertainty but to help you decide, more clearly, where to put your mind inside it. Focus on what you can control, judge by results, say yes to the essential, do the work with care. And meet the results of all that effort with equanimity.

Finally, set down the pressure to do all of this perfectly. That pressure is itself the self-improvement trap we warned about. Philosophy is a compass, not a whip. When you are lost, pull it out once to check your direction — and that is enough.

Discuss on Twitter • View on GitHub