Agreed. A project I worked on in grad school involved developing a thick client (Swing) for a large corporation. Well, we pushed the envelop with Swing, and it was several times where a bug was actually in Swing, and we had to find a workaround in our code while we waited for Sun to fix it.
But on the flip side, everytime we saw something weird happen, our knee jerk reaction was, "Its a bug in Swing". And our project leader would look at us and say, "Java works". His philosophy there was that if your basic assumption is that the tools you are using are broken, you can never get anything done! Start by assuming you made the mistake, and work away from that point.
I did a Swing project soon after Java 1.3 came out and kept finding odd bugs where the behavior of the code directly contradicted the behavior in the JavaDocs. My experience was basically that if you didn't do things exactly as they did in The Java Tutorial, chances are it wouldn't work. Or it'd mostly work, but with weird edge cases when you did something unexpected.
I asked my QA manager about this, and he said that the word on the street was that Java 1.3 was not QA'd. They just made sure that the tutorial worked and pushed it out the door.
I've had similar experiences with Java AJAX frameworks. The basic stuff from Sun (JavaEE, JSF) seems fairly robust, as long as you use it in the intended way. But many of the add-ons like Facelets, A4J, RichFaces, etc. are made by small 2-3 person startups, and they don't QA or document their code at all. Moreover, their code frequently makes functionality in the base JSF layers break (eg. you have to use ui:repeat instead of c:forEach with Facelets, and then you have to use a4j:repeat instead of ui:repeat if you add A4J). Maybe that's changed since they were bought by JBoss, but it's something to keep in mind whenever you use bleeding-edge libraries by small teams.
So I'd amend that: start by assuming you're wrong, but if you can't find anything in your code, look at your dependencies in order of least-used -> most-used. Chances are, software like Python or Apache or Java has been fairly well-exercised, and most of the bugs have been worked out. But there's no reason to believe that JPartTimeOneDeveloperLibrary is any better than code you write yourself, and if you use untested projects like that, you should budget time to look through their source code and debug their problems and send in patches.
Unfortunately, sometimes managers get it into their head that a 3rd-party library is more reliable than it actually is, often because the vendor has the chutzpah to charge a hundred grand for it, and they mandate you use it. This should be considered a bug in your manager, but unfortunately there's no fix for that...
But on the flip side, everytime we saw something weird happen, our knee jerk reaction was, "Its a bug in Swing". And our project leader would look at us and say, "Java works". His philosophy there was that if your basic assumption is that the tools you are using are broken, you can never get anything done! Start by assuming you made the mistake, and work away from that point.