
How to use your full brain when writing code - innerspirit
http://chrismm.com/blog/how-to-use-your-full-brain-when-writing-code/?
======
projectramo
I am not kidding or being sarcastic, but let me add another tip for using your
"full brain":

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
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.

~~~
anpk
Is the 6 days a week requirement or is it nice to do? I do basic yoga for 2-3
days a week and I'm generally tired after.

~~~
colordrops
I don't think it's a requirement, in that the teacher won't kick you out of
class if you don't show up every day, but it's highly encouraged. This is a
opinionated and prescribed form of yoga, and the idea is that you practice as
close to that prescription as your life will allow. But I haven't detected any
pressure or negativity from my teacher toward students that don't show every
day.

------
erdevs
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.

~~~
afarrell
[https://freedom.to/freedom](https://freedom.to/freedom) is useful for this if
you find yourself checking HN on your phone.

~~~
superuser2
What is it? I can't imagine many on HN are going to register for something
just to find out what it is.

~~~
chickenfries
This link is better: [https://freedom.to/](https://freedom.to/)

------
pizza
We should all mimic sleeping dolphins, so we could always use our active
heimsphere to approach 100% coding time

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
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.e "lets do the integratation"

becomes

"integration do".

------
mobiuscog
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.

------
romaniv
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.

~~~
djohnston
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.

~~~
JustSomeNobody
I don't have _that_ many PMs, but when I have multiple people asking me to do
simultaneous tasks, I email all of them, asking them to prioritize the list
for me. I'm polite about it. And it mostly works out. But I never, ever shy
away from doing this.

~~~
vram22
Very good idea - since it both puts the onus on them, and makes them realize
the conflicting demands on your time.

------
quantumhobbit
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.

~~~
mikekchar
Try it. You might be surprised at the reaction.

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!

~~~
dermybaby
Thank you for writing this. How do you figure that I can learn about ..say..
project management or any other tangentially related subject while I code at
work (meaning that coding or developing is my main job)

I guess what I want to know is this - can you apply these principles to learn
other stuff to get you ahead in life while getting hit on the head with kids
responsibilities etc? Pardon - for the ramble and incoherence :)

~~~
mikekchar
It's a hard question to answer mainly because it depends a lot on the kind of
person you are and what your goals are. The answer is definitely "yes", you
can learn all these things, but it's always going to be a trade off. In every
job there are things that people like to do. If you get really, really good at
those things, people will ask you to keep doing those things. Similarly, you
can change your job simply by picking up things that nobody else wants to do.

If you are interested in project management, for instance, there are literally
hundreds of things you can do: write acceptance criteria for stories, collect
data, write daily or weekly reports, etc. Most of these things you can just
start doing tomorrow if you feel like it and people will be pleased. For
example, if you say, "I'm having difficulty understanding what's going on in
the group, so I'm going to write a daily summary of every thing checked into
the source repository", everyone will be happy. If it is useful, it will
become part of your every day job.

Of course the trade off is time. I spend about 1 hour a day on average
collating information for my job. I do it because I've found it effective on
other projects. People seem to like it. Nobody asked me to do it, though. The
downside is that I have 1 hour less per day for coding. I'm not as effective
as a programmer as some people on the team.

You can't escape that math. Don't expect to find a solution that is all upside
with no downside. Same for family responsibilities. Do those things because
you value them. There will be other people who will not have families and will
devote themselves to work. It might seem unfair that they may progress
faster/farther in their job than you do, but that's just the way it is. We all
make choices.

Hope that helps!

------
p_zakharov
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.

~~~
clock_tower
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...

~~~
p_zakharov
Well I definitely think that _some_ computational theory of mind is correct.
Of course the critical difference between computationalism and clockwork
analogies is that we now have formal proof of just how general computation
really is. I don't believe that the embodied human mind is capable of more
computation than a UTM.

That being said, comparing the brain, any animal's brain, to a commercial
Intel or AMD processor is very misleading.

And I guess it's fitting that I compared the brain to a machine we _don 't_
yet know how to build...

------
amelius
> How to use your full brain when writing code

I'm curious how the parts of my brain responsible for walking, riding a
bicycle or telling jokes could be used when writing code.

~~~
JustSomeNobody
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.

~~~
TrevorJ
It's not pedantic, he is directly questioning a core tenant of the article by
using examples of where it may break down. It serves a rhetorical purpose.

~~~
sn9
What purpose?

Does he honestly think the author literally believes the parts of the brain
involved in locomotion can be used for programming?

It's being pedantic in an unproductive way since no charitable reading of the
OP would come away with that conclusion.

------
wtbob
> 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).

Sure enough, I took a look and found this: [http://orgmode.org/worg/org-
contrib/org-drill.html](http://orgmode.org/worg/org-contrib/org-drill.html)

------
ww520
Something I found helpful are: having enough sleep, familiar music to drown
out distraction to put me in the zone.

------
option_greek
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 :)

------
bcheung
I'm surprised they didn't mention Sapir-Whorf in the vocabulary section. I
think the implications for coding and UX are huge.

------
kapv89
Will share one which helped ease down the "getting in the zone" part for me:
Use all 10 of your fingers while typing code

~~~
pvaldes
Writing code with the 100% of your brain is easy; just bang your head in the
keyboard repeatedly as I do.

