What do you do to move beyond a mental block?

Hello ladies an gents,


I've always had a weakness of being too persistent; I often go way to long while knowing that all it would take to resolve whatever I'm troubleshooting (software or hardware) is to step away sometimes for just a few seconds. But I don't have a system, a time, a point at which I know it is time to let go.



What is *your* line between giving up too early and wasting time and energy?


Thanks

I give a max of one hour to make it work, but if it doesn't, then it is a sign of coffee break. Which, most of the times, let your mind look from a different perspective right after you sit away with some fresh air to breathe

I take a drive.

kalabdel said:

I've always had a weakness of being too persistent;

Click to expand...

That is NOT a weakness.

I often go way to long while knowing that all it would take to resolve whatever I'm troubleshooting (software or hardware) is to step away sometimes for just a few seconds.

Click to expand...

Do you have the right trouble shooting tools? That helps immensely.

But I don't have a system, a time, a point at which I know it is time to let go.

Click to expand...

DON'T2! Of course it depends on what your are trying to figure out but as a rule, don't!

What is *your* line between giving up too early and wasting time and energy?

Click to expand...

I don't but I do put things a side for a while. Sometimes if comes to me sitting on the pot or in the shower or even when about going to bed.
Really!

Do you think that the people that Newton and Leibnitz just pulled calculus out of their a$$e$? What about Einstein? Some of the algorithm we take for granted took years to figure out.

The problem is that today we want instant gratification and we are also distracted by modern things they didn't have in older times.

I have solved problems that took me years to finally wrestle the problem into submission.

I know I make a lot of things look easy or I think they are trivial but I am 68 years old. If you don't give up and accept new challenges then you get to be mentally "tough"

Learning takes time. Be persistent.

One Thanksgiving, my brother's family travels up from GA to visit our family in upstate NY. My wonderful spouse is preparing TG dinner and I ask my brother if he will help me change the timing belt on my 4-cylinder K-Car (Plymouth Reliant). "Sure, good brother activity." So we follow the shop manual, line up the crankshaft and camshaft timing marks, take a lot of bolts out, eventually get to the timing belt, go to put a new one one, but oops, it looks like we bumped the crankshaft, so we rotate it back to until the timing marks are aligned again, fortunately no interference, put the new belt on, and put everything back together. We crank the engine but it is not right: my brother is cranking the engine from the driver's seat, peeking under the raised hood and sees gas spurting up out of the carb, and I go to the back an notice a vacuum on the tail pipe. My brother suggests we move the carb to the tail pipe - funny guy, my brother.

We get called into the wonderful meal, but I am depressed, sitting with the plate in one hand and eating it with the other greasy hand - I can still remember chewing on some of the grit - and staring at the floor, thinking about what we did. Finally, I say to my brother, "we assumed there was only one timing mark, but there are two of them, 180 degrees apart; they made 2 so it does not matter to which spark plug wire you attach a timing light." Sure enough, that was it.

To answer the OP question, sometimes life - the call to dinner in this case - makes the breaks for us; I don't think we can "force" a change of perspective, it just happens.

Patience and persistence are the key.

drbitboy said:

To answer the OP question, sometimes life - the call to dinner in this case - makes the breaks for us; I don't think we can "force" a change of perspective, it just happens.

Patience and persistence are the key.

Click to expand...

Thank you everyone.




@Peter, I'm not knocking down persistence but as per drbitboy's quote above, the brain needs a break or even slight distraction sort of stepping back and looking at the whole picture again.
I have not idea what it technically is but it happens almost every single time, I step a way and within minutes and sometimes seconds it becomes very clear.

And of course there's a line between giving up every two minutes and spending two hours working on the same code that just doesn't want to compile.

With regard to having the knowledge, I often don't. I am always learning something new and when it comes to software, there are so many quirks to most that trial and error is the only way (or thousands and thousands to dollars for specialized training.


I read about this 20 minutes /20 seconds method but I a try it turns into 20 minutes/ 15 minutes.


Edit: It think this is like having tunnel vision from focusing on the same thing for too long, and then taking a break allows for a fresh look at the whole problem/system.

Personally, I've found that doing something non work related generally helps for those real head scratches. Of course, you can't go off kayaking or mountain biking in the middle of a breakdown...

The cup of coffee also often helps, not because of the caffeine but from the break. Keep up the water and food intake too, the ol brain doesn't work so well when the body is hungry or dehydrated.

And, bouncing ideas off colleagues. Solved many issues after just having a chat about it with someone else, and coming up with a totally different approach.

I don't think there's an easy timeframe to work too. When i feel frustrated, or find myself trying the same thing repeatedly, then it's time to stop.

It never quite worked with me, but a very good friend of mine takes a toilet break (I guess number 2).
A coffee break and discussing with someone else usually helps either because the other person can point out to something we may have missed or we ourselves understand what we missed by relaying it to someone else. I believe there's a technique revolving around this where you simply explain it to yourself.

