From the series “Programming Paradoxes”
A climber is climbing a steep slope. Can you imagine what would happen if he slips and the safety rope fails? Can you imagine it? He didn't make it in time? And he's already there. The bottom of the abyss is very close…
Wait, excuse me, I meant a programmer, and he's not climbing, he's just sitting there. The only thing moving is the mouse in his hand. “A programmer is a completely different matter,” you might say. But do you think he has no room to slip? Yes! And to a much greater extent than a mountain climber. A computer crash, data loss, a bug that crept into the program, a system crash… I can't list them all. He just won't reach the bottom of the abyss. He'll run into HR on the way. And then they'll deal with him. If he doesn't reach HR, he'll definitely be in big trouble. At least, minor ones are always guaranteed.
But let's not be so gloomy. There are simple steps that can help avoid such an outcome. Let's consider them.
1. Make regular copies of your work or make sure they are made automatically (I would do it myself).
2. When copying important information from one window to another, it's best to have the destination window empty. This way, you'll never get confused about which window to copy from. (Imagine the second window contains a previous copy of the information, and you get distracted for a moment and accidentally move the mouse. The first window suddenly becomes the second, and the second window becomes the first.) I've had cases where a copy overwrites the original. I even did this myself once.
3. Avoid basic confusion! Suppose you have two shortcuts or modules. You need to work with one first, then the other. They have the same interface, indistinguishable. Only at a deep computational level will there be a difference. You work with the first one and go to lunch. When you return, you're confused about which module needs to be launched. You've mentally confused them!
In practice, it's best not to have these shortcuts next to each other. As a last resort, temporarily move the second one to avoid accidentally clicking it, or delete it! Then restore it. But you'll be sure you've worked with the right thing. I had this problem. I needed to run module M1 in ten directories, but there was module M right next to it. There was no visible difference when running them. I acted quickly, but on the fifth run, I caught myself running module M as usual, not M1, which was temporary. How many times have I made this mistake already? I couldn't track it down easily. So I temporarily removed module M and started the entire process again.
4. Don't overload your brain with unnecessary tasks! If you need to enter an operator into a program or a necessary command, it's better, if possible, to copy it from a previously debugged block than to re-enter it. A simple typing error can be costly! I've even had problems with a single word that I somehow couldn't type correctly. A letter was in the wrong case, a number was missing. But my brain was already solving the next problem and completely trusted my hands—it seemed like a simple matter. I tried and tried, then gave up (not on the monitor, of course), went and copied it. The problems disappeared.
5. Protect important information from accidental access, including your own. I'll tell you a funny story. A former systems engineer from my previous job called me and said a large graphics system had suddenly stopped working. Without it, it was impossible to read several thousand models designed over several years. The crash had nothing to do with anything. Everything worked fine that evening, but wouldn't start in the morning. It had been down for a day and a half already. I started thinking. I analyzed the program's message. Everything pointed to access to the C directory being lost. I asked the following questions over the phone:
– Is Directory A in place?
– Yes.
– Directory “B”?
– On site.
– Directory “C”?
– Same.
– What's in directory “C”?
He names it. Everything's correct. There's no way to find fault. And it doesn't work. We break for lunch. Then I start asking him about the directories again, only in reverse order. “Why?” you ask. “It's all clear now!” But it's precisely upon examining it in reverse that it turns out, quite by accident, that directory “C” is inside directory “B,” and not right next to it where it should be.
Someone's nimble hands accidentally picked up “C” with the mouse and unknowingly dropped it inside “B.” Those hands could easily have been my systems engineer colleague's. He typed quickly on the keyboard and used the mouse swiftly. I've had similar experiences myself. The best thing is to block general access to such sensitive areas. If that's impossible, then restrict access to read-only access. But that's not always practical. What if the program writes to the directory? Well, that's up to you. There's always a way out. We shouldn't punish the person for the mistake (if we've found someone to punish, of course), but rather eliminate the possibility of the mistake.
6. Never replace software-created data formats with manual assembly! Even if they are easy and straightforward to create. I had such a case. A diskette arrived from the bank with yet another piece of information that needed to be entered into our system. The accountant inserted the diskette into the computer, called up the program, and within a minute the necessary data was on the screen. He did the same thing this time. However, after looking at the screen, he grabbed the phone in horror. I appeared in front of the screen two minutes later. My insides turned cold. All the names in our huge database had been replaced with just one. I won't say which one, but I might forget my own, but I'll probably never forget this one. It took a day and a half to restore it. Not only names were replaced, but also a lot of personal data, including salary information.
As it turned out later, a new person had arrived at the bank, and when writing to disk, he'd neglected the old program and entered the information manually. It was faster that way. Sure, there were controls in our software, but it's impossible to foresee everything. A rare combination of errors forced our program to work miracles.
7. Finally, I'd like to say: be careful with production databases. Never connect to them while debugging! You might forget to return to the debug database, and then… As a last resort, if you need to test something on the production database and there's no way to do it on a copy, ask a colleague for help. You'll connect with them, and they'll help you disconnect.
So, to make your programs perform fewer unnecessary miracles, use these simple rules. They will protect you from many misfortunes you won't even know about. And what about the mountain climber? Let him climb, but he's much less likely to stumble now.
