Abraham Maslow, whom we know with the concept of Maslow's pyramid, has another lesser known but striking metaphor... Maslow's hammer!
Through this hammer Maslow tells us briefly the following: He who has a hammer in his hand sees everything as a nail.(1*)
Although Maslow says this as a criticism while identifying this common behavior of humanity, he has a point.
Since I am a software developer myself, I decided to start this new series of articles called software philosophy, thinking that I could use some of the tools I use to do my job better to build a better life while living life.
In this first article, we will look at the concept of technical debt and whether the need for refactoring that arises from this debt is applicable to life; we will look for ways to see if we can derive some benefit from it.
If you are ready, let's get started...
When I say software, we can think of it as a website, computer or mobile application. A banking, shopping or social media application that we use all the time is actually software.
Once this software is created, it is constantly updated; a new feature is added at every step. During this process, software developers go on leave, leave their jobs, new ones come in... Over time, the codes that make up this software degrade to such an extent that after a certain point, there is no time to correct these defects and technical debts begin to accumulate to be corrected later.
When we apply all this to life, we see the following:
We put aside some of the cyclical and unpleasant situations we experience by saying "I can't fix it now" and accumulate them almost like a technical debt.
But if we don't break the cycle somehow, if we don't replace it with a cycle that works better for us, these debts become a albatross around our necks.
Just as projects with too much technical debt become undevelopable, our lives can become unlivable, congested and depression-prone over time.
These emotional/mental debts can become so large that they can upset our behavior, our relationships and our productivity.
The harder it is to refactor code that we haven't touched for years, the heavier the emotions that we haven't talked about, shared or understood for years.
In this article we will look at ways to recognize and refactor the emotional, mental and spiritual debts that clog our lives.
Philosophical and Scientific Background
Perspective of Philosophy
Rewriting Yourself
Just as we look at past versions of software to understand technical debt, The inner "version past" of the human being has also often been discussed in philosophy.
Man's rewriting of himself...
Transcending himself...
Purifying himself...
These themes in different civilizations, in different languages, all point to the same truth:
Man thinks of himself as a static being, but in fact he is a living code waiting to be constantly refactored.
Nietzsche: An Inner Rewriting for Self-Transcendence
Nietzsche argues that throughout his existence man is torn between two options:
Either he remains dependent on his old code, or he transcends it and becomes a new version. (2*)
Nietzsche's idea of the "Übermensch" (superhuman) is not as remote or mystical as one might think. It is a simple question one asks when one realizes one's own patterns, one's own habits, one's own sediments:
"Can I be a better version of myself?"
According to Nietzsche, the real battle of man is not outside; it is within himself with his pessimistic side, his inertia, his sediments, the shadow of his old habits.
This battle is not a destruction; it is a call to re-write.
Just as an aged block of code can become useless, so too can aged beliefs, automatic behaviors, unnecessary fears in one's mind render one useless.
Nietzsche's teaching of "self-transcendence" says exactly this:
You cannot create a new you without breaking the old you.
It is an update of character.
An inner refactor.
But not by force; by courage.
Stoacılık: Regular Internal Accounting is Possible with Daily Rewriting
What the Stoacists teach is actually a kind of sustainability practice.
Small internal adjustments made every day...
In the evening, the Stoacists would ask themselves these three questions... (3*)
- What did I do right today?
- What can I improve?
- What do I intend not to repeat
This is literally like looking at the code written in the system to understand the technical debt. But that code is inside ourselves.
What is the biggest enemy of good software?
Letting inconsistent code "accumulate", code that will break if touched.
The Stoics say the same thing about human beings...
If you don't do regular internal accounting, emotional debts accumulate. Accumulated debts lock your self up over time.
Stoicism is not a punitive discipline.
It is a gentle but firm system of internal maintenance.
A little cleaning every day...
A little tidying up every day...
A little awareness every day...
As in software:
Small code updates prevent big crashes.
Wisdom Traditions: Purification / Lightening, Trimming the Old Code
In many of the world's wisdom traditions, from Taoism to Sufism, from Buddhism to Stoicism, the same message appears again and again.
Unless one lets go of unnecessary burdens, one cannot move forward. (4*)
In these traditions, the concepts of "purification", "cleansing", "lightening" are often metaphorical, but surprisingly consistent with current psychology and neuroscience.
Over time, one is surrounded by unnecessary beliefs, fears taught by others, strategies that no longer work, automatic reactions, shadows of old hurts.
This is exactly like legacy code.
Then it worked, but today it reduces efficiency, slows down the system, makes it error-prone.
Wisdom traditions say:
To move forward, you must first lighten up.
To create a new you, you must file away the excess of the old code.
We can think of this as an emotional version cleansing, a mental restructuring and a holistic refactor.
Scientific Perspective
Brain's Perception of "Burden"
Technical debt accumulates in software, the system becomes sluggish and performance begins to decline.
The human brain works in a similar way...
Accumulated stress, deferred emotions and unprocessed experiences build up a mental debt. And just like a project reaching the point of collapse, your brain can eventually reach a similar point.
Science tells us:
As mental load increases, the brain's processing power drops dramatically.
Cumulative Stress, It Causes a Performance Drop in the System
The small stresses of everyday life (arguing with someone, suppressing an emotion, postponing a responsibility, experiencing indecision, guilt, tiny disappointments) accumulate in our brain's memory. Over time, these seemingly innocent bits of stress build up a cumulative load.
The brain perceives this as an "increase in load".
When the load increases, we become distracted, our decision-making slows down, our creativity decreases, our motivation dampens, and our emotional resilience decreases.
This is performance degradation in a literal sense. Just like a block of code that makes the processor run at 100%.
The system works, but it is inefficient, noisy, error-prone.
Emotional Accumulation, Amygdala Hyperactivation Can Lead to Code Overlap
The amygdala, the center of our brain that manages our perception of threat, As unprocessed emotions accumulate, they become hyperactive, they become very talkative, they start to behave as if there is a constant danger. (5*)
Every time we say, "I'll deal with this emotion later, I shouldn't dwell on it now, I shouldn't feel this emotion," we are actually not suppressing the emotion, we are only stimulating it.
And the hoarded emotion starts to trigger the brain's threat circuits constantly.
As a result, our amygdala becomes hyper-awake, constantly on guard, and our prefrontal cortex (logic, planning, willpower) becomes inactive. We can liken this to code "conflicts" in the system.
What kind of problems does this neurobiological conflict cause in daily life?
- We suddenly snap
- We have trouble focusing
- We make the same mistake over and over again
- We show unnecessary irritability
- We can't make decisions even on simple things
- We feel extremely tired
It is like a race condition in software.
Signals collide, the flow is disrupted, the system fails.
Emotions that are suppressed but not processed accumulate, the accumulated emotions raise the tone of the amygdala, as the tone of the amygdala rises, the signal "life is in danger" is born.
In fact there is no danger.
But the system thinks there is.
Re-engagement-of-the-prefrontal-cortex-with-relaxation/regulation
We call it "calming down", but in neuroscience it is much more specific:
Top-down regulation. (6*)
In other words, the prefrontal cortex takes the wheel again.
So what do we do to experience this relaxation, how can we give the wheel back to the prefrontal cortex?
- When we take deep breaths
- When we name an emotion
- When we take a short break
- When we openly accept something by saying "yes, this is happening"
- When we lighten our inner burden
- When we have a small moment of mindfulness to clear our mind
These small micro-actions allow the prefrontal cortex, the brain's executive, to become active again.
What happens:
- Our thoughts become clearer
- Our emotions are regulated,
- Our will comes back,
- Our behavior changes positively
- Our capacity to "bug fix" (solve a problem in code) increases.
When we achieve this, neuroplasticity kicks in and our brain starts to open new pathways.
This is very similar to the performance boost after refactor in software.
The system breathes easier.
Processor load drops.
Code flow picks up.
It's as if the bloated files are cleared.
Real Problems and Solutions
Problem
Technical Debt in Our Lives
In life, just like in software projects, There are technical debts that we accumulate without realizing it. Over time, the little things we say "let's leave it like this for now" grow, causing errors, blockages and performance decreases in our internal system. Most of these debts do not collapse immediately; on the contrary, they accumulate and accumulate silently and only become visible at a critical moment when we ask "why am I like this?"
True technical debt is not "bad code"; it is delayed confrontations. It's the same in our lives.
I can think of the following:
Conversations we postponed
Conversations that we know somewhere inside that we need to talk about, but we keep saying "now is not the time" and putting them on the shelf... These are just like debug logs written into a function as temporary; over time they pollute the system and block our communication channels.
Past issues that we have never faced
Every issue that we have not resolved consumes our processor like a secret task running in the background of our memory. It looks like a closed tab, but it's already tiring the processor and we don't realize it.
The legacy behaviors we leave behind, saying "Let them accept me like this"
They may have been useful to us at one time; maybe even defense mechanisms that helped us survive. But the moment we realize that they are no longer relevant is the moment we start to create a new self. Like "legacy code"... We avoid touching it because it seems both troublesome and risky. But these are often the remnants that limit our growth the most.
Responsibilities that we overload ourselves with but don't optimize
Our system has a certain capacity. We keep adding new features and forget to refactor. Then what happens? Loss of performance, delays, endless fatigue. In fact, the problem is fundamentally not capacity; it is a poorly designed architecture.
Hidden bugs left in the system by past failures
They are not visible from the outside, because they usually work silently. But when the trigger comes, our behavior changes in an instant. Even we are surprised "why did I react like that?". Because the bug has not been fixed, only other code has been added on top of it. The problem is still there and will remain there unless we fix it.
Other than that, I have listed the similar concepts I see both in software and in life as follows:
Hard-coded solutions / Rigid beliefs
In the code we write, sometimes instead of assigning some values to a variable and using that variable, we prefer to write it quickly by hand, but this is not the right behavior because when the environment changes, the hard code does not change, leaving us open to trouble.
These seem like quick solutions at the time. So it is with rigid and fixed beliefs in life. We say, "I believe this way because it has always been this way," but life changes, circumstances change. The hard-coded approach destroys the flexibility of the system.
Spaghetti code / Emotional complexity
Spaghetti code is a pile of codes, where the codes get mixed up, where it is not clear where it starts and where it goes, and the more you try to decipher it, the more it gets tangled. Like a plate of tangled spaghetti.
Life can be like that sometimes. One emotion is connected to another, that emotion is connected to another trauma, that trauma is connected to an old story... It would take us hours to figure out what the problem is. The solution is the same in both code and life. Simplify code and life, resolve dependencies, reorganize.
Insufficient documentation - Confused thoughts
In software, we can think of documentation as a user manual that explains how the code works. When it is insufficient, everyone does the same thing in different ways according to their own minds, and this causes us to struggle with inextricable code over time.
When we do not write clearly what we feel, what we want, why we do what we do, our confusion increases in life. Just as a newcomer to an undocumented project might say, "What was that doing?", we become alienated from our own inner world.
Dead code / Habits that no longer work
Dead code is the unnecessary pieces of code that no one notices, that no longer do anything but continue to stay in the system. It's like the stuff in the house that we haven't used for years but we can't bear to throw away.
Similarly, habits that are no longer useful are still inside us, taking up space, perhaps overlapping with new behaviors, but they no longer have a function. Like routines that we have been carrying around as "habits" for years, but which in fact do not contribute to our lives.
Workaround / Short-term escapes
Short-term escapes are famous in software and in life. When there's a bug in the software, sometimes we don't go to the root cause of the bug and look for a quick fix, just to make a quick fix for that bug. Usually this solves the problem but leads to new and more difficult problems.
We think we have solved a problem but in reality we have only delayed it. Workarounds are another version of the everyday behavior of "getting by": "I'll think about it later", "Let's leave it for now", "No need to break it"...
But in the long run they create huge debt.
Solution Suggestions
Life Refactor
Technical debt by its very nature tells us something...
Problems build up, but solutions come with small and regular touches.
Life works on the same principle.
The following steps show the psychological equivalents of concepts we use over and over again in software. A sort of guide to optimizing our internal system.
"Code Review", meaning "Self-observation"
What we do when reviewing a code is actually very simple:
We find the error not to look for blame, but to make the system healthier.
A short internal "code review" at the end of the day works in the same way:
What emotion was triggered in me today? Anger, anxiety, resentment... It's in the log.
Which behavior cycle did I automatically enter?
Does it work like a function with the same trigger every day?
Why did I do what?
But not with guilt.
Data...
Just being able to say "This happened" activates the prefrontal cortex.
The life-applicable version of code review is: observe ourselves without judgment.
That is, not to blame the system, but to understand the system.
Refactor / Rewriting Life with Small Steps
Not big transformations; micro-adjustments...
Refactor is never a complete destruction.
The idea of "big change" is nice, but it triggers the brain's perception of threat.
That's why the most effective method, both in software and in life, is:
1 tiny fix every day.
- Choosing a word differently
- Delaying a reaction by half a second
- Leaving a breath pause
- Moving a habit by 5%, not 100%
The brain doesn't like big revolutions, but falls in love with micro changes.
Because they are safe, sustainable and trigger neuroplasticity.
Change doesn't happen through revolution, but through repetition of small improvements.
Deleting dead code and unnecessary habits
Learning to break habits that no longer work...
How is dead code defined in software?
Pieces of code that no longer work, that are useless but occupy space in the system...
The equivalent of this in life is very clear:
- Defense mechanisms that we don't use but still have
- Automatic reactions that worked for us as children but make us nervous in adulthood
- Habits that once gave us confidence but now restrict us
- Habits that we carry around as "I've always been like this.I've always been this way."
When we don't delete the dead code, we have hidden conflicts in the system.
When we delete it?"
We become lighter.
The life version of this step starts with a very simple maxim:
"Does this behavior still work for us?"
If the answer is "no", it is time to delete that code in the next iteration.
Modular Thinking
Breaking problems into small pieces and prioritizing them...
One of the golden rules of software:
If a module is too complex, break it into small pieces so you can manage it.
Much of what is complex in life is because it is treated as a single block.
When we break the problem down into modules, we can create modules in our minds like this:
- "Relationships module"
- "Self-esteem module"
- "Work habits module"
- "Emotional triggers module"
We can break each module into smaller tasks...
Trying to organize them all at once can lead to a system crash.
We can take the most buggy module first and start from there.
Sothere is no need to try to fix everything at once.
We can start by stabilizing the most painful part first.
Test, Observe, Repeat
To see every behavior as an A/B test...
Let's say we change a behavior.
With the reflex of a software developer, we can do the following:
Test.
Observe.
Rework.
Let's say we give a new reaction, we can immediately see how the system responds... Let's say we alleviate a habit by 10%, we can see if our energy increases as a result.
Let's say we set a limit, we can see if the relevant module gives a conflict or is stable.
When we change a perspective, we can see if the error logs decrease...
This cycle is exactly the same as behavioral iteration, one of the most effective principles of change in psychology.
In software language, life is like a CI/CD pipeline. We are like a project that receives micro-updates every day.
What I want to say in all these steps is:
Life gets clogged if not refactored.
It gets beautiful if refactored.
No need to wait until it crashes.
The internal system responds big to small touches.
Conclusion and Message to the Reader
Just as even written programs succumb to time, human beings also succumb to time with the turmoil of life, fears, sorrows, traumas, and they accumulate emotional and mental debts like technical debts.
Solutions in software and in life are similar, writing everything from scratch at once is difficult and laborious, but making small correction cycles a habit will help us move both our software and our lives to a better point.
From this point of view, refactoring both our software and our lives is not to erase our past; it is to make our future more readable.
As always, I have not forgotten your question.
What module in your life is waiting to be refactored? Or let me put it this way, which small adjustment can turn on the light that will make everything better?
Next week, we will talk about an approach that was born in the software world but actually touches the very heart of life.
This approach, called Agile, suggests taking small steps instead of being crushed under the weight of big plans; learning quickly and moving on instead of seeing it as the end of the world when you make a mistake.
In a sense, we can say 'living life sprint by sprint': small trials, small corrections, small gains...
And perhaps life is more flexible, lighter, more sustainable when lived in this way.
So in the next post we will look at:
Is life really a giant project to be solved in one go, or is it a process to be continuously improved with small steps?
Till then, stay refactor and love.
Sources
- Abraham Maslow - "The Psychology of Science"
- Friedrich Nietzsche - "Thus Spoke Zarathustra" & "Beyond Good and Evil"
- Marcus Aurelius - "Meditations" (Thoughts to Myself)
- Pema Chödrön - When Everything Falls Apart
- Joseph LeDoux - "The Emotional Brain"
- Daniel J. Siegel - "Mindsight"
