Everything Breaks, All the Time.
jeff-vogel.blogspot.com
jeff-vogel.blogspot.com
Most bugs you experience daily (Word or your favorite game/appp crashing, etc...) are caused by actual software errors in overly complex systems with many dependencies. Multithreaded-coding errors can often account for many of those, but not only, complex system with many layers and complex dependencies can often hide obscure behaviors that can cause crashes in a given machine if, for example, you have a weird combination of disk drivers, file system code, and an antivirus hooking and acting on every filesystem read or write.
When, for example, a Word plug-in makes a call to Word's object model, this goes through easily 10 software layers until it reaches its target, some of these layers being configured via the flaky Windows registry, others going through jumps from VM-based to native code using weird "marshalling" techniques, etc... in these cases, you may encounter buggy behavior in any one of the 10 layers, or in a combination of two of them, even if it seems like you are just incrementing a simple counter.
Most of the time, though, bugs are caused by the app's own code (your own code): careless code, dangerous practices, lack of solid control-flow design, etc... if you write really good code, it's unlikely you will have many support issues. Only if you are working in some problem-prone area: plug-ins to other complex, often poorly-designed products, code pushing graphics drivers to the max, etc... where you get into "complex system" behavior.
Even if you use multithreading, if you control all the code, you can write very solid code. If your multithreaded code is perfect, it won't crash. Although it can uncover bugs in third-party libraries, etc... which is why I tend to write only "worker threads" with no third-party dependency if multithreading is required.
And I think it's very dangerous to warn novice programmers to think that the bug is probably somewhere else.
But at the same time, as a small developer, you have very little time to spare for support. Time spent getting the game working for one person is time not spent making a new game for everyone. You will need to develop a sense of when the time lost helping a person is not worth it, either because you won't be able to solve their problem or because they will not able to implement the fix you provide.
...
Remember: It's only worth the time to do tech support if you have the chance to, in a reasonable amount of time, fix a problem and make a loyal customer. If you realize that, at the end of the road, you aren't going to end with a happy person and a working product, end the conversation as quickly and pleasantly as possible.
In that context, I think his approach is very rational. If you pushed him, he'd probably agree that more often than not the issue is in his code (even if it's just a question of inadequate error handling). However, if the problem is only seen by a single user and will be a significant investment to try and fix, then it's simply not worth the time when he could be working on a new game, a port, or even a different problem that has been seen by multiple users.
Im not saying fix everything always immediately, but dont write people off as victims of cosmic rays just because you can't repro in 30 seconds or dont see the bug where youd expect in the code.
voodoo-style fixes
They're not voodoo, they're sledgehammer to smash a nut fixes. A reboot reinitializes every part of your system into a mostly-known-good state. If you knew what, you could say "restart this service" or "reinitialise this driver like that", but a reboot gets all of it.
If you actually stabbed a doll with a pin and your program started working, that would be ... scary.
I don't ignore bugs. I follow the same first step, and send the standard list of things to try like reinstalling, rebooting, etc. But if they still have it, I always look into it. Almost every time it's been a real bug. Some were really hard to track down, but would have caused a lot of grief later. I was always glad I did it.
For the record, I killed four weeks digging through code and running tests and it turned out that temperatures in winter coupled with some bad soldering was the cause of the issue. D:
It definitely takes some experience to be good at debugging. I guess that's why all the emphasis on development environments these days, where the hard stuff is being debugged by someone else and I can work on my app-level stuff in peace.
But I have never said, 'I won't look into a bug until multiple people have it.'
1) Most bugs are in code. But it might not be your code. Your code layers itself on top of many other layers of code that are outside of your control. Learning to deal with that will make a difference in your work.
2) Know how everything works. I am always hocked at people who claim to be web developers who don't even understand how an HTTP request/response works, much less what your browser does with the results. It is one of my interview questions for tech folk - I ask them to explain to me exactly what happens on the server when a browser sends it a request. Few people can give much detail here. Most can only give a generic explanation of the actions taken, if that.
Programmers aren't perfect. Practice makes permanents.
First, the diameter of the Earth is not quite 8000 miles, but 7926. So if anything says more than 7926 (plus maybe the height of a mountain or whatever), it's not calculating a straight line in Cartesian 3d space.
Second, that distance of 7926 miles would be from a point to its antipode. Iowa is not antipodal to Egypt, not even close. The antipode of Iowa is in the Indian Ocean and hundreds of miles from any land. The straight-line distance from Iowa to Egypt through the Earth's sphere would be more like 6000 miles.
Excerpts:
"In the measured period, one out of 132 software faults was a Bohrbug, the rest were Heisenbugs."
"[retry] routines had a 76% success rate in continuing system execution."
Cosmic rays or race conditions, transient bugs are common.