The Gaslighting of Software Engineering

A Speech on Substance, Status, and Liberation

I. The Question

Have you ever had a colleague—or a person in your life—who, when you asked a simple question or pointed out that a system was unnecessarily complex, made you feel like you were the problem?

Not the system. Not the complexity. You.

"You just don't understand." "This is how we've always done it." "It's more complicated than you think." "Maybe you're not senior enough to see the bigger picture."

This is gaslighting.

And it is everywhere in software engineering.

II. The Example

I once told a colleague that I hated working with Webpack. You waste all day fighting it to set it up the way you want. You almost can't do it without debugging Webpack itself and understanding how the config is being processed.

To this they said: "This is because you don't understand it."

Or: "No, I don't think it is hard at all. I never had this problem."

This is a lie. Webpack is notoriously picky about tools working together. CSS, TypeScript, PostCSS—there will be friction. It is unavoidable. You will have to debug it.

But my colleague did not admit this. They gaslit me. They made me feel like the problem was me. Like I was not smart enough. Like I was not experienced enough. Like I was not serious enough.

III. Another Example

It is not just build tools. It is the frameworks themselves.

React started as a declarative view library. It promised simplicity. It promised "just render the UI."

But today, React requires careful understanding of lifecycle, hooks, dependencies, memoization, and reconciliation. Expertise is not measured in how clearly and cleanly you build. Expertise is measured in how well you manage the internals of React.

This is absolute nonsense.

React completely violated common sense. Instead of being a dumb declarative view library with the ability to manage reactive state and various side effects externally, it baked everything inside its library.

The state management is internal. The side effects are internal. The lifecycle is internal. Everything is internal.

You cannot use React as a simple view layer. You must understand React itself. You must master its internals. You must fight its abstractions.

And when you say "this is unnecessarily complex," they say: "You just don't understand React."

IV. The Pattern

This pattern repeats everywhere.

You say: "This system is unnecessarily complex."
They say: "You just don't understand the bigger picture."
You say: "Why do we need seven layers of abstraction?"
They say: "This is how we maintain separation of concerns."
You say: "Can we simplify this?"
They say: "It's more complicated than you think."
You say: "React should be a dumb view layer."
They say: "You just don't understand the React way."

Each time, the message is the same: Your confusion is your fault. Your desire for clarity is a weakness. Your intuition that something is wrong is a sign that you don't belong.

V. The Toxicity

I have experienced this in so many flavors.

The backend engineer who looks down on frontend work as "lesser."
The architect who dismisses your simplification as "naive."
The senior developer who uses obscure jargon to prove their superiority.
The manager who asks why you can't "just get it done."

Each time, the message is the same.

This toxicity is one of the reasons our industry is so hard.

It is not the code. It is not the deadlines. It is not the complexity.

It is the people who use complexity as a weapon. It is the culture that rewards obscurity over clarity. It is the status trap that makes us compete with each other instead of helping each other.

VI. The Root Problem

But what if I told you that this exact toxicity is the root problem behind software being "hard"?

What if the complexity we fight is not the natural cost of doing real work—but the deliberate creation of a priesthood that wants to keep you out?

When someone says "Webpack is not hard, you just don't understand it," they are not defending Webpack. They are defending their status.

When someone says "React is not complicated, you just don't understand hooks," they are not defending React. They are defending their status.

They have mastered the labyrinth. They have invested years in learning its twists and turns. They have become the expert. And when you say "this is unnecessarily complex," you are threatening their identity.

If Webpack is a bad tool, then their expertise is in a bad tool. If React is a bad abstraction, then their mastery is of a bad abstraction. If the labyrinth is a waste, then they have wasted their time.

They will not admit this. They cannot admit this. Their self-worth is tied to the complexity they have mastered.

VII. What Makes These Systems So Complex?

Webpack is an overcomplicated system that lacks empirical grounding.

It is not grounded in what the user perceives. It is grounded in the machinery of building. It solves a problem that should not exist—the problem of bundling, transpiling, and managing dependencies in a fragmented ecosystem.

