Shoshin: The Zen Concept Steve Jobs Used to Innovate (And Why Your Experience Might Be Limiting You)
After 10 years of programming, I discovered my experience was my biggest obstacle.
I was reviewing code from a junior on my team. The solution he proposed was "wrong" according to my years of experience. I explained the "correct" way to do it.
Two weeks later, we discovered his approach was 3x faster than mine.
What I struggled to accept: it wasn't a technical knowledge problem. It was a mindset problem.
What is Shoshin (And Why Steve Jobs Practiced It)
Shoshin is a Zen Buddhism concept meaning "beginner's mind."
The core idea: when you're a beginner, your mind is open to all possibilities. When you're an expert, your mind is closed to most.
Steve Jobs studied Zen for years in Japan and applied this concept religiously at Apple. In his own words: "In the beginner's mind there are many possibilities, in the expert's mind there are few."
It's no coincidence that Apple revolutionized industries where established experts already existed:
→ The music industry already had "experts" who knew how to sell music → The mobile industry already had "experts" who knew how to make phones → The tablet industry already had "experts" who knew what worked
Jobs knew nothing about these industries. And that was his advantage.
The Experience Trap
Here's the problem with becoming an expert:
Each year of experience gives you mental patterns. "This works. That doesn't work."
These patterns are useful. They make you efficient. You avoid mistakes you've already made.
But they also close doors.
When you see a problem, your brain automatically classifies it: "Ah, this is like that time in 2019. I know how to solve it."
And you stop seeing other possible solutions.
Psychologists call it "functional fixedness": when you can only see traditional uses of something because your experience has taught you "the right way."
My Real Example
I was building a local directory of plumbers. My experience told me:
→ You need a complex database → You need user authentication → You need a CMS to manage content → You need contact forms with backend
"That's how directories are built. I've done it 10 times."
But I forced myself to ask: "What would I do if I'd never built a directory?"
The answer: static generated pages. No database. No authentication. No backend.
Result: the site was built in days instead of weeks. Hosting costs are minimal. Performance is superior.
My experience would have led me to overcomplicate.
How to Practice Shoshin as a Builder
1. Ask "Why?" Three Times
When you're about to do something "because it's always done this way":
→ Why do I need this? → Why is it done this way? → Why aren't there alternatives?
Real example:
Me: I need Redux for global state. Why?: Because it's what I've always used. Why no alternatives?: Because... wait, maybe Context API is enough for this project.
Result: fewer dependencies, less complexity.
2. Actively Seek Beginner Perspectives
Read junior developers' code. Read Stack Overflow questions from new people.
Not to correct. To understand what they assume is possible.
Beginners ask questions experts stopped asking years ago:
→ "Why can't I just...?" → "What if we tried...?" → "Does it have to be so complicated?"
These questions often reveal unnecessary complexity.
3. Build Something Outside Your Domain
Every 6 months, build something in an area where you're a beginner.
If you're a backend developer, build a mobile app. If you do web, experiment with hardware. If you code, try design.
Not to become an expert. To remember what not knowing feels like.
That discomfort of being a beginner is exactly what you need to keep alive.
4. Challenge Your Own Rules
Make a list of your development principles:
→ "I always use TypeScript" → "I never deploy without tests" → "The database must be normalized"
Now ask yourself: when was the last time you questioned this?
I'm not saying break all your rules. I'm saying examine them.
Sometimes you'll discover you were following a rule out of inertia, not reason.
The Real Cost of Not Practicing Shoshin
It's not just that you miss innovation opportunities.
It's that you become obsolete faster.
The tech industry changes constantly. The tools you mastered 3 years ago are no longer optimal.
If your identity is tied to "being an expert in X," every change is a threat.
But if your identity is "being someone who constantly learns," every change is an opportunity.
Jobs understood this. That's why Apple could reinvent itself multiple times.
The Expert-Beginner Paradox
Here's the uncomfortable truth:
The best builders I know are experts who act like beginners.
They have decades of experience, but the curiosity of someone in their first year.
They know what works, but constantly ask "what if...?"
They master their stack, but regularly experiment with alternatives.
It's not choosing between experience or beginner's mind.
It's cultivating both simultaneously.
Your Shoshin Exercise for This Week
Choose a project you're working on right now.
Ask yourself these questions as if you'd never built anything before:
→ If I had to build this in one day, what would I eliminate? → If I didn't know "best practices," what would I do differently? → If it were my first time, which parts would seem unnecessarily complex?
Write down the answers.
You don't have to change anything yet. Just observe what comes up.
Sometimes the best innovation comes from asking yourself: "What if my experience was wrong?"
---
The lesson that took me 10 years to learn:
Your experience is valuable. But only if you keep it flexible.
The moment you stop questioning what you "know" is the moment you stop growing.
Shoshin isn't about ignoring your experience. It's about keeping it open to revision.
As Jobs said: "Stay hungry. Stay foolish."
Translated freely: maintain a beginner's mind, even when you're an expert.
What's one "truth" in your stack that you haven't questioned in a while? Reply and let's see if it's still actually true.
