The last couple of years have been weird for software engineering.
Layoffs everywhere.
Teams getting smaller.
Expectations somehow getting bigger.
And in the middle of all that, we kept doing the same thing:
Adding more stuff.
More tools. More layers. More abstractions. More complexity.
That’s why I keep coming back to SpaceX.
Not because of rockets.
Because of how they think.
This Isn’t About Rockets
When people talk about SpaceX, they talk about launches, engines, Mars.
But the interesting part is not what they build.
It’s how they build it.
There’s a simple idea behind a lot of their decisions:
If you can remove a part, remove it.
Not optimize it.
Not rewrite it.
Not scale it.
Remove it.
Less parts means:
- Less things that can fail
- Less cost
- Faster iteration
It sounds obvious. But it’s not how we build software.
We Went in the Opposite Direction
Somewhere along the way, software engineering became obsessed with adding layers.
We convinced ourselves that:
- More abstraction = better design
- More services = more scalable
- More patterns = more “senior”
So now we have systems where:
- One request touches 5 services
- A simple feature needs coordination across multiple teams
- Debugging feels like detective work
And the worst part?
A lot of that complexity is self-inflicted.
The Layoffs Exposed Everything
Before 2022, you could get away with it.
Big teams.
Big budgets.
Plenty of time to maintain overengineered systems.
Then the layoffs hit.
Suddenly:
- Half the team is gone
- The system is still just as complex
- And now fewer people understand it
That’s when things start breaking.
Deployments get scary.
On-call becomes exhausting.
Simple changes take forever.
Not because people got worse.
Because the systems were never simple enough to survive pressure.
Complexity Is Not Free
Every extra layer you add has a cost.
Not just in performance.
In understanding.
Every:
- Service
- Dependency
- Abstraction
Adds cognitive load.
And that’s the part nobody tracks.
At some point:
- No one understands the full system
- Bugs become unpredictable
- Fixes create new problems
You don’t have control anymore.
You’re just reacting.
SpaceX’s Real Advantage
The real lesson from SpaceX is not innovation.
It’s discipline.
They question everything:
- Do we actually need this part?
- Can we simplify this design?
- What happens if we remove this entirely?
In software, we rarely do that.
We think ahead too much:
- “Let’s make it scalable from day one”
- “We might need this later”
- “Let’s add a layer just in case”
So we build for imaginary problems…
…and pay real costs.
What Actually Matters Right Now
The industry is loud right now.
AI everywhere.
New tools every week.
New “best practices” every month.
But none of that fixes a system that’s too complex.
You can plug the latest model into your stack…
…and it will still be a mess if the foundation is bad.
If you want to actually improve as an engineer right now, focus on:
- Making systems easier to understand
- Reducing dependencies
- Removing unnecessary abstractions
- Building things that are easy to change
Not just adding new tools.
Complexity Is a Career Trap
There’s something subtle happening.
A lot of developers think complexity equals seniority.
Like if the system is complicated, it must be “advanced”.
But the best engineers I’ve worked with do the opposite.
They simplify.
They:
- Remove code
- Challenge unnecessary decisions
- Push for clarity
They don’t build impressive systems.
They build systems that don’t fall apart.
What I’m Trying to Do Now
I still explore new tools. I still like new tech.
But my default changed.
Now I ask:
- Can I solve this without adding anything new?
- Can I remove something instead?
- Will this make the system easier… or harder?
If it makes things more complex without a clear reason, I skip it.
No matter how trendy it is.
Final Thoughts
SpaceX didn’t win by adding more.
They won by removing what didn’t matter.
And right now, that mindset feels more relevant than ever.
Because the systems that survive pressure aren’t the most advanced ones.
They’re the ones that are simple enough to actually work.
What about you?
Are you building systems…
or slowly making them harder to understand?
Top comments (0)