The thing that brought me joy
stephenlewis.meI love this, it resonates so deeply with me. Code is, for me, joy. I spent a little more than an afternoon writing a parser to parse a new ad-hoc file format I created to represent the IDs (class name and ID names) I will use in my CSS, and it was just fun. Sure some AI could probably have written that for me, but for what? So I can dig directly back into complicated actual engineering issues? Where would my breaks be?
> I love this, it resonates so deeply with me. Code is, for me, joy.
A credo I have held for some time is:
HTHWhen making software, remember that it is a snapshot of your understanding of the problem. It states to all, including your future-self, your approach, clarity, and appropriateness of the solution for the problem at hand. Choose your statements wisely.I think we are presented with a false dichotomy here, as you can use llm tools for menial tasks and code whatever scratches your itch at the same time. For me, I really do not enjoy writing any frontend, html, javascript, whatever; I just want to bring some website I need to light. I focus on other code and that is what brings me joy.
Ironically I have a somewhat of a different view - I love rubber ducking and tinkering with LLMs. Sometimes they come up with a use case that I would not have thought of, but I would have liked to have maybe 2 weeks later. Other times it is nitpicking each others' code etc.
> Sure some AI could probably have written that for me, but for what?
One reason would be to raise the ceiling of what your project can do within the budget of time and motivation you have. Or, as it often happens, to be able to finish the project at all.
I mean that's perfectly valid for a hobby project, but I think the argument is from the pov of a company seeing your time as a resource. In that context, it is obvious why it makes economic sense to spend your time on the actual, complex issues, assuming AI can handle the basic tasks. My job doesn't give a f about me finding joy, I can raw dog all the code I want in my free time/for hobby projects.
This is artisans vs industry.
You can get a hand-crafted, beautiful, solid, chair made by a guy who knows all the tricks of carpentry. He's spent his whole life perfecting the technique of how to drill the holes, how to fit everything together, how to balance the chair.
It used to be the only way.
Then someone invents a machine that can make you a hundred crappy chairs. Sometimes the legs don't fit in the seat, sometimes the chair isn't balanced. But it's close enough often enough.
On top of it, the new tool is not in the lineage of the old tools. It doesn't FEEL like you are crafting a chair.
> This is artisans vs industry. ... But it's close enough often enough.
If I had a nickle every time I heard the equivalent of "close enough often enough" on root-cause analysis bridge calls during prod outages...
Except that chairs (or anything that's automated today, even cars) don't rapidly evolve or are dynamic like Software is.
Not the OP, but I’ve been thinking about why LLMs feel different and I think it’s closer to the chair analogy than I initially thought. Not able to fully articulate it but here’s my try.
Conventionally programming software needed you to know your tools like language, framework, OS, etc. pretty well. There’s a divergent set of solutions dependent on your needs and the craftsmen (programmers/engineers) you went to. Many variables you needed to know to produce something useful. You need to know your raw materials, like your wood.
With LLMs it’s weirdly convergent. Now there’s so many ways to get the same thing because you just have to ask with language. It’s like mass produced furniture because it’s the most common patterns and solutions it’s been trained on. Like someone took all the wood in the world, ran it through some crazy processing, and now you are just the assembler of IKEA like pieces that mostly look the same.
There’s a lost in necessity in craft. It helps to know the underlying craft, but it’s been industrialized and most people would be happy enough with that convergent solution.
I think fundamentals are more important than ever. How can you debug without understanding it? "Claude please rewrite" is not good engineering.
Quality QA folk are able to reason and develop an understanding of a system without ever seeing a line of code. As long as we're discussing fundamentals, being able to develop such an understanding will be a skill to develop that will pay off returns even after AI comes and goes. Even when given the code, rushing to throw print everywhere, or rushing to throw it at debugger both come behind someone that understands the system and is able to observe the bug, then sit and reason about it, and then in some cases, just fix the bug. I've worked with a couple of programmers that good, it's awesome to experience.
Point is though, you don't need to see the code to debug it, so the fact that the code was generated should not be the thing holding you back.
---
When given only three words, is the rewrite any good? When given to a human intern, would it be any good? Instead "refactor the foo that's repeated n bar, baz and qux into one reusable shared class/component/the appropriate thing for the given language" is good actual software engineering that a human would do, or ask an intern to do.
I feel similarly. Sounds a bit like other crafts that were later industrialized and (partially) mechanized, like woodworking and carpentry.
One can certainly enjoy the laborious handcrafted process of building your own table, and yet go back to a shop that churns out cheap furniture that’s nonetheless useful for many others, and see the value in both.
Obviously there’s more degrees of freedom in software, but I’m trying to see it that way to rationalize how I’m feeling with the current state of things.
I see a lot of people saying things like, if you don't use LLMs for coding then you are slower than your peers who do and you are are obsolete, not worth working with, etc., etc.
I am curious where this train of thought has come from. For decades, there have been
a) some human programmers who worked faster than others
b) other non-LLM programming tools that enabled productivity boosts
While maybe (maybe?) slower programmers aspired to be faster, and maybe (maybe?) their managers wished they were faster, it was generally accepted. You might have someone who codes slowly, or medium, or fast, or superhuman fast. Just so long as they were "fast enough" for your business needs, it wasn't a huge issue. There wasn't a culture of shaming all of the medium-speed programmers into the ground.
And while maybe some programming tools did indeed offer productivity boosts, there really wasn't a culture of demanding all possible boosting tools be used. If you want to use Nano to edit, great, up to you. Emacs? Great. Visual Studio Code? Great. Debuggers? Great. Print statements? Great. Outside of some highbrow programmer ivory towers, there wasn't a widespread insistence that "only these tools shall be used because they let you write code the fastest".
But now it seems that there is demand that LLMs be used to write code as fast as possible as possible.
Why? Why now, is it suddenly important that code be written as fast as possible, and anything less should be mocked and derided?
It's because the velocity difference is no longer 25% between the slower and faster programmers.
I think 25% is a low estimate. Using a proper programming editor alone could realistically offer 2x or more productivity over a basic text editor, and there have definitely been programmers who stayed with basic editors.
And I have first hand seen programming teams where there was clearly more than a 25% difference — some could code much, and some could barely code at all.
I think it would be quite fair to say that, between tools and individual skill, there could easily be a 5x speed difference between slower and faster programmers, maybe more. Granted, LLMs are even faster, but I don’t think a 5x potential speed up was a slouch.
What I've seen is that the productive developers are the ones who understand what problem they are solving. They either take the time to think it through or just have an seemingly uncanny ability to see right to the heart of the problem. No false starts, no playing with different implementations. They write the code, it's efficient, and it works.
The slow developers have false starts, have to rework their code as they discover edge cases they didn't think about before, or get all the way through and realize they've solved the wrong problem altogether, or it's too slow at production scale.
> It’s not that the agents are now producing flawless code. I spent a good 20 minutes yesterday watching one tie itself in knots trying to write a regex: first in Sed, then in Bash, and finally in Python (six times).
This sounds very strange.
I'm using Claude (Opus 4.5 via Code) every day and it's very good with regexes, sed, awk and similar bash oneliners.
We don't know what the author asked it to do, but this smells like the problem started at least several messages before that.
To author's point: code brings me joy. I'm currently learning Zig, for no reason whatsoever other than intellectual challenge and I, subjectively, like the language. I'm writing silly little programs that nobody will ever see. It's fun.
Then I switch over to a paid project, and claude[0] another task from my backlog.
There's code, and then there's code. You can find joy in some code and absolutely want to avoid coding in something else.
[0] code using Claude
> We don't know what the author asked it to do, but this smells like the problem started at least several messages before that.
Author here. It was what I assumed would be a fairly simple task, fixing some duplicate closing frontmatter delimiters.
I think the LLM took a wrong turn early on, and then just spiralled. It was morbidly fascinating watching it rabbit hole.
> It was morbidly fascinating watching it rabbit hole.
Oh yes, it's like slow-motion train wreck.
Once it gets off the rails, the best thing is to nuke the context, reset the state (git reset --hard or equivalent) and retry, this time with foresight.
> this time with *foresight*.
So much this! Nondeterministism in LLMs does not mean you simply "reroll" your prompt and hope for the best; the incremental reprompting is what helps.
Or you just code it yourself.
Some people like the making and tinkering with 3D printers, but have no actual projects they want to make with them, nor do they have the skills to use CAD to design them. On the other side are the people that have no interest in 3D printers, and just use them to implement their ideas.
I'm starting to think programming might become the same thing; people that program will be the people that just like to tinker with code and have no real ideas to implement, while the people that have ideas will use LLMs to implement the code so they can just work on their idea.
I've seen the same thing with Linux. There are people that like to tinker with Linux, playing with every setting and every window manager, but don't actually use the computer to DO anything, and then there are people that don't care what the OS is, and are just using the computer as an actual tool to get something done.
I disagree with this framing that people who tinker are unproductive, and that people who don’t care about their tools or OS are only focused on productivity. Perhaps you just fall in the latter camp and feel that way about tinkerers?
In reality I think depth of tinkering and productivity are two separate axes. I’ve seen plenty of examples of all combinations of each extreme.
I think there must be a continuous spectrum between the extremes you describe.
I suspect there's a synergy between the two.
> ... but don't actually use the computer to DO anything
So people installing and tinkering with Linux but somehow not being able to install a browser?
I write for fun, to organize and articulate my thoughts, and I love doing that in vim. The same is true for note taking (I just write .md files and sync them with syncthing). I also like working neomutt. It's just fun working with (relatively) simple, stable tools that seem to grow on you over time for every day tasks. Writing code is just one of those things.
If it truly brings you joy we have hat covered: it's a simple enough hobby!
The actual issue is that then you need something still that makes money. I think, for a programmer, that's fairly unproblematic too, for the foreseeable future: all those agents will need direction. Anyone can do that up to some level of complexity on their own, sure, but it simply is hard for humans to structure requirements and reason about a big enough systems and I don't see demand for those decreasing.
You don't have to leave the command line. Claude Code, and other agentic tools like it, make you feel like you've left the command line because they capture the whole terminal and leave you with less agency. There are tools like aider (and my own project runprompt) which let you retain more control in your terminal and in my experience feel much less disempowering, while still giving you a productivity boost.
My father passed away a year ago, and I felt a deep well of depression, an inescapable draw that tainted every action, every color of feeling, that sapped my very soul.
I had booked a trip to Cartagena. I hadn't realized that I arrived on Fat Tuesday, and I don't think that it would have mattered.
Arriving there, bathing in the insubstantial "joy d'vivre," the sinking feeling lifted.
I remember that well, and it's cure. I love Latin America for this reason.
I really enjoyed the full piece by Dave Kiss that this piece quoted: https://davekiss.com/blog/agentic-coding/
AI assisted coding (and broader idea exploration) is 100% bringing me joy in this way.
I don't code for a living in any way, but I teach IT. And for years and years I've had little script ideas and tasks (e.g. music organization) that worked decently, but also life got in the way and I have that thing where I want it to work just right etc, and now that the pipeline is orders of magnitude shorter, man this stuff is FUN for me again.
Do you hold up that code to the standards you teach? Genuine question.
> He’s not wrong, but it does make me wonder: even if the code was not the point, what do you do if it was the thing that brought you joy?
You still write the code! We do lots of things that could be done more efficiently. People build their own furniture and make their own clothes and brew their own beer. If you love doing something for its own sake, keep doing it.
Interesting, I suppose I'm still doing debugging and finding solutions to problems even with AI coding. I think my dopamine was from problem solving, not necessarily doing the math/logic. It helps I get paid for solving problems, so more problems solved = more money. And I'd like to emphasize, I still debug.
I think it seems to crystalize out a skill set of prompt engineering, debugging, system design (especially safeguard) design and potentially testing to be the most efficient for productivity. It depends obviously what kind of coding you do. The more standard it is, the more AI can help. When you need to engineer new patterns, math, system design logic is more important.
Weirdly mine is completely not standard. Obscure API and in a different language from the original docs.
> I spent a good 20 minutes yesterday watching one tie itself in knots trying to write a regex: first in Sed, then in Bash, and finally in Python (six times). By the time I pulled the plug, it had ruined all of the correct files without doing anything to fix the original problem.
If you just need a regex, why are you letting Claude Code run rampant all over your code base? Just use a web gui? Or another terminal?
>Good enough that choosing to focus on the fundamentals seems rather foolish.[...]but most of the time it sticks the landing. At this point, learning Awk seems about as sane as mastering the loom
The joy aspect aside, if you're writing code professionally obviously that is no substitute for knowing how Awk works because you still need to make sure that what it produced is correct, because I sincerely hope that you're not pushing code into production, in particular not a piece of code some tool got wrong for 20 minutes, without understanding what it does.
If that were an intern rather than a machine and you as the programmer don't know how the code works you're not doing your job. AI systems have not freed people from acquiring "arcane knowledge" it makes that knowledge more important than ever, the only thing it does is type faster than you do.
Author here...
> I sincerely hope that you're not pushing code into production... without understanding what it does.
I do not. That hasn't changed.
> ...the only thing it does is type faster than you do.
LLMs can do many, many things that I cannot. Their breadth of knowledge dwarfs mine.
How do you verify that the output is correct for these areas that the LLM dwarfs your knowledge?
If it's throwaway code to accomplish a one-off task, I just care about whether the task has been accomplished. The method is largely irrelevant.
Anything more "serious" (client work, for example) usually falls within my sphere of knowledge, at least to the point where I can accurately review the LLM's solution.
My long-standing habit of practising TDD also helps.
I was addressing the areas of which you are lacking knowledge.
AI is making us face the reality of non-physical goods and services. If a product exists solely as data (writing, music, code, drawings, movies, etc.) then the value is in the idea and its distribution, and less on its production.
I'll give some examples:
Novel algorithms: PageRank, BitTorrent, Like buttons, disappearing pictures, etc.
Artistic styles: Cubism, impressionism, Wes Anderson, etc.
The above algorithms are (relatively) straightforward to implement and could be implemented by Claude Code in a matter of hours if not minutes. But, you'd still need a means to distribute them.
Similarly, you can have AI generate an image in any of the above styles (or a combination thereof), but the image won't have intrinsic value unless you can finds a means of (profitable) distribution.
Put another way, there's limited value in being able to master physical tasks (playing piano, typing fast), but fundamental skills that lead to creative innovation will remain important...along with being able to package/market/distribute the AI-implementation of your ideas.
You could imagine beings who live on an abstract plane, creatively playing around with abstract thoughts and producing abstract goods. Except you couldn't imagine it in any detail, because it has no details, because its abstract. It's easier to imagine that they live in a virtual world, and play creatively with virtual objects in the course of producing virtual goods that owe a lot to real physical goods. But that's tantamount to learning physical skills. Besides, for the time being, the world we inhabit is an amalgam of the virtual with the physical (not to mention the abstract). I'm saying that if you lock yourself in a box and think abstract thoughts you won't innovate much. It worked for Descartes with his oven, but that's unusual. Usually we need to play with a somewhat physical environment that's friendly to our physical monkey-shaped bodies and senses, in order to be creative, so physical skills aren't going away in the foreseeable.