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 f...
For further actions, you may consider blocking this person and/or reporting abuse
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.
The story reminds me of my past. Though I really liked computer itself when I was a kid, I majored in business/management in the college. But I enjoyed developing stuff, which resulted in applications like automatic supply status chart generator or tracker for contents of competitor's product(lol). At that time I was only one who was capable of coding among managers, and my goal was practical and needed.
And time flied.
Now I'm lead developer of about 10 people, and I'm working with vim, vim9-lsp, and llama.vim.
The basic principle of supply and demand in economics applies everywhere.
The distribution problem is real, but you're conflating market fit with technical legitimacy.
You chose IndexedDB for the right architectural reason (data sovereignty). That's sound engineering. But 25 tools with zero users isn't a distribution gap—it's a signal problem.
Real constraints include: Does anyone outside your head actually need this solved this way?
The $0 phase isn't a character flaw. It's a feedback loop you haven't closed. Shipping isn't orthogonal to building—it's the forcing function that tells you if the problem was real or just real to you.
I think this comment is meant for the original article—mine is a response to it, not a continuation of it. I never had a $0 phase. The piece explains why.
But shouldn't we explore new architectures? Like try to do something different instead of just solving problems?
My article never says "don't explore new architectures." It says: don't let exploration become the point at the expense of solving real problems. The distinction between fluency and judgment—which I lay out in my reply to Kai Alder—is the entire thesis.