You can't find a solution? There is no revision of the source code that still compiles? Then find that revision first.
Divide and conquer.
And define things out of existence.
Ask HN: How do you get better at debugging/finding a solution?
51–60 of 83 posts
Re: Ask HN: How do you get better at debugging/finding a solution?
#52For a new job is a common problem. When I was younger I always thought I must be stupid because basic setup, builds are done well and I just can't figure it out. Now I realize that most teams have random quality builds and likely there is some peculiarity that you can't google for. You need a buddy to keep asking, also pair programming is great, if you can sit with someone else and watch what they do it really helps.
I also suspect their builds have no good reproducibility tests.
Re: Ask HN: How do you get better at debugging/finding a solution?
#53* start logging shit, even things you know to be true / can't possibly be the problem. Somewhere your model of the code is broken, and you need to test find the breakage (model needs correction, or program needs correction).
* Split the problem space. Payment messages are not getting to the slack channel. Well, is it a bug in receiving payments, or a bug sending slack messages? Check if the payments are hitting the database. If no, you know it's on the input side. If yes, you know it's on the output side.
* Explain the problem to someone else; if you're alone write it up like a question you're going to post on a forum, with as much detail as possible. This must engage a different part of the brain, because often I'll figure out the issue while writing it up I'll reveal some clue while logging example output to add to the post.
Longer-term, teach a programming class! You'll get very good at debugging issues because you'll encounter a lot of other people's bugs, and you'll get a feel for what causes particular failures.
Also, don't feel any shame in asking others for help. Even senior devs get blocked, and they ask other seniors, or juniors, or if juniors are not available a rubber duck will suffice.
Re: Ask HN: How do you get better at debugging/finding a solution?
#54I don't know if I'm "good", i.e. efficient at debugging. I'm just incredibly persistent. If that means stepping through 20 layers of framework code... so be it. I've found weird undocumented edge cases that way.
That said, you mention not getting your code to compile. I've never (at least not in recent memory) not been able to get my code to compile by myself after a while, but I also don't know what language you're working with. Are you struggling with the type system? That can usually be tackled by taking expressions apart, assigning them explicit types and then reasoning through the inputs and outputs (with pen and paper if need be).
Re: Ask HN: How do you get better at debugging/finding a solution?
#55This talk, "Debugging with the Scientific Method" changed how I debug problems. I try to watch it once every year or two. tl;dr, when debugging people naturally form a hypothesis about what is going wrong and then set about gathering evidence to support or refute that hypothesis. When you do so unconciously you are very prone to biases of all sorts, most importantly confirmation bias. When you do so mindfully, and Wr…
One thing I have learned is to never say "This should work". If it doesn't work it shouldn't work.
For sure! My least favourite type of bug is the converse though. "How is this possibly working?"
When you're pulling on a thread and come across a function that looks completely broken and yet somehow is not.
Re: Ask HN: How do you get better at debugging/finding a solution?
#56Simply get good at gaslighting yourself to keep yourself going on until you solve it.
Re: Ask HN: How do you get better at debugging/finding a solution?
#57Learn to use a debugger. This advice would be very obvious to many, but I'm constantly surprised by how many of my coworkers don't know how to do this and test code by pushing logging statements into a production environment.
Most of the time it is about being lazy - they just don't want to spend time recreating prod setup on their local.
To quickly fix something a lot of the times it is easier to push debug statements to environment that setup whole shebang on your local.
Most of the times you don't know which part of the system is wrong so yeah you can unit test all you want but if data in database is incorrect you still have to reproduce incorrect data on your local - but you still have to somehow get to know that there is incorrect data somewhere.
Re: Ask HN: How do you get better at debugging/finding a solution?
#58* start logging shit, even things you know to be true / can't possibly be the problem. Somewhere your model of the code is broken, and you need to test find the breakage (model needs correction, or program needs correction). * Split the problem space. Payment messages are not getting to the slack channel. Well, is it a bug in receiving payments, or a bug sending slack messages? Check if the payments are hitting the d…
>Somewhere your model of the code is broken, and you need to test find the breakage (model needs correction, or program needs correction).
Most of the harder bugs I run into fall into this category. Great list of techniques to use. For when I'm really stumped I go into a more formal scientific method to the splitting the problem space approach. Formulate a hypothesis that if answered will reduce the search space, either by ruling in or ruling out things. Write it down - this is the important part, test it, repeat.
It's slow but usually helps me keep forward momentum. Worst case it at least creates a list of things that need better logging to figure out what's going on
Re: Ask HN: How do you get better at debugging/finding a solution?
#59I often tend to sprinkle conditional code with "in theory you shouldn't ever get here" printouts.
They get triggered more often than you'd think.
Re: Ask HN: How do you get better at debugging/finding a solution?
#60I'm fairly good at finding bugs and understanding code. Then recently I've had to mentor a few junior engineers and it seemed they struggled a lot.
It's a mix of search space reduction + heuristics. You start looking for most probable areas of fault. This includes new commits. Then you try to partition the places where the bug could be by probablistic reasoning, logging as you go.
If these approaches don't work then you start questioning your assumptions. For example, if there is eatApple() method, what did you assume about this method?
Did you assume all apples are rex, or is the functionality actually eatFruit()?