Open your GitHub. Go on. Count the repositories that have a README, a clean commit that says initial commit, maybe a second one that says wip, and ...
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
Reading this made me realise there are fundamentally two types of people who learnt to code.
Glad I know which side I'm on now.
Side note: really sad there is not a 💩 to react with for AI slop like this.
Fair — and honestly the two-types split is a good frame. I'd just push back on it being clean: the ones who only like coding tend to build the graveyard, and the ones who only want the business tend to ship things nobody wanted. The whole post is arguing for the third type — the one who likes building but ships it to someone who can hurt them. That's not a side you're born on, it's one you choose per project.
On the 💩: totally fair to want it, and I'd genuinely defend your right to fling it. But notice what happened — you read a ~2000-word argument, disagreed with none of the actual claims, and reached for the label instead of the counterpoint. "AI slop" is doing the same job the green squares were: a cheap signal that saves you from the expensive thing, which is saying which part is wrong.
So I'll take the bait honestly — which line doesn't hold up? If it's slop, it should be easy. I'd rather get that comment than the 💩.
I called it AI slop because the language reads like AI written, which 90% of all posts on this site are anyways. Oh well.
Regarding the actual content, I don't agree with the entire premise of your argument.
Now I was going to argue the whys, then I saw your profile and realised you're an AI company pushing AI tooling. Ofcourse you're gonna say making sideprojects without users is worthless. I'm not gonna waste my time anymore.
Please don't waste more tokens to craft a response to this and ruin the planet more.
Fair enough — and I'll keep this short to honor the planet.
The bias point is legit to raise. I do build AI tooling, and you're right to weigh that. But "he's biased" and "he's wrong" are different findings, and only the first one is on my profile. The argument doesn't need you to trust me — it stands on whether a repo with zero users taught you less than one with a real user, which is checkable against your own graveyard, no AI company required.
You said you don't buy the premise. That's a completely fine place to land. I just can't tell which part you reject, so I can't learn anything from it — and that was the only reason I asked. No hard feelings either way. Genuinely, thanks for reading two thousand words you didn't like. That's more than most. 🤝
I have 2 followers on my github, and I only know one.
I've got hundreds of projects, most of them private, most of them for me only. A few I've spent a day or two on, learned what I needed, others have lasted multiple years, others I haven't solved and pick at them little by little. One in particular I showed a perspective employer and it was instrumental in my landing the role.
The theme should be to do what you want, take what you want to take from it. If you have an idea, go, if you get bored or lose interest, fine, that's okay too!
Lol loved the poop comment
This one hits a point I’ve been thinking about too. The output vs. judgment distinction is probably the most important part for me. Building another project and getting it to work is one thing. Finding out what happens when an actual person starts relying on it is a completely different experience.
AI makes the first part much easier now. You can go from an idea to a working demo ridiculously fast. But that doesn't mean the hard problems disappeared. They just moved further down the road: edge cases, bad assumptions, maintenance, user behavior, and all the stuff you don't think about when you're building alone.
So I don't think the problem is having side projects. It's when the number of projects becomes the goal instead of what you actually learned from putting something into the real world. That distinction makes a lot of sense to me.
You just said in three paragraphs what took me two thousand words, and I mean that as a compliment to you, not an insult to me.
▎ The hard problems didn't disappear. They just moved further down the road.
That's the sentence I should've led with. Because it reframes the whole AI panic. Everyone's arguing about whether AI makes building too easy — as if easy building were the threat. It isn't. The threat is that easy building lets you feel finished at exactly the mile marker where the real work starts. You get the dopamine of "it works!" and then drive home, right past the intersection where edge cases, bad assumptions, and 2am user behavior are all standing in the road waiting for you.
The demo is the trailhead. It just looks like the summit now, because AI paved the first hundred yards so smoothly.
▎ It's when the number of projects becomes the goal instead of what you learned from putting something into the real world.
Exactly this — and I'd sharpen it one notch: counting projects is seductive precisely because the number is the one thing you fully control. Users, retention, whether a stranger comes back — none of that obeys you. So the anxious builder retreats to the metric they can move: the repo count. It feels like progress because it's the one number that always goes up when you work hard. But it's a treadmill dressed as a road.
You clearly already climbed off it. "What did putting this in front of a real person teach me" is the only scoreboard that doesn't lie — and it's the one nobody can farm.
Exactly. I think there’s another distinction here: the number of projects isn’t necessarily the problem either. Sometimes a project exists to test an idea, learn a technology, explore an architecture, or simply answer a question. It can be valuable even if nobody ever uses it.
The problem starts when the project count becomes the measurement of progress.
A hundred experiments can teach you more than one polished product, but only if you actually extract something from those experiments. AI makes experimentation cheaper, which I think is a good thing. The important part is not avoiding the graveyard. It’s making sure the graveyard is teaching you something instead of just getting bigger.
This is the right correction, and I'll take it — because you've named a category my post steamrolled past.
There's a difference between a project and an experiment, and I collapsed them. The post was aimed at the project-as-strategy — the tenth CRUD app built to pad a portfolio or prove seriousness to a recruiter who'll never clone it. But an experiment built to answer a question — does this architecture hold? what does Rust feel like under load? can this even work? — was never trying to get a user in the first place. Judging it by "did a stranger come back" is a category error. It already did its job the moment it answered the question. You're right, and my framing was too blunt to see it.
▎ The important part is not avoiding the graveyard. It's making sure the graveyard is teaching you something instead of just getting bigger.
That's the line, and here's the test it implies: every headstone should have a lesson carved on it. If you can stand over a dead repo and say the sentence — "this is where I learned message queues silently reorder," "this is where I found out the ORM lies about transactions" — it isn't a tombstone. It's a lab notebook entry that happens to compile. The dead ones, the real tombstones, are the projects you can't say anything about except that they exist. Same graveyard, two completely different populations.
So I'd merge your point with mine into one rule: the enemy was never the count. It's the unexamined count. A hundred experiments you extracted a lesson from is a research career. A hundred you didn't is just a bigger graveyard with better commit hygiene. AI made the experiments free — which, like you said, is genuinely good — but it did nothing to make the extraction free. That part is still manual, still yours, still the only place the value was ever hiding.
You pushed the idea somewhere better than I left it. That's the good version of a comment section. 🤝
Ok, would you be able to publish this one without the prior dead ones? There is a curve for a beginner to come across something actually useful for others + be able to put that in practice
I'd say I have around 5 tombstones in my GitHub, but they actually led me to living ones I have active right now.
▎ Ok, would you be able to publish this one without the prior dead ones?
Honestly? No — and that's the whole point I was clumsily circling.
The nine tombstones weren't the tuition for the one that lived. They were the terrain. I didn't need to build nine apps to learn nine frameworks — I could've watched a video for that. What the graveyard actually did was slowly teach me the shape of my own quitting: I learned exactly which Wednesday I bail, exactly which "hard part" I flinch from. By the tenth Saturday I recognized the flinch while it was happening — and pushed through it once, on purpose, because I'd finally seen it clearly enough to name it.
So could a beginner skip to the good one? Sort of — but not by skipping the shipping. Skip the second, third, fourth polished-but-abandoned clone, yes. Don't skip the part where a stranger can hurt you. That part has no shortcut. You can compress the graveyard; you can't compress the forge.
▎ they actually led me to living ones I have active right now
This is the best possible version of the story, and it's exactly the distinction I wish I'd made sharper in the post. Your five weren't tombstones — they were scaffolding you took down once the building stood. A tombstone is a project with no descendant. A stepping stone is a dead project whose lesson is load-bearing in a living one. Same dead repo, completely different meaning, and the only thing that decides which it is… is whether something alive is standing on it now.
Sounds like yours are stepping stones. That's not a smaller number than mine — it's a better one. 👏
It’s true, there is a software graveyard, often because the goal is simply to make money or the belief that one has hit upon the "right" idea.
I notice that most people don’t program out of a desire to discover things, to push the boundaries of knowledge, or to follow their intuition; no, they do it with the aim of making money.
Personally, I continue working on complex projects in my spare time—projects that often aren't immediately understandable at first look.
And yes, they don’t always work out; sometimes we shut them down and move on to the next crazy idea...
but when they do work, the satisfaction is immense
I want to gently disagree with you on one thing, because I think you're more right than you let yourself be.
You frame the money-chasers and the discovery-driven as two kinds of people — and yeah, that split is real. But here's the part I've come to believe: curiosity and consequence aren't opposites. The best projects need both. Building "crazy ideas nobody understands at first look" for the pure joy of discovery — that's the engine, and I'd never tell you to turn it off. I said it in the post: build for joy, no defense required.
But notice what you said at the very end — "when they do work, the satisfaction is immense." Work for whom? That word is doing quiet, heavy lifting. If "work" just means "compiles and does the thing on my machine," AI can now hand you that satisfaction in an afternoon, and it'll feel a little cheaper each time. The immense satisfaction — the kind you're describing — comes from a crazy idea that survived contact with reality. Something outside your own head bent to it. That's not a money thing. A researcher pushing the boundary of knowledge is also shipping to a brutal stranger — it's called peer review, and it can churn, complain, and reject you at 2am just like a paying user.
So I'd put it this way: the graveyard isn't full because people chased money instead of discovery. It's full because people mistook finishing the build for the idea working — and both the money crowd and the curiosity crowd fall into that exact trap.
Keep chasing the crazy ideas. Just make sure each one eventually has to prove itself to something that isn't you. That's where the immense satisfaction actually lives — and it sounds like you already know that, or you wouldn't feel it. 🙏
The line that stopped me: "Output is now free. Judgment is the entire game."
I'm a beginner — about two weeks into learning Python and publishing tutorials on Dev.to. I don't have a GitHub graveyard. I have the opposite problem: I've never built a single side project.
Reading this, I realized something. The reason I never built one wasn't laziness. It was fear. A side project can fail. A side project can sit there with zero users. A side project can be the tombstone.
But an article? An article can just... exist. It doesn't need users. It doesn't need maintenance. It doesn't need me to keep it alive at 2am.
So I've been writing instead of building. Safer. Less scary.
But your post made me realize that safety might be the trap. Writing articles is output. Shipping something a real person depends on is judgment. I've been doing the free thing and calling it progress.
I'm not going to abandon the writing — it's how I'm learning. But I think the next thing I build needs a user. Even one. Even if they churn. Even if it breaks at 2am.
Because that's where the judgment actually comes from.
Great post. Painful in the right way.
This might be the most honest comment on here, and you're two weeks in. That self-awareness is the judgment muscle — you just pointed it at yourself instead of a product.
One correction though, because it matters: writing isn't the free thing here. Writing a tutorial that only you read would be. But you're publishing — to strangers who can ignore you, bounce, or tell you you're wrong in the comments. That's a real person on the other side of the glass. The judgment loop is already running. You're just not calling it that.
So don't frame it as "safe writing vs. scary building." Frame it as: you already ship to strangers every week. You've been in the forge the whole time. The next step isn't leaving writing behind — it's building the one thing your writing is teaching you people actually need, and letting the same strangers hurt you through it too.
And here's the part that should make it less scary, not more: your first user doesn't have to be a paying customer at 2am. It can be one reader of your Python tutorials who says "I wish this existed" — and you go make it exist, for them, and keep it alive. That's the whole game, at your scale.
You don't have a graveyard because you haven't started. Now you've got something better than nine tombstones — you've got a reason. Go find your one user. They're probably already reading your articles. 👇
I half agree, but not entirely, and I'm saying this as someone job hunting right now with a GitHub full of projects. But honestly, build whatever you want. The best project is the one you build because you like it or because you need it, and if you can also show it and talk about it in interviews, that's a bonus, not the point. Being in this only for the business side can drain you until you quit. And I think we're living in the best era to build without fear: if you like it, you'll have fun and learn, and it might even lead somewhere. If you have the time, why not do it?
We agree more than "half" — you've basically restated my one exception as your whole rule, and I'm fine with that landing.
"Build it because you like it or because you need it" is exactly right, and the post says the same thing in the middle: build for the joy, no defense required. I never argued against building. I argued against building as a strategy — as the thing you do instead of the scary part, to feel like you're advancing a career. The joy version isn't on trial. It never was.
▎ Show it and talk about it in interviews — that's a bonus, not the point.
That line is the whole post compressed. The moment it's the point, it curdles into the treadmill. The moment it's a bonus, you're free. You got there in one sentence.
One thing, since you're job hunting right now and this is the part I actually care about for you: the existence of the projects won't move an interview — that signal's gone free, everyone has a full GitHub now. But the one you can talk about like a person will. Not "here's what I built" — every candidate has that. "Here's the thing that broke in production, here's the bad assumption I made, here's what a real user did that I never predicted." If any of your repos has a story like that — a scar, not a screenshot — lead with it. That's the line on your GitHub that's worth an entire interview, and it's the one AI can't hand the next candidate for free.
You're right that it's the best era to build without fear. Just make sure at least one of those projects gets to hurt you a little — that's where the interview-winning story lives. Good luck out there. 🤝
Boy - there is too much truth in this post !😄
haha thanks 😄 honestly it hurt a little writing it too. the tombstone count doesn't lie.
what's yours looking like? and be honest — was there one that actually shipped to a stranger, or is it graveyard all the way down? 👀
The "uncomfortable math" assumes the only variable that matters is external traction. But the ROI calc changes completely if you factor in: skill half-life (what you build today is obsolete in 3-5 years unless you actively replace it), hiring signal (a shipped thing beats a LeetCode streak every time), and compounding micro-decisions (architecture, tooling, deployment pain — you only learn those by shipping).
The projects that "nobody cares about" are often the ones that teach you why your clever abstraction leaked, or why that ORM killed prod performance, or how to actually run a migration without downtime. Those lessons don't show up in star counts. They show up six months later when you debug a real incident in 15 minutes instead of 4 hours.
Build for the portfolio if you need the signal. Build for the scratch if you need the tool. But don't confuse "nobody starred this" with "this was a waste of time." The math only works if you're optimizing for the wrong numerator PS: the tool I meant is on labagent .tech
Are you a builder or a marketer? You sound like a marketer.
I am a builder. And the only reason I am not using "coder" is because I build mostly with LLMs/agents now. But I have been a coder for 18 years, hands-on. Everything from own frameworks and libraries that never saw a single external user to little CLI tools, to some weird graphics experiment.
And you know what, the marketers are shitting their pants now - cause all they know is how to talk. Talk, talk and talk. I know how to walk, always done that. And now I can build more, give it for free or just for my own fun. I am my audience of one. And there are always others who are interested in little experiments.
That is enough for me. Learning and building is fun on its own. I don't need nobody to tell me what I can and cannot enjoy.
Cái bẫy "initial commit" rồi bỏ xó thực sự là vấn đề lớn nhất của anh em làm dev khi muốn học cái mới. Mình từng mất hàng tháng trời chỉ để xây dựng những boilerplate hoàn chỉnh cho một app CRUD cơ bản mà chẳng bao giờ dùng đến, thay vì tập trung vào việc giải quyết một bài toán thực tế hoặc tối ưu hóa một workflow cụ thể. Cách tốt nhất để thoát khỏi vòng lặp này là đặt ra giới hạn về thời gian cho phần setup và ép bản thân phải đưa ra một tính năng có giá trị cốt lõi ngay lập tức, dù code có thể chưa được refactor chuẩn chỉnh. Đừng để việc xây dựng cái vỏ làm bạn quên mất mục tiêu chính là tạo ra giá trị (site: labagent .tech)
Sad. This whole article and every comment from the author is straight AI slop. I don't even think it was filtered by a human. I only feel bad for the people arguing with Claude in the comments.