Hacker News Reader

Comment by harkain | Hacker News Reader

Anyone have any recommendations for material which teaches debugging in a systematic and formal way?

I teach debugging in all my courses. The best systematic approach to give broken code to students, both in activities and on tests. Students are exposed to common errors for each and every topic. I collect examples of mistakes from previous years and from Stack Exchange.

I also demonstrate how to debug. It is combination of making accidental mistakes during live coding and introducing intentional mistakes that I show how to identify and fix.

After reading this post and the link there on the ‘Feynman Method’, I’ve decided to read Polya’s ‘How to Solve it’ [1]. I say this as someone who did his BSc in pure mathematics, MSc in CS and has worked as a programmer for a number of years. I meant to read it back in university, but I instead decided to keep applying the ‘Feynman method’, which I find for me is less efficient and more error prone due to my comparatively lower intelligence. The principles in the book shouldn’t be too hard to apply to both coding and debugging code.

They say you can’t teach an old dog new tricks, and you can’t increase IQ, but I’ve recently burnt a lot of actually quite simple coding interviews due to things like a missed edge case, and I wonder whether I can discipline myself to do things in a more disciplined and systematic fashion with this book. Not only for Leetcode/Hackerrank style questions, but for work as well.

[1] https://en.wikipedia.org/wiki/How_to_Solve_It?wprov=sfti1

On the topic of getting burned on edge cases I myself am in the same boat. I’m very much a speedy, excited programmer. I want to build the thing and see if it works afterwards. This can make me a bit sloppy especially in a time boxed coding problem.

What I’ve done to improve this to pretty good effect is follow this rough formula on problems:

- ask questions

- write out assumptions

- come up with a basic solution (pseudocode)

- see if i can come up with edge cases or converse examples that break my solution/assumptions

- code while stopping occasionally to repeat the previous step

- walk through the code manually with some examples

After doing this a bunch I’ve actually internalized a lot of the edge cases or errors I might have missed before. So I think I am slowly teaching myself to be more precise for these types of questions. It’s slow going but decently effective.

It’s hard to balance how much you should write on paper in place of just coding. Coding in itself allows you to explore the problem, but induces its own cognitive overhead, which might distract you from important insights about the direction you’re taking.

I replied prematurely. It definitely looks like we’re in the same boat regarding programming style. I wonder whether I can apply this with measurable results. It would be nice if it were easier to compare your completion time with others on Leetcode and Hackerrank so that the improvement could be measured.

EDIT: Some context about myself so as to not misrepresent myself as some sort of expert. I’ve been prepping while working full time for 6 months. I was really quite bad at doing the problems initially and now can pretty much knock out most problems without too much trouble. Planning to start interviewing in a month or two.

IMO comparing against yourself over time would be more productive. I say that cause it would definitely stress me out personally if I knew I was in the 10th percentile or whatever. And then that negative attitude could snowball into stopping practice.

If you do want an objective measure for FAANG I think Facebook recommends being able to complete 2 Medium level LC problems in 35 minutes. But again, it’s real hard to mimic the real interview environment of explaining yourself, being able to ask questions, etc. I did find mock interviews helpful early on to refine my process before just grinding problems.

Can always talk to yourself if you’re on your own. Maybe get a rubber duck so it’s less weird.

John Regehr has a post with some book recommendations from 2013 [0]. Notably one of the books corresponds to an older Udacity course [1].

There's also this book that was recently published called Effective Debugging: 66 Specific Ways to Debug Software and Systems [2].

[0] https://blog.regehr.org/archives/849

[1] https://www.udacity.com/course/software-debugging--cs259

[2] https://www.amazon.com/Effective-Debugging-Specific-Software...

Debugging by David Agans is great. It’s my #1 book recommendation for software engineers. https://amazon.com/dp/0814474578

The lessons from the book are especially helpful when I feel stuck in debugging; I’ll think through the guidelines and they get me unstuck almost every time. For example, yesterday I started feeling stuck trying to figure out why my tests were failing, and I realized I was failing to follow the “stop thinking and look” guideline. We tend to theorize way too much about what may be happening when we should simply look to see what is actually happening.

I didn't see this before I wrote my other comment (https://news.ycombinator.com/item?id=25337491), but the free Software Debugging course on Udacity is great: https://www.udacity.com/course/software-debugging--cs259

I teach undergrad CS, and recently wrote this to explain how to debug: http://justinnhli.oxycreates.org/debugging/

It's still a work in progress (I would like to add some worked examples), so any suggestions for improvements are welcome.

Reply on news.ycombinator.com