had a question and found answer

[Weiss]

simply allowed myself to think about it before posting. I mean, I already had it typed in, only a button push away, but remembering previous occasions let it sit for a minute.

Never stop being amazing how code writing works. I wish I could be more active on this forum, but I don't know much to help beginners, and run out of questions before I ask them.

[Joanna from IRC]

Maybe you need somewhere to chat 

[egsuh]

It's quite interesting that I spend several hours at least not days to solve a problem without success, I decide to ask for help in this forum, and after a few munites since I write the question here I find a solution.

[Joanna from IRC]

It's quite interesting that I spend several hours at least not days to solve a problem without success, I decide to ask for help in this forum, and after a few munites since I write the question here I find a solution.

You probably did this https://en.wikipedia.org/wiki/Rubber_duck_debugging
The act of composing your forum posts gave you new insights about solving the problem.

I once helped someone solve a programming problem which I knew nothing about simply by encouraging them to talk about it. 

[Zvoni]

I once helped someone solve a programming problem which I knew nothing about simply by encouraging them to talk about it. 

Was there a couch involved?   

[Joanna from IRC]

I once helped someone solve a programming problem which I knew nothing about simply by encouraging them to talk about it. 

Was there a couch involved?   

No couch involved, it was Back on freenode 

[Weiss]

It's quite interesting that I spend several hours at least not days to solve a problem without success, I decide to ask for help in this forum, and after a few munites since I write the question here I find a solution.

I am thinking, maybe when we formulate the question, we narrow it down to one small thing. Something about explaining the issue to others that helps seeing a solution. There is definitely a mental trick.

[TRon]

I am thinking, maybe when we formulate the question, we narrow it down to one small thing. Something about explaining the issue to others that helps seeing a solution. There is definitely a mental trick.

I do not know if this applies for everyone but for me that definitely helps.. a lot.

Most issues I encounter are situated in larger projects and in order to be able to formulate an actual question that can be answered I have to narrow down the problem. In doing so (and for me) there is almost a 100% rate of success being able to locate my own error when writing a small test-project that produces the same error (most of the times the test is so small it is easy to debug as well in case it was not a simple oversight).

It truly is a god-sent when you are able to reach such level of confidence which allows you to be able to solve your own issues and the great part is that you can start at any level of expertise (e.g. as long as you understand the (your own) code). Once you are confident enough about your own code you can expand that knowledge exploring other peoples code or try new (language) features that you are not (so) familiar with.

[MarkMLl]

In my student days, there was a "cult book" by the name of "Zen and the art of Motorcycle Maintenance". The core of the narrative was that an academic had tried to isolate the concept of "quality" across multiple fields, and that the attempt had driven him to a nervous breakdown.

A "trendy" friend suggested that just about everybody arrives at their own personalised interpretation. However from our POV, and allowing that the book is rarely discussed, I trust the community will allow me to insert a passage.

Of the value traps, the most widespread and pernicious is value rigidity. This is an inability to revalue what one sees because of commitment to previous values. In motorcycle maintenance, you must rediscover what you do as you go. Rigid values make this impossible.

The typical situation is that the motorcycle doesn't work. The facts are there but you don't see them. You're looking right at them, but they don't yet have enough value. This is what Phædrus was talking about. Quality, value, creates the subjects and objects of the world. The facts do not exist until value has created them. If your values are rigid you can't really learn new facts.

This often shows up in premature diagnosis, when you're sure you know what the trouble is, and then when it isn't, you're stuck. Then you've got to find some new clues, but before you can find them you've got to clear your head of old opinions. If you're plagued with value rigidity you can fail to see the real answer even when it's staring you right in the face because you can't see the new answer's importance.

The birth of a new fact is always a wonderful thing to experience. It's dualistically called a "discovery" because of the presumption that it has an existence independent of anyone's awareness of it. When it comes along, it always has, at first, a low value. Then, depending on the value-looseness of the observer and the potential quality of the fact, its value increases, either slowly or rapidly, or the value wanes and the fact disappears.

The overwhelming majority of facts, the sights and sounds that are around us every second and the relationships among them and everything in our memory...these have no Quality, in fact have a negative quality. If they were all present at once our consciousness would be so jammed with meaningless data we couldn't think or act. So we preselect on the basis of Quality, or, to put it Phædrus' way, the track of Quality preselects what data we're going to be conscious of, and it makes this selection in such a way as to best harmonize what we are with what we are becoming.

