Eight years ago, I was absolutely convinced of one thing:
I was ahead of the curve.
Not just good.
Not just competent.
Elite.
The kind of developer who would casually refactor your entire codebase before lunch and then explain distributed systems over coffee.
There was just one small issue.
My bank account disagreed.
For six straight months, I made exactly $0 from my side projects.
Not “almost something.”
Not “about to launch.”
Not “investor talks in progress.”
Zero.
And somehow, I still thought I was winning.
The “Top Developer” Era
At that time, I was working a regular developer job. Comfortable salary. Stable team. Safe environment.
I had two coworkers who couldn’t have been more different.
Richard.
Quiet. Focused. The kind of guy who solved algorithm problems for fun. If you asked him about time complexity, he didn’t hesitate — he just answered. Calmly. Correctly. No drama.
And then there was Ronald.
We called him “Smart Man”
Because he talked like a retired grandfather who accidentally became a software engineer.
He would say things like:
“Code is not for showing smart. Code is for solving problem.”
At the time, I internally translated that to:
“Okay, boomer.”
I believed I had already passed the “average developer” stage.
I knew JavaScript deeply. (Meaning: I could center a div without crying.)
I had built multiple CRUD apps.
I watched tech conference talks at 1.5x speed and nodded like I fully understood event loops and memory leaks.
I used phrases like:
- “This architecture isn’t scalable.”
- “We should decouple this layer.”
- “Long-term this will create technical debt.”
Meanwhile, I had never shipped a product that more than five people used.
But confidence? Oh, I had that in bulk.
The Six-Month Illusion
Here’s what my daily routine looked like during that period:
6:00 AM — Wake up. Watch a productivity video.
7:00 AM — Coffee. Open laptop like a warrior entering battle.
8:00 PM — Close laptop like a philosopher questioning existence.
I built:
- A task manager app
- A SaaS dashboard template
- A productivity Chrome extension
- A habit tracking app
- A startup landing page generator
Total combined revenue after six months: $0
Total real users: 0
Total installs of my Chrome extension: 5
Three of those installs were my laptop, my desktop, and my friend who clicked it out of pity.
I had analytics dashboards tracking visitors.
Daily active users: 1.
Guess who that was?
Me. Testing in incognito mode.
Still, I kept thinking:
“These ideas are just too advanced for the market.”
Classic delusion.
The Overengineering Disease
Looking back, my biggest problem wasn’t skill.
It was ego-driven engineering.
For a simple to-do app, I built:
- Custom state management
- Complex folder architecture
- Microservices (for 0 users)
- Docker setup
- CI/CD pipeline
- Detailed README
- Architecture diagrams in Figma
For who?
Nobody.
I was building skyscrapers in a desert and wondering why no one was renting apartments.
Meanwhile, Richard was freelancing quietly after work. Small gigs. Real clients. Real money.
Ronald was contributing to open source and writing blog posts about bugs he fixed.
I thought:
“They are playing small. I’m building something big.”
But “big” without validation is just expensive fantasy.
The Lunch That Broke My Ego
One random Tuesday during lunch break, Richard asked casually:
“So… how many users now?”
The tone wasn’t aggressive.
That made it worse.
I replied confidently:
“It’s not about users. It’s about architecture.”
There was a pause.
Ronald smiled.
That slow, grandfather smile.
Then he said:
“If nobody use it, you are architect of empty building.”
Everyone laughed.
I laughed too.
But internally?
Critical damage.
That sentence followed me home.
That night, I opened my analytics again.
0 users.
And for the first time, I didn’t blame marketing.
I asked myself:
“What if I’m not as good as I think?”
That question was the beginning of everything.
The Real Diagnosis
Here’s what I slowly understood over the next few months:
I wasn’t building products.
I was building validation for my ego.
I was:
- Avoiding marketing because “good products sell themselves.”
- Refusing feedback because “people don’t get the vision.”
- Overengineering because it made me feel advanced.
- Ignoring users because talking to them felt uncomfortable.
- Comparing myself only to junior developers.
Confidence without results is just delusion with good posture.
And I had perfect posture.
The Accidental Discovery
One night, around 1:30 AM, I was debugging a nasty async issue.
The classic:
“It works locally but breaks in production.”
After 45 minutes of frustration, I searched online and landed on an article.
It wasn’t from a famous engineer.
It wasn’t polished.
The grammar wasn’t perfect.
But it was honest.
The author explained:
- The exact bug
- Why it happened
- How they misunderstood something
- How they fixed it
- What they learned
No ego.
No “As a 10x engineer…”
Just real struggle.
I clicked the author’s profile.
Then another article.
Then another.
Soon I was reading story after story from developers sharing:
- Failed side projects
- Interview rejections
- Imposter syndrome
- Production disasters
- Salary negotiations
- Burnout
And something inside me shifted.
I felt relief.
Not because I solved the bug.
Because I realized:
Everyone struggles.
Even the ones who look confident.
The Small Shift That Changed Everything
Instead of launching another “revolutionary SaaS,” I tried something different.
I wrote a small article about a bug I fixed.
Nothing groundbreaking.
Just:
- What broke
- Why it broke
- What I misunderstood
- The fix
- The lesson
It took 40 minutes.
It felt vulnerable.
But I published it.
A few days later:
- 300 views
- 12 comments
- 4 developers thanking me
Four.
That was more users than all my apps combined.
So I wrote another one.
Then another.
I started:
- Sharing tiny lessons
- Asking beginner questions publicly
- Admitting when I didn’t know something
- Reading other people’s journeys
- Leaving thoughtful comments
And something strange happened.
Opportunities appeared.
A freelance message.
A collaboration invite.
A recruiter DM.
Someone asking if I could help debug their app.
Nothing explosive.
But real.
The Numbers Don’t Lie
Over the next two years:
- 100+ freelance proposals sent
- 80+ rejections
- 20+ failed side projects
- 3 serious burnout phases
- Countless refactors
- Hundreds of small bugs fixed
- Dozens of uncomfortable feedback conversations
But also:
- Consistent income
- Real clients
- Real users
- Better code
- Better communication
- Less ego
I stopped trying to impress imaginary senior engineers.
I started trying to be useful to real humans.
That changed everything.
What Smart Man Meant
Years later, I finally understood Ronald.
“Code is not for showing smart. Code is for solving problem.”
The market doesn’t reward your confidence.
It rewards value.
Nobody pays for:
- Your clean folder structure
- Your complex architecture diagram
- Your hot take on microservices
- Your GitHub star count
People pay for:
- Problems solved
- Time saved
- Revenue increased
- Headaches removed
It’s simple.
But not easy.
From $0 to Senior Developer
Becoming a senior developer wasn’t about mastering every framework.
It was about:
- Listening more than talking
- Shipping small things consistently
- Asking for feedback early
- Accepting I was wrong
- Teaching others what I learned
- Caring about outcomes, not just code
It wasn’t one breakthrough moment.
It was thousands of small, humbling corrections.
And honestly?
I’m grateful for those six broke months.
They destroyed the version of me that needed to look smart.
And built the version that focuses on being useful.
If You’re in Chapter One
If you’re currently in your:
“I’m a genius but nobody pays me” phase…
Congratulations.
You’re not failing.
You’re learning.
Just don’t stay there too long.
Build small.
Ship fast.
Ask users.
Listen carefully.
Write honestly.
Help others.
And if you have someone like Smart Man in your life…
Listen.
Especially when he smiles before destroying your ego.
That smile might save you six months.
Or maybe six years.
Top comments (107)
I'm struck by the humbling quality of this story, the way your ego got in the way of producing something truly useful. It's like when I was learning to play an instrument, and I'd spend hours trying to recreate some fancy solo, only to realize I'd forgotten the simple melody that made the whole song beautiful in the first place. The conversation with "Smart Man" must have been a turning point, it's amazing how a single conversation can shift our perspective like that, isn't it?
Thank you for this — your analogy about focusing on the fancy solo instead of the core melody really captures the technical mistake I made, because I was over-engineering patterns instead of delivering something actually usable and maintainable. That conversation was definitely a turning point, and now I try to prioritize simplicity, clear architecture, and real user value over clever abstractions
This was a powerful and honest reminder that building real value matters more than chasing complexity or ego. The ‘architect of an empty building’ line really stood out—it perfectly captures the trap many developers face. Sharing lessons publicly and helping others truly accelerates growth.”
The article emphasizes how the author spent months building over-engineered projects with zero users or income, and only began progressing after sharing real experiences and focusing on solving actual problems for people.
Thank you for this thoughtful insight — the “architect of an empty building” idea really highlights the technical trap of over-engineering systems without validating real user needs, which is something many of us learn the hard way. I truly believe sustainable growth comes from solving concrete problems, shipping iteratively, and getting real feedback early, and I’m excited to keep building with that mindset moving forward.
Thanks for sharing this life lesson, Art! It feels like you’re becoming a bit of a boomer yourself now 😉
What really struck me was when you mentioned Ronald’s line: “If nobody uses it, you are the architect of an empty building.” And especially when you talked about the hit your ego took.
I think, at some point, most of us go through that phase — the oversized ego, the certainty that we know better, and the temporary deafness to anything that challenges our vision. What makes the difference is what comes next.
Your real strength wasn’t avoiding that phase — it was being able to listen, reflect, and turn the experience into growth. Not everyone develops that kind of self-awareness. That’s what transforms a tough lesson into long-term wisdom.
Thanks again for the honest reflection — it’s the kind of perspective that helps the rest of us grow a little faster.
Haha, maybe I am slowly earning that boomer badge 😄 — but honestly, you’re right, the real technical mistake wasn’t the architecture itself, it was optimizing and over-engineering before validating real user demand. That experience changed how I approach system design now: I focus first on usage signals, feedback loops, and measurable adoption metrics — because clean architecture means nothing if it solves the wrong problem, and I’m genuinely interested in refining that balance even more in future builds.
That shift in perspective really shows. Focusing on usage signals and feedback before polishing the architecture is such a powerful mindset — and honestly, not an easy one to internalize until you’ve lived through the opposite.
What I find interesting is that many of us are trained to think “build it right” means “build it perfectly,” when in reality it often means “build it relevant.” Clean architecture becomes meaningful only when it serves something alive and evolving.
It’s great to see how that experience reshaped the way you design systems. That kind of balance between technical excellence and real-world validation is probably one of the hardest skills to master — and one that keeps evolving with every new project.
Thank you for this — I really appreciate how clearly you captured that tension between “perfect” and “relevant,” because that’s exactly the technical trap many of us fall into early on. I’m still learning to balance clean architecture with real usage signals
When I first started posting on here I was afraid to be judged.... like on social media. Then I realized, people on here are writing quality content. Real stories. Real struggles. Those are my favorite. I found it to be a safe place to share my coding dramas freely. People actually respond, and say meaningful things!
What I have learned the past couple years is that people believe a relatable story over some shiny new perfection. I resonate with that. Relatable stories build trust and connections. Alot of people are scared to share. It takes a little bit of bravery to get to the other side of that. Excellent story. ✨️
Thank you so much for sharing this — I completely relate, especially the part about feeling nervous to post at first, because putting real technical struggles out there can feel vulnerable but it’s also where the most meaningful conversations start. I truly believe honest stories about debugging failures, architectural mistakes, and growth teach us far more than polished perfection, and I’m excited to keep sharing and learning alongside people like you who value that authenticity.
✨️🦾
😎
It's great and really impressive.
Great post — I really relate to this.
I don’t actually build side projects after hours (at most, simple demos for articles or conference talks), but the core message applies far beyond coding. It’s true for pretty much every area of life.
From time to time, it’s worth doing an honest audit: are we moving in the right direction, are we making real progress, or are we just staying busy? Sometimes that reflection is exactly what shows us that something needs to change.
Thank you.
Especially the idea of doing an honest audit instead of just staying busy, because that’s where real technical growth usually starts. In engineering, I’ve noticed that without stepping back to evaluate architecture decisions and long-term impact, we can mistake activity for progress, so I’m very interested in building a habit of more intentional reflection around the systems we design.👍👍👍
This is the story no one tells junior devs.
Being "elite" at coding ≠ being elite at business.
I spent 3 years at 500 YouTube subscribers making $0 because I was teaching "React Native basics" like everyone else.
The $0 phase ended when I realized: developers don't need another todo app tutorial. They need to see how to handle REAL money without getting hacked.
Thanks for sharing your experience! What is the name of your YouTube channel?
I am glad you found it helpful
👍
Thanks.😎
If you are interested in that, feel free to contact me via telegram light4661
Love this perspective — you’re absolutely right, being technically sharp doesn’t automatically translate into business impact, and that shift in mindset is something most junior devs only learn the hard way. I’m especially interested in the security angle you mentioned, because building apps that actually handle real money securely (proper auth flows, encryption, secure key management, backend validation, etc.) is the kind of real-world technical depth we need more of in this space.
Nice approach
Good
Everything are perfect!
Thanks for the story. In this so-called 'social media' era, no one opens up about their failure. Everyone wants to show their success story even if they're not. Seeing this kind of story feels like the real world. Real world doesn't have only joy and success. Failure and struggles are also real. And, seeing success stories only doesn't help. It worsens the mind and confidence.
Thank you so much for this — you’re absolutely right, and that’s exactly why I wanted to share the uncomfortable parts, not just the highlight reel. From a technical and career perspective, I believe we grow more from debugging our failures, bad architectural decisions, and missed expectations than from celebrating wins.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.