Found out about "attention deconcentration" in The Disappearance of the World’s Greatest Free Diver[1] which was posted earlier by Thevet[2].
The article linked in this submission is by Igor Kusakov. It "attempts to describe specific mental techniques that are related to resolving very complex tasks in software engineering" and "also proposes to treat software engineering itself as research on human thinking because software is meant to simulate thinking."
Seems like a way to deliberately induce "shower thinking"? (Working away all day on some knotty problem and then it comes to you in the shower). If so it might be worth practising.
AKA "back burner" AKA "sleep on it". I've grown more and more to appreciate and try to use this modus of thought as much as possible. For me, it's cycles of active research and "cramming" everything I think is relevant to a solution into my mind, then a complete release of the stress of an active search away while I do something else and let thoughts of my previous problem come and go as they please. Sometimes, creative solutions come in the form of a self conversation in "language", other times it's sort of non-verbal, like visually seeing the problem from different perspectives. For me, this happens in the gym, while cleaning, doing dishes or other chores, while driving, etc. It takes practice but it's a very interesting thing to experience. I feel like sometimes it's the release of focus that lets the network of systems in your brain accept new stimuli from other systems and senses and tickle the thought in new ways.
A nice and relevant anecdote I recently discovered. When talking about the invention of the periodic table, everyone always focuses on the sudden dream that Dmitri Mendeleev had that revealed to him the table in it's full form, but they fail to acknowledge, as the story goes, the many hours of study and play with his set of "element cards" that preceded the revelation.
Absolutely. If I'm stuck on a problem I make a conscious effort to focus on that problem as I wake. I find there's a ~10 minute window in the awakening state where I can 'lucid dream' and often arrive at novel solutions.
tldr: There is a background, non-verbal process in your brain that has the advantage of a larger working set size than your foreground verbal thinking. It is able to observe and consider more stuff at once and find associations better than your conscious thought process. But, it has several disadvantages. It takes time to do it's processing. You can't will it into action. It communicates non-verbally with your foreground process. That doesn't work under pressure (thus the need for relaxed, unfocused time). The non-verbal understanding is difficult to deconstruct, generalize and reapply. It can lead to you solving a problem, not understanding how and not being able to solve a variant of the same problem.
Likewise. My first thought there was how it applied to martial arts. I've been told by a sparring partner to 'look at me' when sparring once, making me more aware of how I 'deconcentrate' my field of vision to take in all limbs and forms of attack, including those from others sparring around us. It's probably seen as a lack of attention by some, but it is quite the opposite. I also suspect a little distraction technique in asking me to think about where I'm looking as it was quite a 'dominating' sparring partner who made the request.
I noticed various sensais have suggested this kind of perception in their teaching also, asking us to look at the chest area and rely on peripheral vision etc. in certain exercises. No doubt other disciplines require this also. I wonder if target range activities would benefit or not from this kind of 'live peripheral data feed'.
wow - was thinking the exact same thing. Weird co-incidence in both of us noticing the same parallel. I'm guessing you got the newyorker link off reddit too?
IMHO and from my experience, the main keys to addressing complexity of software
are just to (A) define the data, input,
inside the software, data base, key-value store,
etc., and output,
(B) organize the work for any real time
parts,
(C) organize the code
essentially a calling hierarchy of
pieces, where each piece is
fairly easy to test well, and
where the purpose
of each piece is fairly easy to
document,
and (D), most important,
document everything so that
it is all easy enough to understand,
check, modify, etc.
For really big projects, there is more,
but (A)-(D) are the basics and where still
in practice a lot of problems are.
A curious but crucial part is that nearly
all the meaning of the system is
just in the documentation, not the code.
Rez is my favorite game of all time and the best game ever.
When I first started playing Rez, the screen was a flurry of light and color. I could guess what things should be shot at but I was mainly shooting things randomly and seeing what would happen.
It turns out that Rez tracks several metrics for each completed level and these are key to progressing in the game. The "Analyzation" metric notes how many "layer levels" of any level you've unlocked; you do this by shooting something called a "password lock". It consists of a little satellite holding a rainbow prismatic cube; shooting the satellite releases the cube, which must be shot eight times to proceed to the next "layer level". Missing one of these cubes when they appear negatively affects your "analyzation".
The other important metric is "Shot down", which notes how many enemies you've killed; HOWEVER, only enemies that "spawn from nowhere" actually really count. Enemies that spawn from other enemies do not affect your shot down total and may be safely missed unless they are projectiles which directly threaten you (slowly home in to your location).
So when you have a flurry of shit flying at you on the screen, suddenly target discrimination becomes key. So you have to pay attention to the objects on-screen and decide whether each should be shot or not, if it's worth the effort to swing your targeting reticle over it.
Then I reached a point in my Rez play where I was not paying attention to the targets but rather keeping it focused over the entire screen at once, noticing everything but zeroing in on nothing -- deconcentrated attention. And then it became no longer about aiming to shoot things down; enemies seemed to materialize directly under my reticle waiting to be hosed down.
And then things got really weird. I was watching the screen, but also observing myself playing the game. It almost seemed as if a different person were at the controls, a person which I still knew was me. I was thinking and reacting faster than I could understand what I was doing. It was akin to a mystical experience, one sought after by many in temples, abbots, and ashrams, brought within my humble reach by a fucking video game.
And people wonder why I'm a gamer.
To this day my copy of Rez remains a treasured possession, and playing it has shown me many neat things about what I'm cognitively capable of.
This is interesting, but while the article focuses on the issue of attention, it doesn't address the role of abstraction and chunking. There's been a lot of work in psychology that argues that 'expert performance' comes from lower-level concepts and operations getting grouped and automated. Attention remains important, but it is able to operate on larger, more meaningful pieces without getting bogged down in details.
In my interpretation of meditation, "ignoring" seems to take up too much energy; it's too combative. I've seen it described as acknowledging, and then letting go the thoughts. You acknowledge that they pop up, they they exist, that they can have an effect on you, that they can frustrate you, then you release them. It's a third person view of your own thoughts if that makes sense. Deconcentration is new to me, but seems that can be a similar strategy of not letting a singular thought dominate your whole mind and/or affect you emotionally, for better or for worse, and allow yourself to return to a calmer state that allows more thoughts equal chance in your mind.
Yes, this looks like Zen and the Art of Computer Programming if ever I saw it. I often think coding well is about letting yourself do it rather than trying to do it.
In Buddhist meditation the initial exercise is almost always concentration meditation (samatha, breath meditation). This trains you in single pointed concentration, relaxing the mind on the object, skillfully dealing with distractions.
But that isn't the goal of Buddhist meditation, its the preliminary practice. You need those skills in order to release your fixation/concentration without just spacing out in a dull sleepiness.
After that you do various forms of insight meditation (vipassana) which can explore what the single pointed concentration is.
In Dzogchen there are alternating exercises of single-pointed concentration and then releasing the attention and observing all things (including observing the observer and the observation process). If a beginner observes "everything" they just get spaced out and dull minded. That's why you alternate the exercises.
Meditation is NOT an absolute goal with an absolute value in and of itself. The whole point of meditation is to help get you in a state of flow. If, once in that state, you ignore your impulses, you're no longer in the flow. You might as well be struggling with your daily worldly problems then - you are no longer meditating, you are trying to escape yourself (which is struggle, which is the opposite of flow).
> Try experiencing red without visualizing it, naming it or imagining associated objects.
can be commanded to be done without being able to objectively qualify what exactly is occurring when one 'experiences' red?
How does one know when 'has experienced red' has occurred? How are they able to qualify this as a comparative to 'has not experienced red'? When I read this it honestly sounded like the author was telling me to find god.
Snarky commentary aside, while I think this is an interesting picture for the descriptions of thought, the processes for reasoning about software complexity can develop independently without fitting any of these models, and those heuristics will modulate and mold the adaptive abilities of the developer on a similar scale of overall improvement.
> These phenomena will slowly start to convert from being some “runaway kids”, living in the shadows never lit by consciousness, into “rightful citizens” of the psychical space, with overall balancing and efficiency-improving effects.
This scares the crap out of me and would make me want to run like all hell. You can learn and teach thinking using multiple techniques and you can teach those techniques without enforcing a clear right and wrong. Instead, trust that the experience and influence of the world marching along to the beat of time will help direct people better than an authoritative command on what reduces software complexity and what does not. The summation of a lot of 'wrong' might wind up being one big 'right'.
The funny thing really is that when one uses the a reasoning system to reason about their reasoning, assuming they are reasoning with the correct reasoning, they often wind up contradicting themselves.
The article linked in this submission is by Igor Kusakov. It "attempts to describe specific mental techniques that are related to resolving very complex tasks in software engineering" and "also proposes to treat software engineering itself as research on human thinking because software is meant to simulate thinking."
[1] http://www.newyorker.com/news/sporting-scene/the-disappearan...
[2] https://news.ycombinator.com/item?id=10027307