Inspired by—but not aligned with—"The $0 Developer Phase—And How Dev.to Pulled Me Out" by Art Light
Eight years into this field, I'm grateful for many things—but one stands above the rest:
My ego never grew big enough to make me forget why I learned to code in the first place.
Not to signal intelligence. Not to perform seniority. Not to join a developer identity group. But to solve real problems life put in front of me.
Art Light's article reminded me how common the opposite path is—the path where developers build for validation, aesthetics, or imagined audiences. His story is honest and valuable, but it's not my story. I didn't come up through that culture, and I've never belonged to the dev.to "developer journey" ecosystem. My work sits adjacent to it, not inside it.
Still, the article sparked a reflection worth writing down.
Why My Ego Never Had Room to Grow
I never had a "$0 developer era" because my work was never hypothetical. I didn't learn to code to impress anyone or to architect theoretical systems. I learned because something real needed to function—and I was the one responsible for making it work.
When your code has to survive contact with reality, ego has nowhere to attach. There's no imaginary user to hide behind. No architectural theater. No performance layer.
Just the blunt clarity of: does this solve the problem or not.
That's why one line from Art Light's article stood out—not as a lesson I had to learn, but as a sentence that names a trap I never had the luxury to fall into:
"If nobody use it, you are architect of empty building."
It's a concise description of a dynamic I've always been structurally insulated from.
A Different Lineage Entirely
Many developers on dev.to are early in their journey—building confidence, exploring tools, and finding their voice. The platform is well-designed for that kind of growth, and there's nothing wrong with it.
But there's also a quieter minority who use the space differently. People who publish to document, to timestamp, or to clarify their own thinking rather than to network or participate in the social layer. I've always found myself in that group—and I know I'm not the only one.
My work has always been shaped by:
- real constraints
- real users
- real stakes
- real consequences
That environment naturally keeps ego in check and orients you toward clarity rather than performance. It's not a better path, just a different one—one that happens to align with how I learned to build and why I continue to write.
The Landing
Art Light's story is useful because it exposes a pattern many developers fall into when they build for image instead of impact. My path was different, but the underlying truth is universal:
Code is a tool for solving real problems—nothing more, nothing less.
And if you ever meet someone who can collapse your illusions with a single sentence and a knowing smile, pay attention. People like that shorten your learning curve in ways no tutorial ever will.
Sometimes that smile saves you months. Sometimes it saves you years.
Top comments (21)
Great post Narnaiezzsshaa, I'm so glad you've been able to stay true to your roots and keep your focus on solving real problems. It's rare to see developers who aren't swayed by the pursuit of perfection or validation, and I think that's what makes your work so valuable.
Thank you, Aryan.
The 'real constraints keep ego in check' observation maps to something I've noticed in AI-assisted development too. Developers working on toy projects with AI tend to over-architect — because there's no feedback loop pushing back. Developers working on production systems with real users can't afford that. The constraint isn't just ego management, it's information quality. Real users generate real bug reports. Real stakes generate real debugging sessions. That feedback is what builds the judgment that no amount of AI tooling replaces. The quiet minority who write to document and clarify rather than to network — that's exactly how I use Dev.to too.
VERY well said. Wow. You just opened my mind.
What a thoughtful article. As a beginner developer it's a real wake-up call to what kind of applications I need to be thinking about - applications solving real problems and not just having the illusion of it.
This hits close to home. I spent my first couple years obsessing over "clean architecture" and rewriting the same project three times before shipping anything. The turning point for me was freelancing — when someone's paying you and there's a deadline, you stop debating folder structures real quick.
The "architect of empty buildings" line is perfect. I still catch myself falling into that trap sometimes, especially with side projects. It's so easy to convince yourself that perfecting the codebase IS the work, when really you're just avoiding the scary part — putting it in front of actual users.
Do you think there's a middle ground though? Like, some amount of "building for yourself" early on is probably healthy for learning, right? The problem seems more when it becomes the default mode and you never graduate to building for real use cases.
There is a middle ground—but it isn’t a 50/50 split between “build for yourself” and “build for users.” It’s about understanding what kind of learning each mode actually produces.
Early self‑directed projects are great for building mechanical fluency: how to move in an environment, how to reason about constraints, how to debug your own thinking. That’s real skill‑building.
But the moment the architecture becomes the point—when the project exists mainly to give you a place to rearrange patterns—you’ve crossed into a different activity entirely. It feels like progress, but it doesn’t generate the kind of feedback that changes your judgment.
Shipping to real users forces a different muscle: contact with reality. Deadlines, ambiguity, tradeoffs, the fact that no one cares how elegant your folder structure is if the feature doesn’t land. That’s where engineering judgment is actually formed.
So the middle ground isn’t “some of both.” It’s: use personal projects to build fluency, but don’t mistake fluency for judgment. Judgment only emerges when something external pushes back.
When “building for yourself” becomes the default mode, you end up with beautifully engineered systems that never encounter friction—which means they never teach you the thing you actually need to learn.
I see your point dude, well this definitely something to bear in mind and your let's say attitude to coding is just as a tool and not as a hobby or whatsoever (at least I infered it). The quote with the empty emire/building architect is so me, that I cannot even name it.
As a junior or I say a newbie in this tech market. I cannot emphasize enough to have such people who share their experience and real thoughts like you and art_light did, which definitely will help newbies like me and others.
Well said 👏
We should focus more on impact rather than perfection.
Great breakdown! 💡 The real-world examples make this so much more actionable.
Can't wait to see what you build next 🚀
There's a third category your framing misses, and I think it's where the real discomfort lives.
You draw a clean line: builders-for-validation vs builders-for-reality. But what about people who build for real problems, ship to real users, and still sit at $0? Not because their ego inflated. Not because the work was hypothetical. But because building the thing and finding the people who need it are completely orthogonal skills.
I maintain 25+ browser-based dev tools and a finance app — all zero-backend, all solving specific problems I personally hit. Real constraints, real architecture decisions (chose IndexedDB over a backend because the user's financial data should never touch a server). The code survives contact with reality daily.
And the revenue is $0.
By Art Light's framing, I'm the architect of empty buildings. By your framing, I should be structurally insulated from that trap because my work was always grounded in real need.
Both framings are incomplete. The missing variable is distribution — and it has nothing to do with ego. You can build the most useful thing in the world and still be invisible because you never learned that shipping and reaching people are two entirely different disciplines.
The dangerous version of your argument isn't that you stayed grounded — it's that it can read as "I never had to struggle with this, therefore the struggle itself was optional." For a lot of developers, the $0 phase isn't a character flaw. It's a distribution problem wearing a motivation costume.
Kai Alder's question above is the right one: is there a middle ground? I'd argue the middle ground isn't about how much you build for yourself vs others. It's about how quickly you close the feedback loop between building and reaching.
You're describing a distribution problem. I agree it's real and distinct from ego. My article wasn't claiming otherwise—it was describing a different entry point entirely, not prescribing a universal path. Your work sounds genuinely grounded, and the distribution gap you're naming deserves its own article, not a footnote in mine.
I was unaware of this "$0 dev" stage of programming. Not out of lack of ego or something, just never heard of the concept before.
When I learned to program it was hard, took multiple years, and launching a whole project on your own was not even something you would entertain.
There were no BaaS or 2-click hosting. Side projects ran locally and showed something cool you were interested in. You'd actually talk someone through the code when interviewing. GitHub was used the way people pretend it's used today.
So idk man... You sure that your "I just don't have that kind of ego" isn't you missing how high the ground was raised in the era after you did your learning. A silly side-project has had 95% of the hard problems already solved. Back in the day, you literally couldn't be a $0 dev. That was just being unemployed.
Think about what you would say to a junior today if they showed you one of your side-projects from when you were a junior.
"Did you make that this morning?"
Scale has changed. Expectations have changed. Lowest acceptable standards have changed. Comparing apples to oranges.
You're right—the $0 dev phase is a luxury of infrastructure that didn't exist when the cost of failure was unemployment, not a bruised ego. The article isn't about that era. It's about the developers living in this one who have every tool available and still build for applause instead of impact.
Except it isn't. Your entire article is comparing against yourself. This is "just buy a house for $30 and provide for your family of 4 on a single wage" levels of "get with the times old man".
Those $0 devs are just hobby devs that haven't entered the field yet. It's not a fair comparison. You're comparing pre Renaissance art to post Renaissance art and saying back in the day people didnt use perspective because they had real problems to solve and money to earn. That's simply not an accurate representation of the landscape.
You also wrote a whole article about yourself and how you're better than the current noobs because you don't have an ego. If you can't see the irony in that, I dunno what to tell you.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.