Don't Fool Yourself: On Knowing When
TL;DR
Every framework is a fossilized solution to someone else's problem. The moment you stop asking whose problem it was, you stop being a practitioner and start being a priest. The tool is never the problem. The thinking before reaching for it is. Know when. That is the whole skill.
Here is a recurring theme I keep seeing everywhere, and it bothers me more than it probably should.
Someone learns a thing. A tool, a framework, a philosophy. They get excited. They start using it. And then somewhere along the way, without noticing, they stop using it and start performing it.
The tool becomes a costume.
And the worst part? They never notice. Because the costume looks exactly like the real thing.
And I say this as someone who caught himself masturbating on this and doing exactly this for years. Reading the books, collecting the frameworks, feeling the dopamine hit of understanding a new concept.
And then one day realizing the dopamine was the point. Not the understanding. Not the application. Just the feeling of acquiring something that looked like expertise.
Post-nut clarity hits and the ego wears off: the learning became the costume.
I got high on the theory, patterns, and feeling like I understood something most people did not.
And by the time the high wore off, I was standing in front of a codebase full of abstractions that solved nothing, wondering what the hell happened because I just became a monstrous obfuscator.
That is not a metaphor. That is a thing I actually did. More than once.
Feynman called this out in his 1974 Caltech commencement address. Not the part about the South Seas islanders building bamboo antennas. The part that stuck with me is the Millikan story.
Robert Millikan measured the charge of the electron, and got a number that was slightly wrong. Not wildly wrong. Just off by a small amount.
But because he was Millikan, because he was the authority, every experimenter who came after him and got a result too far from his number assumed they had made a mistake.
So they went hunting for errors in their own work until they found one.
And when their numbers landed close to Millikan's, they stopped looking. They moved on. Published.
The correct value drifted upward over decades, inching closer to reality one nervous paper at a time, because nobody wanted to be the person who said the important guy got it wrong.
That is not a science problem. That is a people problem.
And it is everywhere.
The experimenters were not bad scientists. They were scared. Contradicting Millikan did not just mean being wrong about a number. It meant being the person who thought they knew better than one of the most respected physicists alive.
That is a socially expensive place to stand.
So they flinched. They looked for errors in themselves before they looked for errors in the authority.
Most people would have done the same thing. Most people do, every day, in every field.
I have done it more times than I would like to admit.
The pattern, once you see it, is almost comically consistent:
- Copy the visible ritual
- Skip the invisible understanding
- Wonder why it does not work
Robert Cialdini called this social proof. The tendency to look at what others are doing as a signal for what is correct, particularly under conditions of uncertainty. In low stakes situations, it is a reasonable heuristic. In technical decision making, it is how teams end up with architecture they cannot justify and do not need.
I see this in the tech field a lot.
Just writing that sentence I can feel the pattern recognition kicking in. I have been mentally cataloguing this for months now and it keeps showing up in the same shape every time.
The moment a famous company or a famous person endorses a practice, something shifts. The practice stops being a tool anyone evaluates. It becomes the thing you do. And questioning it means you are the one who does not get it.
Uncle Bob says Clean Architecture, so codebases get wrapped in layers of abstractions nobody asked for, solving problems that do not exist yet and may never exist.
Did anyone ask what problem it solves? No.
Did anyone check whether they actually have that problem? No.
They read the book. That was enough.
Martin Fowler writes about microservices, so five person startups split monoliths that were working fine into seventeen services and spend the next year debugging distributed systems instead of building the actual product.
Because microservices are what serious companies use. That is the whole thought. That is all of it. That is the entire engineering rationale. It is not an engineering rationale. It is social proof with a technical costume on.
The GOF patterns get forced into every problem because someone read the book and thought that was what real engineering looked like. So now there is a factory that produces a builder that configures a strategy, and the whole thing does what a single function could have done.
But it looks like engineering. And looking like engineering is apparently enough.
Kubernetes gets adopted because Netflix uses it. Nobody asks whether they are Netflix. They are not. They have twelve users and a PostgreSQL database.
DDD sounds serious, so teams spend weeks in expensive domain modeling workshops. They come out with elaborate diagrams and a shared vocabulary that nobody outside the room will ever use.
They do not create anything.
And the uncomfortable truth underneath all of it is this. Most of the time, the team adopting these things has zero users. No scale problem. No distributed systems problem. No domain complexity problem.
Reality check. Zero users.
Just a team that read the right books and wanted to feel like they were doing serious work.
I know this because I have been that person. I sat there high on the dopamine of having the right vocabulary and the right diagrams, and shipped nothing.
But the upside? You learn a lot. Genuinely.
That is not nothing. Working through Clean Architecture teaches something real about separation of concerns. Building microservices teaches something real about system boundaries and failure modes. The learning is legitimate.
But there is a difference between learning from a tool and pretending you need it.
One makes you better. The other just makes the codebase worse.
That is why I love these concepts. I just try to be honest now about when I am using them to solve a problem and when I am using them to chase the dopamine of feeling like I know what I am doing.
The one question that actually matters never gets asked.
What specific problem does this solve, and do we actually have that problem?
That question is free. It costs nothing. It takes ten seconds. And it almost never gets asked, because asking it means possibly being the person who does not get it.
So everyone nods along, adopts the thing, and wonders six months later why everything is a mess.
I see it in political arguments too. People cargo cult the form of evidence (especially in the fucking Philippine political landscape, I won't talk about that shit but yeah). A statistic, a citation, a chart. The ritual of looking informed without doing any of the work to verify whether the evidence actually supports the claim.
The chart is not the argument. The citation is not the proof.
But it looks like both. And looking is usually enough.
Nobody checks. Checking might mean changing your mind. And changing your mind feels like losing.
I see it in journaling too. Filling pages with feelings and frustrations, closing the notebook, moving on. That feels like the work.
It is not.
That is step one of three. And most people never get to step two.
The actual loop is Clarify, Assess, Act. Write to see clearly. Interrogate what the writing is actually surfacing. Then act on it.
Skip the last two steps and journaling is just a very expensive way to feel things and stay exactly where you are.
I have caught myself doing all of this. Every single one.
Learning a framework, stoicism, GTD, whatever, and going through the motions without ever stopping to check whether the motions are producing anything measurable.
Journaling because that is what thoughtful people do. Running weekly reviews because the system prescribes it. Never once asking whether any of it is producing clearer thinking or just the feeling of clearer thinking.
Those are not the same thing. And the fact that they feel identical is exactly the problem.
I have built a lot of very convincing bamboo antennas. I called them systems, frameworks, and actual theoretical concepts.
I want to be honest about something, because I know how this reads.
I love these concepts. I genuinely do.
Clean Architecture, TDD, BDD, ATDD, DDD, FDD, whatever DDDDDDD (XD), microservices, design patterns. All of it.
These things exist for a reason. Smart people with hard, specific, well understood problems built these tools because they needed them.
The GOF were not writing fiction. Martin Fowler was not guessing. Uncle Bob was solving something real.
They created a real solution to real problems that were biting their ass for a long time.
The problem was never the tools.
The problem is reaching for them without understanding the problem they were built to solve, and then acting confused when the solution does not fit.
Remember: a tool is only a tool when you understand its domain of applicability.
The moment that understanding disappears, the tool stops being a solution and starts being a ritual.
Not everything is a nail just because you are holding a hammer.
And no, I am not writing this to be contrarian. This is not a "best practices are overrated" take.
This is an honest reflection. Mostly me just trying to write down what I have been observing in my own work before I forget it again.
Because for years, every time I got excited about a new idea, a new pattern, a new framework, something quietly went wrong in my own work.
Accidental complexity and essential complexity started bleeding into each other. And I could not always tell which was which.
Frederick Brooks made this distinction precise in No Silver Bullet, back in 1986. Essential complexity is intrinsic to the problem domain. It cannot be abstracted away because it is a direct consequence of what the problem actually is.
Accidental complexity, by contrast, is introduced by the tools, processes, and structures chosen to solve the problem. It is not inherent. It is a byproduct of approach.
The critical insight Brooks offers, and the one that took me embarrassingly long to internalize, is that most of the grand promises in software engineering, the silver bullets, address accidental complexity.
They make the incidental parts of the work easier. But they do not touch essential complexity, because nothing can. The hard part stays hard.
Noting this down because I keep having to relearn it. When a framework gets adopted without understanding why, complexity does not get reduced. It gets moved.
Essential complexity, which is hard but honest, gets buried under accidental complexity that feels like progress because it is so busy.
Months spent refactoring toward a Clean Architecture ideal while the real problem, that nobody actually understands the business logic, goes untouched.
The architecture looks great. The layers are clean. The code is organized.
And nobody can tell you what the software actually does.
Split into microservices, spend more time on infrastructure orchestration than on feature delivery. Green dots on the Kubernetes dashboard. Everything must be fine.
The tool became the problem. And it is hard to notice because the tool looks so much like progress.
That is what I kept catching myself doing. Not ignoring good ideas. Worshipping them.
Worship does not leave room for questions.
Learning this stuff is hard.
Nobody hands you Clean Architecture and says use this, but only when the codebase reaches a certain size, the team has a certain shape, and the domain boundaries are stable enough to justify the abstraction cost.
Nobody hands you stoicism and says this framework was developed for a specific kind of suffering and works better for grief than for ambition.
It gets figured out the slow way. By reading, by trying, by embarrassing moments in pull requests or conversations or journal entries that went nowhere.
But unlearning is harder (Dogma, something that I often struggle with, and often slip up. Even I tell my mentees to avoid being too dogmatic on whatever information they get from their mentors).
Because unlearning means admitting that the thing that took months to understand, the thing that got defended, the thing that quietly became part of an identity, might not belong here.
Might not belong now.
Might never have belonged at all.
And that is not just admitting the tool was wrong.
That is admitting the reasoning that reached for it was not careful enough.
And then there is the third thing. The thing that rarely gets discussed with any precision.
Knowing when.
Knowing when to reach for the pattern and when to let the problem breathe.
Knowing when the framework is reducing essential complexity and when it is generating accidental complexity while looking like it does the former.
Knowing when Feynman is the answer and when Feynman is just another authority to hide behind.
That is not knowledge. That is not experience alone. That is judgment. And judgment is the thing that formal education in software engineering is worst at producing, because it cannot be taught directly. It can only be developed through repeated, honest contact with real problems and real consequences.
It comes from sitting with a problem long enough to actually see it.
Not long enough to categorize it. Not long enough to pattern match it against something familiar.
Long enough to see it for what it actually is.
That is the skill. That is the whole skill.
Everything else is just a very convincing bamboo antenna.
Feynman's fix is deceptively simple. "The first principle is that you must not fool yourself, and you are the easiest person to fool."
That is it. That is the whole thing.
Not a method.
Not a framework.
Just the willingness to ask, at every step, whether there is actual understanding of why something is being done.
Or whether it is just a very convincing bamboo antenna, waiting for planes that will never come.
The irony I cannot escape is this.
Someone will read this, nod along, screenshot the Feynman quote, add "don't fool yourself" to a morning routine, and never once ask whether they are actually doing it.
The ritual will replace the understanding. The bamboo antenna will go up again, just with a different label on it.
That is how strong the pull is. Even the warning against the trap becomes the trap.
I keep forgetting to ask.
So here is what I actually try to ask now, before reaching for anything. Writing this down mostly so I can come back to it the next time I get high on a new framework.
What is the problem? Not the category of problem. The actual, specific, present-tense problem, stated precisely enough that someone else could verify whether it exists.
Do I have empirical evidence that this problem exists at the scale that warrants this solution, or am I anticipating a problem that may never materialize?
Has this tool demonstrably solved this specific class of problem for teams or individuals in a situation structurally similar to mine, or just for teams in situations that sound similar on the surface?
What is the adoption cost, what is the reversal cost if the assumption turns out to be wrong, and is the expected value of adopting it now positive given those costs?
If the answers are vague, the tool is probably wrong for right now. Maybe right for later. But not now.
No formula. No flowchart. Just four honest questions asked before reaching for the next thing.
My message to my future self is this:
The most important thing is not knowing more frameworks, reading more books, or following more brilliant people.
It is to stop, before reaching for the next tool, and ask whether the problem in front of me is actually understood with enough precision to justify the solution being considered.
Not the problem the book described. Not the problem Netflix had.
The one that is actually here, right now, with its specific constraints and its specific context and its specific costs.
Understand that first. Then decide.
The planes will not come just because the antenna looks convincing. They never did.