I was in this camp as well until recently, in the last 2-3 weeks I've been seeing problems that I wasn't seeing before, largely in line with the issues highlighted in the ticket (ownership dodging, hacky fixes, not finishing a task).
I really don't get this sentiment. The only sets that I think didn't contribute like this were the bionicle stuff. Getting a few more unique parts with a set gives you more options, not less.
I wonder if it's just: compact earlier, so there's less to compact, and more remaining context that can be used to create a more effective continuation
I've been using a `/feedback ...` command with claude code where I give it either positive or negative feedback about some action it just did, and it'll look through the session to make some educated guesses about why it did some thing - notably, checking for "there was guidance for this, but I didn't follow it", or "there was no guidance for this".
the outcome is usually a new or tweaked skill file.
it doesn't always fix the problem, but it's definitely been making some great improvements.
I was already programming when I got into mindstorms (so very happy that my high school had an "Industrial Control Technologies" class), but the jump in complexity and the thrill of seeing my code power something physical was definitely a turning point
I feel like the special parts have eased off, it was pretty bad with the bionicle stuff (which ironically are apparently what saved lego from financial difficulties), but I'd say all of the recent sets I've got (I get one a year for Christmas) going back at least 5 years have been made up of relatively generic parts, with the odd little special bit for flair.
I do think that the "model" form of something recognizable (thinking mostly about the Star Wars kits here) does lend itself to kits that sit on the shelf, but no one is forcing you to keep it assembled.
With that said, one thing I remember seeing in older kits is instructions for more than one build, which could serve as a kicking off point for someone to reapproach a bundle of bricks in multiple ways.
My own guideline is that once something is built, after a little while it has to be either modified/evolved, or disassembled and put into the bucket-o-bricks for reuse (well if I'm honest, it's several very well sorted craft/hardware bins)
I feel like this talk by John Hughes showed that there is real value in this approach with production systems of varying levels of complexity, with two different examples of using the approach to find very low level bugs that you'd never think to test for in traditional approaches.
Slow doesn't really begin to do justice, I'd have to wait for >5 minutes for pipenv to finish figuring out our lock file. uv does it in less than a second.
I don't know, I tend to agree. I feel like the number of times I've been thrown off by an out of date comment for code that could have probably been refactored to be clearer, outweigh the times a comment has helped.
Docstring comments are even worse, because it's so easy for someone to update the function and not the docstring, and it's very easy to miss in PR review
I managed to get claude to create a recovery script to un-brick sessions, YMMV
https://gist.github.com/robertfw/993dbe8643c4fbdf12005dff2ec...