Edsgar Dijkstra, a famous Dutch computer scientist (well, at least famous among computer scientists of a certain age), was once asked what you should look for when you planned to hire a computer programmer. His answer was that you should look for someone fluent in their native language. Dijkstra reasoned that anyone who could communicate could be taught everything else they needed to know, and someone who couldn’t communicate wasn’t going to survive no matter what else you taught them. Indeed, anyone who has given instructions to a child about how to do something has already performed many of the tasks needed by every programmer.
To Dijkstra’s requirement, I would add that a good programmer needs a high tolerance for frustration. Anyone who has given instructions to a child will understand why. Computers are literal-minded; they do exactly what you tell them to do rather than what you wanted them to do. But they are also perverse; they sometimes seem to know what you wanted, but still do only what you said except that they will thumb their noses at you while doing it. The only way out of this is to persist. Keep trying until you have managed to describe what you actually want. These two characteristics are not valuable just for programmers. They would be very helpful in any profession where diagnosis and correction of problems is part of the practice.
I’ve had quite a few lessons in perseverance in the last couple of weeks. The church I attend has had problems with its WiFi network lately and I decided that I could fix the problems. I looked at what they had and what they wanted to do with it and said to myself “two hour job.” I’ve now been there for two hours or more at least five times. And at last, the network is beginning to behave. The WiFi can be seen all over the church campus (there are several buildings and, unlike your house, many poured concrete walls that do a poor job of transmitting WiFi signals). Where you can see the network, you can actually connect to it and get it to do something (this is new). And, the hidden mystery access point left over from some earlier, undocumented version of the network has been tracked down and killed. Considering the trouble it caused, “killed” is a pretty apt word.
I think I’ve finally overcome this problem. The interesting thing is that it was not my skill at networking that solved the problem. My skill at networking is what got me into this mess in the first place. It was tolerance for frustration and perseverance that got through the problem. Background got me to open the can and look at the worms, but it didn’t tell me what to do with any individual worm when I picked it up–”this thing is a router and I know what routers do, but I don’t know how this one works.” The new network design changed several times (for example, because of unexpected concrete walls) but ended up about where I thought it might.
It would have been satisfying to go to the church and fix a straight-forward network connectivity problem. It should have been much more satisfying to start with what appears to be straight forward problem, but has lots of hidden traps, and still solve the problem. It wasn’t. Everything works well enough, and the customers seem satisfied, but I still have an idea of what it could and should have been. I feel a need to go back there and tinker. Maybe tomorrow.
And no, I can’t solve Your problem, especially if it involves Windows.