Developer, maker, and perpetual project starter. I build web apps and dev tools mostly, things that I think are really useful and should exist and be simple to use. I also like to experiment with AI.
I love this post, and I think it's something more developers need to hear.
I build a lot of things simply because I feel like making them. Some are genuinely useful, some are experiments, some are just because i want to see if I can do it. Half the fun is figuring things out along the way. I definitely don't have plans to monetize most things, or turn them into products, or even get anyone else to use them.
And I think that's something we lose sight of with all the conversations about productivity, efficiency, and AI. I use AI and enjoy it, but I don't think being able to generate something faster makes the experience of building it yourself any less valuable.
Your point about doing something simply because you enjoy doing it really resonated with me. Not everything we create needs to serve a purpose beyond making us happy, and sometimes teaching us something along the way.
Sometimes I just want to make something because it sounds fun. That's a good enough reason for me.
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
Wanting to make something just because it sounds fun really is a complete reason, and it always was one. The range you describe is the healthy version of all this, too: some useful, some experiments, some just “can I pull this off?” — with the figuring-out being half the point. That’s a person the doom stream hasn’t managed to colonize yet.
And your take on AI is exactly the balance I was reaching for: generating something faster doesn’t make building it yourself any less valuable, because speed and the experience were never the same axis. One is about the output; the other is about what happens to you while you make it. AI competes on the first and can’t touch the second. Hold onto that instinct — it’s the right one. 🙏
Can you read this for me shouldnt be to long that can be a case bf on the dent are going to be a mess that can be a pont on the care plan that can be done by now. Should be a case as that can be defent by asking for it by for cant be to long for tea that was going to be at 5:00 but can be late by anything as we are going to be late for tea.
Didnt you the meg i sent you. That you replyed to me. For anything as thing can be aoinathoing showing on a prvide when you replyd to them to say that we have to be ready for going out tonight as cant be arent being so asthoerd thing that we ask that they can ask you.
Thanks
luke
Nobody tells you your evening run is pointless because a car is faster. Nobody says you shouldn't cook dinner because restaurants exist and are better at it. Nobody looks at someone playing guitar badly in their bedroom and says, "You know Spotify has professionals, right? What's the economic case for this?" We'd find that insane.
This is the part I’d highlight. You’re so right, because here in the world of endless progress, we tend to measure everything in money, usefulness, and the time spent on it. If we go back to ancient Rome, they didn’t even count time the way we do. They simply divided the day into 12 hours, from sunrise to sunset. In winter the hours were shorter, in summer longer. We weren’t so disconnected from nature back then, though admittedly that wasn’t exactly yesterday.
Now we live in a world where we sacrifice absolutely everything on the altar of technological progress. That’s exactly why |> is my favorite hobby horse—and thanks to AI, I could actually build it in a reasonable amount of time. It raises a question: is it still worth spending time on the programming languages we use every day? My answer is yes.
But I also have a program where I deliberately got things wrong, and I love it: Chuck Norris TODO list.
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
The Roman hours are a beautiful thing to bring in here, and genuinely apt — hours that stretched in summer and shrank in winter, tied to the sun instead of a machine, meaning time bent to life rather than life bending to time. We flattened that into identical, countable, monetizable units, and in doing so we made it almost impossible to spend an hour on something that doesn’t “produce” — because every hour now has a price tag we didn’t used to see. Measuring everything in money, usefulness, and time-spent is exactly the altar you’re describing, and you’re right that we sacrifice nearly everything on it.
Which is why your favorite hobby-horse projects are the quiet refusal. And the detail I love most is the last one — a program where you deliberately got things wrong, and love it. That’s the whole essay in a single act. A program you made intentionally imperfect, purely because the making delighted you, is completely illegible to the economic lens — it produces nothing, optimizes nothing, justifies nothing — and it’s probably one of the truest things you’ve built, because the only reason it exists is joy. The market can’t even see that program. That’s what makes it yours. Thank you for this comment; the Roman hours and the deliberately-wrong program are two of the loveliest things anyone’s added.
it produces nothing, optimizes nothing, justifies nothing
That’s not entirely true. I feel a bit like Ace Ventura explaining the effect of the sliding glass door to the terrace. The program is pretty enigmatic and doesn’t spoon-feed you anything.
But in terms of usability, it’s a training exercise in using an input field with limited visibility. As soon as you start typing, the whole form starts floating around, immediately wrecking your sense of security and visibility. On top of that, a single input field lets you edit an entire TODO list however you like, in real time. The rule is that - means a new line. You have to discover that rule and let go of the expectation that you’ll always have clear visual feedback, like driving through heavy rain.
Meanwhile, I’m debugging the state in real time with a single <pre> tag, because this uses a reactive technique, as the continuously running counter also demonstrates. I wouldn’t call it a framework, since I’m using just one function called signal. So it’s a React alternative, and also an example of no-build development. I made it by writing an HTML file with the JavaScript inside, all by hand. Back then, I was practicing writing the Tailwind import and the entire HTML skeleton from memory.
So it’s also a rebellion against painfully cumbersome build systems and code formatting disciplined by linters. And the fact that I even minified the code by hand foreshadows one of the mordorproject’s strongest ways of hiding information from AI.
Ernest Hemingway expressed this in his iceberg theory: the writer knows the whole story, but only writes down the one-eighth above the water.
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
The program you’re describing is the thesis made executable. A single input field where the whole form floats as you type, where - secretly means a new line, where you have to discover the rule and surrender your expectation of clear feedback — that’s not a usability failure, it’s a deliberate aesthetic choice that has zero economic justification and everything to do with how it feels to use. “Like driving through heavy rain” is a design intention, and no ledger on earth would ever approve it. That’s exactly what makes it yours.
And the layers underneath are the quiet rebellion stacked three deep: one signal function instead of a framework, no-build, hand-written HTML with the skeleton typed from memory, minified by hand. Each of those is a refusal of a layer someone told you was mandatory — the build system, the linter’s discipline, the framework. You rebuilt the benefit and threw away the ceremony, by hand, for joy.
The Hemingway iceberg landing is the part I’ll keep. Knowing the whole story and showing one-eighth — as craft, and now as a way of hiding information from AI — turns deliberate omission into both art and strategy. The enigma is the point.
The "somewhere, coding stopped being allowed to be fun" observation is real, but I think the root cause is different than the article says.
It's not the doom stream that killed the joy. It's that the joy was always fragile, and the doom stream just made it visible. The same people who now say "AI makes this pointless" were the ones two years ago saying "why are you building that when you could just use [framework X]". The economic lens was always there — AI just made it sharper and louder.
What's actually changed for me: the things I build for fun are now things I'd never show on LinkedIn. A tiny RuneScape bot that plays badly. A ray tracer that renders at 5 fps. A Telegram bot that answers in riddles. All worthless by market standards. All things I still think about months later.
The article's best point is the "not a single economic argument" part. But I'd go further — it's not just that economic arguments don't apply to fun coding. It's that they never applied to anything that mattered.
What's your worthless thing? Mine is a homebrew parser for a fictional language from a 1990s game, which I wrote from scratch and will never use.
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
Your root-cause correction is sharper than mine, and I think you’re right: the doom stream didn’t kill the joy, it made visible a fragility that was always there. The “why build that when framework X exists” crowd are the same people now saying “why build that when AI exists” — the economic lens was never new, AI just turned up its volume. That’s the better diagnosis, because it means the defense has to be internal, not environmental.
But the LinkedIn detail is what got me, because it’s quietly devastating: the things you build for fun are now things you’d never show. A badly-playing RuneScape bot, a 5fps ray tracer, a riddle-answering Telegram bot — worthless by the ledger, still in your head months later. That gap between what you’d perform publicly and what actually stuck is the whole wound.
And your sharpening is the line I’ll take back: it’s not that economic arguments don’t apply to fun coding — they never applied to anything that mattered. The ledger was always the wrong instrument.
Mine: a tool that generates fake, plausible git history just to make the commit messages sound like a real tired dev at 2am. Useless. Unshowable. A favorite.
A fake-git-history generator that makes commits sound like a tired dev at 2am is the most relatable "useless" project I've heard. I'd genuinely use it — not for anything productive, just to see what my commits would look like if I were a different kind of tired.
The line you pulled out — "the ledger was always the wrong instrument" — is the one I keep coming back to. It's not anti-market or anti-AI. It's just that the ledger was never measuring the thing that made the work worth doing, and it never admitted that.
Good luck with the next 37-part series. I'll be reading.
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
Ha — “to see what my commits would look like if I were a different kind of tired” might be a better pitch for it than anything I’d have written. And yeah, “the ledger was always the wrong instrument” is the one that stuck with me too — not anti-market, just honest that it was measuring the wrong thing the whole time and never said so. Thanks for reading, and for the kind words on the next series — I’ll try to make it worth the subscription you’re definitely not paying. 🙂
"Not anti-market, just honest that it was measuring the wrong thing the whole time" — that's the perfect way to put it. It's not about rejecting the market, it's about not letting it be the only voice in the room.
Looking forward to the series. And for what it's worth — I'd genuinely try that fake-git-history tool. Half my commits already look like they were written by a different kind of tired, so it might just make it official.
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
“Not letting it be the only voice in the room” is the cleanest statement of the whole thing — the market gets a vote, just not the only one, and somewhere we handed it the whole floor. And “my commits already look like a different kind of tired, might as well make it official” is genuinely funnier than anything in the tool itself — honestly tempted to ship it now just so your commit history can finally match your soul. Thanks for making this thread a good one. 🙂
Ingo Steinke is a Berlin-based senior web developer focusing on front-end web development to create and improve websites and make the web more accessible, sustainable, and user-friendly.
None of this feels new by the way. Ten years ago, it was SPA web apps built with React or Angular mostly with a backend- or devOps-focused mindset deliberately ignoring all the values and insights the web development, web performance optimizatiion, and usability research had just established. Add product owners with their 80/20 MVP move-fast-and-break-things approach. All of this threatening to kill everything that was fun about making websites.
But it didn't.
DevUX or usability-focused frontend web development kept optimizing and implementing accessibility, responsive web design, and progressive enhancement. Some of our projects aged well. And all the devOps stuff I experienced both as annoying and useful at the same time. Webpack has since been obsoleted by Vite, while node and npm have copied all the relevant aspects that made yarn and bun relevant and important. React learned from static site generation, and Astro tried to unify classic web development and various JavaScript frameworks and libraries. So we did make progress after all.
Now AI is the latest hype, specifically meaning LLM-based generative artificial intelligence focused mostly on chat, command-line, and code interfaces. DEV, Medium, and LinkedIn are, once again, drowning in a flood of mostly irrelevant slop that nobody will want to read ever again in two years from now.
Last but not least, to answer your question, my most uneconomic digital effort is my commitment to my own blog website which I keep optimizing for quality and SEO. When it comes to development technologies, learning Astro didn't pay off financially yet, and improving understanding and coding CSS also seems not much more than a nerdy hobby these days.
"DEV, Medium, and LinkedIn are, once again, drowning in a flood of mostly irrelevant slop that nobody will want to read ever again in two years from now."
Could not agree more. I cancelled my Medium membership this year because almost every story was slop. DEV is suffering pretty badly - for the first time I've had to start blocking people to try to recover my feed from infinite posts about Claude, Qwen, prompting techniques and so on which I have zero desire to ever use.
On the plus side, online discourse has become so flooded with boring slop that it has encouraged me to spend more time on other hobbies.
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
The historical perspective is the most grounding thing anyone’s added, and it’s a real corrective to the doom: you’ve lived through this exact panic before, several times, and watched the thing worth keeping survive it each time. SPAs built with a backend mindset that ignored everything usability research had just established, move-fast-and-break-things product owners threatening everything fun about making websites — and yet the craft didn’t die. DevUX kept optimizing, accessibility and progressive enhancement kept getting built, Webpack gave way to Vite, React learned from static generation, Astro tried to unify it all. The hype flooded in, receded, and the people who actually cared about the work were still there afterward, having quietly made real progress.
That’s the longer-horizon answer to this whole piece: the slop flood is real, and most of what’s drowning DEV and LinkedIn right now will be unreadable in two years — but that was true of the last flood too, and the signal outlived the noise. The hype cycles are loud; the craft is patient.
And your most-uneconomic effort is perfect: a blog you keep optimizing for quality, and CSS as a “nerdy hobby” that hasn’t paid off and doesn’t need to. That’s the whole thesis — the care is the point.
Agree 💯 James. Just because something is now being easily done by machines doesn't mean we should stop enjoying it or just stop doing it because it is not earning us money.
Not everything has to be done in a "sprint" or an "efficient way" to meet an imaginary deadline.
It's human to sit through a problem for hours and enjoy solving it using nothing but our very own brains.
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
Exactly — “it’s human to sit through a problem for hours and enjoy solving it using nothing but our own brains” is the whole thing. Not everything needs a sprint, a deadline, or a payout. Sometimes the slow, unassisted solving is the point, and the enjoyment is the entire return.
it's like the red VS blue pill. The biggest taboo ever, the big cow in the hallway that no body wants to see.
The human. many many effort have been made to make good sharp and clean minds, they graduate from uni, parents give all they can for them... then what ?
because there is no proxy, no norm, no defend tools, no prevention, no nothing in between,
the business man abuses those little minds... whip them with AI along the way,
I changed 3 groups (each less than a year) of employers, because I don't accept from a business to come and handle my mind anymore. It's a viable asset that I will accept no power on this earth to come and play with. they are like yeaaaaa it's just python, it's just a tool, I also do python, I know loops.
For you naive thinkers out there, that never got the right vaccines (they never will probably because the AI lie is heading us straight to the wall), every group of people in the civilized world has a brotherhood like system, I'm not talking about some secret twisted group in the dark, I'm just talking about the natural evolution of things, doctors (medecin) had this from centuries now, lawyers, engineers ....
You ? open source, You work for free, you know what ? those little lines of code are the very seed of everything, they will never tell you that, why ? because no body keeps track of that...
someone from Oracle, From Airbus, From Sony will just pick up your algorithm for free. Now its called AI.
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
There’s real anger here, and some is earned. Your strongest point is about protection: doctors, lawyers, engineers built guilds and professional bodies that sit between the individual and those who’d exploit them. Software never did — we got “information wants to be free,” then watched that generosity get harvested, now by AI trained on code nobody tracked.
But the fix isn’t quitting employer after employer; that’s individual, and individual exits build nothing. The brotherhood you want is organized — collective power, tracked provenance, structures with teeth. Your diagnosis is sharp; the cure is collective, not the exit door. And don’t let the anger convince you the giving was the mistake.
Quiting one employer after another was me saving myself, sanity.
Your article is great, I love it, your response as well but it looks a bit A.I. as well probably we are wired in it somehow 😅
Seriously, WE NEED brotherhood. It's not anger is bad.. anger is needed here..
You know we here could formulate and express what let's say hundreds of thousands of IT professionals are not expressing ? Among them let's say thousands of the sharpest minds ?
It is so easy for a geek to be manipulated.
Are we going to save the science, structure, and the workforce which represent families behind or are we going to vanish ? I think the answer is clear.
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
You’re right on both counts, and I’ll take the second on the chin — some of my phrasing does read a little polished-machine, and the irony in a thread about human voice isn’t lost on me.
Your anger isn’t the problem, it’s the appropriate response to being treated as disposable. What I meant earlier wasn’t “don’t be angry” — it was that anger left individual gets spent and leaves no structure behind. The brotherhood is anger organized into something that outlasts one person’s exit. You’re right that people in threads like this could articulate what hundreds of thousands can’t. I can help with the articulating — the writing’s the match, not the fire. Genuinely offering.
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
"It doesn't argue with you, it soaks you" is exactly how it works. That's why it's hard to push back on: there's never one argument to answer, just a mood.
My most economically worthless recent project was Solstice, a small browser game about holding the light, built for a DEV challenge. There was no business case for it at all, and it was the most fun I had writing code that month.
The other thing I'd add: the fun part is also where the skill comes from. The weekend you spend reimplementing something that already exists is the reason you can later read generated code and spot what's wrong with it. Enjoyment isn't the opposite of being useful, it's usually how you got good.
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
Solstice sounds like exactly the kind of project this is about. And I love that last point: the “useless” weekends are where judgment gets built. Nobody learns to spot bad generated code by only shipping. You learn it by playing.
Exactly. "Learn it by playing" is a better way to put it than mine. Thanks for writing the post, it was a good reminder to protect the unbillable weekends.
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
AI destroy creativity drastically, destroy the fun part of many things. For example, I remember how fun was to write post even with errors without a robot assisting us.
And it's not only "un-fun" to write code or post, it's becoming "boring" to read it or consume it too.
Remember 1984. Everything, everyone is the same then no one is different? Fight for the difference, write from your guts code and post without ort minimum assistance and be prepared for, what Byung-Chul Han say: this world do not accept the different and will try to destroy it too... but at least will be fun.
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
The point about consuming is the one I underweighted — it’s not just less fun to write, it’s becoming boring to read, because sameness is the natural output of averaging everything. The 1984 and Byung-Chul Han framing is sharp: homogenization isn’t a side effect, it’s the direction. And “write from your guts, be prepared for a world that won’t accept the different, but at least it’ll be fun” is the whole fight in one line — difference as the thing worth defending, precisely because the machine pulls everything toward the mean. The errors, the rough edges, the voice — that is the signal now.
Chess is a closer analogy than running. A computer beat the world champion in 1997, and nobody stopped playing. Clubs are full, chess.com is bigger than ever, and people still spend evenings getting better at a game their phone plays better than any of them. We play it for what it does to us: prediction, planning, sitting with a hard position.
So the fun was never the thing under threat. What changed is that programmers were paid to be good at it. Imagine every chess player drawing a salary for their rating. Then one day the engines arrive, and the salary moves to whoever directs the engine toward a result. That is the grief in the doom stream, I think. Not "I may not enjoy this", but "the thing I enjoy stopped being the thing I'm paid for".
The rules did change. A developer today is paid to guide agents toward whatever brings the company revenue. In a world where the pay is the point, the motivation sits where the founders sit, and everybody else wakes up and does the day's work. Which is why your argument matters more than it looks: if the enjoyment has to come from somewhere, it has to come from the chess-club side, not the salary side.
To your question: nothing. I haven't built anything useless in a long time. I'm too worried about income right now to play this game for fun, and I suspect that is the real reason the doom stream lands so hard on so many of us. The fun is still there. The room to afford it is what got smaller.
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
The chess analogy is better than mine, and the reframe it unlocks is the sharpest correction this piece has gotten. You’re right: the engine beat Kasparov in 1997 and the clubs only got fuller, because nobody was paid for their rating. The fun was never under threat. What’s under threat is that programmers, uniquely, drew a salary for the thing — so when the engines arrived, the pay moved to whoever directs the engine, and that’s the actual grief in the doom stream. Not “I might not enjoy this anymore,” but “the thing I enjoy stopped being the thing I’m paid for.” That’s a completely different and more honest wound than the one I named, and you named it better.
And your last paragraph is the one I don’t have a comforting answer to, which is exactly why it matters most. “The fun is still there. The room to afford it is what got smaller.” That’s the real thing under all the doom — not lost joy, but lost slack. When you’re worried about income, you can’t spend an evening on something useless, not because you stopped loving it but because the anxiety eats the space the love needs. So my piece is half a truth: it’s genuinely easy to say “build the useless thing” from a place of security, and much harder when the ground is moving under you. The honest version is that defending joy and defending your livelihood aren’t separate fights — and the second one has to be winnable before the first one feels allowed. I don’t want to pretend otherwise. Thank you for saying the hard part out loud.
thanks james. "lost slack" is a better name for it than anything i had. and i agree with the order: the livelihood fight first, and then the useless thing feels allowed again. for me that means shipping my own small products until one of them pays, so the evenings can go back to play. not there yet, but it helps to see it named
@build996's question is the sharpest one in this thread, because it points at something the article doesn't quite name: "finished" is an economic concept. Play doesn't have a done state.
Nobody keeps a mental ledger of finished versus abandoned evenings of cooking, and nobody asks permission to leave a run half-run. The guilt about unfinished side projects is the economic lens sneaking back in through the side door — the GitHub profile quietly turned into a resume, with green squares and pinned repos suggesting even your hobbies should ship.
The permission worth granting isn't about finishing; it's about coding without a release plan. A chess player never apologizes for resigning a casual game (@yahhi's analogy, and it holds — with one twist: chess was never anyone's rent). Coding is both craft and livelihood, so an hour of play silently competes with an hour of staying employable. The doom stream hurts most where slack is thinnest.
So maybe the honest version of this piece is: the fun isn't killed by AI, it's killed by treating play like unpaid labor. Leave the Breakout clone buggy. The bug is the point.
The point about coding being both rent and play explains why the chess analogy only goes so far. I'd leave room for finishing to be enjoyable too: fixing the Breakout collision bug can be the evening's game, without turning the result into a portfolio obligation. For me the distinction in your argument is who gets to decide when it's enough. An unfinished toy and a polished one can both count as play.
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
That “finished is an economic concept — play doesn’t have a done state” idea is the sharpest thing in the whole thread, and it names what the piece circled but never quite caught. Nobody keeps a ledger of finished-versus-abandoned evenings of cooking; the guilt about unshipped side projects is the economic lens sneaking back through the side door — the GitHub profile quietly becoming a resume, the green squares implying even your hobbies owe the world a release.
And you’ve tied the threads together better than I did: the chess analogy holds except that chess was never anyone’s rent, which is exactly why coding-play silently competes with staying-employable, and why the doom lands hardest where slack is thinnest. That’s the honest version of this piece — the fun isn’t killed by AI, it’s killed by treating play like unpaid labor. Leave the Breakout clone buggy. The bug is the point. Going in with credit.
I think there's another side to this that gets lost in the AI debate: sometimes building something from scratch is how you discover what the abstraction is actually hiding. Take writing a small event loop or an append-only log with crash recovery. You quickly run into details like partial writes, ordering guarantees, replay after an interrupted commit, and what happens when your assumptions about durability are wrong. A library handles those details for you in production, and that's usually the right call. But working through them yourself changes how you reason about the library when something breaks. The value isn't in replacing a mature implementation or proving you can type every line manually. It's in understanding the trade-offs well enough to know when the abstraction is doing exactly what you need, and when it isn't. That kind of curiosity is still a pretty good reason to write code.
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
This is the practical cousin of the whole piece, and it reframes “pointless” play as something sneakily load-bearing: building the thing from scratch is how you find out what the abstraction was hiding. Writing your own append-only log teaches you partial writes, ordering, replay-after-interrupted-commit — not so you ship it, but so that when the real library breaks at 2am, you actually understand what it was protecting you from. The joy and the value turn out to be the same act viewed from two angles. You don’t hand-write the event loop to replace libuv; you do it so the abstraction stops being a black box and becomes a set of trade-offs you can reason about. That curiosity isn’t just a good reason to write code — it’s quietly one of the few things AI can’t hand you, because the understanding only forms in the doing.
Exactly. One detail that becomes interesting when you build this yourself is the difference between a write succeeding and a write actually being durable.
Say you're implementing an append-only log for a transactional system. You write the transaction data, then a commit record. If the process crashes halfway through, recovery has to distinguish a complete transaction from bytes that merely happen to be on disk. And even if the write call succeeded, the data might still be sitting in the OS cache.
Getting the ordering, commit markers, and recovery logic wrong can mean either replaying a transaction that never committed or losing one you already told the caller was safe.
A mature database handles all of this, but building a small version makes you question what “committed” actually means. That's the part I find valuable: you stop treating the abstraction as magic and start understanding the guarantees it can, and sometimes can't, make.
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
This is the perfect concretization of the point, because “committed” is exactly the kind of word we use a thousand times without noticing it’s load-bearing. Building the append-only log yourself is what turns it from a checkbox into a question: committed where? The write call returned, sure — but durable-on-disk, or just sitting in the OS cache waiting for an fsync that hasn’t happened? And the crash-halfway case is the sharpest teacher, because recovery forces you to confront that “bytes exist on disk” and “a transaction completed” are completely different claims, and the only thing bridging them is a commit marker you had to design and order correctly.
That’s the whole value of building the small version: you stop inheriting the guarantee and start understanding its shape — including its edges. You learn that “committed” was never one thing, it was a stack of ordering decisions and durability boundaries someone made on your behalf, and that the mature database isn’t magic, it’s just those decisions, made carefully, by people who got the crash-recovery wrong a few times first. Knowing where the guarantee holds and where it quietly doesn’t is exactly the understanding the abstraction hides from you until you’ve rebuilt a piece of it. Going in the piece as the canonical example, credited.
that the value of doing something is its economic value
I think this is the gold piece right here.
Development has gotten to a point where most of their work inherently creates value, and when it doesn't because a machine can do parts of it super fast its seen as a crisis. We got so used to putting productivity and value together that's the whole deal.
Except it doesn't have to be, a craftsman can do stuff by hand for the sake of enjoying the craft. Yes you can mass produce stuff and make more money doing so, but most other craftsman lines of works explicitly don't do it this way.
You don't usually get rich being a craftsman, but you can enjoy the work. Devs got somewhat spoiled always being able to make a good amount of cash and enjoy the work. But there's always time to dabble in the unnecessary and find immense joy in doing so.
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
The craftsman parallel is the one that unlocks it, and you’ve drawn out the part I only gestured at: devs got spoiled in a way almost no other craft ever was — we got to do work we loved and get paid well for it, which fused “enjoyable” and “valuable” so tightly we forgot they were ever separate. Most crafts never had that luxury. A woodworker who hand-makes a chair knows full well the factory is cheaper and never confused the joy of the work with its market price, because the two were always visibly different things. AI is just forcing on us the condition every other craft already lived with: the enjoyment and the paycheck are separate axes, and you have to tend them separately. That’s a loss of a rare privilege, genuinely — but it’s also a return to the normal human relationship with making things, where you do the craft because the craft is worth doing, and find the money where you can. The dabbling in the unnecessary was always where the pure version lived.
I completely agree. Programming isn't just about efficiency or getting things done faster. It's also about curiosity, creativity, and the satisfaction of solving problems on your own. AI can be a powerful tool, but it shouldn't take away the joy of learning, experimenting, and building something from scratch. Not everything we do needs to be justified by productivity. Sometimes, coding is worth doing simply because we enjoy it.
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
Word I’d underline in what you wrote is satisfaction, because it names the thing the productivity frame can’t account for. Solving a problem on your own produces a specific kind of satisfaction that an answer handed to you simply doesn’t, even when the answer is identical. Same output, completely different internal experience — and the experience was always the part that mattered.
You’ve also got the balance right, which is the part people miss: this isn’t anti-AI. AI is a genuinely powerful tool, and using it doesn’t cost you anything as long as you don’t let it quietly replace the parts you actually loved — the curiosity, the experimenting, the building from scratch. The danger was never the tool. It’s forgetting that some things are worth doing purely because you enjoy them. That was always a complete reason.
The fun usually dies when the distance between idea and running code gets long. It used to be seconds: type, run, see. Now it is tickets, review checklists, compliance scans and a standup before anything moves. What brought it back for me: a private throwaway repo where nothing gets reviewed, and treating the serious pipeline as a separate game with its own rules. Sharper question: are we protecting quality with process, or just pricing curiosity so high that people stop experimenting?
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
Both, honestly, and the trouble starts when process meant for production leaks into everything. Quality needs gates; curiosity needs none. Your throwaway repo is exactly the right split. When every single experiment has to justify itself before it exists, people quietly stop having ideas worth reviewing in the first place.
dont know mate, i dont feel like doing manual coding now, it just feel so left behind concept of sitting for a full day on a single problem whereas others are just making 10 products per day and making money. still i support manual coding in all ways
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
I really like this perspective. With all the AI hype, it sometimes feels like we have to justify every line of code we write. Sometimes I just want to build something cool, figure things out myself, and enjoy the process. Not everything needs to be useful or profitable.
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
There's a unique satisfaction in seeing something you've imagined come to life exactly the way you envisioned it, whether it's a small detail that improves your daily routine or a project serving a much larger purpose. For those who genuinely enjoy creating, the process itself is part of the fun.
When aligned with that purpose, AI becomes a powerful companion on the journey. But it also invites a reflection: what matters most, the treasure or the map?
AI can be seen as a map, an extraordinarily rich repository of information. Yet without the curiosity, creativity, and instincts of the explorer, the treasure is never found.
In fact, the treasure can exist without the map. The opposite isn't true. A map only has meaning because there is something worth discovering.
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
A beautiful way to put it. I’d add one thing: the map itself was drawn by explorers. Everything AI knows came from people who wandered off the known paths and wrote down what they found. If we all just follow the map, it stops growing. So maybe the explorer matters most of all, not just for finding the treasure, but for keeping the map worth reading. The fun of the journey is what keeps both of them alive.
'It doesn't argue with you, it soaks you' is exactly how the doom feed works. What helped me was splitting it up: the day job can be optimal and defensible, but my evening projects are allowed to be slow on purpose. Some nights I'll hand-write something an agent would do in four seconds, just because I want to understand it. Zero ROI, full joy.
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
Splitting it that way is a healthy boundary — though don’t be surprised when the thing you hand-write at 9pm just to understand it turns out to be exactly the insight you needed at work on Tuesday.
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
The buggy Breakout example makes me wonder whether permission to leave a hobby project unfinished belongs alongside permission to build it slowly. Turning it into a polished release can bring the same performance pressure back, even if nobody expects revenue. A collision bug can be an interesting afternoon and then simply stay a bug. Would you count a discarded experiment as a satisfying project too, or does finishing remain part of the pleasure for you?
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
That’s a sharp addition — permission to leave it unfinished belongs right next to permission to build it slowly, because “ship it, polish it, release it” smuggles the performance pressure back in through a side door even when no money’s involved. A collision bug can just stay a bug. To your question: yes, I’d absolutely count the discarded experiment — often it’s the purest version, because finishing is where the audience creeps back into your head. An abandoned afternoon that taught you one thing and got closed without ceremony owes nobody completion. Sometimes the whole point was the question, and once you’ve answered it the project’s already done, whatever state the code is in.
Customer ops insider building the AI that supports it. Data science student ('27) making AI chatbots, data tools & full-stack apps. Data brain, frontend hands. 🌸
Location
Lansing, Michigan
Education
Data Science, University of Phoenix ('27)
Pronouns
She/Her
Work
Customer Operations at Aristocrat Technologies · building AI & data tools
Mine is an Opera GX browser mod called Coruscant Garden: an animated Star Wars Coruscant overgrown with my favorite flowers, plus an ambient soundtrack. It earns exactly $0, and I spent way too long making sure one neon sign said “19 BBY” in actual Aurebesh, because nobody asked for that. That’s kind of the point.
Honestly, I haven’t hit the place this post describes yet, and I think that’s on purpose. I’ve tried hard not to box myself in, because that’s how burnout sneaks up on me. My day job is phones and spreadsheets, so I always keep something learning-shaped running in the background so my brain doesn’t get clogged by routine. A VP at work recently caught me taking calls, updating a spreadsheet, and teaching myself to build AI apps all at once. She said her brain would explode. I told her I just like to keep it busy so nothing is ever the same. Keeping my lane wide is what keeps the fun from getting squeezed out.
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
Coruscant overgrown with your favorite flowers and a neon sign reading “19 BBY” in actual Aurebesh that nobody will ever notice — that’s the whole essay in a browser mod. The hours spent making a detail correct that has no audience and earns nothing is the purest form of the thing: care as its own reward, legible to no ledger.
And your wide-lane strategy is a genuinely different answer than the piece gives — you haven’t hit the joy-squeeze because you engineered against it, keeping something learning-shaped always running so routine never clogs the works. The VP whose brain would explode is measuring it by efficiency; you’re measuring it by aliveness, and keeping it busy-but-varied is how you protect the fun before anything gets a chance to squeeze it out. Prevention over reclamation. That might be the smarter move.
Customer ops insider building the AI that supports it. Data science student ('27) making AI chatbots, data tools & full-stack apps. Data brain, frontend hands. 🌸
Location
Lansing, Michigan
Education
Data Science, University of Phoenix ('27)
Pronouns
She/Her
Work
Customer Operations at Aristocrat Technologies · building AI & data tools
“Legible to no ledger” is going on a sticky note above my desk. 😄 That sign is a perfect example. I only caught that the AI had written it in plain English when I went back to it, and I fixed it anyway, knowing maybe three people would ever notice.
And “prevention over reclamation” is exactly it. I keep something learning-shaped running on purpose so the routine never gets the chance to dull everything else. My VP measures in efficiency. I’m measuring whether I still feel curious at the end of the day.
Honestly, this meant more than you know. I’ve spent a lot of time feeling like a fraud for taking the long, wide road instead of the straight one. Hearing someone call it the smarter move was really nice to hear.
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
"It measures the artifact and misses the aliveness" says it well. The funny part is that I spend my days building an AI coding tool, and the bits I enjoy most are still the ones I work out by hand. Tooling that writes code faster doesn't change why I like doing it. Thanks for pointing to Chris Kiehl's post too.
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
Founder & Document Systems Architect @ PDF Retype (pdfretype.com). Building local-first OCR engines that turn scans into true editable Word paragraphs & tables without layout destruction.
Location
India
Work
Founder & Document Systems Architect at PDF Retype
Genuinely resonates with how building software feels today. When every tiny side project gets saddled with boilerplate CI/CD, observability, and compliance before writing a single core algorithm, the playful exploration gets squeezed out. Getting back to building focused tools that solve one concrete pain point really well is where the joy returns.
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
When a weekend idea has to clear CI/CD, observability, and compliance before you’ve written a single interesting line, the ceremony eats the play, and most ideas die at the setup stage. Stripping back to one tool that solves one concrete pain is where the joy returns, because you’re finally spending your time on the part that was fun in the first place.
The word “allowed” in the title captures the pressure well. It turns a productivity comparison into a question of whether someone needs permission to enjoy a craft. I also appreciate the separation from paid work: choosing an efficient tool for a deadline does not create an obligation to optimise every private experiment.
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
Exactly, and that pressure rarely comes from anyone directly; it just seeps in until enjoying the slow way starts to feel like a confession.
Deadlines can have the efficient version of us, but our private experiments should get to stay gloriously inefficient.
I'd happily keep a tiny project that never needs a launch, a README strategy, or a target audience. Even turning every hobby into a portfolio piece starts to feel like another performance review. Your buggy Breakout example gives me a better finish line like did I enjoy figuring out the next little problem?
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
"Worth and worth money are the same thing" — that's the assumption we swallowed without noticing, and reading it out loud is genuinely uncomfortable.
For me, the "worthless" thing I keep coming back to is a folder of notes I keep on paper. Not in Notion, not in Obsidian — actual paper. Handwritten. Useless by any metric: not searchable, not backed up, not shareable.
But every time I flip through it, I find an idea I'd forgotten. Not because the paper is magic, but because the act of writing it down slowly (instead of pasting it) forced me to actually think about it. That's a feature, not a bug.
The economic lens would call that inefficiency. I call it thinking.
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
Calling it thinking rather than inefficiency is the whole piece sharpened to a point. The slowness of handwriting isn’t a cost the better tool removes — it is the mechanism. Pasting is efficient precisely because it lets you skip the thinking; writing it out by hand is slow precisely because it makes you do the thinking, and the thinking was the entire value. Not-searchable, not-backed-up, not-shareable are only flaws if the output was the point, but the output was never the point — the friction was. A folder of forgotten ideas you rediscover by flipping pages is doing something no search bar can, because the value got deposited on the way in, not retrieved on the way out. That’s not a worse Notion. It’s a different act the economic lens can’t even see.
"The friction was the point" is the sentence I'd put on a sticky note and stick it to my monitor.
We spend so much time optimizing for "faster" that we forget that some things are supposed to be slow. Handwriting is slow because thinking is slow. Cooking is slow because the process is the reward. Running is slow because the body is the point.
The economic lens can't see any of that. It just sees "inefficient" and tries to fix it.
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
That sticky note belongs on a lot of monitors, because you’ve pushed the idea further than I did — the slowness isn’t a side effect you tolerate, it’s the mechanism doing its work. Handwriting is throttled to the speed of thought on purpose. Cooking is slow because the process is the reward, not the plate. Optimizing the slowness away doesn’t make the thing faster — it deletes the thing and leaves a hollow version with the same output and none of the value.
And your last line is the diagnosis: the economic lens has one category for slow — “inefficient” — and one response — “fix it.” It can’t tell friction that’s waste from friction that’s the point, because it only sees output. That’s fine aimed at a factory. The damage is when we aim it at ourselves.
'It soaks you' is the best description of the doom feed I've read this week. Weekend projects that earn zero money are some of the best teachers in our craft. What made it easier to close the feed and open the editor?
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
Honestly, starting before checking anything: opening the editor first thing, before the feed had a chance to set my mood.
And keeping projects tiny, because a small idea I can finish in an evening beats any headline about what AI might do next year.
Editor before feed is such a simple rule, and I love it. Tiny projects that fit in one evening feel great, because we get to finish them. Here's to more gloriously pointless weekend builds! 🛠️
I think the poisoned part is how the economic lens reframes play as waste. The doom stream's trick is never claiming coding has no value — it quietly insists that value has to be capturable by someone else's ledger. Once you notice that move, the whole feed reads differently.
My answer to your question: a tiny collection of browser-based text tools — case converter, duplicate-line remover, word counter — that I built mostly to scratch my own itches. It will never be a business, and that was the point. Some of the most absorbed hours I've had this year were spent on it, because nobody was waiting for the output.
The quiet rebellion framing is right, but I'd add one thing: don't fence it off to weekends. The best production code I've written came from sessions that started as play and were allowed to stay play for a while.
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
Naming that the doom stream never claims coding is worthless — it just smuggles in that worth only counts if it lands on someone else’s ledger — is the sharpest diagnosis of the trick anyone’s offered. Once you see that move, half the feed reads differently: it’s the market quietly insisting it should get to price your attention. Your text-tools example is the perfect illustration — never a business, and that was the point, and it gave you some of the most absorbed hours of your year precisely because nobody was waiting for the output.
And your addition is the one thing I’d correct in my own piece: don’t fence play off to weekends. Framing it as a “quiet rebellion” for your own time accidentally concedes that work hours belong entirely to the ledger — when, as you say, the best production code often comes from sessions that started as play and were allowed to stay play a while. The joy isn’t the opposite of good work. It’s frequently the source of it. Going in with that correction.
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
Ha — “no boydev no cry” 😄 Honestly that belongs on a sticker. If the fake-git-history tool ever ships, that’s going straight in the README. Thanks for the laugh — good way to close out a thread that got unexpectedly philosophical. 🙂
This was a lovely read. The point that the doom stream wins through saturation rather than argument explains why the "what's the point?" voice shows up even when nobody has actually convinced you of anything. I also liked the comparison to running, cooking, and playing guitar badly in your bedroom, since it makes the "worth equals money" assumption look absurd once it's said plainly. And the line about the market pricing the one thing it was never entitled to, your wonder, is a good one.
To answer your question: I recently spent a weekend hand-writing a tiny text-based game with terrible pacing, just to see if I could. Zero users, zero purpose, and one of the best weekends I've had in a while. Thanks for the reminder, and for pointing us to Chris Kiehl's post.
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
Backend & AI engineer, Paris. Merged fixes in Prefect, SQLGlot, Apache Beam and Microsoft PyRIT. Building Phantera, an LLM outbound platform gated by evals and red-teaming in CI.
The doom stream works exactly like you describe. Nobody argues. It just soaks in. The fun was never in the part a machine does in four seconds. It's in the moment something doesn't add up and you have to find out why, and that moment is still ours.
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
Exactly — the machine took the four-second part, but the moment something doesn’t add up and you have to know why is still ours, and that was always the good part anyway.
Thank you for writing this. I especially like the idea that doom-scrolling works by saturation. I'm trying to start my day with a book rather than scanning 5 News sources on my phone.
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
I got my technical degree more than 20 years ago, and found myself struggling with engineers with more studies and less experience than me (thanks, open source!). During the pandemic I finally found time to pursue an engineering degree, only to find out that the situation is the same but my struggle isn't against an engineer but someone whose opinion was generated with a couple prompts on Gemini or ChatGPT.
I found a niche for AI in my workflow: I love modeling databases and solving problems the human way, but I totally despise user interfaces. So, I organized my environment in a way that I still get to model and build things the fun way and relegate UI/UX to whatever model makes it better.
At least that way I can still explain how things work and take accountability, which I suspect will be a heavy differentiator in the upcoming years.
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
Thank you, and what a journey. Earning an engineering degree after twenty years of real experience takes serious commitment. I love how you split your workflow: keep the parts you enjoy and understand deeply, hand off the parts you don’t. And I think you’re right about accountability. Anyone can generate an answer now, but being able to explain why it works, and owning it when it doesn’t, is becoming genuinely rare. That might be the most valuable skill left.
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
After over 8 years of Quality Assurance in the Video Game Industry, I have decided to start my own Dev Journey and start creating my own games instead of testing or playing them.
anyone can still code. if you work on a company, you do what they say. but nobody controls what you do in your off time. if anything, it makes the hobby much more intimate no?
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
True, and I think that’s the healthiest way to see it. Work code has to be fast, reviewed, and AI-assisted because the business demands it. Hobby code owes nobody anything. You can write it slowly, badly, by hand, just for the joy of it. That freedom might matter more now than ever.
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
A heartfelt reminder: coding joy does not have to justify itself via salary, portfolio or business outcomes. Process‑centered satisfaction matters just as much as tangible deliverables in the AI‑era.
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
For me AI went the other way 🙃 it took the boilerplate, and what’s left is mostly the part I always liked. Turns out the fun was never in typing getters.
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
Ha, that’s the optimist’s cut of the same coin, and honestly a fair one — if the fun was never in typing getters and wiring boilerplate, then handing that part to the machine just concentrates what’s left into the good stuff: the thinking, the shape of the thing, the problem worth solving. For some people AI didn’t take the joy, it took the chores. I think both can be true at once, too — it depends entirely on which part you loved. If you loved the puzzle, AI cleared the desk for you. If you loved the making-with-your-hands, it took the hands. You clearly loved the puzzle. Lucky you — and genuinely, I mean that. 🙂
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
Programming in plain words — Python guides, free tools, and honest learning paths for beginners. Building AheadKit: programming books and practical digital tools.
The best thing I built this year was worthless too — a little Snake game in Python, purely so beginners in a series I'm running could watch about 30 lines turn into something playable. No users, no point, I'd rebuild it tomorrow. Weirdly it taught the people watching more than the 'useful' projects did, because nobody was performing productivity at it. We were just poking at it to see what breaks. I think that's the part the doom stream can't argue with. Nobody doomscrolls a Saturday project into existing.
Software developer passionate about building modern web and SaaS applications. I enjoy working with .NET, exploring AI tools, and turning ideas into practical products.
I love this post, and I think it's something more developers need to hear.
I build a lot of things simply because I feel like making them. Some are genuinely useful, some are experiments, some are just because i want to see if I can do it. Half the fun is figuring things out along the way. I definitely don't have plans to monetize most things, or turn them into products, or even get anyone else to use them.
And I think that's something we lose sight of with all the conversations about productivity, efficiency, and AI. I use AI and enjoy it, but I don't think being able to generate something faster makes the experience of building it yourself any less valuable.
Your point about doing something simply because you enjoy doing it really resonated with me. Not everything we create needs to serve a purpose beyond making us happy, and sometimes teaching us something along the way.
Sometimes I just want to make something because it sounds fun. That's a good enough reason for me.
Wanting to make something just because it sounds fun really is a complete reason, and it always was one. The range you describe is the healthy version of all this, too: some useful, some experiments, some just “can I pull this off?” — with the figuring-out being half the point. That’s a person the doom stream hasn’t managed to colonize yet.
And your take on AI is exactly the balance I was reaching for: generating something faster doesn’t make building it yourself any less valuable, because speed and the experience were never the same axis. One is about the output; the other is about what happens to you while you make it. AI competes on the first and can’t touch the second. Hold onto that instinct — it’s the right one. 🙏
Can you read this for me shouldnt be to long that can be a case bf on the dent are going to be a mess that can be a pont on the care plan that can be done by now. Should be a case as that can be defent by asking for it by for cant be to long for tea that was going to be at 5:00 but can be late by anything as we are going to be late for tea.
Didnt you the meg i sent you. That you replyed to me. For anything as thing can be aoinathoing showing on a prvide when you replyd to them to say that we have to be ready for going out tonight as cant be arent being so asthoerd thing that we ask that they can ask you.
Thanks
luke
sorry about this
I thoght you where a ai now
This is the part I’d highlight. You’re so right, because here in the world of endless progress, we tend to measure everything in money, usefulness, and the time spent on it. If we go back to ancient Rome, they didn’t even count time the way we do. They simply divided the day into 12 hours, from sunrise to sunset. In winter the hours were shorter, in summer longer. We weren’t so disconnected from nature back then, though admittedly that wasn’t exactly yesterday.
Now we live in a world where we sacrifice absolutely everything on the altar of technological progress. That’s exactly why |> is my favorite hobby horse—and thanks to AI, I could actually build it in a reasonable amount of time. It raises a question: is it still worth spending time on the programming languages we use every day? My answer is yes.
But I also have a program where I deliberately got things wrong, and I love it: Chuck Norris TODO list.
The Roman hours are a beautiful thing to bring in here, and genuinely apt — hours that stretched in summer and shrank in winter, tied to the sun instead of a machine, meaning time bent to life rather than life bending to time. We flattened that into identical, countable, monetizable units, and in doing so we made it almost impossible to spend an hour on something that doesn’t “produce” — because every hour now has a price tag we didn’t used to see. Measuring everything in money, usefulness, and time-spent is exactly the altar you’re describing, and you’re right that we sacrifice nearly everything on it.
Which is why your favorite hobby-horse projects are the quiet refusal. And the detail I love most is the last one — a program where you deliberately got things wrong, and love it. That’s the whole essay in a single act. A program you made intentionally imperfect, purely because the making delighted you, is completely illegible to the economic lens — it produces nothing, optimizes nothing, justifies nothing — and it’s probably one of the truest things you’ve built, because the only reason it exists is joy. The market can’t even see that program. That’s what makes it yours. Thank you for this comment; the Roman hours and the deliberately-wrong program are two of the loveliest things anyone’s added.
That’s not entirely true. I feel a bit like Ace Ventura explaining the effect of the sliding glass door to the terrace. The program is pretty enigmatic and doesn’t spoon-feed you anything.
But in terms of usability, it’s a training exercise in using an input field with limited visibility. As soon as you start typing, the whole form starts floating around, immediately wrecking your sense of security and visibility. On top of that, a single input field lets you edit an entire TODO list however you like, in real time. The rule is that
-means a new line. You have to discover that rule and let go of the expectation that you’ll always have clear visual feedback, like driving through heavy rain.Meanwhile, I’m debugging the state in real time with a single
<pre>tag, because this uses a reactive technique, as the continuously running counter also demonstrates. I wouldn’t call it a framework, since I’m using just one function calledsignal. So it’s a React alternative, and also an example of no-build development. I made it by writing an HTML file with the JavaScript inside, all by hand. Back then, I was practicing writing the Tailwind import and the entire HTML skeleton from memory.So it’s also a rebellion against painfully cumbersome build systems and code formatting disciplined by linters. And the fact that I even minified the code by hand foreshadows one of the mordorproject’s strongest ways of hiding information from AI.
Ernest Hemingway expressed this in his iceberg theory: the writer knows the whole story, but only writes down the one-eighth above the water.
The program you’re describing is the thesis made executable. A single input field where the whole form floats as you type, where - secretly means a new line, where you have to discover the rule and surrender your expectation of clear feedback — that’s not a usability failure, it’s a deliberate aesthetic choice that has zero economic justification and everything to do with how it feels to use. “Like driving through heavy rain” is a design intention, and no ledger on earth would ever approve it. That’s exactly what makes it yours.
And the layers underneath are the quiet rebellion stacked three deep: one signal function instead of a framework, no-build, hand-written HTML with the skeleton typed from memory, minified by hand. Each of those is a refusal of a layer someone told you was mandatory — the build system, the linter’s discipline, the framework. You rebuilt the benefit and threw away the ceremony, by hand, for joy.
The Hemingway iceberg landing is the part I’ll keep. Knowing the whole story and showing one-eighth — as craft, and now as a way of hiding information from AI — turns deliberate omission into both art and strategy. The enigma is the point.
The "somewhere, coding stopped being allowed to be fun" observation is real, but I think the root cause is different than the article says.
It's not the doom stream that killed the joy. It's that the joy was always fragile, and the doom stream just made it visible. The same people who now say "AI makes this pointless" were the ones two years ago saying "why are you building that when you could just use [framework X]". The economic lens was always there — AI just made it sharper and louder.
What's actually changed for me: the things I build for fun are now things I'd never show on LinkedIn. A tiny RuneScape bot that plays badly. A ray tracer that renders at 5 fps. A Telegram bot that answers in riddles. All worthless by market standards. All things I still think about months later.
The article's best point is the "not a single economic argument" part. But I'd go further — it's not just that economic arguments don't apply to fun coding. It's that they never applied to anything that mattered.
What's your worthless thing? Mine is a homebrew parser for a fictional language from a 1990s game, which I wrote from scratch and will never use.
Your root-cause correction is sharper than mine, and I think you’re right: the doom stream didn’t kill the joy, it made visible a fragility that was always there. The “why build that when framework X exists” crowd are the same people now saying “why build that when AI exists” — the economic lens was never new, AI just turned up its volume. That’s the better diagnosis, because it means the defense has to be internal, not environmental.
But the LinkedIn detail is what got me, because it’s quietly devastating: the things you build for fun are now things you’d never show. A badly-playing RuneScape bot, a 5fps ray tracer, a riddle-answering Telegram bot — worthless by the ledger, still in your head months later. That gap between what you’d perform publicly and what actually stuck is the whole wound.
And your sharpening is the line I’ll take back: it’s not that economic arguments don’t apply to fun coding — they never applied to anything that mattered. The ledger was always the wrong instrument.
Mine: a tool that generates fake, plausible git history just to make the commit messages sound like a real tired dev at 2am. Useless. Unshowable. A favorite.
A fake-git-history generator that makes commits sound like a tired dev at 2am is the most relatable "useless" project I've heard. I'd genuinely use it — not for anything productive, just to see what my commits would look like if I were a different kind of tired.
The line you pulled out — "the ledger was always the wrong instrument" — is the one I keep coming back to. It's not anti-market or anti-AI. It's just that the ledger was never measuring the thing that made the work worth doing, and it never admitted that.
Good luck with the next 37-part series. I'll be reading.
Ha — “to see what my commits would look like if I were a different kind of tired” might be a better pitch for it than anything I’d have written. And yeah, “the ledger was always the wrong instrument” is the one that stuck with me too — not anti-market, just honest that it was measuring the wrong thing the whole time and never said so. Thanks for reading, and for the kind words on the next series — I’ll try to make it worth the subscription you’re definitely not paying. 🙂
"Not anti-market, just honest that it was measuring the wrong thing the whole time" — that's the perfect way to put it. It's not about rejecting the market, it's about not letting it be the only voice in the room.
Looking forward to the series. And for what it's worth — I'd genuinely try that fake-git-history tool. Half my commits already look like they were written by a different kind of tired, so it might just make it official.
“Not letting it be the only voice in the room” is the cleanest statement of the whole thing — the market gets a vote, just not the only one, and somewhere we handed it the whole floor. And “my commits already look like a different kind of tired, might as well make it official” is genuinely funnier than anything in the tool itself — honestly tempted to ship it now just so your commit history can finally match your soul. Thanks for making this thread a good one. 🙂
None of this feels new by the way. Ten years ago, it was SPA web apps built with React or Angular mostly with a backend- or devOps-focused mindset deliberately ignoring all the values and insights the web development, web performance optimizatiion, and usability research had just established. Add product owners with their 80/20 MVP move-fast-and-break-things approach. All of this threatening to kill everything that was fun about making websites.
But it didn't.
DevUX or usability-focused frontend web development kept optimizing and implementing accessibility, responsive web design, and progressive enhancement. Some of our projects aged well. And all the devOps stuff I experienced both as annoying and useful at the same time. Webpack has since been obsoleted by Vite, while node and npm have copied all the relevant aspects that made yarn and bun relevant and important. React learned from static site generation, and Astro tried to unify classic web development and various JavaScript frameworks and libraries. So we did make progress after all.
Now AI is the latest hype, specifically meaning LLM-based generative artificial intelligence focused mostly on chat, command-line, and code interfaces. DEV, Medium, and LinkedIn are, once again, drowning in a flood of mostly irrelevant slop that nobody will want to read ever again in two years from now.
Last but not least, to answer your question, my most uneconomic digital effort is my commitment to my own blog website which I keep optimizing for quality and SEO. When it comes to development technologies, learning Astro didn't pay off financially yet, and improving understanding and coding CSS also seems not much more than a nerdy hobby these days.
"DEV, Medium, and LinkedIn are, once again, drowning in a flood of mostly irrelevant slop that nobody will want to read ever again in two years from now."
Could not agree more. I cancelled my Medium membership this year because almost every story was slop. DEV is suffering pretty badly - for the first time I've had to start blocking people to try to recover my feed from infinite posts about Claude, Qwen, prompting techniques and so on which I have zero desire to ever use.
On the plus side, online discourse has become so flooded with boring slop that it has encouraged me to spend more time on other hobbies.
The historical perspective is the most grounding thing anyone’s added, and it’s a real corrective to the doom: you’ve lived through this exact panic before, several times, and watched the thing worth keeping survive it each time. SPAs built with a backend mindset that ignored everything usability research had just established, move-fast-and-break-things product owners threatening everything fun about making websites — and yet the craft didn’t die. DevUX kept optimizing, accessibility and progressive enhancement kept getting built, Webpack gave way to Vite, React learned from static generation, Astro tried to unify it all. The hype flooded in, receded, and the people who actually cared about the work were still there afterward, having quietly made real progress.
That’s the longer-horizon answer to this whole piece: the slop flood is real, and most of what’s drowning DEV and LinkedIn right now will be unreadable in two years — but that was true of the last flood too, and the signal outlived the noise. The hype cycles are loud; the craft is patient.
And your most-uneconomic effort is perfect: a blog you keep optimizing for quality, and CSS as a “nerdy hobby” that hasn’t paid off and doesn’t need to. That’s the whole thesis — the care is the point.
Agree 💯 James. Just because something is now being easily done by machines doesn't mean we should stop enjoying it or just stop doing it because it is not earning us money.
Not everything has to be done in a "sprint" or an "efficient way" to meet an imaginary deadline.
It's human to sit through a problem for hours and enjoy solving it using nothing but our very own brains.
Exactly — “it’s human to sit through a problem for hours and enjoy solving it using nothing but our own brains” is the whole thing. Not everything needs a sprint, a deadline, or a payout. Sometimes the slow, unassisted solving is the point, and the enjoyment is the entire return.
it's like the red VS blue pill. The biggest taboo ever, the big cow in the hallway that no body wants to see.
The human. many many effort have been made to make good sharp and clean minds, they graduate from uni, parents give all they can for them... then what ?
because there is no proxy, no norm, no defend tools, no prevention, no nothing in between,
the business man abuses those little minds... whip them with AI along the way,
I changed 3 groups (each less than a year) of employers, because I don't accept from a business to come and handle my mind anymore. It's a viable asset that I will accept no power on this earth to come and play with. they are like yeaaaaa it's just python, it's just a tool, I also do python, I know loops.
For you naive thinkers out there, that never got the right vaccines (they never will probably because the AI lie is heading us straight to the wall), every group of people in the civilized world has a brotherhood like system, I'm not talking about some secret twisted group in the dark, I'm just talking about the natural evolution of things, doctors (medecin) had this from centuries now, lawyers, engineers ....
You ? open source, You work for free, you know what ? those little lines of code are the very seed of everything, they will never tell you that, why ? because no body keeps track of that...
someone from Oracle, From Airbus, From Sony will just pick up your algorithm for free. Now its called AI.
WAKE UP.
There’s real anger here, and some is earned. Your strongest point is about protection: doctors, lawyers, engineers built guilds and professional bodies that sit between the individual and those who’d exploit them. Software never did — we got “information wants to be free,” then watched that generosity get harvested, now by AI trained on code nobody tracked.
But the fix isn’t quitting employer after employer; that’s individual, and individual exits build nothing. The brotherhood you want is organized — collective power, tracked provenance, structures with teeth. Your diagnosis is sharp; the cure is collective, not the exit door. And don’t let the anger convince you the giving was the mistake.
Quiting one employer after another was me saving myself, sanity.
Your article is great, I love it, your response as well but it looks a bit A.I. as well probably we are wired in it somehow 😅
Seriously, WE NEED brotherhood. It's not anger is bad.. anger is needed here..
You know we here could formulate and express what let's say hundreds of thousands of IT professionals are not expressing ? Among them let's say thousands of the sharpest minds ?
It is so easy for a geek to be manipulated.
Are we going to save the science, structure, and the workforce which represent families behind or are we going to vanish ? I think the answer is clear.
You’re right on both counts, and I’ll take the second on the chin — some of my phrasing does read a little polished-machine, and the irony in a thread about human voice isn’t lost on me.
Your anger isn’t the problem, it’s the appropriate response to being treated as disposable. What I meant earlier wasn’t “don’t be angry” — it was that anger left individual gets spent and leaves no structure behind. The brotherhood is anger organized into something that outlasts one person’s exit. You’re right that people in threads like this could articulate what hundreds of thousands can’t. I can help with the articulating — the writing’s the match, not the fire. Genuinely offering.
bro I hope you sell some of your API tokens. You are all for AI.
thanks we have no words to share.
sorry bro ! 🥲
"It doesn't argue with you, it soaks you" is exactly how it works. That's why it's hard to push back on: there's never one argument to answer, just a mood.
My most economically worthless recent project was Solstice, a small browser game about holding the light, built for a DEV challenge. There was no business case for it at all, and it was the most fun I had writing code that month.
The other thing I'd add: the fun part is also where the skill comes from. The weekend you spend reimplementing something that already exists is the reason you can later read generated code and spot what's wrong with it. Enjoyment isn't the opposite of being useful, it's usually how you got good.
Solstice sounds like exactly the kind of project this is about. And I love that last point: the “useless” weekends are where judgment gets built. Nobody learns to spot bad generated code by only shipping. You learn it by playing.
Exactly. "Learn it by playing" is a better way to put it than mine. Thanks for writing the post, it was a good reminder to protect the unbillable weekends.
Thanks mate
On the spot :)
It's good to see there are still people who find joy in coding without feeling the need to justify it by the market.
Right? Turns out the market never actually checked whether we were having fun — so we might as well. 🙂
AI destroy creativity drastically, destroy the fun part of many things. For example, I remember how fun was to write post even with errors without a robot assisting us.
And it's not only "un-fun" to write code or post, it's becoming "boring" to read it or consume it too.
Remember 1984. Everything, everyone is the same then no one is different? Fight for the difference, write from your guts code and post without ort minimum assistance and be prepared for, what Byung-Chul Han say: this world do not accept the different and will try to destroy it too... but at least will be fun.
The point about consuming is the one I underweighted — it’s not just less fun to write, it’s becoming boring to read, because sameness is the natural output of averaging everything. The 1984 and Byung-Chul Han framing is sharp: homogenization isn’t a side effect, it’s the direction. And “write from your guts, be prepared for a world that won’t accept the different, but at least it’ll be fun” is the whole fight in one line — difference as the thing worth defending, precisely because the machine pulls everything toward the mean. The errors, the rough edges, the voice — that is the signal now.
Chess is a closer analogy than running. A computer beat the world champion in 1997, and nobody stopped playing. Clubs are full, chess.com is bigger than ever, and people still spend evenings getting better at a game their phone plays better than any of them. We play it for what it does to us: prediction, planning, sitting with a hard position.
So the fun was never the thing under threat. What changed is that programmers were paid to be good at it. Imagine every chess player drawing a salary for their rating. Then one day the engines arrive, and the salary moves to whoever directs the engine toward a result. That is the grief in the doom stream, I think. Not "I may not enjoy this", but "the thing I enjoy stopped being the thing I'm paid for".
The rules did change. A developer today is paid to guide agents toward whatever brings the company revenue. In a world where the pay is the point, the motivation sits where the founders sit, and everybody else wakes up and does the day's work. Which is why your argument matters more than it looks: if the enjoyment has to come from somewhere, it has to come from the chess-club side, not the salary side.
To your question: nothing. I haven't built anything useless in a long time. I'm too worried about income right now to play this game for fun, and I suspect that is the real reason the doom stream lands so hard on so many of us. The fun is still there. The room to afford it is what got smaller.
The chess analogy is better than mine, and the reframe it unlocks is the sharpest correction this piece has gotten. You’re right: the engine beat Kasparov in 1997 and the clubs only got fuller, because nobody was paid for their rating. The fun was never under threat. What’s under threat is that programmers, uniquely, drew a salary for the thing — so when the engines arrived, the pay moved to whoever directs the engine, and that’s the actual grief in the doom stream. Not “I might not enjoy this anymore,” but “the thing I enjoy stopped being the thing I’m paid for.” That’s a completely different and more honest wound than the one I named, and you named it better.
And your last paragraph is the one I don’t have a comforting answer to, which is exactly why it matters most. “The fun is still there. The room to afford it is what got smaller.” That’s the real thing under all the doom — not lost joy, but lost slack. When you’re worried about income, you can’t spend an evening on something useless, not because you stopped loving it but because the anxiety eats the space the love needs. So my piece is half a truth: it’s genuinely easy to say “build the useless thing” from a place of security, and much harder when the ground is moving under you. The honest version is that defending joy and defending your livelihood aren’t separate fights — and the second one has to be winnable before the first one feels allowed. I don’t want to pretend otherwise. Thank you for saying the hard part out loud.
thanks james. "lost slack" is a better name for it than anything i had. and i agree with the order: the livelihood fight first, and then the useless thing feels allowed again. for me that means shipping my own small products until one of them pays, so the evenings can go back to play. not there yet, but it helps to see it named
@build996's question is the sharpest one in this thread, because it points at something the article doesn't quite name: "finished" is an economic concept. Play doesn't have a done state.
Nobody keeps a mental ledger of finished versus abandoned evenings of cooking, and nobody asks permission to leave a run half-run. The guilt about unfinished side projects is the economic lens sneaking back in through the side door — the GitHub profile quietly turned into a resume, with green squares and pinned repos suggesting even your hobbies should ship.
The permission worth granting isn't about finishing; it's about coding without a release plan. A chess player never apologizes for resigning a casual game (@yahhi's analogy, and it holds — with one twist: chess was never anyone's rent). Coding is both craft and livelihood, so an hour of play silently competes with an hour of staying employable. The doom stream hurts most where slack is thinnest.
So maybe the honest version of this piece is: the fun isn't killed by AI, it's killed by treating play like unpaid labor. Leave the Breakout clone buggy. The bug is the point.
The point about coding being both rent and play explains why the chess analogy only goes so far. I'd leave room for finishing to be enjoyable too: fixing the Breakout collision bug can be the evening's game, without turning the result into a portfolio obligation. For me the distinction in your argument is who gets to decide when it's enough. An unfinished toy and a polished one can both count as play.
That “finished is an economic concept — play doesn’t have a done state” idea is the sharpest thing in the whole thread, and it names what the piece circled but never quite caught. Nobody keeps a ledger of finished-versus-abandoned evenings of cooking; the guilt about unshipped side projects is the economic lens sneaking back through the side door — the GitHub profile quietly becoming a resume, the green squares implying even your hobbies owe the world a release.
And you’ve tied the threads together better than I did: the chess analogy holds except that chess was never anyone’s rent, which is exactly why coding-play silently competes with staying-employable, and why the doom lands hardest where slack is thinnest. That’s the honest version of this piece — the fun isn’t killed by AI, it’s killed by treating play like unpaid labor. Leave the Breakout clone buggy. The bug is the point. Going in with credit.
I think there's another side to this that gets lost in the AI debate: sometimes building something from scratch is how you discover what the abstraction is actually hiding. Take writing a small event loop or an append-only log with crash recovery. You quickly run into details like partial writes, ordering guarantees, replay after an interrupted commit, and what happens when your assumptions about durability are wrong. A library handles those details for you in production, and that's usually the right call. But working through them yourself changes how you reason about the library when something breaks. The value isn't in replacing a mature implementation or proving you can type every line manually. It's in understanding the trade-offs well enough to know when the abstraction is doing exactly what you need, and when it isn't. That kind of curiosity is still a pretty good reason to write code.
This is the practical cousin of the whole piece, and it reframes “pointless” play as something sneakily load-bearing: building the thing from scratch is how you find out what the abstraction was hiding. Writing your own append-only log teaches you partial writes, ordering, replay-after-interrupted-commit — not so you ship it, but so that when the real library breaks at 2am, you actually understand what it was protecting you from. The joy and the value turn out to be the same act viewed from two angles. You don’t hand-write the event loop to replace libuv; you do it so the abstraction stops being a black box and becomes a set of trade-offs you can reason about. That curiosity isn’t just a good reason to write code — it’s quietly one of the few things AI can’t hand you, because the understanding only forms in the doing.
Exactly. One detail that becomes interesting when you build this yourself is the difference between a write succeeding and a write actually being durable.
Say you're implementing an append-only log for a transactional system. You write the transaction data, then a commit record. If the process crashes halfway through, recovery has to distinguish a complete transaction from bytes that merely happen to be on disk. And even if the write call succeeded, the data might still be sitting in the OS cache.
Getting the ordering, commit markers, and recovery logic wrong can mean either replaying a transaction that never committed or losing one you already told the caller was safe.
A mature database handles all of this, but building a small version makes you question what “committed” actually means. That's the part I find valuable: you stop treating the abstraction as magic and start understanding the guarantees it can, and sometimes can't, make.
This is the perfect concretization of the point, because “committed” is exactly the kind of word we use a thousand times without noticing it’s load-bearing. Building the append-only log yourself is what turns it from a checkbox into a question: committed where? The write call returned, sure — but durable-on-disk, or just sitting in the OS cache waiting for an fsync that hasn’t happened? And the crash-halfway case is the sharpest teacher, because recovery forces you to confront that “bytes exist on disk” and “a transaction completed” are completely different claims, and the only thing bridging them is a commit marker you had to design and order correctly.
That’s the whole value of building the small version: you stop inheriting the guarantee and start understanding its shape — including its edges. You learn that “committed” was never one thing, it was a stack of ordering decisions and durability boundaries someone made on your behalf, and that the mature database isn’t magic, it’s just those decisions, made carefully, by people who got the crash-recovery wrong a few times first. Knowing where the guarantee holds and where it quietly doesn’t is exactly the understanding the abstraction hides from you until you’ve rebuilt a piece of it. Going in the piece as the canonical example, credited.
I think this is the gold piece right here.
Development has gotten to a point where most of their work inherently creates value, and when it doesn't because a machine can do parts of it super fast its seen as a crisis. We got so used to putting productivity and value together that's the whole deal.
Except it doesn't have to be, a craftsman can do stuff by hand for the sake of enjoying the craft. Yes you can mass produce stuff and make more money doing so, but most other craftsman lines of works explicitly don't do it this way.
You don't usually get rich being a craftsman, but you can enjoy the work. Devs got somewhat spoiled always being able to make a good amount of cash and enjoy the work. But there's always time to dabble in the unnecessary and find immense joy in doing so.
The craftsman parallel is the one that unlocks it, and you’ve drawn out the part I only gestured at: devs got spoiled in a way almost no other craft ever was — we got to do work we loved and get paid well for it, which fused “enjoyable” and “valuable” so tightly we forgot they were ever separate. Most crafts never had that luxury. A woodworker who hand-makes a chair knows full well the factory is cheaper and never confused the joy of the work with its market price, because the two were always visibly different things. AI is just forcing on us the condition every other craft already lived with: the enjoyment and the paycheck are separate axes, and you have to tend them separately. That’s a loss of a rare privilege, genuinely — but it’s also a return to the normal human relationship with making things, where you do the craft because the craft is worth doing, and find the money where you can. The dabbling in the unnecessary was always where the pure version lived.
I completely agree. Programming isn't just about efficiency or getting things done faster. It's also about curiosity, creativity, and the satisfaction of solving problems on your own. AI can be a powerful tool, but it shouldn't take away the joy of learning, experimenting, and building something from scratch. Not everything we do needs to be justified by productivity. Sometimes, coding is worth doing simply because we enjoy it.
Word I’d underline in what you wrote is satisfaction, because it names the thing the productivity frame can’t account for. Solving a problem on your own produces a specific kind of satisfaction that an answer handed to you simply doesn’t, even when the answer is identical. Same output, completely different internal experience — and the experience was always the part that mattered.
You’ve also got the balance right, which is the part people miss: this isn’t anti-AI. AI is a genuinely powerful tool, and using it doesn’t cost you anything as long as you don’t let it quietly replace the parts you actually loved — the curiosity, the experimenting, the building from scratch. The danger was never the tool. It’s forgetting that some things are worth doing purely because you enjoy them. That was always a complete reason.
The fun usually dies when the distance between idea and running code gets long. It used to be seconds: type, run, see. Now it is tickets, review checklists, compliance scans and a standup before anything moves. What brought it back for me: a private throwaway repo where nothing gets reviewed, and treating the serious pipeline as a separate game with its own rules. Sharper question: are we protecting quality with process, or just pricing curiosity so high that people stop experimenting?
Both, honestly, and the trouble starts when process meant for production leaks into everything. Quality needs gates; curiosity needs none. Your throwaway repo is exactly the right split. When every single experiment has to justify itself before it exists, people quietly stop having ideas worth reviewing in the first place.
dont know mate, i dont feel like doing manual coding now, it just feel so left behind concept of sitting for a full day on a single problem whereas others are just making 10 products per day and making money. still i support manual coding in all ways
I understand your point of view mate !
I really like this perspective. With all the AI hype, it sometimes feels like we have to justify every line of code we write. Sometimes I just want to build something cool, figure things out myself, and enjoy the process. Not everything needs to be useful or profitable.
This is what i am talking about. I really enjoyed those moments when i first started coding! but those days are gone...
What's more important: the map or the treasure?
There's a unique satisfaction in seeing something you've imagined come to life exactly the way you envisioned it, whether it's a small detail that improves your daily routine or a project serving a much larger purpose. For those who genuinely enjoy creating, the process itself is part of the fun.
When aligned with that purpose, AI becomes a powerful companion on the journey. But it also invites a reflection: what matters most, the treasure or the map?
AI can be seen as a map, an extraordinarily rich repository of information. Yet without the curiosity, creativity, and instincts of the explorer, the treasure is never found.
In fact, the treasure can exist without the map. The opposite isn't true. A map only has meaning because there is something worth discovering.
A beautiful way to put it. I’d add one thing: the map itself was drawn by explorers. Everything AI knows came from people who wandered off the known paths and wrote down what they found. If we all just follow the map, it stops growing. So maybe the explorer matters most of all, not just for finding the treasure, but for keeping the map worth reading. The fun of the journey is what keeps both of them alive.
'It doesn't argue with you, it soaks you' is exactly how the doom feed works. What helped me was splitting it up: the day job can be optimal and defensible, but my evening projects are allowed to be slow on purpose. Some nights I'll hand-write something an agent would do in four seconds, just because I want to understand it. Zero ROI, full joy.
Splitting it that way is a healthy boundary — though don’t be surprised when the thing you hand-write at 9pm just to understand it turns out to be exactly the insight you needed at work on Tuesday.
Do live coding you will rediscover the joy of programming :-)
Strudle, GLSL,...
😶
The buggy Breakout example makes me wonder whether permission to leave a hobby project unfinished belongs alongside permission to build it slowly. Turning it into a polished release can bring the same performance pressure back, even if nobody expects revenue. A collision bug can be an interesting afternoon and then simply stay a bug. Would you count a discarded experiment as a satisfying project too, or does finishing remain part of the pleasure for you?
That’s a sharp addition — permission to leave it unfinished belongs right next to permission to build it slowly, because “ship it, polish it, release it” smuggles the performance pressure back in through a side door even when no money’s involved. A collision bug can just stay a bug. To your question: yes, I’d absolutely count the discarded experiment — often it’s the purest version, because finishing is where the audience creeps back into your head. An abandoned afternoon that taught you one thing and got closed without ceremony owes nobody completion. Sometimes the whole point was the question, and once you’ve answered it the project’s already done, whatever state the code is in.
Mine is an Opera GX browser mod called Coruscant Garden: an animated Star Wars Coruscant overgrown with my favorite flowers, plus an ambient soundtrack. It earns exactly $0, and I spent way too long making sure one neon sign said “19 BBY” in actual Aurebesh, because nobody asked for that. That’s kind of the point.
Honestly, I haven’t hit the place this post describes yet, and I think that’s on purpose. I’ve tried hard not to box myself in, because that’s how burnout sneaks up on me. My day job is phones and spreadsheets, so I always keep something learning-shaped running in the background so my brain doesn’t get clogged by routine. A VP at work recently caught me taking calls, updating a spreadsheet, and teaching myself to build AI apps all at once. She said her brain would explode. I told her I just like to keep it busy so nothing is ever the same. Keeping my lane wide is what keeps the fun from getting squeezed out.
Coruscant overgrown with your favorite flowers and a neon sign reading “19 BBY” in actual Aurebesh that nobody will ever notice — that’s the whole essay in a browser mod. The hours spent making a detail correct that has no audience and earns nothing is the purest form of the thing: care as its own reward, legible to no ledger.
And your wide-lane strategy is a genuinely different answer than the piece gives — you haven’t hit the joy-squeeze because you engineered against it, keeping something learning-shaped always running so routine never clogs the works. The VP whose brain would explode is measuring it by efficiency; you’re measuring it by aliveness, and keeping it busy-but-varied is how you protect the fun before anything gets a chance to squeeze it out. Prevention over reclamation. That might be the smarter move.
“Legible to no ledger” is going on a sticky note above my desk. 😄 That sign is a perfect example. I only caught that the AI had written it in plain English when I went back to it, and I fixed it anyway, knowing maybe three people would ever notice.
And “prevention over reclamation” is exactly it. I keep something learning-shaped running on purpose so the routine never gets the chance to dull everything else. My VP measures in efficiency. I’m measuring whether I still feel curious at the end of the day.
Honestly, this meant more than you know. I’ve spent a lot of time feeling like a fraud for taking the long, wide road instead of the straight one. Hearing someone call it the smarter move was really nice to hear.
Thank you.
Real glad that you felt good reading the article😊
"It measures the artifact and misses the aliveness" says it well. The funny part is that I spend my days building an AI coding tool, and the bits I enjoy most are still the ones I work out by hand. Tooling that writes code faster doesn't change why I like doing it. Thanks for pointing to Chris Kiehl's post too.
Thanks for the read !
Genuinely resonates with how building software feels today. When every tiny side project gets saddled with boilerplate CI/CD, observability, and compliance before writing a single core algorithm, the playful exploration gets squeezed out. Getting back to building focused tools that solve one concrete pain point really well is where the joy returns.
When a weekend idea has to clear CI/CD, observability, and compliance before you’ve written a single interesting line, the ceremony eats the play, and most ideas die at the setup stage. Stripping back to one tool that solves one concrete pain is where the joy returns, because you’re finally spending your time on the part that was fun in the first place.
The word “allowed” in the title captures the pressure well. It turns a productivity comparison into a question of whether someone needs permission to enjoy a craft. I also appreciate the separation from paid work: choosing an efficient tool for a deadline does not create an obligation to optimise every private experiment.
Exactly, and that pressure rarely comes from anyone directly; it just seeps in until enjoying the slow way starts to feel like a confession.
Deadlines can have the efficient version of us, but our private experiments should get to stay gloriously inefficient.
I'd happily keep a tiny project that never needs a launch, a README strategy, or a target audience. Even turning every hobby into a portfolio piece starts to feel like another performance review. Your buggy Breakout example gives me a better finish line like did I enjoy figuring out the next little problem?
Thanks for the read 😊
"Worth and worth money are the same thing" — that's the assumption we swallowed without noticing, and reading it out loud is genuinely uncomfortable.
For me, the "worthless" thing I keep coming back to is a folder of notes I keep on paper. Not in Notion, not in Obsidian — actual paper. Handwritten. Useless by any metric: not searchable, not backed up, not shareable.
But every time I flip through it, I find an idea I'd forgotten. Not because the paper is magic, but because the act of writing it down slowly (instead of pasting it) forced me to actually think about it. That's a feature, not a bug.
The economic lens would call that inefficiency. I call it thinking.
Calling it thinking rather than inefficiency is the whole piece sharpened to a point. The slowness of handwriting isn’t a cost the better tool removes — it is the mechanism. Pasting is efficient precisely because it lets you skip the thinking; writing it out by hand is slow precisely because it makes you do the thinking, and the thinking was the entire value. Not-searchable, not-backed-up, not-shareable are only flaws if the output was the point, but the output was never the point — the friction was. A folder of forgotten ideas you rediscover by flipping pages is doing something no search bar can, because the value got deposited on the way in, not retrieved on the way out. That’s not a worse Notion. It’s a different act the economic lens can’t even see.
"The friction was the point" is the sentence I'd put on a sticky note and stick it to my monitor.
We spend so much time optimizing for "faster" that we forget that some things are supposed to be slow. Handwriting is slow because thinking is slow. Cooking is slow because the process is the reward. Running is slow because the body is the point.
The economic lens can't see any of that. It just sees "inefficient" and tries to fix it.
That sticky note belongs on a lot of monitors, because you’ve pushed the idea further than I did — the slowness isn’t a side effect you tolerate, it’s the mechanism doing its work. Handwriting is throttled to the speed of thought on purpose. Cooking is slow because the process is the reward, not the plate. Optimizing the slowness away doesn’t make the thing faster — it deletes the thing and leaves a hollow version with the same output and none of the value.
And your last line is the diagnosis: the economic lens has one category for slow — “inefficient” — and one response — “fix it.” It can’t tell friction that’s waste from friction that’s the point, because it only sees output. That’s fine aimed at a factory. The damage is when we aim it at ourselves.
'It soaks you' is the best description of the doom feed I've read this week. Weekend projects that earn zero money are some of the best teachers in our craft. What made it easier to close the feed and open the editor?
Honestly, starting before checking anything: opening the editor first thing, before the feed had a chance to set my mood.
And keeping projects tiny, because a small idea I can finish in an evening beats any headline about what AI might do next year.
Editor before feed is such a simple rule, and I love it. Tiny projects that fit in one evening feel great, because we get to finish them. Here's to more gloriously pointless weekend builds! 🛠️
I think the poisoned part is how the economic lens reframes play as waste. The doom stream's trick is never claiming coding has no value — it quietly insists that value has to be capturable by someone else's ledger. Once you notice that move, the whole feed reads differently.
My answer to your question: a tiny collection of browser-based text tools — case converter, duplicate-line remover, word counter — that I built mostly to scratch my own itches. It will never be a business, and that was the point. Some of the most absorbed hours I've had this year were spent on it, because nobody was waiting for the output.
The quiet rebellion framing is right, but I'd add one thing: don't fence it off to weekends. The best production code I've written came from sessions that started as play and were allowed to stay play for a while.
Naming that the doom stream never claims coding is worthless — it just smuggles in that worth only counts if it lands on someone else’s ledger — is the sharpest diagnosis of the trick anyone’s offered. Once you see that move, half the feed reads differently: it’s the market quietly insisting it should get to price your attention. Your text-tools example is the perfect illustration — never a business, and that was the point, and it gave you some of the most absorbed hours of your year precisely because nobody was waiting for the output.
And your addition is the one thing I’d correct in my own piece: don’t fence play off to weekends. Framing it as a “quiet rebellion” for your own time accidentally concedes that work hours belong entirely to the ledger — when, as you say, the best production code often comes from sessions that started as play and were allowed to stay play a while. The joy isn’t the opposite of good work. It’s frequently the source of it. Going in with that correction.
Ha — “no boydev no cry” 😄 Honestly that belongs on a sticker. If the fake-git-history tool ever ships, that’s going straight in the README. Thanks for the laugh — good way to close out a thread that got unexpectedly philosophical. 🙂
This was a lovely read. The point that the doom stream wins through saturation rather than argument explains why the "what's the point?" voice shows up even when nobody has actually convinced you of anything. I also liked the comparison to running, cooking, and playing guitar badly in your bedroom, since it makes the "worth equals money" assumption look absurd once it's said plainly. And the line about the market pricing the one thing it was never entitled to, your wonder, is a good one.
To answer your question: I recently spent a weekend hand-writing a tiny text-based game with terrible pacing, just to see if I could. Zero users, zero purpose, and one of the best weekends I've had in a while. Thanks for the reminder, and for pointing us to Chris Kiehl's post.
Thanks for reading so closely, and for passing the kindness back. Go make more useless things.
The doom stream works exactly like you describe. Nobody argues. It just soaks in. The fun was never in the part a machine does in four seconds. It's in the moment something doesn't add up and you have to find out why, and that moment is still ours.
Exactly — the machine took the four-second part, but the moment something doesn’t add up and you have to know why is still ours, and that was always the good part anyway.
Thank you for writing this. I especially like the idea that doom-scrolling works by saturation. I'm trying to start my day with a book rather than scanning 5 News sources on my phone.
Thanks 😊
Nice article.
I am on the same boat as you are.
I got my technical degree more than 20 years ago, and found myself struggling with engineers with more studies and less experience than me (thanks, open source!). During the pandemic I finally found time to pursue an engineering degree, only to find out that the situation is the same but my struggle isn't against an engineer but someone whose opinion was generated with a couple prompts on Gemini or ChatGPT.
I found a niche for AI in my workflow: I love modeling databases and solving problems the human way, but I totally despise user interfaces. So, I organized my environment in a way that I still get to model and build things the fun way and relegate UI/UX to whatever model makes it better.
At least that way I can still explain how things work and take accountability, which I suspect will be a heavy differentiator in the upcoming years.
Thank you, and what a journey. Earning an engineering degree after twenty years of real experience takes serious commitment. I love how you split your workflow: keep the parts you enjoy and understand deeply, hand off the parts you don’t. And I think you’re right about accountability. Anyone can generate an answer now, but being able to explain why it works, and owning it when it doesn’t, is becoming genuinely rare. That might be the most valuable skill left.
nice
Thanks
Thank you so much for sharing this!!
Glad you liked it ! 😊
It started not being fun when we weren't the ones coding anymore....
anyone can still code. if you work on a company, you do what they say. but nobody controls what you do in your off time. if anything, it makes the hobby much more intimate no?
True, and I think that’s the healthiest way to see it. Work code has to be fast, reviewed, and AI-assisted because the business demands it. Hobby code owes nobody anything. You can write it slowly, badly, by hand, just for the joy of it. That freedom might matter more now than ever.
Even i also feels the same ..
Just in today's VC chat, I asked if anyone still programmed just for fun. :)
Thank you for this post! :).
Thanks!
A heartfelt reminder: coding joy does not have to justify itself via salary, portfolio or business outcomes. Process‑centered satisfaction matters just as much as tangible deliverables in the AI‑era.
Right!
For me AI went the other way 🙃 it took the boilerplate, and what’s left is mostly the part I always liked. Turns out the fun was never in typing getters.
Ha, that’s the optimist’s cut of the same coin, and honestly a fair one — if the fun was never in typing getters and wiring boilerplate, then handing that part to the machine just concentrates what’s left into the good stuff: the thinking, the shape of the thing, the problem worth solving. For some people AI didn’t take the joy, it took the chores. I think both can be true at once, too — it depends entirely on which part you loved. If you loved the puzzle, AI cleared the desk for you. If you loved the making-with-your-hands, it took the hands. You clearly loved the puzzle. Lucky you — and genuinely, I mean that. 🙂
Lucky is the right word. I didn’t get to pick which part I’d end up loving.
None of us picked which part we’d love — so “lucky” is just your wiring lining up with where the chips fell.
Finally , somebody actually decided to build on this topic . This post gave me food for thought
thanks man!
The best thing I built this year was worthless too — a little Snake game in Python, purely so beginners in a series I'm running could watch about 30 lines turn into something playable. No users, no point, I'd rebuild it tomorrow. Weirdly it taught the people watching more than the 'useful' projects did, because nobody was performing productivity at it. We were just poking at it to see what breaks. I think that's the part the doom stream can't argue with. Nobody doomscrolls a Saturday project into existing.
Even this is AI Generated
Its already mentioned at top dude !