I 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:
When 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.
Well yeah, but I probably would never have done the parser for the company either. Honestly I’m luck to be in a company where most of the time I spend is not coding, but architecting instead (currently). The implementation of the architecture is mostly details.
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.
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 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?
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.
> 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.
> 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.
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.
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.
>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.
Readit News
A credo I have held for some time is:
HTHOne 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.
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.
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...
Deleted Comment
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.
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 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?
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.
This sounds like an awful way to debug. Operating on less information just makes things harder for no reason.
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
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.
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.
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.
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.
So people installing and tinkering with Linux but somehow not being able to install a browser?
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.
> 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.