[Meegul]

I recently had to write a scheduling algorithm for our home-grown operating system. I was running into some very difficult to debug issues, so I asked my TA for help. They had no clue and told me to consult the professor. The professor wouldn't help. Our textbook offered no guidance. We're not allowed to discuss projects whatsoever with other students. So after north of 5 hours spread over a few days of trying to figure out my issue, I gave up. How was this a beneficial experience?

[bsder]

Not being able to discuss your project with other students in an operating systems class is insane. You need to get input for the subtle bugs that are going to occur.

There is a reason why operating systems and compiler classes are notorious.

However, if 5 hours debugging is too much, I'd get out of the field now. Try debugging something for MONTHS while your bosses are all hanging over your shoulder.

In addition, 5 hours spread out is a problem. Subtle bugs require intense focus and you should be doing 5 hours per session. You have to inload and control a lot of details, most of which are irrelevant, in order to find the thing that really matters.

I really wish I could teach a "debugging class" where I hand groups real code with frustrating bugs. Unfortunately, no CS department would ever let me teach it as it would destroy enrollment.

[Meegul]

I agree - 5 hours really isn't that much. I've spent much more time than that on single issues in the past, and it's by no means something that's scaring me out of the field. I should've spent more time in a single session hunting down the issue, but I didn't quite have the time (or motivation after seemingly making no progress) when it was only one of a few things I had to work on that week. One of my issues with that class in general was the complete lack of guidance on how we should go about debugging our operating systems' issues. The only method mentioned by my TA was to print more variables, which isn't incredibly useful if the kernel won't boot or if the print function isn't working. And the issues would compound as the projects were often dependent on previous projects. One of the tasks was to implement asynchronous signal handling through registered callback functions, which is quite difficult to do if you didn't get the scheduling algorithm working properly in the previous project. It felt like the class was designed to be difficult and not designed for me to learn. I was pretty excited to take an Operating Systems class, despite what I'd heard, and it was the class that left me feeling let down, not the content.

I would personally love a debugging class to get some more varied ideas on how to approach difficult problems. Seeing someone's thought process when debugging something like a kernel would've been really useful.

[bsder]

> Seeing someone's thought process when debugging something like a kernel would've been really useful.

The first thing when doing a kernel is don't be clever. Suboptimal isn't just good--it's preferred. Linear searches are fine. Shell sorts are fine. Arrays are fine even if you have to recopy them a lot. Hashes are too complicated. Trees are too complicated. Randomizing things is too complicated. Until your kernel needs to scale, the "suboptimal" ways are more understandable, and, as a bonus, they sometimes are more optimal as they require less up front overhead.

The second thing is "replace pieces". Because you weren't clever, you can rip out and change chunks with relative ease. It's not "proper", but, if you're on a deadline, sometimes swapping some component and having the bug go away is good enough. Just realize that, if a bug goes away randomly rather than because you understood it and killed it, you have planted a time bomb likely to blow up in your face at the worst moment. :{

The third thing is "hypothesize and THEN test". This drives me crazy with junior folks. If I had a nickel for every time I got the response "I dunno" in reply to "Okay, why did you think doing X would fix things?" I would be a rich man. This is the piece that makes debugging a kernel hard. You have multiple layers of abstraction, and the bug is probably 3 layers away from the thing that triggers it.

Something which I tend to use more for things like kernels than "normal" programming (whatever that means) is that I religiously check and assert on my data structures even at great performance penalty. Having a data structure blow up immediately is far better than soldiering on and getting the malfunction after everything is scrambled.

Something which I am becoming increasingly religious about is that time is an input to my functions that operate on "external" inputs (button presses, RF events, USB events, network packets, etc.). It's a pain sometimes, but when you need to debug something subtle, it is really nice to be able to replay things exactly.

And, a final piece of advice, learn your tools. GDB, for example, is amazingly powerful. Unfortunately, I only seem to learn more about it after the fact. :( I do something really stupid and someone asks "Why didn't you just do <mumble foo mumble> in gdb?" and my response is always "Because I didn't know about it."

[ams6110]

5 hours over a few days is nothing. You gave up too soon.

[Meegul]

5 hours on a single issue. I had spent north of 20 hours on my implementation before that. This was for a semi-weekly lab project.

[flyingcircus3]

I feel like there's always a little crotchetyness in older engineers. I remember being in school right when companies were putting all of their literature online. For electronics, that was such a huge leap forward from having to buy entire books of data sheets for integrated circuits. People on the other side of that divide had the same complaint about a different subject.

"You only looked through the data sheet for 4 hours? Back in my day it might take 4 hours to get the thing to even turn on!"

[infinite8s]

Who's going to help you in real life when no one has the answer?

[flyingcircus3]

Stack Overflow. The key to debugging is to not be so arrogant as to assume you are working on a problem for the first time. In fact, this is the underlying premise of rubber duck debugging. You tell an inanimate object what you did to get where you are now, and as you enumerate and elucidate, your faulty assumption is often laid bare.