| ▲ | LeCompteSftware 2 hours ago |
| This is ominous and very depressing given what we've recently learned / reconfirmed about LLMs sapping our ability to persist through difficult problems: > There were 2 or 3 bugs that stumped me, and after 20 min or so of debugging I asked Claude for some advice. But most of the debugging was by hand! Twenty whole minutes. Us old-timers (I am 39) are chortling. I am not trying to knock the author specifically. But he was doing this for education, not for work. He should have spent more like 6 hours before desperately reaching for the LLM. I imagine after 1 hour he would have figured it out on his own. |
|
| ▲ | j1elo 12 minutes ago | parent | next [-] |
| I just grabbed an Android remaster of "Broken Sword: Shadow of the Templars", a 90's point-and-click adventure that has been added a hints system which pops up automatically after a timeout of the player not progressing. This can be set as far as 1h of being stuck. Can also be 5 minutes. But by default it is 30 seconds. My inner kid was screaming "that's cheating!" :-D but on second thought it is a very cool feature for us busy adults, however it's sad the extremes that gamedevs have to go in order to appease the short-term mindless consumers of today's tik-toks. But more seriously, where's the joy of generating long-standing memories of being stuck for a while on a puzzle that will make you remember that scene for 30 years? An iconic experience that separates this genre from just being an animated movie with more steps. I couldn't imagine "Monkey Island II but every 30 seconds we push you forward". Gimme that monkey wrench. TFA and this comment just made me have this thought about today's pace of consumption, work, and even gaming. |
|
| ▲ | Gigachad 2 hours ago | parent | prev | next [-] |
| Often when LLMs give me some command option or advice I haven’t seen before I try to independently verify it. And I’ve often been frustrated just how hard it is to find this info from the source documents. Though a lot of the time this is more an inefficiency of the documentation and Google rather than something only LLMs could do. |
| |
| ▲ | nyarlathotep_ an hour ago | parent [-] | | As the rate of 'hallucinations' seems to have dropped dramatically (at least IME as regards non-existent flags and the like), I'm more concerned with usage. I often use grep.app/GH code search to look for usage examples as a sanity check when things look "off", for exactly the reason you described--there's often a total lack of good documentation on things like that, especially on "younger" tools/stuff. |
|
|
| ▲ | alemwjsl 2 hours ago | parent | prev | next [-] |
| Yep and after 6 hours don't reach for LLM, instead: * Ask someone to come over and look * Come back the next day, work on something else * Add comment # KNOWN-ISSUE: ...., and move on and forget about it. But year spent days on a bug at work before ha ha! |
| |
| ▲ | moregrist an hour ago | parent | next [-] | | > Come back the next day, work on something else This is a tried and true way of working on puzzles and other hard problems. I generally have 2-4 important things in flight, so I find myself doing this a lot when I get stuck. | |
| ▲ | justonceokay 2 hours ago | parent | prev | next [-] | | You say this as if the LLM isn’t committing things it doesn’t even recognize as bugs if you don’t babysit it. I’d rather have a codebase with a few very well marked evil zones, rather than a codebase no one has read. All code contains demons and it’s good to have an understanding of their locations and relative power | |
| ▲ | calvinmorrison 9 minutes ago | parent | prev [-] | | so many eureka moments of mine were simply sitty on the MTA |
|
|
| ▲ | JuniperMesos an hour ago | parent | prev | next [-] |
| Why shouldn't someone consult some kind of external resource for help, after struggling with a specific coding problem for 20 minutes? Why is 6 hours the right amount of time to timebox this to? |
| |
| ▲ | Jtarii 19 minutes ago | parent | next [-] | | It entirely depends on what your goals are. If you want to solve the problem quickly then just use the resources you have, if you want to become someone who can solve problems quickly then you need to spend hundreds of hours banging your head against a wall. | |
| ▲ | demorro 36 minutes ago | parent | prev | next [-] | | 20 minutes is not enough time to drive you into a state of desperation, where you may be forced to try something novel which will expand your mind and future capabilities in unknown and unexpected ways. You might be driven to contact another human being, for example. | |
| ▲ | bhelkey 30 minutes ago | parent | prev | next [-] | | There wasn't always an external resource to go to for help. Especially for legacy pieces of software, it was easy to become the person with most context on the team. | | | |
| ▲ | thrance 40 minutes ago | parent | prev | next [-] | | The struggle is the point, that's how you learn. If you offload your task to someone/something else after barely 20 minutes of head scratching, you've missed the plot entirely. | |
| ▲ | th0ma5 42 minutes ago | parent | prev [-] | | [dead] |
|
|
| ▲ | usernametaken29 an hour ago | parent | prev | next [-] |
| I’ve worked in financial modelling before where you need to make sure results are correct, not approximate.
One time there was a nasty bug in pandas multiindexes (admittedly we banned pandas for all new code because it just can’t do semver).
Spent 9 days to debug three lines of code.
Endurance and patience are learned skills and sometimes they’re the only way you can get a correct verifiable solution. |
|
| ▲ | sho_hn 2 hours ago | parent | prev | next [-] |
| Now imagine someone else reading this and genuinely considering 20 minutes a long time to wait :-) |
|
| ▲ | derangedHorse an hour ago | parent | prev | next [-] |
| I'm sure the author will encounter problems where the only way to solve them will be the marginal effort provided by a human. At that point he won't be just be solving problems to work his brain, but also to accomplish a goal. |
|
| ▲ | raw_anon_1111 44 minutes ago | parent | prev | next [-] |
| Why? I’m as old timer as old timer can get - started programming as a hobby in 1986 in assembly on an Apple //e in 65C02 assembly language. But just today a bug was reported by a customer (we are still in testing not a production bug). I implemented this project myself from an empty git repo and an empty AWS account including 3 weeks of pre implementation discovery. I reproduced the issue and through the problem at Claude with nothing but two pieces of information - the ID of the event showing the bug and the description. It worked backwards looking at the event stream in the database, looking at the code that stored the event stream, looking at the code that generated the event stream (separate Lambda), looking at the actual config table and found the root cause in 3 minutes. After looking at the code locally, it even looked at the cached artifacts of my build and verified that what was deployed was the same thing that I had locally (same lambda deployment version in AWS as my artifacts). I had it document the debug steps it took in an md file. Why make life harder on myself? Even if it were something I was doing as a hobby, I have a wife who I want to spend time with, I’m a gym rat and I’m learning Spanish. Why would I waste 6 hours doing something that a computer could do for me in 5 minutes? Assuming he has a day job and gets off at 6, he would be spending all of his off time chasing down a bug that he could be using doing something else. |
| |
| ▲ | grebc 38 minutes ago | parent | next [-] | | It’s always the journey that matters. If you’re experienced as you are, you’re not learning the same way a junior assigned this might learn from it. | | |
| ▲ | raw_anon_1111 14 minutes ago | parent [-] | | So the project I mentioned while I did write every single line of app code and IAC, made every architectural decision, etc., I did come on an off the project over the course of a year and I couldn’t even remember some of the decisions I made. I also used Codex and asked questions about how the codebase worked to refresh my own memory. Why wouldn’t a junior developer do the same? I mentioned that I had Codex describe in detail how it debugged it. It walked through each query it did, the lines of code it looked at and the IAC. It jogged my memory about code I wrote a year ago and after being on other projects |
| |
| ▲ | LeCompteSftware 36 minutes ago | parent | prev [-] | | Did you miss this part? But he was doing this for education, not for work.
That's why he should spend 6 hours on it, and not give up and run to the gym. That's like saying "I shouldn't spend an hour at the gym this week, lifting weights is hard and I want to watch TV. I'll just get my forklift to lift the weights for me!" |
|
|
| ▲ | Trasmatta 2 hours ago | parent | prev [-] |
| YES. I don't know how many multi WEEK sessions of debugging I've been through in my career. Frustrating, but so many valuable lessons learned in the process. LLMs are absolutely causing us to lose something very important. |
| |
| ▲ | encrux 2 hours ago | parent | next [-] | | I don’t miss multi week debugging sessions. Having a tool that instantly searches through the first 50 pages of google and comes up with a reasonable solution is just speeding up what I would have done manually anyways. Would I have learned more about (and around) the system I‘m building? Absolutely. I just prefer making my system work over anything else, so I don’t mind losing that. | | |
| ▲ | Trasmatta an hour ago | parent [-] | | The multi week debugging sessions weren't fun, but that doesn't mean they weren't valuable and important and a growth and learning opportunity that we now will no longer experience. | | |
| ▲ | glhaynes an hour ago | parent | next [-] | | Seems like there's a good argument to be made that we'll have plenty of opportunities for valuable growth and learning, just about different things. Just like it's always been with technology. The machine does some of the stuff I used to do so now I do some different stuff. | |
| ▲ | LeCompteSftware an hour ago | parent | prev [-] | | IMO the more salient point is that bugs requiring multiple weeks of human work aren't going away! Claude has actually not been trained on, say, a mystifying and still poorly-explained Java concurrency bug I experienced in 2012, which cost a customer $150,000. Now in 2026 we have language-side tooling that mitigates that bug and Claude can actually help a lot with the rewrite. But we certainly don't have language tooling around the mysterious (but now perfectly well-explained) bug I experienced in 2017 around daylight saving's time and power industry peak/off-peak hours. I guess I haven't asked, but I can almost guarantee Claude would be no help there whatsoever. Just so many confusing things go wrong in real-world software, and it is asinine to think that Mythos finding a ton of convoluted memory errors in legacy native code means we've solved debugging. People should pay more attention to the conclusion of "Claude builds a C compiler" - eventually it wasn't able to make further progress, the code was too convoluted and the AI wasn't smart enough. What if that happens at your company in 2027, and all the devs are too atrophied to solve the problem themselves? I don't think we're "doomed" like some anti-AI folks. But I think a lot of companies - potentially even Anthropic! - are going to collapse very quickly under LLM-assisted technical debt. |
|
| |
| ▲ | chasd00 26 minutes ago | parent | prev | next [-] | | Geez you guys need to spend some time in orgs where your paycheck is depends on getting the bugs fixed and deployed. If your direct deposit happens whether you deliver or not then you’re missing the most valuable career lesson of all. | | | |
| ▲ | jjice an hour ago | parent | prev | next [-] | | But oh my god, do you remember how good it felt to finally fix it? The euphoria I felt after fixing bugs that I stayed up late working on is like nothing else. | | |
| ▲ | mapontosevenths an hour ago | parent [-] | | Debugging code is fun for the same reason hitting yourself in the head with a hammer is: It feels really good when you stop. |
| |
| ▲ | raw_anon_1111 41 minutes ago | parent | prev | next [-] | | And if I were your boss you would immediately be fired if you spent weeks trying to debug an issue a junior developer solved just by launching Claude and telling it the symptoms of the issue because you refused to use an LLM. | |
| ▲ | voidfunc 2 hours ago | parent | prev | next [-] | | If I told someone I spent a week debugging a problem these days I think I would get laughed out of the call. Even a day might hit somw chuckles. If you cant fix the bug just slop some code over it so its more hidden. This is all gonna be fascinating in 5-10 years. | | |
| ▲ | seanw444 2 hours ago | parent | next [-] | | This really does feel like a mass hysteria event. Bizarre to have to live through it. | |
| ▲ | SlinkyOnStairs an hour ago | parent | prev [-] | | This does depend on who you are; If you're a senior with 10+ years of experience, it's a failure of your abilities to cut your losses or know when to seek help if you take far too long debugging something. But for juniors, it's invaluable experience. And as a field we're already seeing problems resulting from the new generations of juniors being taught with modern web development, whose complexity is very obstructing of debugging. | | |
| ▲ | badc0ffee an hour ago | parent [-] | | There are definitely situations where you can't ask for help and you can't turn your back on the bug. I worked on a project that depended on an open source but deprecated/unmaintained Linux kernel module that we used for customers running RHEL[1]. There were a number of serious bugs causing panics that we encountered, but only for certain customers with high VFS workloads. I spent days to a week+ on each one, reading kernel code, writing userland utilities to repro the problem, and finally committing fixes to the module. I was the only one on the team up to the task. We couldn't tell the customers to upgrade, we couldn't write an alternative module in a reasonable timeframe, and they paid us a lot of money, so I did what I had to do. I'm sure there are lots of other examples like this out there. [1] Known for its use of ancient kernels with 10000 patches hand-picked by Red Hat. At least at the time (5-10 years ago). | | |
| ▲ | z500 an hour ago | parent [-] | | Thank you for injecting some perspective into the thread of AI hysteria. I feel like everyone is imagining a bug in a CRUD app. |
|
|
| |
| ▲ | echelon an hour ago | parent | prev [-] | | > LLMs are absolutely causing us to lose something very important The time wasted thinking our craft matters more than solving real world problems? The amount of ceremony we're giving bugs here is insane. Paraphrasing some of y'all, > "I don't have to spend a day stepping through with a debugger hoping to repro" THAT IS NOT A PROBLEM! We're turning sand into magic, making the universe come alive. It's as if we just got electricity and the internet and some of us are still reminiscing about whale blubber smells and chemical extraction of kerosene. The job is to deliver value. Not miss how hard it used to be and how much time we wasted finding obscure cache invalidation bugs. Only algorithms and data structures are pure. Your business logic does not deserve the same reverence. It will not live forever - it's ephemeral, to solve a problem for now. In a hundred years, we'll have all new code. So stop worrying and embrace the tools and the speed up. | | |
| ▲ | Trasmatta an hour ago | parent [-] | | > The time wasted thinking our craft matters more than solving real world problems? This is both a strawman and a false dichotomy. | | |
| ▲ | echelon an hour ago | parent [-] | | I mean to cause a stir! Let me invoke every logical fallacy and dirty rhetorical device I can if it draws attention. Too many of our engineering conversations are dominated by veneration of the old. Let me be hyperbolic so that I can interrupt your train of thought and say this: We're starting to live in the future. Let go of your old assumptions. Maybe they still matter, but it's also likely some of them will change. The old ways of doing things should be put under scrutiny. In ten years we might be writing in new languages that are better suited for LLMs to manipulate. Frameworks and libraries and languages we use today might get tossed out the door. All energy devoted to the old way of doing things is perhaps malinvested into a temporary state of affairs. Don't over-index on that. | | |
|
|
|