Live data from Hacker News

Ask HN: How do you get better at debugging/finding a solution?

news.ycombinator.com

61–70 of 83 posts

Re: Ask HN: How do you get better at debugging/finding a solution?

#61
Ask someone? If you have ever been part of a founding dev team you know there is gonna be stuff in the code that is unpleasant to untangle unless you are acquainted with how/why it was done. If you have some kinda searchable chat/FAQ thing I am sure someone has encountered this before or will in the future. I always thought slack was pretty good at storing years of dev questions threads in a single channel due to its informal question/answer nature vs something like stack overflow or Confluence

Re: Ask HN: How do you get better at debugging/finding a solution?

#62
post #38

- Create a call stack map and write it down - This will give you an overview of which classes, functions, methods, paths are being used. - People look down on console/logging, but it's useful specifically when there are race conditions or too many variables. It's way better to have several outputs and logs rather than a "standstill" picture you can only look while using the debugger. - "Learn to debug" - This advice…

> Create a call stack map and write it down

(personal anecdote) I strongly agree with this. Writing it down is very important. Whenever I trace through a call stack, I tend to construct a visualization of it in my mind (in the form of a DAG + each root starting with the caller, if you will). But I could never hold that image especially when it gets too complex. Forcing myself to write it down helped me a lot - it doesn't matter if it's messy writings or drawings, somehow the _act of writing_ just helped me so much in reconciling concepts and connecting the dots.

Re: Ask HN: How do you get better at debugging/finding a solution?

#64
I think sometimes not being able to get a software system with hundreds of thousands, or even millions of lines of code to compile is fine?

unless you didn't even do any changes, and it's a matter of the codebase requiring a specific environment or option to compile and you not having/knowing it

on getting better at debugging, I would try to isolate possible sources of the problem, form a hypothesis, test it experimentally

you'll need to know what you know

is it the environment you have? networking? OS? etc., whatever applies to your system

I think having a known working state is probably the most useful, though it might be difficult to get

something to consider, I do remember there being a paper on getting wrong results even when doing nothing wrong

Re: Ask HN: How do you get better at debugging/finding a solution?

#66

Something I read forever ago and can't find a link for: Keep a debugging journal. Take notes on every step you take and its results. It's easy to go in circles because you forget what you tried or forgot some detail of its outcome. Seeing a summary of what you already know helps you rule out possibilities and inspires new ones. I often forget to do this or feel like "I can handle this bug without a crutch". Yet every…

A journal also makes it much faster to jump back into a productive state after that inevitable interruption. (That interruption could be a meeting, or an emergency that forces you to drop everything and work on a higher-priority issue for several days.)

You can also refer back to your journal to remind yourself how you fixed that similar problem months ago.

Of course, a journal doesn't have to be limited to debugging. It's useful for development too.

Re: Ask HN: How do you get better at debugging/finding a solution?

#67
I use scientific method for the tougher bugs. It helps in situations where there are multiple root causes or when the testing loop is over 15 mins.

Write down a list of hypotheses. Then write an experiment to test it.

Sometimes there's this intuition to comment out a block of code, run, and then comment out another block of code. Or revert to something before a bug happens. That's all fine, just make sure it's linked to a hypothesis or multiple ones.

Or sometimes you don't have a hypothesis. This is where the scientific method is also useful - you know what you don't know!

Then you use the Monte Carlo method, or as I call it, throwing darts and seeing if it hits a bug. Basically you slice out random blocks of possibly offending code, compile, slice out more or less, compile, until you narrow down an area.

From that area, you might formulate a hypothesis. Or you may need to throw more darts until you see a pattern.

Scientific method is bloody slow but you'll get to the answer eventually. It's not for everything.

Re: Ask HN: How do you get better at debugging/finding a solution?

#68
post #57

Learn 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 reprodu…

Also, some languages are much more difficult to run debugger code on in production or running the debugger uses a whole lot more resources that would interrupt the stability of the production environment for a bug that might not be worth that much.

I use PHP/Laravel mostly, and while XDEBUG will work with a remote server, it requires an extra extension be installed and activated with a restart of PHP-FPM. That might mean downtime if you only have one app server. After the extension is activated, it requires extra resources to profile each request. Sometimes an order of magnitude more.

Luckily, because it is just PHP, running it locally isn't too hard, but I wanted to outline a scenario where a bunch of people cannot really use a debugger in prod. I've definitely been on teams that have pushed log statements to production to track down issues that were only present in one environment and not reproducible locally. Actually, one just came up about a month ago. Our app server is behind a firewall and a VPN (internal company app) and one of those services isn't properly forwarding the `X-Forwarded-Host` header correctly which caused issues later down the line when the framework was attempting to generate URLs. This caused an issue in our frontend code where some JSON data included bad URLs to the UI. Wasn't reproducible at all locally. Took some logging to find out where in the process the URL was wrongly generated so we could develop a workaround.

Re: Ask HN: How do you get better at debugging/finding a solution?

#69
post #67

I use scientific method for the tougher bugs. It helps in situations where there are multiple root causes or when the testing loop is over 15 mins. Write down a list of hypotheses. Then write an experiment to test it. Sometimes there's this intuition to comment out a block of code, run, and then comment out another block of code. Or revert to something before a bug happens. That's all fine, just make sure it's linked…

If anyone reading this thinks they don't need to use the scientific method and be explicit about hypotheses, you just haven't found a hard enough bug yet. No matter how good you are, there's some bugs that you'll only be able to solve this way.
Post reply on HN