For me, usually it's doing something non work related. The most awkward one in my early years was running out of water polo practice and writing the solution to the problem I left at work in the coach's white board (I was dripping wet and didn't fancy finding paper). Had another solution pop in my mind whilst on the bus back home from a game too.

Staring into a screen or some diagrams or manuals may be blocking you from seeing the explanation/solution.

Take breaks.
Write the problem down or make a sketch on a piece of paper.
Write pseudo code.
Simulate it.
Talk to someone that is experienced in the problem.
Talk to someone that is in-experienced in the problem (who asks 'stupid' questions).
Do the whole thing in a different way.

Somewhere in this range of activities one can do, usually the explanation/solution is revealed.
If all of the above is exhausted, then post on the forum. Don't post on the forum as the 1st thing.

I don't have a method. Usually I take the break latest when I start going second round on the "what ifs, could ifs". Quite often sooner. Sometimes it needs a weekend or just a night in between.

Sometimes doing just something totally different.

Sometimes one just needs to try out some guesses.

The best usually is to have a good chat with someone about the stuff like Jesper said, inexperienced or experienced give different mechanics but it's important to speak out loud the things in your head and challenge them. It's not even just once or twice I have found the problem the second I just spoke it out loud to someone.

cardosocea said:

I believe there's a technique revolving around this where you simply explain it to yourself.

Click to expand...

Yup, cf. this link.

drbitboy said:

Yup, cf. this link.

Click to expand...

That's exactly it. Thanks!

kalabdel said:

Hello ladies an gents,


I've always had a weakness of being too persistent; I often go way to long while knowing that all it would take to resolve whatever I'm troubleshooting (software or hardware) is to step away sometimes for just a few seconds. But I don't have a system, a time, a point at which I know it is time to let go.



What is *your* line between giving up too early and wasting time and energy?


Thanks

Click to expand...

I agree with Peter, no such thing as being "too persistent". But I get what you're saying, as I do the same thing sometimes. I'll just keep at a problem until the light finally comes on in my head and I figure it out. I swear, I gave myself hemorrhoids stressing myself out one time trying to figure out a coding problem! Walked out of the office all stressed and frustrated because I couldn't understand why my code wouldn't work. Two hours later, I was walking around the house as if I'd been screwed by an elephant. LOL.

I try to avoid that kind of thing now (stressing out too much on a problem). I find walking away from it and coming back to it a full day later works best for me. That's not always possible of course, but I find when I'm rested and refreshed, and then come back to the problem, I typically figure it out rather quickly and easily. Often times, it's something simple or silly that I just couldn't see at the first go of it.

I encourage persons to be persistent!! Keep at it until you figure it out, but take a break and clear your mind and don't beat your head against a wall for too long. What annoys and outright frustrates me is when persons just give up on a problem to do something 'easier' (and often times not the best solution) just because they couldn't "figure it out" in <=10 minutes. I hate that!!

My boss noticed something funny about when I'm troubleshooting at a jobsite. He said I'll call him and tell him exactly what's happening, and how "it should be doing ABC, but instead it's doing DEF. I wonder why that is, maybe because of XYZ..." and then I'll hang up and call him back 5 minutes later having figured it out. I find it really helpful to have someone to talk out the problem to and bounce ideas off of, even if they don't have any input whatsoever. This seems to be essentially rubber duck debugging, where you sit and explain what should be happening, what isn't happening and what the possible causes might be.

I usually pair this with taking a walk or a break, and it seems to do the trick a surprising amount of the time, especially on those problems where you're familiar with the theory and the process, but something that should be happening just isn't.

EDIT: I see drbitboy has already posted the rubber duck debugging link, but it does seem to be a useful method of troubleshooting.

Slightly OT - or maybe not?

The advice so far is sound - especially the rubber duck thing. Explaining the problem to others is priceless.

All too often our industry is suffering from people that are trying to play songs on the piano without practicing playing the scales first. We all get mental blocks but if we are well-versed in the fundamentals we get a lot less of them. In my mind this means a digital class - logic gates, flip flops, the whole deal. Take it until you can ace it with your eyes closed. If you can get a part-time gig teaching it somewhere so much the better. DeMorgans, logical feedback, circuit reduction, SOP vs POS, the whole deal.

Another step is (gasp) leaning assembly language on a small chip. Years ago there were simple 6805 trainers for that purpose. Don't do a customer job with it but if you spend some time there the experience will benefit you for a lifetime. The field of computer science took a hit when somebody decided you could get a CS degree without ever looking at a line of assembler. Maybe that explains why CCW is 20 gigabytes.

Another help is learning and doing a non-trivial fun side project in real C - not ++ or Sharp. It'll help your understanding of everything - scope of data, function block instances, data structures, parameter passing, data types, etc.

Another help is studying the protocol documents for protocols that you are using. So many Modbus questions would fade away if people took the time to learn Modbus at the packet level.

The ladder programming language has deceived corporate America into thinking that the PLC works like relays. It doesn't and it never did. It's a computer, we are programming computers, and we need an understanding of mechanics, electricity, digital logic, relays and programming to make these computers work. You can't be a concert pianist without playing the scales.

Yet even concert pianists need to keep a rubber duck near their keyboards..