Good encoder instincts will ultimately “hit you in the mouth”

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 earn 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 inconspicuous and confusing bugs. They even started calling me a master.

But intuition alone is not enough. I ran into a wall. And no encoder instinct helped me break through it. Then Bill Sourour will share with us information on how not to stop there. To some, these considerations will certainly seem obvious. Well, someone will come in handy.

The problem of distrust of one's 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 limitations and cope only with those problems that do not go beyond the boundaries . This will give you the opportunity to feel like a star, but at the same time greatly limit your professional and career growth. It’s also boring.

I moved further and further up the career ladder - I began to challenge my own capabilities - and began to notice an alarming trend. I was no longer the fastest.

I always knew that sooner or later, meeting people is stronger and more talented than myself. My megalomania had its limits. I understood that I was not a genius.

I looked around and realized that the people who surround me are not at all gifted with an intelligence superior to me, they have no 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.

No matter who you are, how much passion or natural talent you have, you will reach the limit sooner or later. I will share with you several tricks that will help radically solve the problem with discipline and the development of your abilities.

I am sure that if you have a debugger, you already started it, google it a bit, and did not achieve the result.
I’m 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, then 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. Start eliminating the divergences one by one until you reproduce the conditions.

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

Read the damn instructions!

Read the instructions in the end! RTFM's approach is not only that, but even children can read.

Actually, read it. And more than once, if necessary. Do not browse through it for what you can copy / paste and hope that everything works.

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

If there is no documentation, it is worth creating it after you deal with the problem. She could 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 running? Is it connected to the network? Are all the brackets and semicolons in their 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 jump out of the window. So save yourself time and nerves.

Disassemble and reassemble

Remove 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. Be sure to make a backup before starting in case everything goes bad. 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 recover 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 your deadlines are on, contact someone who knows your code better. If such a person is not nearby, you will find a sleepless night. It is worth understanding how this code works. Only then can you fix it.

Exclude Variables

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

Here Development Through Testing (TDD) will help you. If you are using TDD, then you should have at your disposal several dummy objects (Mock objects).

Fictitious objects simulate the controlled behavior of real objects. A programmer, as a rule, creates a mock object to test the behavior of some other object. This is much like what a car designer does using a mannequin crash test to simulate a person’s dynamic behavior during a car accident. - Wikipedia

Hint: if during the experiments with the object the error disappeared, then most likely the problem is in this object.

Use Saff Squeeze

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

The author describes it like this:

To effectively isolate a defect, start with a system-level test and progressively advance until you find the smallest possible test that demonstrates the defect.
- Kent Beck

Thus, instead of digging into 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, however, will be as focused as possible.

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

After you fix it, 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 a mistake and don’t know where it comes from, and how exactly you corrected it, it will come back and attack you again at the most inopportune moment.

But what about instincts?

Now that you have learned these techniques, does it mean that you should use them and not trust your own instincts? No, not at all like that.

I advise you to preserve your instincts until the right moment. If you know 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 acting 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 — this will help reduce errors — you can get it by clicking here .

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

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