4 ms·

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

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 6mo ago
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 6mo ago
  Thank you for injecting some perspective into the thread of AI hysteria. I feel like everyone is imagining a bug in a CRUD app.
- t43562 6mo ago
  For sure! I had a bug that crashed our system once every 14 days or so and every coredump had a different stack trace. The "star programmer" managed to shift the bug onto me, the newbie graduate, after failing. This was a long time ago and I had to sort of invent fuzz-testing (as far as I knew!) to reproduce the problem in a short enough time that it could be debugged. That bug took weeks to find and there was nobody to help and only a manager kicking my arse every day. Instead of a medal I got brickbats for solving it but they did carry on using my testing system...
  - badc0ffee 6mo ago
    [dead]

badc0ffee 6mo ago

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 6mo ago
Thank you for injecting some perspective into the thread of AI hysteria. I feel like everyone is imagining a bug in a CRUD app.
t43562 6mo ago
For sure! I had a bug that crashed our system once every 14 days or so and every coredump had a different stack trace. The "star programmer" managed to shift the bug onto me, the newbie graduate, after failing. This was a long time ago and I had to sort of invent fuzz-testing (as far as I knew!) to reproduce the problem in a short enough time that it could be debugged. That bug took weeks to find and there was nobody to help and only a manager kicking my arse every day. Instead of a medal I got brickbats for solving it but they did carry on using my testing system...
- badc0ffee 6mo ago
  [dead]