I started doing Ashtanga Mysore style yoga a month and a half ago, and I'm bursting with energy throughout the day. I'm saying this as someone who is 41, has spinal degeneration and is a cancer survivor, and I feel years younger after practicing. It's a more traditional style that is done very early in the morning, and has an exact sequence which is great for those who like structure. The expectation is that you practice every day except Saturday. It's pretty demanding physically, but can be adapted for those who are less fit and flexible. A lot of thought has been put into the design of the sequence, in that each posture and movement is preparation for another movement later in the sequence, so it leads you step by step to do things with your body you wouldn't have guessed you were capable of. The sequence emphasizes both strength and flexibility, and my body is already taking a much nicer shape after only a short period.
By writing one letter at a time, you're not utilizing your "full communication" power. In fact you're using just 1/26 of the power of the alphabet, that comes at 3.84%. So, instead, write with a superposition of all letters at once to utilize 100% of the power of the alphabet, using 100% of the brain.
Strongly agree. Another good option for aerobic exercise is the 7 minute workout [1]. I often do a couple of rounds of this when I need a quick refresh between sessions of focussed work.
The routine is easily done in an office / park / parking lot, though you'll probably want a shower afterwards.
Sprinting is largely anaerobic, which is good too. Variety is probably best since different muscle fibers release different myokines, and since the stimulus necessary to elicit a particular level of response increases with degree of training.
Perhaps I missed it and the article already covered these, but a few other major tips that I doubt anyone would disagree with:
-Eliminate distractions. Any external stimuli subtract from concentration and "processing power" for your task. Even the possibility of distraction can put your brain on alert for them when they're not present, so best if you can create an environment which is free of distraction generally. This relates not only to your office/work environment, but things like going into DND on your phone and IMs.
-Work in large, contiguous time chunks (and then take breaks; see next). For complex tasks, it takes a while to "spin up". To load all the context, to explore possibility branches of solutions, to implement possible solutions and test them. As with distractions, very short work windows break this problem solving time up and require a re-spin-up period.
-Take breaks between longer work sessions. Taking breaks-- and in particular moving around while on break-- helps prevent fatigue, sustaining efficacy and productivity for longer windows of the day. Taking a break, especially wherein you change your environment (eg walking outside), can also help invigorate problem-solving. Finally, moving around is healthy for both your body and your mind.
I don't think you can make full use of your brain without following all of these as well.
RPN style thinking is also something i feel that helped.
Because "thinking" has the inputs on tape/memory already, so its matter of bandwidth and pre-processing.
I would also add "be interested in what you're writing". If you don't care at all for what you're working on, there's little chance of paying full attention.
Computer science has a plethora of studies related to OS process scheduling. All of it is directly relevant to human task management. I've never, ever seen in referenced in any management talks/books/etc.
At work, I currently have 4-5 different PM's on 4-5 different projects. Each of them has no idea what the others are asking, and I am constantly bombarded with one off tasks via hipchat or in-person requests. The point is not to complain about work, but to agree that management would do well to recognize the importance of process scheduling and queueing, and that a failure to do so is only detrimental to their own objectives.
Don Reinertsen mentioned it. At least in a talk, and maybe in his book "The Principles of Product Development Flow".
That's only 1 example, but in my personal estimation he's one of the two most effective management theorists I know. Though I wish he were a better explainer. (The other of course is Shanley Kane.)
I agree with every point. Too bad that, aside from splitting the problem into small tasks, the conditions most software devs work in prevent taking this advice. It is impossible to avoid multitasking in a collaborative open office environment. I can't imagine saying in a standup meeting that I'm just going to work through tutorials and work on memorizing the standard library instead of assigned work.
Let me be a little more specific, though, because it's trickier than I let on. I prefer working on XP style teams, so I'll use XP style vocabulary here, but in my experience what I'm about to say is pretty universal, so feel free to extrapolate.
One of the most important things for running a successful project is understanding the attention span of your stake holders (which includes customers, managers, etc). You must deliver "user visible functionality" (i.e. things that your stake holders value) at a regular rate. There is a threshold after which if you fail to deliver something valued by the "customer" the project's chance of failure increases. If you regularly cross that threshold, the chances of success can be almost zero.
The actual threshold depends on many factors, but my rule of thumb is 2 weeks. If you don't deliver something of value to the stake holders in 2 weeks, they will get uncomfortable and start thinking about other options. If it happens regularly, then they will constantly be thinking about other options and eventually will chose one of them.
(The corollary of my rule of thumb is that the biggest danger to a project is senior management since they are the ones with the power and responsibility to cancel projects that they think are not going to be successful).
The more you deliver in that window, the happier stake holders will be, but... if you get into a situation where something you deliver turns out not to be complete/satisfactory/whatever it works against you. So if your stake holder ever utters the words, "But I thought we already did that", then it's like missing 2 windows (well, in my experience, more like 1.5, but I'm splitting hairs).
You might be wondering what this has to do with the topic. :-) The problem is that you can't just wander away and study stuff, even if it is going to have a good effect on the project. Similarly, wandering away for a month to gather requirements, or write design, or refactor crappy code, or write a decent build system, or pay back technical debt, or... anyway, it all moves you toward cancellation. This is the real reason waterfall doesn't work IMHO -- stake holders don't have the attention span to deal with the time it takes for things to shake out and so the projects get cancelled.
What this means is that every thing you do must be linked to customer-visible value. Furthermore, it limits the amount of time you can spend on every part. You can't wander away for 2 weeks to learn Rails. But you can easily wander away for 1 or 2 days to learn an aspect of Rails that will help you with the story/task that you are currently working on -- so long as that doesn't push you over the threshold.
If you start delivering stories with customer-visible value every 2 days, for instance, nobody will care if you are spending half of that time doing tutorials, katas, memorising stuff -- whatever you think is productive. You actions are invisible to the customer and they just don't care.
With that in mind, where I always find problems when I see people complaining about this issue is in the work backlog. Usually the stories are organised by technical rather than customer issues. So you'll have a bunch of stories that provide absolutely nothing to the customer and then you will have a story that links it all up gives them a lot -- usually a month or two down the road.
The root cause of this is usually because programmers/PMs try to be efficient and not duplicate work. Instead, identify all of the customer-visible value and try to create a story for each one. Make vertical stripes of functionality that you can deliver at a more measured pace. This will require you to do refactoring between each story because your infrastructure will always be incomplete. However, it allows you to deliver value more regularly and causes the "big red eye of management" to focus its attention elsewhere.
I've already written more than you are likely to read, so I'll stop here. Just let me encourage you a bit more in saying that you have the ability to change things. It's not easy and it takes time, but you can do it if you work patiently toward your goal. Don't get discouraged!
This may be a little anal but analogies between a typical von Neumann architecture computer and any animal brain are pretty limited. The brain is essentially like some next-gen MIMD processor.
I remember once hearing it said that the brain is always compared to the most complex machine we know how to build; before von Neumann architectures, the analogy was punch-card looms, and before punch-card looms, it was clockwork. I can't agree more that these analogies should always be taken with a grain of salt...
Sometimes I feel like I reallocate my facilities for speech and spatial navigation, to the extent that I need 20 minutes to 'switch gears' before I can function normally again.
I was intrigued by the title, and disappointed by the article.
I'm curious why people have to be so darned pedantic. It's not funny nor cute. And it makes it almost impossible to have any sort of enjoyable conversation with a normal person.
> I like to complement this with memorization of the most difficult concepts, especially things I don’t run into very often while reading. You can use Anki for this (or any other spaced-repetition software).
anecdotal but I don't think I can agree with no multitasking rule. I go nuts if I spend on any task for more than 10-15 minutes. I have to switch to something else and come back. How ever I can keep doing this all day with little exhaustion :)
[+] [-] projectramo|9 years ago|reply
aerobic exercise.
If you just take a brisk walk, a quick sprint, or a jog, before you code or intermittently, you'll notice a world of difference.
[+] [-] colordrops|9 years ago|reply
[+] [-] omginternets|9 years ago|reply
Installing a pull-up bar in my apartment has noticeably improved the quality of my work, as well my own enjoyment of working.
Any time I feel a bust of frustration in my gut, or any time my code is compiling, I get up and crank a few (like 5) out.
Makes a world of difference.
[+] [-] visarga|9 years ago|reply
[+] [-] peterhartree|9 years ago|reply
The routine is easily done in an office / park / parking lot, though you'll probably want a shower afterwards.
[1] http://7-min.com/
[+] [-] firethief|9 years ago|reply
[+] [-] Joky|9 years ago|reply
[+] [-] erdevs|9 years ago|reply
-Eliminate distractions. Any external stimuli subtract from concentration and "processing power" for your task. Even the possibility of distraction can put your brain on alert for them when they're not present, so best if you can create an environment which is free of distraction generally. This relates not only to your office/work environment, but things like going into DND on your phone and IMs.
-Work in large, contiguous time chunks (and then take breaks; see next). For complex tasks, it takes a while to "spin up". To load all the context, to explore possibility branches of solutions, to implement possible solutions and test them. As with distractions, very short work windows break this problem solving time up and require a re-spin-up period.
-Take breaks between longer work sessions. Taking breaks-- and in particular moving around while on break-- helps prevent fatigue, sustaining efficacy and productivity for longer windows of the day. Taking a break, especially wherein you change your environment (eg walking outside), can also help invigorate problem-solving. Finally, moving around is healthy for both your body and your mind.
I don't think you can make full use of your brain without following all of these as well.
[+] [-] afarrell|9 years ago|reply
[+] [-] pizza|9 years ago|reply
Also, to add some neuron info that the article didn't mention:
- place / grid cells would allow you to use your brain more, easily - see the book Moonwalking with Einstein a book recommended by a friend
- neural codes are convex- could we use this knowledge somehow?
- using your full brain is known as an epileptic seizure, iirc..
- tonic/phasic firing matters a lot as to the effect of neural firing, although I forget as to whether that's a dopamine-only trait..
[+] [-] keyboardwarrior|9 years ago|reply
i.e "lets do the integratation"
becomes
"integration do".
[+] [-] mobiuscog|9 years ago|reply
[+] [-] romaniv|9 years ago|reply
[+] [-] djohnston|9 years ago|reply
[+] [-] jasonpeacock|9 years ago|reply
[+] [-] hashkb|9 years ago|reply
[+] [-] calibraxis|9 years ago|reply
That's only 1 example, but in my personal estimation he's one of the two most effective management theorists I know. Though I wish he were a better explainer. (The other of course is Shanley Kane.)
[+] [-] quantumhobbit|9 years ago|reply
[+] [-] mikekchar|9 years ago|reply
Let me be a little more specific, though, because it's trickier than I let on. I prefer working on XP style teams, so I'll use XP style vocabulary here, but in my experience what I'm about to say is pretty universal, so feel free to extrapolate.
One of the most important things for running a successful project is understanding the attention span of your stake holders (which includes customers, managers, etc). You must deliver "user visible functionality" (i.e. things that your stake holders value) at a regular rate. There is a threshold after which if you fail to deliver something valued by the "customer" the project's chance of failure increases. If you regularly cross that threshold, the chances of success can be almost zero.
The actual threshold depends on many factors, but my rule of thumb is 2 weeks. If you don't deliver something of value to the stake holders in 2 weeks, they will get uncomfortable and start thinking about other options. If it happens regularly, then they will constantly be thinking about other options and eventually will chose one of them.
(The corollary of my rule of thumb is that the biggest danger to a project is senior management since they are the ones with the power and responsibility to cancel projects that they think are not going to be successful).
The more you deliver in that window, the happier stake holders will be, but... if you get into a situation where something you deliver turns out not to be complete/satisfactory/whatever it works against you. So if your stake holder ever utters the words, "But I thought we already did that", then it's like missing 2 windows (well, in my experience, more like 1.5, but I'm splitting hairs).
You might be wondering what this has to do with the topic. :-) The problem is that you can't just wander away and study stuff, even if it is going to have a good effect on the project. Similarly, wandering away for a month to gather requirements, or write design, or refactor crappy code, or write a decent build system, or pay back technical debt, or... anyway, it all moves you toward cancellation. This is the real reason waterfall doesn't work IMHO -- stake holders don't have the attention span to deal with the time it takes for things to shake out and so the projects get cancelled.
What this means is that every thing you do must be linked to customer-visible value. Furthermore, it limits the amount of time you can spend on every part. You can't wander away for 2 weeks to learn Rails. But you can easily wander away for 1 or 2 days to learn an aspect of Rails that will help you with the story/task that you are currently working on -- so long as that doesn't push you over the threshold.
If you start delivering stories with customer-visible value every 2 days, for instance, nobody will care if you are spending half of that time doing tutorials, katas, memorising stuff -- whatever you think is productive. You actions are invisible to the customer and they just don't care.
With that in mind, where I always find problems when I see people complaining about this issue is in the work backlog. Usually the stories are organised by technical rather than customer issues. So you'll have a bunch of stories that provide absolutely nothing to the customer and then you will have a story that links it all up gives them a lot -- usually a month or two down the road.
The root cause of this is usually because programmers/PMs try to be efficient and not duplicate work. Instead, identify all of the customer-visible value and try to create a story for each one. Make vertical stripes of functionality that you can deliver at a more measured pace. This will require you to do refactoring between each story because your infrastructure will always be incomplete. However, it allows you to deliver value more regularly and causes the "big red eye of management" to focus its attention elsewhere.
I've already written more than you are likely to read, so I'll stop here. Just let me encourage you a bit more in saying that you have the ability to change things. It's not easy and it takes time, but you can do it if you work patiently toward your goal. Don't get discouraged!
[+] [-] _ao789|9 years ago|reply
[+] [-] p_zakharov|9 years ago|reply
[+] [-] clock_tower|9 years ago|reply
[+] [-] amelius|9 years ago|reply
I'm curious how the parts of my brain responsible for walking, riding a bicycle or telling jokes could be used when writing code.
[+] [-] rch|9 years ago|reply
I was intrigued by the title, and disappointed by the article.
[+] [-] JustSomeNobody|9 years ago|reply
[+] [-] romaniv|9 years ago|reply
https://vimeo.com/97903574
[+] [-] adrianratnapala|9 years ago|reply
[+] [-] asdfologist|9 years ago|reply
[+] [-] wtbob|9 years ago|reply
Sure enough, I took a look and found this: http://orgmode.org/worg/org-contrib/org-drill.html
[+] [-] ww520|9 years ago|reply
[+] [-] option_greek|9 years ago|reply
[+] [-] bcheung|9 years ago|reply
[+] [-] kapv89|9 years ago|reply
[+] [-] pvaldes|9 years ago|reply
[+] [-] pg_is_a_butt|9 years ago|reply
[deleted]
[+] [-] mahmoodadv|9 years ago|reply
[deleted]