I'm intrigued that debugging feels to you as if it ought to be easy. It doesn't feel like that to me in many situations; I would go so far as to say it can often be one of the very hardest parts of being a good software engineer. Of course that's mostly due to phenomena like unrepeatable circumstances (in, say, complicated distributed systems), uncertainty-principle effects (where trying to get extra diagnostics out of the program perturbs the bug away), and so on; so some kinds of debugging (notably a lot of what I do at work, which runs on an emulated CPU and hence really is utterly deterministic and completely inspectable from the outside without altering its internal logic) are nice and easy. But debugging in general? Not nearly so convinced. I don't know what this says about our relative levels of geek-cred :-)

(The absolute hardest part of software engineering, I currently think, is anticipating all the tricky corner cases in advance, which I think many people don't even try to do any more, preferring to rely on writing "exhaustive" – or at least extensive – test suites after the fact and trusting that any code which gets through them will also not fail too badly in the field. Or just expecting to get bug reports from users and fix them later. Or not even noticing there were potential problems to begin with, and being surprised when they start to show up.)

I think debugging mostly falls into two classes: "easy" (the bulk of it; only one step up from fixing those pesky compiler warnings), and "hard" (the ones that can take a week to track down). The trick is to program in a way that avoids the hard bugs in the first place :-)
I don't find debugging per se very frustrating. Trying to debug (or do anything else) with lousy tools gets frustrating very quickly, though.

Hm. In retrospect, I think I wasn't thinking about debugging in general, but more "getting something to work". If I've written a system, understand it well, but there's some obscure case, then tracking that down can be interesting and challenging, or at least necessary drudgework[1]. (And of course the majority of errors are fairly mechanical.)

But if I'm handed or have written this thing, and it's *supposed* to work, but it *doesn't*, then I feel like I'm a complete failure for not understanding it. There's not obvious bugs like compiler errors or assertions (or they'd be fixed) and there's not some specific obscure bug (or it would work most of the time, and I know what I have to do) but lots of "doesn't work because you didn't call foo function" and "the make command line should be [lots of algebra], ok?" and so on. And it's supposed to be build, compile, start using, but in fact takes two weeks of blundering about; hence screaming.

[1] FWIW, I'm still no good at dealing with it, because my scheduling paradigm, such as it is, breaks down completely for "2 hours to 2 weeks" tasks :(

I just expect it to take 2 weeks every time, because every time I write something and make it work I then go off and do things that aren't programming for a few months, and forget all my good practice.