However, protective equipment is taken seriously and then shoes stay on. Here in Sweden, of course ordinarily all shoes are taken off (for 8-9 months of every year they're wet and dirty) but if workers come in to do some work, they keep their shoes on because they're protective equipment. If you're having them come during a particularly dirty time of the year, you may want to cover your floor with newspapers or give them shoe covers.
I also suspect comments are very much tied to how Claude reasons because not only are they bad comments, I can't get rid of them. Commenting is the one area in which I've been unable to get Claude to respect any rules. It can follow code conventions I prefer, it can do other things, but it can't keep the comment volume down.
My CLAUDE.md has rules about not including any redundant comments in the code that are obvious from the code itself. I reiterate that occasionally while working. It's absolutely disregarded and any Claude-written code is full of comments. Some of them are simply redundant, like "Collect Foos and pass them to the requested sink" on a function that's void CollectFoos(IFooSink sink). But worse, many comments include in the moment reasoning like "added parameter bar because we can no longer use the frob to automatically derive bar". That's stuff for a commit message, or just a mental note, and absolutely not for comments.
I haven't found any way to stop Claude from doing these, so I have to tell Claude afterwards to clean the comments up. Which it does, making a note in memory to comment less, and it still does the exact same thing next time.
> Commenting is the one area in which I've been unable to get Claude to respect any rules.
Exactly my experience! Since the release of Opus 5, no amount of instructions helps. In CLAUDE.md, in a separate file, in memory, as brief bullets, as long detailed guides, with reasoning from medium to max — nothing.
Even worse, recently, after getting another opus in a tiny bugfix session, I prompted directly, "drop the comments from the current code changes" — Claude instead just slightly trimmed them. I couldn't believe my eyes.
I have a relatively low bar for prose, could live with some junk. But Claude's comments are _poisonous_. They always require maintenance, instantly become out of sync with the actual code, and are a token black hole — for all agents, but especially for Claude itself.
Gave up and canceled Anthropic subscription yesterday. To my taste, it has become unusable for coding.
> Even worse, recently, after getting another opus in a tiny bugfix session, I prompted directly, "drop the comments from the current code changes" — Claude instead just slightly trimmed them. I couldn't believe my eyes.
For me, Claude knows how I want the comments due to all the memories and CLAUDE.md, so funnily it's now enough with even a brief groan from me like "Come on, the comments" and then Claude goes through its recent additions and fixes comments quite well per my long-term instructions. But only ever during an extra pass that I initiate, never during the initial writing of the code.
> But worse, many comments include in the moment reasoning like "added parameter bar because we can no longer use the frob to automatically derive bar". That's stuff for a commit message, or just a mental note, and absolutely not for comments.
I've noticed this a lot, and before your remark I couldn't put my finger on what was wrong. Now I know: Claude is writing its thought processes and maybe parts of the conversation it had with you as comments in the code!
I always end up manually trimming those comments, which is cumbersome.
It also loves to reference internal notes and scratch docs that never go into source control, so a reader will have no idea what it’s talking about. For example:
// load_tree() loads the binary tree with data, but only the recently updated data, not all data (INTERNAL_NOTES.md section 4)
Ok but nobody reading the source code knows what this doc is. You don’t have to cite it.
I wouldn't generalize Europe like that, our differences in the normal schedule are massive from north to south.
Here in Sweden, it's a morning culture. Blue collar workers often start work at 7, daycare is open from 6 in the morning for parents with early jobs, dinner is at 18 or even 17 for people. At 22, most places are closed including supermarkets and restaurant kitchens. Lunch for the vast majority of working people is at noon.
That is totally different to a country like Spain, where you see families - with kids! - start dinner at 21 or later. In Sweden people would say it's strange not to have your kids in bed by then. Lunch is at 14, cities are full of life until midnight every day.
A large part of that is probably due to daylight hours. A big chunk of Sweden is dark by 16 for the winter half of the year. During November-January there's minimal light and it's gone by 15.
> Even if you deeply into tinkering, 1 can be an insanely exciting and rewarding step: for example "how could an abstraction look like in which 2-4 become trivial special cases for many classes of programming problems?".
Yes, but I think there's really two different definitions of point 1. It's "figure out what non-software problem you can solve with software" vs "figure out what technical problem to solve".
As the tinkering type, I also find 1 very rewarding but using the latter definition. Exploring a sizable code base and finding the part that, if simplified, cascades to a lot more simplification, that's very exciting. Figuring out what problem some companies or people have that could be solved? Very hard, very unexciting, not rewarding.
> Yes, but I think there's really two different definitions of point 1. It's "figure out what non-software problem you can solve with software" vs "figure out what technical problem to solve".
In my opinion these variants are not very different:
For example keep in mind that physics is basically a descipription of the software that runs reality, which automatically gives you are huge portfolio of potential problems. :-)
For mechanical engineering, observe that the advances in 3D printing and home CNC milling mean that a lot of problems that were previously in the domain of mechanical engineering now become partly software problems.
Or for more "human" problems: If you are very trained in mathematics, you start to see mathematical structures in a lot of "more human" problems (or areas that are not associated with "software") basically all the time. If you find these mathematical structures that you see interesting, it is often possible to turn them into software.
Thus, "figure out what non-software problem you can solve with software" vs "figure out what technical problem to solve" is rather a litle bit like "in mathematics: do you prefer analysis or algebra?" - yes, they (often) represent a different style of thinking and many mathematicians do have their preferences, but in the end both analysis and algebra is mathematics.
--
So, I disagree with your point
> Figuring out what problem some companies or people have that could be solved? Very hard, very unexciting, not rewarding.
In my opinion the boring part is not finding or solving problems that companies or people have. As I wrote: after some time, you often start to see highly interesting, often very novel mathematical patterns in these problems (of course not always, but it is not an uncommon situation). Why are these patterns often so novel and interesting? A heuristic answer in my opinion is: if they weren't, someone would typically already have implemented them in software. :-)
The really annoying part is rather convincing the people/company of your solution (which can be considered to be part of step "5) You ship/deploy/publish the program. This means you see people be happy users and/or you get paid for it and so on.").
Yes, it's a very well written, touching tribute and I think it's all the more touching when you're familiar enough with Wolfram's writings to notice the contrast here.
It's one of the most beautiful things I've ever read in my entire life. The reader departs both fallen in love with Elise and tragically heartbroken. Excuse me while I go cry some more in the laundry room, collect myself and annoy my wife with a huge hug.
There's practical considerations with AI like it being a probabilistic layer and not deterministic in the way that compilers and deterministic, yes.
But the "letting go" point is I think about what people enjoy. Personally, I enjoy code. I've had jobs where I really enjoyed what I was doing because they gave me the opportunity to write interesting code. The end product wasn't interesting to me. I had a great job building tools for companies that build a very popular consumer product that I've never owned or been interested in. So the software we were building to assist in creating those products wasn't interesting to me in terms of what it is, but the job was motivating and interesting because of the technical problems I got to solve.
I think that's one of the big divides we're seeing in comments now. There are people who want to build things for the sake of the final product. They're happy because LLMs speed that up by a lot, at least initially. Then there are people who enjoy the process and craft of writing code. For them it's hard to let go of manual coding because that's the enjoyable part of the work.
> They're happy because LLMs speed that up by a lot, at least initially. Then there are people who enjoy the process and craft of writing code. For them it's hard to let go of manual coding because that's the enjoyable part of the work.
coding enjoyer here, but for me i want it to be an assistant to speed up what im doing (in the "bicycle for the mind" kind of way) or a problem solver for when i got really stuck; i feel like "agentic" workflows miss a lot of this cause its like talking to someone through slack... thats not enjoyable and also too far removed from the actual code/problem im working on; i think there is an opportunity for much better ux here...
I don't buy into the huge LLM hype but I certainly think late 2025 was the inflection point. Up until then, I thought LLMs universally sucked at code. GPT-3.5, GPT-4, o1, o3, Claude 3.5, Sonnet 4, the whole bunch. Each iteration got marginally better, hallucinated APIs less and so on, but my overall evaluation of them all was that they wrote crap code and were unsuitable for anything other than one-off scripts.
Then the incremental improvements did, in my experience, cross some kind of threshold in late 2025 where the things became useful. It is of course anecdotal and personal judgment. But I asked LLMs to implement a small feature in my codebase (my usual test) and finally it produced code I was happy with. They've also been able to locate and diagnose a problem based on logs. In my view it's now a markedly different level of capability than we had a year ago, though I would call the previous two years equally useless.
Wolfram is definitely not a crank. Cranks do not understand scientific methods and also have a minimal understanding of whatever field they're trying to be active in. Like trying to push physics theories while demonstrably failing to understand high school level calculus. Cranks are also conspiracy theorists who inevitably believe knowledge like theirs is being suppressed.
Wolfram does display a similar ego to cranks. He tends to place his cellular automata at the same tier of importance as general relativity or wave-particle duality. But unlike cranks, he doesn't say that Einstein, Feynman and other greats are wrong, he doesn't "prove" his theories by math-looking babble that is definitely not math. He loves cellular automata and so much of what he writes is more like philosophy of science than science. He will model certain processes as an automaton and then he jumps from that to every natural process being a cellular automaton.
Eccentric, definitely, and most of his physics research isn't accepted but he's several orders above the level of crank.
I'm a big Linux advocate with limited experience on modern versions of Windows, but PowerShell objects are great. So is the Unix way of doing text. I think the strengths of each approach are in different use cases. Unix style is better for interactive usage because it's fast, I can type df -h | grep /home very quickly. Object output is better for scripts that can, thanks to objects, store and operate on sensible data while Bash scripts do a lot of ad-hoc data extraction/reformatting with string expansion, awk and whatever else to get data to the next step in the script.
One of the most impressive and useful free software projects. My first experience was being totally confused by KDE 1 during my first attempts to use Linux, and I'm writing this from my KDE desktop.
Other than the really bad KDE 4 release, the project has consistently been great for me. I've submitted a few smaller patches over the years and that experience was also low friction for a project of this size. KDE is highly customizable, full of power user features but also really simple with its current defaults (looks pretty much like Windows) and generally robust.
Shoutout to some KDE applications like Okular (great document viewer), Kate (solid tech editor), Krusader (double pane file manager) and KolourPaint (a simple image editor even I can use).
Konsole and Spectacle deserve a shoutout as well. Konsole for its flexibility and feature set while remaining really performant, and Snapshot for being just so darn handy for both screenshots and screen captures.
I used Konsole for years and it's great but since switching to Neovim as a primary editor I also switched to Kitty terminal which is in its own league. Kitty is the only one that I substituted the core KDE app for.
I agree it's really impressive, it brings a lot of things together into a cohesive package and experience. I'm a huge evangelist, I think it's the best desktop experience.
I've been using KDE for the last 30 years I guess but somehow never used KolourPaint until to 2 weeks go. That's the first "pain" program that is usable to do simple things. Gimp is waaaaay to complex for simple tasks (especially the selection which I've never understood). Congrats KolourPaint team for KISS.
I have zero artistic inclination so 90% of image manipulation I do is simple resize/scale/draw line operations, with the remaining 10% being some sort of select+move operation to show mockups, adding transparency or something on that level of complexity. I have GIMP installed and respect it, but as any "real" editor it's too complex for me. KolourPaint does the simple operations I need, with fundamentally the same UI as Win 3.1 pbrush.exe had.
KolourPaint fills a small niche but does it very well.
I remember when it first came out. Very impressive at the time. I was never a fan though personally, I always hated the look of KDE. I used it recently on CachyOS for fun and it worked great, just not for me visually. I'm glad it exists, I just wish there was something visually appealing with less settings bloat. It feels like going to a diner with 300 items on the menu and they're all sorta half baked.
reply