Encoder's good instincts will ultimately hit you in the teeth

I wrote my first few lines of code almost 32 years ago, when I was 6. I developed very strong programming instincts and could look at any problem, immediately knowing how to solve it — just intuitively.

By the time I started writing programs to make a living, I felt like a rock star. I found and corrected errors faster than any of my colleagues. My team gave me the most subtle and intricate bugs. They even began to call me master.
')
But intuition alone is not enough . I ran into a wall. And no encoder instinct helped me get through it. Next, Bill Sourour will share with us information about how not to stop there. To some, these arguments will certainly seem obvious. Well, someone will come in handy.

The problem of distrust of your own intuition

Unfortunately, intuition cannot be considered a means of solving problems. When you rely only on intuition and instincts, you get a curve that looks like this:



Of course, you can accept these restrictions and deal only with problems that do not go beyond the boundaries . This will give you the opportunity to feel like a star, but it will severely limit your professional and career growth. Besides, it's boring.

I moved further and further along the career ladder — I began to challenge my own capabilities — and began to notice a disturbing trend. I was no longer the fastest.

I always knew that sooner or later I would meet people stronger and more talented than myself. My delusions of grandeur had their limits. I realized that I was not a genius.

I looked around and realized that the people who surround me are not at all endowed with intellect superior to me, they do not have a special gift. They just have a special weapon that I miss: discipline.

It turns out that a consistent, step-by-step, methodical approach to studying and solving problems ultimately surpasses any natural data (or instincts that you are trying to develop).

Let's look at these abilities

Regardless of who you are, how much passion or natural talent is in you, sooner or later you will reach the limit. I will share with you several techniques that will help to fundamentally solve the problem with the discipline and development of your abilities.

I am sure that if you have a debugger, you have already started it, google it a little, and have not achieved the result.
I am also sure that if someone told you about this problem, you would reproduce it. This is an important statement. If you cannot reproduce the problem, this will be your first step.

You need to compare the context and the environment in which the problem occurred with those in which you are trying to reproduce it. Begin to eliminate the differences, one by one, until you reproduce the conditions.

As soon as you can reproduce the problem, and as soon as the debugger is useless, you should use the method of discipline.

Read the damn instructions!

Read the instructions in the end! The RTFM approach is not only about this, but even children can read.

Actually read. And more than once, if necessary. Do not look at it in search of what you can copy / paste and hope that everything will work.

The problem is that the answer you need is quick. You need the thrill of easy victory. You do not want to work. Slow down. Inhale. Take some coffee. And read the accompanying documentation!

If there is no documentation, you should create it after you understand the problem. She can be useful to someone else.

Check your assumptions

If you assume that something should work, but it does not work, it is because somewhere you made a mistake. Check all your assumptions and find the right answer.

Start with the simplest assumptions that can be easily verified. Is the server itself running? Is it connected to the network? Are all the brackets and semicolons in place?

If you do not start with the simplest assumptions, and then it turns out that this was the problem, you will be ready to throw yourself out the window. So save yourself time and nerves.

Disassemble and reassemble

Remove the components step by step until everything starts to work, and then reassemble everything and you will find the non-working part.

It looks tedious and scary, but it is one of the most effective ways to find an error in the code. Make sure that you make a backup copy before starting, in case everything deteriorates completely. So you can always return to the starting point.

By the way, if you find yourself in a situation where you don’t know how to restore the code, then the problem is more serious than it seems: you don’t understand the code you are working with. This is a bad sign, my friend.

If you have deadlines, contact someone who understands the code better than you. If such a person is not around, you will find a sleepless night. It is worth understanding how this code works. Only then can you fix it.

Eliminate variables

Everything that can change at least in one of the points should remain static while the debugging process is in progress. You cannot hit a moving target.

This will help you to develop through testing (TDD). If you are using TDD, then you should have several dummy objects (Mock objects) at your disposal.

Dummy objects simulate the controlled behavior of real objects. The programmer, as a rule, creates a mock object for checking the behavior of some other object. This is largely similar to what a car designer does using a crash test dummy to simulate a person’s dynamic behavior during a car accident. - Wikipedia

Hint: if in the course of experiments with an object the error disappeared, then, most likely, the problem is precisely in this object.

Use "Saff Squeeze"

There is a technique called "Saff Squeeze" ("Saff's vise"), its author and creator is Kent Beck. And this is something between the previous two options.

The author describes it as follows:

To effectively isolate a defect, start with a system-level test and gradually move forward until you find the minimum possible test that the defect demonstrates.
- Kent Beck

Thus, instead of digging through the code, you just need to add the tested functions to the test itself, and then check the statements until the error itself disappears.

This will give you an advantage: you will be able to perform all the smaller tests, which, nevertheless, will be as focused as possible.

Note: Jim Balter provided us with this link for a better understanding of the Saff Squeeze technique.

After fixing everything, break it again and fix it again.

Never leave a mistake until you understand how you fixed it. You must learn to reproduce the error and correct it again.

You have no idea how important this is. If you correct the mistake and you don’t know where it comes from, and how exactly you fixed it, it will come back and attack you again at the most inappropriate moment.

And what about instincts?

Now that you have learned these techniques, does this mean that you should use them and not trust your own instincts? No, absolutely not.

I advise you to save your instincts to the right moment. If you guess what the problem may be, and you can quickly check it - go ahead, satisfy your curiosity. If your mistake is under the green line, most likely your intuition will help you identify it most quickly.

But, if you tried a couple of your assumptions and nothing worked, stop and start to act methodically .
Combining discipline with instincts, you can become the best in any team.

To do even more, I want to combine five of my favorite refactoring techniques into a free PDF list — it helps reduce errors — you can get it by clicking here .

PS We recommend another useful article on the topic of work on yourself - Overcoming of labor marathons: 3-step method of increasing productivity, which allows you to avoid working at night .

The author of the translation is Vyacheslav Davidenko, the founder of the TESTutor company.