No, our skulls are not bigger to hold larger-than-average brains. We have lumps on our heads from banging them on the wall when things like this happen:
I use a program every morning to display a list of recent changes to a customer database, as a double-check that things look fine. This way, if there is a problem in the database system, say from an errant automated process, I will notice that a large number of records have been added, removed, or changed, and I can check that it was intentional.
I wrote the program myself and it's worked fine for over a year. Today I turned over the task of running the program to a coworker who has inherited the task. But it didn't work when he tried it! I made sure it had nothing to do with his login name (the program doesn't care who runs it and it uses the database under the same credentials no matter who runs it). So it was clearly impossible that it always worked for me and failed for him, right?
After banging on my head on the wall for a while (the usual technique for programmers to solve impossible problems), I discovered the problem wasn't getting solved, so I went to Plan B: debugging the program. I'm sure you'd like to know what the answer turned out to be.
Answer: The program used a temporary filename based on the operating system process ID, and a form in which the filename was used had a field with a limited character size. If the script was run early in the day when process IDs were lower on a system that was booted each day, the process ID was four digits long and the filename field fit on the form. If the script was run later in the day when process IDs were higher, the process ID was five digits long and the filename field was truncated!
I ran the program first thing each day. My coworker tried it in the afternoon. Sure enough, when I shortened the temporary filename, it started working for him too. At any time of day!
The problem is solved, but I seem to have a lump on my head. Thanks for listening.
I use a program every morning to display a list of recent changes to a customer database, as a double-check that things look fine. This way, if there is a problem in the database system, say from an errant automated process, I will notice that a large number of records have been added, removed, or changed, and I can check that it was intentional.
I wrote the program myself and it's worked fine for over a year. Today I turned over the task of running the program to a coworker who has inherited the task. But it didn't work when he tried it! I made sure it had nothing to do with his login name (the program doesn't care who runs it and it uses the database under the same credentials no matter who runs it). So it was clearly impossible that it always worked for me and failed for him, right?
After banging on my head on the wall for a while (the usual technique for programmers to solve impossible problems), I discovered the problem wasn't getting solved, so I went to Plan B: debugging the program. I'm sure you'd like to know what the answer turned out to be.
Answer: The program used a temporary filename based on the operating system process ID, and a form in which the filename was used had a field with a limited character size. If the script was run early in the day when process IDs were lower on a system that was booted each day, the process ID was four digits long and the filename field fit on the form. If the script was run later in the day when process IDs were higher, the process ID was five digits long and the filename field was truncated!
I ran the program first thing each day. My coworker tried it in the afternoon. Sure enough, when I shortened the temporary filename, it started working for him too. At any time of day!
The problem is solved, but I seem to have a lump on my head. Thanks for listening.
. That and just make sure the head blows don't land on the actual computer, which has the unfortunate likelyhood of rendering the hardware you are working with inneffective 
