Hacker News Reader

This depends hugely on what kind of code you're doing. If you're mostly writing "glue" code between in-house libraries which may not be battle-tested, it's probably a reasonable assumption. If you're writing large amounts of application code yourself and the libraries you're using are widely used, then it's much less likely that there's something wrong with the libraries.

View on HN

Again, it doesn’t really matter whether the library actually has a bug in it: you’re just tricking yourself into finding the bug by looking at code that’s not your own. However, from personal experience well-used libraries and tools have more bugs in them than you’d think ;)

Alternatively, you can just internalize that anything running on your machines is your code. There's no difference between the piece of software you're writing and the library it's calling; you can and should step back and forth between them when debugging. Abstractions are cool, but there's great value in just getting your hands dirty and looking under the hood.

I can’t always fix “my” code, then :(

I'd generally agree with this (bumped up against more gcc, libc and kernel bugs than I'd have liked), but I find that my code has even more bugs than that. :)

Reply on news.ycombinator.com