Debugger block

Question

Have you ever encountered a mistake when you simply do not know the ideas and do not know what to do next, and you are very annoyed? Are there any general ideas on how to get out of this mode?

Answer 1

When I lock in this way, the best advice I have found is to leave it for a while. Whether it's a long lunch or an all-day vacation. Come back fresh and take a look at the new. Most of the time, the answer will look in your face. So far, a 10-minute coffee break is not enough for me, but your mileage may vary.

Second, talk with your peers. Go through everything you've tried. Just ask them to listen, and while you speak many times, the answer will come to you.

These are just the two that I use most often when I debug a lock.

Answer 2

• Five minute break

It is imperative that you do not break the keyboard.

• Explain the problem in a letter to your sister

Or your two year old son. Someone who would not understand the word if you did not explain it very clearly. You do not need to send email, you just need to be sure that you understand it inside out. You are surprised at how many times just repeating a problem suddenly makes it obvious to you where you did wrong. This is a good way to find out what your assumptions were about the problem, and how they may not always be correct.

* This link is JaredPar's excellent answer to another SO question.

• Talk to a colleague

At this point, you have already "emailed" the family pet, so you know that I hope you have covered all the silly aspects, it's time to talk with a real person. Perhaps in the past they experienced some obscure thing that reminds them of this situation, and they will definitely have a different perspective. Try to make sure that you understand what the problem is, not what you think. You do not want to prejudice them. You can and should talk about what they tried, and explain why you think that the problem is in this area (you are probably right), but you do not want to cover your mind with their sentences, even if they do not seem to be right.

• Look at the code again

By this time, I hope you will be less cruel, and you should be armed with new ideas. Start by re-checking the error. A simple step, but I was upset for hours on the error that was in our test script, and not in our code. Once you have checked the error again, start at the top. Check ALL. Place a breakpoint at the last point at which you are 100% sure, and then work your way forward until you find that the result is again broken. This is a huge success, because now you have, I hope, a smaller block of code for investigation. Then, if necessary, pull a colleague to look at the actual current code.

Answer 3

I usually take a break ... if that doesn't work, I sleep on this issue. (Actually, to be honest, I have to say that I spend sleepless nights pondering the problem).

I almost always have a list of possible solutions ready for the morning. :-)

Answer 4

I usually take a few steps:

• Look at the code that is involved in the functionality that has the error, and place the log messages in such a way that they help me narrow down the problem (this allows you to look at the logger later when you are no longer annoyed, and possibly find useful hints: P)
• ask my senior colleagues for tips
• call the customer to have a clear idea of ​​when the problem occurs.

Answer 5

I usually find myself in a mood where I have not used a structural approach from the very beginning. Iteratively narrowing down the area in which the problem may occur, and trying to write the smallest code base that can reproduce the error, I have not yet failed.

Answer 6

I think that if you run into such a problem, it's time to do some serious refactoring ...

It may also indicate false assumptions. Try to programmatically use everything that you "just" assume. See that not one invariant method is broken about any methods that are on the stack.

Answer 7

Others spoke of rest or "sleeping on it." This method is known as (among other things) incubation. Once you accept the idea, you can accept it too.

One important aspect that really leaves the problem, I’m sure you will have the answers later. It is dangerous otherwise, especially if you sleep on it, because you will worry about it until the last minute, then it will become an endless cycle that your mind gets into at night. You probably end up waking up not too well rested, dreamed a lot of circular dreams. Do it too much and this is the way to depression.

Answer 8

Another good option is to drop ideas from other developers / team members. Sometimes they ask you questions that you did not consider.

If you work alone, it’s nice to have several development colleagues with whom you can communicate to troubleshoot using different approaches. You will be surprised how often a new perspective can be the breakthrough you need.

Answer 9

Try David Ungars "Soul Methodology":

"If you know what to enter, enter. If you do not know what to enter, take a shower and stay in the shower until you know what to type."

This type causes what most like. Take a break! It doesn’t matter what the gap is if you don’t think about what you did before the break. Distraction in any form is good.

Greetings!

Answer 10

I usually do a dry move through the insult method / function, step by step. And do not assume that the error comes from there, it can come from anywhere.

Use the correct debugger, do not use the printfs series.