mindfulness....
It’s ironic that I’m sitting in my comfy Ikea chair trying to write an article about being ‘mindful’ while I simply cannot concentrate. My mind skips like a stone between my gmail account, boing boing, email, iTunes…anything but sitting down and typing this article.
Now I will focus.
Mindfulness, conceptually, is as simple as its name suggests. It is self-awareness on a very basic level. Be aware of what your mind is doing and how it is working and plan your current task accordingly. Different states of minds serve different purposes. For example, wandering un-focused drifting might put you in an excellent place to make a new discovery but it is not a place where you could expect accomplish very much. On the other side, hyper focused diligence is a great way to bang out a lot of source code but it’s not a state of mind where you’ll find much inspiration. This article is not the end all of writing about mindfulness. Additionally, due to this bloggy media it’s impossible to do much other than skip, rough shod, over the concepts. We’ll walk through a potential problem and explore mindful states during this three part series. Keep in mind that all these distinctions are completely arbitrary. They are blurry concepts and they tend to overlap. Keep that in mind as we go over them.
the wandering mind
This is where debugging starts. We are informed of the problem over email, from the QA engineer, in our own testing, from our boss. We must immediately open the aperture of our mind as much as possible. It is in this place that we find inspiration and new hypothesis. This wandering mind lends itself to brainstorming and culminates in a theory. New theory cannot be discovered through heavy focus and I’ll explain why. The more you think exactly about the problem the more your mind will settle into the ruts laid down by your previous attempts. If you don’t belive me, look at the history of scientific breakthrough. Newton was sitting under a tree when he was hit on the head by an apple when he had his stroke of genius, Archimedes was sitting in the tub when he had his breakthrough on the theory of displacement.
Compare their moments of discovery to your own moments of inspiration: they almost always happen when you aren’t thinking about the problem at hand. This is the purpose of the wandering mind; it unlimbers your unconscious. Rather than traveling down roads you’ve wandered before you’re free to challenge your boundaries and confront your pre-conceptions. The need for the wandering mind leads us into something of a paradox, which is best explained by the following example.
The deadline for your drop is 2 hours away. Everything looks perfect until someone in quality assurance wanders over to your office. They point out a bug that crashes your platform 25% of the time during a fairly common use case. Your blood pressure increases, you have 2 hours to fix this or you’re going to have to spend three times that long time answering angry emails from your client and your boss. You tell yourself to focus. Find the problem and fix it right now! You ask a series of questions but each one leads to a dead end. As time ticks down the pressure mounts and as the pressure mounts you keep trying to focus on the problem to no avail.
Many developers have experienced something similar to the story above, (hopefully not quite so intense). There are several problems at work here but I’m going to focus on one of them for the purposes of this topic. The harder the problem and the greater the pressure we’re under the more we, as engineers, tend to think and focus about the problem. But as we’ve just discussed this is exactly the opposite of what leads to good problem solving. Your brain needs space to develop a good hypothesis but if you’re under a lot of stress it’s hard to justify time to perpetuate the wandering mind. This is the paradox of problem solving, you focus on the problem by instinct. Your gut reaction, in this case, is hampering your ability to create a good hypothesis for the problem.
How do we perpetuate the wandering mind? Three words: “Do Something Else” I’m not advocating that you screw around. (although it can be helpful if your environment is one that supports short periods of inactivity) Doing something else means exactly what it sounds like. Walk around the office, stare out the window, read or write documentation. Let your unconscious mind work on the problem without interference. We see moments like these in story all the time. The protagonist will be stumped by a problem. They’ll be pacing, eating, fighting, or doing something else wholly unrelated to the problem when suddenly they’ll see an object or interaction that in some way resembles what we as the audience knows as the solution. Ping! Inspiration strikes, at which point the hero fits all the pieces together and the solution seems obvious. With a little work and self-awareness you can put the same process to work for you. While at first it might seem counterproductive or, worse, self-indulgent, it quickly becomes obvious (if used in moderation) that it’s actually both helpful and time saving.
The wandering mind can be vital when inspiration is required. It is important, however, to cover subjects that the wondering mind is awful at doing. Chief among them is coding and concrete logical work. If you throw the focus of your mind all the way open it becomes impossible to concentrate on just one thing. This makes it very difficult to keep complicated data structures and algorithms in your mind all at once. If you find yourself unable to shake your wandering mind, attack problems it helps rather than trying to fight it off. Brainstorm new designs, products, and ideas. Work on bugs that haven’t been diagnosed yet.
When you get the next killer bug you can’t explain, diagnose, or figure out, try doing something else for a little while you might find that that the solution hits you faster than you might expect. It might just give you the inspiration you need to move into the next state which I’ll get into in my next article: the narrowing mind.
It’s ironic that I’m sitting in my comfy Ikea chair trying to write an article about being ‘mindful’ while I simply cannot concentrate. My mind skips like a stone between my gmail account, boing boing, email, iTunes…anything but sitting down and typing this article.
Now I will focus.
Mindfulness, conceptually, is as simple as its name suggests. It is self-awareness on a very basic level. Be aware of what your mind is doing and how it is working and plan your current task accordingly. Different states of minds serve different purposes. For example, wandering un-focused drifting might put you in an excellent place to make a new discovery but it is not a place where you could expect accomplish very much. On the other side, hyper focused diligence is a great way to bang out a lot of source code but it’s not a state of mind where you’ll find much inspiration. This article is not the end all of writing about mindfulness. Additionally, due to this bloggy media it’s impossible to do much other than skip, rough shod, over the concepts. We’ll walk through a potential problem and explore mindful states during this three part series. Keep in mind that all these distinctions are completely arbitrary. They are blurry concepts and they tend to overlap. Keep that in mind as we go over them.
the wandering mind
This is where debugging starts. We are informed of the problem over email, from the QA engineer, in our own testing, from our boss. We must immediately open the aperture of our mind as much as possible. It is in this place that we find inspiration and new hypothesis. This wandering mind lends itself to brainstorming and culminates in a theory. New theory cannot be discovered through heavy focus and I’ll explain why. The more you think exactly about the problem the more your mind will settle into the ruts laid down by your previous attempts. If you don’t belive me, look at the history of scientific breakthrough. Newton was sitting under a tree when he was hit on the head by an apple when he had his stroke of genius, Archimedes was sitting in the tub when he had his breakthrough on the theory of displacement.
Compare their moments of discovery to your own moments of inspiration: they almost always happen when you aren’t thinking about the problem at hand. This is the purpose of the wandering mind; it unlimbers your unconscious. Rather than traveling down roads you’ve wandered before you’re free to challenge your boundaries and confront your pre-conceptions. The need for the wandering mind leads us into something of a paradox, which is best explained by the following example.
The deadline for your drop is 2 hours away. Everything looks perfect until someone in quality assurance wanders over to your office. They point out a bug that crashes your platform 25% of the time during a fairly common use case. Your blood pressure increases, you have 2 hours to fix this or you’re going to have to spend three times that long time answering angry emails from your client and your boss. You tell yourself to focus. Find the problem and fix it right now! You ask a series of questions but each one leads to a dead end. As time ticks down the pressure mounts and as the pressure mounts you keep trying to focus on the problem to no avail.
Many developers have experienced something similar to the story above, (hopefully not quite so intense). There are several problems at work here but I’m going to focus on one of them for the purposes of this topic. The harder the problem and the greater the pressure we’re under the more we, as engineers, tend to think and focus about the problem. But as we’ve just discussed this is exactly the opposite of what leads to good problem solving. Your brain needs space to develop a good hypothesis but if you’re under a lot of stress it’s hard to justify time to perpetuate the wandering mind. This is the paradox of problem solving, you focus on the problem by instinct. Your gut reaction, in this case, is hampering your ability to create a good hypothesis for the problem.
How do we perpetuate the wandering mind? Three words: “Do Something Else” I’m not advocating that you screw around. (although it can be helpful if your environment is one that supports short periods of inactivity) Doing something else means exactly what it sounds like. Walk around the office, stare out the window, read or write documentation. Let your unconscious mind work on the problem without interference. We see moments like these in story all the time. The protagonist will be stumped by a problem. They’ll be pacing, eating, fighting, or doing something else wholly unrelated to the problem when suddenly they’ll see an object or interaction that in some way resembles what we as the audience knows as the solution. Ping! Inspiration strikes, at which point the hero fits all the pieces together and the solution seems obvious. With a little work and self-awareness you can put the same process to work for you. While at first it might seem counterproductive or, worse, self-indulgent, it quickly becomes obvious (if used in moderation) that it’s actually both helpful and time saving.
The wandering mind can be vital when inspiration is required. It is important, however, to cover subjects that the wondering mind is awful at doing. Chief among them is coding and concrete logical work. If you throw the focus of your mind all the way open it becomes impossible to concentrate on just one thing. This makes it very difficult to keep complicated data structures and algorithms in your mind all at once. If you find yourself unable to shake your wandering mind, attack problems it helps rather than trying to fight it off. Brainstorm new designs, products, and ideas. Work on bugs that haven’t been diagnosed yet.
When you get the next killer bug you can’t explain, diagnose, or figure out, try doing something else for a little while you might find that that the solution hits you faster than you might expect. It might just give you the inspiration you need to move into the next state which I’ll get into in my next article: the narrowing mind.
posted by Haseman at 2:42 PM
12 comments