React is also overcomplicated. It violates common sense. Instead of being a dumb view layer, it bakes everything inside. Lifecycle, state, side effects—all internal. All requiring mastery of React itself.

Why do we accept this?

Because we are gaslit into believing that this is normal. That this is "real work." That this is what it means to be a serious engineer.

VIII. The Screen Is the Ground

Here is the truth they do not want you to know:

The screen is the ground.

What the user perceives is the only reality that matters. Everything else—the code, the architecture, the database, the infrastructure, the Webpack config, the React internals—exists in service of that screen.

The user does not see your Webpack config. The user does not see your React lifecycle. The user does not see your architecture.

The user sees buttons, text, images, status messages, forms, lists, results.

That is the software. That is the substance. Everything else is machinery.

IX. The Status Trap

The bitter truth is this:

Software developers are constantly flexing on each other.

Backend over frontend.
Systems over applications.
Algorithms over UI.
Infrastructure over user experience.
Complexity over clarity.

We have built a hierarchy of status based on distance from the user. The farther you are from the screen, the more "serious" you are considered.

The Webpack gaslighting is just one example. The React gaslighting is another. The tools are hard. The tools are unnecessarily complex. But admitting that would threaten the status of those who have mastered them.

This is not a technical truth. This is a status game. It is a way of signaling superiority. It is a way of keeping others out.

X. The Liberation

When you understand this, you are free.

You are free from the gaslighting. You are free from the status trap. You are free from the hierarchy.

You know that the screen is the ground. You know that the user's experience is the substance. You know that Webpack is an accident. You know that React is an accident.

You no longer have to pretend that fighting a build tool is "real work." You no longer have to pretend that mastering a framework's internals is "expertise." You no longer have to pretend that complexity is a sign of seriousness.

You know the truth.

XI. The Call to Action

Stop gaslighting yourself.

Stop accepting the hierarchy. Stop believing that complexity is competence. Stop treating the machinery as if it were the substance.

The screen is the software. The screen is the substance. The screen is the ground.

Everything else is machinery. Everything else is support. Everything else is accident.

When someone gaslights you—when they make you feel small for wanting clarity, for wanting simplicity, for wanting to focus on what matters—remember this:

They are not defending Webpack. They are defending their status.

They are not defending React. They are defending their status.

XII. The Truth

The truth is simple:

Software is the communicated idea. It is what the user perceives and understands.

The code is machinery. The frameworks are machinery. The databases are machinery. Webpack is machinery. React is machinery.

The screen is the substance. The user is the ground.

Everything else is an accident.

XIII. Join the Movement

The time for gaslighting is over. The time for clarity has come.

I am building a movement.

It is called Empirical Software.

It says: ground everything in perception. Treat everything else as swappable. Refuse the status trap. Build soft software.

What We Stand For

The screen is the substance. What the user perceives is the only reality that matters.
The user is the ground. Their experience is our guide.
The code is machinery. Frameworks are machinery. Tools are machinery. Everything else is an accident.
Complexity is not competence. Simplicity is not naivety.
Clarity is strength. Obscurity is weakness.

What You Can Do

Join the community. We are building a movement of developers who refuse the gaslighting. Who demand clarity. Who ground everything in perception.

Learn Empirical Software. Study the principles. Apply them to your work. See the difference.

Start building substance. Stop building ghosts. Stop building labyrinths. Build what the user actually sees and experiences.

Challenge the status quo. When someone gaslights you, push back. When someone defends complexity, question it. When someone makes you feel small, remember: they are protecting their status, not the system.

Spread the word. Share this philosophy with your colleagues. With your team. With your company. With the industry.

The Truth Is on Your Side

Stop gaslighting yourself. Stop accepting the hierarchy. Stop building ghosts.

Start building substance. Start building soft software.

The revolution is here. The truth is on your side.

Join us.

https://empiricalsoftware.com/community

This is the way. This is the truth. This is the liberation.