Hacker News Reader

Comment by lll-o-lll | Hacker News Reader

Not sure I completely agree with this. It’s true that errors are feedback, and iterating from them makes progress. I just think it’s easy to get stuck in an inefficient loop. You’re making progress, no need to think harder.

When I first started programming for actual money (an embarrassing number of years ago now) I remember the old guy mentoring me wouldn’t let me use a debugger. “You have to think through the code, the debugger is the last resort”. I didn’t agree, it just looked like masochism and bravado from someone who hadn’t had good tools so I should suffer too.

Now that I’m the old guy, I recognise the wisdom. Stepping back, thinking through the problem, and you can write all that code without the inefficiency “run” “error” “modify”.

Or maybe that’s just how us old guys think.

View on HN

I never /really/ learned how to use a debugger. I know what one is and know enough to flounder around in one, but I haven't reached for one in a long time.

These days, I work on buzzwords like kubernetes, microservices and Go and I likely couldn't use a debugger for customer issues even if I wanted to. Instead, I rely on a mix of intuition, logs and sometimes blind luck. I wonder if I've accidentally ended up in a domain that isn't that difficult. Or perhaps my luck will run out and I'm going to hit a debugging brick wall some day in the future.

You should see tye faces of people when they observe mee looking at strace or something.

I've had way more success than I probably should have using something I now call "empathy driven debugging". I almost never use a debugger, instead I try to imagine I'm the person who wrote this program, and imagine where I might introduce this issue, and almost every freaking time I find the craziest stuff very quickly.

I usually think of it as a very scientific inspired process. Information gathering - Hypothesis forming - testing - evaluation.

Easy problems / bugs require next to no hypothesis. You just see the error, backtrace or whatever and can go fix it.

But harder bugs and system bugs usually require information gathering and analysis of that information to figure out and form a good hypothesis. To do that, just like your mentor said, you need good knowledge of the code and good understanding of what the information is telling you and what that can suggest or rule out.

I also find myself relying less on debuggers over time, but I think it’s for very different reasons. Namely, I get more of the kind of feedback I’d want either before even running the code (type checker, linter, etc all providing instant feedback in editor); or from improved code navigation tooling (type checker/editor again); or from years of honing my test writing instincts (if it’s worth debugging, it’s likely also worth testing, so you don’t have to debug it again).

But this is all very different from “just” thinking through the code. If anything, my cognitive capacity has declined significantly with age. I depend heavily on tools to shorten the paths I have to think through in the first place. And tests (if you’re doing TDD anyway) are just a more efficient “run, error, modify” after all.

Most reliable finding of my career is that when I meet at big problem, the best thing is to go "touch grass" as kids say these days. I will get my solution while climbing or standing in the shower. Whacking at the keyboard for 12 hours straight and ingesting ungodly amounts of stimulants will not help.

Having said that, I am quite keen to not learn from my experoence and I keep doing a thing I know doesnt work.

The lessons here are that understanding the code will have to happen anyways and that it is actually easier to tackle one problem (understanding the logic) rather than two problems (understanding the logic through the mechanics of how it is implemented at the machine level).

Sometimes you have to slow down to go faster.

Reply on news.ycombinator.com