What you have to do, if you get caught in this gumption trap of value rigidity, is slow down...you're going to have to slow down anyway whether you want to or not...but slow down deliberately and go over ground that you've been over before to see if the things you thought were important were really important and to -- well -- just stare at the machine. There's nothing wrong with that. Just live with it for a while. Watch it the way you watch a line when fishing and before long, as sure as you live, you'll get a little nibble, a little fact asking in a timid, humble way if you're interested in it. That's the way the world keeps on happening. Be interested in it.

At first try to understand this new fact not so much in terms of your big problem as for its own sake. That problem may not be as big as you think it is. And that fact may not be as small as you think it is. It may not be the fact you want but at least you should be very sure of that before you send the fact away. Often before you send it away you will discover it has friends who are right next to it and are watching to see what your response is. Among the friends may be the exact fact you are looking for.

After a while you may find that the nibbles you get are more interesting than your original purpose of fixing the machine. When that happens you've reached a kind of point of arrival. Then you're no longer strictly a motorcycle mechanic, you're also a motorcycle scientist, and you've completely conquered the gumption trap of value rigidity.

-- https://chiro.org/Graphics_Box_LINKS/FULL/ARCHIVE/Zen/chapter26.htm

MarkMLl

[Weiss]

there was a "cult book" by the name of "Zen and the art of Motorcycle Maintenance".

...The overwhelming majority of facts, the sights and sounds that are around us every second and the relationships among them and everything in our memory...

What you have to do, if you get caught in this gumption trap of value rigidity, is slow down...you're going to have to slow down anyway...

-- https://chiro.org/Graphics_Box_LINKS/FULL/ARCHIVE/Zen/chapter26.htm

MarkMLl

this is also a fact, with rigid value, if you take it seriously. It is like fighting the Pharisees, you eventually become one, because you believe they are wrong and you are right.

I say, lets have rigid value to old and trusted facts. There is no gremlins in electronic circuits, but there are a lot of bad contacts.

Mark, I can turn anything you say upside down, and appear to be right and instill a doubt. I play this trick to my wife all the time. What we talk about here is simple. Narrow down the problem, be specific, and there will be light.

[MarkMLl]

I say, lets have rigid value to old and trusted facts. There is no gremlins in electronic circuits, but there are a lot of bad contacts.

It is possible to have chaotic behaviour in electronic circuits: I raise you with the classic http://engineering.nyu.edu/mechatronics/Control_Lab/bck/VKapila/Chaotic%20Ref/Porfiri's/Biblio/Matsumoto87.pdf

MarkMLl

[Wesbat]

In my student days, there was a "cult book" by the name of "Zen and the art of Motorcycle Maintenance". The core of the narrative was that an academic had tried to isolate the concept of "quality" across multiple fields, and that the attempt had driven him to a nervous breakdown.

Thanks for sharing this quote, very enlightening! I now want to read the book - will find a copy for my upcoming holidays

[Wesbat]

In response to the Original Post - this is the reason why developers keep journals. It provides a way to problem solve in a lateral way, especially when written in a conversation-style form (a monologue for example).

I keep occasional journals for some of my longer-running projects, and yes it takes effort, practice and time, but consider this fact: programming is not exclusively limited to typing in code

p.s. Do a search for "why you should keep a developer journal"

[TRon]

In my student days, there was a "cult book" by the name of "Zen and the art of Motorcycle Maintenance". The core of the narrative was that an academic had tried to isolate the concept of "quality" across multiple fields, and that the attempt had driven him to a nervous breakdown.

Thanks for sharing this quote, very enlightening! I now want to read the book - will find a copy for my upcoming holidays

+1

Very refreshing to read about the art of Zen these days.

[MarkMLl]

In response to the Original Post - this is the reason why developers keep journals. It provides a way to problem solve in a lateral way, especially when written in a conversation-style form (a monologue for example).

I keep occasional journals for some of my longer-running projects, and yes it takes effort, practice and time, but consider this fact: programming is not exclusively limited to typing in code

p.s. Do a search for "why you should keep a developer journal"

An engineer was, traditionally, expected to keep a notebook: usually hardbacked, and often with squared paper for ease of neat sketching.

This had sufficient recognition that it was acceptable in court cases, and my understanding is that so far there is no recognised software equivalent. Obviously there's things like Jupyter Notebook, but the problem is that it's difficult if not impossible to produce an adequate audit trail of when things were done... this is obviously something that a blockchain could help with but could we please not go there.

In terms of software, my code is very heavy on the comments. And I regularly update colleagues by email as to what I'm doing, particularly if they respond it provides a modicum of traceability.

MarkMLl