> As a programmer, you learn to blame your code first, second, and third... and somewhere around 10,000th you blame the compiler. Well down the list after that, you blame the hardware.
I wish this were the case. The average programmer blames whatever library/third-party/etc. they're using, then somewhere around the 10,000th they might blame their own code.
(I run a third-party service and everything is always my fault, even syntax errors.)
This feels like it might be selection bias. I’m cautious to say that with more certainty, I hope my caveat below makes that clear.
No doubt these people exist, and I’ve worked with people who were similarly quick to stop debugging and come bother me with their problems that had nothing to do with whatever underlying thing I’d built. But the vast majority of my users have not come to me at all, because either they haven’t had any problems or they’ve done the appropriate legwork to investigate their own stuff first. A few come to me with legitimate bugs.
Caveat: these relative proportions have varied a lot depending on context, of course. But I can’t think of any context where the worst case was even conceivably close to average.
You’re right, I probably am biased. I run an HTTP API, and a lot of devs are unfamiliar with how to use HTTP APIs, especially when interfacing with an API without an SDK.
But take a look at any moderately popular OSS and the issues will be littered with “issues” that are actually due to the app code, not the OSS.
With that being said -- it was probably hyperbolic to use the term “average”, but meh.
Sorry, the particular bias I wanted to point out could be more clear. I think it’s possible that many of your users solve their own problems before they ever report anything at all. You won’t hear from them, so their problem solving demeanor won’t register unless you’re assuming some users are self-serving their problems. The “selection” part of this bias is applying your experience from people who report issues to people who experience issues. It’s very easy to get a very wrong picture of your user base by assuming the people who show up are representative of the people who use the thing you made!
It’s also very possible the thing you made is so effortless or free of potential problems that the only people having them are having their own problems! That introduces another bias: the only problems are self error. Unfortunately that means you built the thing well and you only get crap feedback, and unfortunately for you it makes feedback itself seem suspect.
If there's a bug in 3p code, they'd need to open up a PR to the open source library and be stalled on 3 weeks for the maintainer to see it. If it's a one-line bug in their own code, it's one glance at a stack trace.
There are many strange assumptions here. Why in your example is the library open source? Even when it is, why would the developer be expected to know how to fix it? Why in your example is the bug in the developer's code a "one-line" bug fixable by "one glance at a stack trace"?
The point is that, if the bug's cause is not immediately obvious, some developers tend to jump to "it's the 3rd party library", because in many cases they can then claim to be unable to fix it, or offload the responsibility to the 3rd party.
The assumptions were to minimize the amount of work for the developer in this case. If it wasn't an open source library then they'd need to roll their own, or scrap the entire feature if it isn't workable, both of which involve a good deal work than opening up a PR.
I also like to espouse a philosophy that problems should be investigated from inside out. Start with what you had direct control over, assume the issue is with something you did. Then work your way out.
However, I have watched more than one person do the exact opposite: assume everything else was wrong before even looking at their own contributions.
And this holds not just for programming, but for any endeavor.
My first job in the 1990s was programming VB for MS Access. I learned the hard way that if the bug wasn't obvious, it was probably Microsoft's fault. And over and over again I was able to demonstrate that it really WAS their fault.
My next job was in Perl. It took me a couple of years to find a bug that wasn't my own mistake.
I wish this were the case. The average programmer blames whatever library/third-party/etc. they're using, then somewhere around the 10,000th they might blame their own code.
(I run a third-party service and everything is always my fault, even syntax errors.)