First rule in programming: It is always your fault

You already know that feeling. It happened to all of us at some point: you pored over that code dozens of times and still couldn't find a problem in it. But there are a few bugs or bugs that you can't seem to get rid of. Perhaps there is something wrong with the computer you are programming on, or with the operating system you are running, or the tools and libraries you are using. Definitely like that!

Các lỗi trong phần mềm thì phần lớn là nguyên nhân do code của bạn! Errors in software are largely caused by your code!

No matter how desperate you are, don't act that way. Behavior in that way you are cheating on yourself and believing in the magic of computation and programming by coincidence. Or more briefly, is a blindness.

These cryptic bugs keep repeating and making you difficult and frustrated, but don't allow despair to get you lost. The key to becoming a humble programmer is to realize that whenever there's a problem with the code you wrote, it is always your fault. This is the summary in the famous book The Pragmatic Programmer called "Select Isn't Broken":

In most projects, the code you are debugging can be a mix of code and applications written by you and others in your project team, third-party products (basis data, connections, graphics libraries, special communications or algorithms, and many other things) and platform environments (operating systems, system libraries, and compilers).

There may be a bug that exists in the operating system, in the compiler, or a third-party product – but don't think about this first. Much of that bug exists in the application that is in development. Assuming that the application's code is wrong during the process of invoking a library, it is much more useful to assume that the library itself is faulty. Even if the problem is in a third-party product, you will still have to exclude in your code before announcing the bug to the vendor.

We used to work on a project where a veteran engineer was convinced that a faulty system call was caused by the Solaris operating system. Nothing can be convincing and no logic can change his mind (in fact, all other networking applications in the same category are working very well). He spent several weeks writing a remedial solution, and for some odd reasons, did not seem to be able to overcome that problem. Eventually he was forced to sit down and read the document about that summon, and he discovered the problem and corrected it in just a few minutes. Now we often use the phrase "select is broken" as a gentle reminder whenever a member of our team starts to blame the system as the main cause of the error.

The downside of owning that code is that you are responsible for that code. No matter what the problem with your software is – even if it doesn't seem to be due to your code – it should always be assumed that the problem is in your code and acting in that direction. If you want to be your software owner, take full responsibility for all its failures. Even if technically speaking, you don't have to do that. But that is how you will receive respect and trust. You will certainly not receive respect or trust by constantly blaming others, on other companies, or other resources.

Statistics show that an unbelievable result is rarely having any bugs or bugs in your software that are not your own. In the classic book Code Complete by the famous author Steve McConnell cited two studies to prove it:

Two studies conducted [in 1973 and 1984] found that, of the total number of reported errors, approximately 95% were caused by programmers , 2% were by systems soft (compiler and operating system), 2% is by some other software, and 1% is by hardware. Today's software systems and development tools are used by more people than the 1970s and 1980s, so my guess is, today, even the percentage of errors due to these causes The programmer is even higher.

Whatever problems occur with your software, take the responsibility. Start reviewing your code, and investigate further and further out until you have a definitive proof of where the problem resides. If that problem is in another piece of code that you can't control, you'll not only learn the essential debugging and diagnostic skills, but you will also have a trace of evidence to provide a basis for. his statement. This is definitely more work than just shrugging and pointing your finger to blame the operating system, on tools, or frameworks – but it also gives a sense of trust and respect that you will not be able to obtain through pointing your finger at the blame and finding ways to abstain.

If you're really inspired to become a humble programmer, then you never hesitate to say "hey, this is my fault – and I'll find a way to fix it."

ITZone via vinacode

Share the news now