How to use your full brain when writing code | Hacker News Reader

How to use your full brain when writing code

chrismm.com

218 pointsinnerspirit72 comments

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.

Agreed. Hell, it doesn't even have to be aerobic.

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.

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.

What do you mean by "write with a superposition of all letters at once"?

I assume it means he's been playing with quantum algorithms lately.

The logic that we are using "only a small part" of our brain is caused by the sparse activations. When perceiving something, we need to encode the raw sense data. When encoded, only a small part of the brain is necessary to represent it, thus the misconception that we are only "using" that part. In fact we are using all of it, even the inactive parts. By analogy, when I am writing, I am only using one letter at a time. This does not imply that I am only using 4% of the power of the alphabet, just that it works by sparse combinations. Thus there is no basis to thinking that we could improve if only we could use 100% of our neurons at once.

He's being sarcastic and it's actually quite funny if one uses less than 100% of the brain.

Presumably that would mean all 26 letters printed on top of each other.

There's a silly old factoid about how "you only use 10 percent of your brain," which psychics and other woo-peddlers use to sell their personal solutions for opening up the potential of the unused 90%. Of course the idea that you can think better if you use 100% of your brain at once is as silly as the idea that you can communicate better if you use 100% of the alphabet at once, which was Visarga's point.

That's not what the article is talking about specifically, but the bit about "using your full brain" does raise unfortunate associations.

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.

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.

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.

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.

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.

[1] http://7-min.com/

Why interleave? Just install your laptop on top of a treadmill ;-)

This is basically what I do. Well, it's a desktop installed semi-permanently on a desk that I raised with cinder blocks to be high enough to fit a treadmill underneath. I try to walk 5 miles each work day on it. I can only walk about 3mph before things get too wobbly to stay focused.

I've found that there is some sub-conscious mental block that makes it hard for me to start walking, but once I'm going I barely even notice that I'm walking - I can get lost in the work I'm doing just as deeply (possibly more deeply?) as when I'm sitting or standing.

I've tried to come up with some objective ways to measure my productivity walking vs standing vs sitting but haven't come up with anything concrete. If I had to guess I'd rank my focus level high to low in this order: 1) First 3-5 miles of walking 2) sitting 3) 5th - 10th mile walking 4) standing. Standing is much more strenuous than walking to me.

Great idea! If you don't have the time or money to set all that up, or you want something a bit more portable, you can also pick up a pedal exerciser/exercise pedaller (same thing, oddly). They're $25-$50 on Amazon, and you can stick them under your desk and pedal away while you work.

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.

https://freedom.to/freedom is useful for this if you find yourself checking HN on your phone.

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

This link is better: https://freedom.to/

I really really want this to get an Android client.

Right now still using heyfocus.com for Mac + ClearLock for Android.

Whichever provider can have a scheduled blacklist/whitelist across Android + Mac first gets my dollars.

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

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

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.

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

Oh, also Joel Spolsky mentions it too: (http://www.joelonsoftware.com/articles/fog0000000022.html)

(But it's not worthwhile for me to trawl through the managerial lit, so no doubt there's more examples.)

Thank you. I couldn't remember the name of the book or the author. There's a lot of queuing theory in the book, along with the mathematical conclusions (eg 100% utilization = arbitrarily long queue times). Fantastic book, I think I'm going to have to make sure it's on the kindle for some upcoming flights.

If you're an engineer and have trouble getting past project management methodologies that feel like bullshit (or conversely if you care a lot about them but have trouble convincing your team to) you must read "Principles of Product Development Flow".

It's definitely a pretty dry read in parts, but battle through it.

Management doesn't care what percentage of your brain you use as long as you're shipping.

..but you do. Because it helps you to finish tasks quicker

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.

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.

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

>when I have multiple people asking me to do simultaneous tasks, I email all of them, asking them to prioritize the list for me.

exactly, as programmers we should be able to understand and apply basic concurrency management techniques.

Your manager/team lead should be shielding you from such

Why haven't you got a public list of this that you ask them to add to and argue amongst themselves on the priority?

Also, your manager is shit.

>I currently have 4-5 different PM's

That sounds like Agile done right! /s

Have you considered telling the 4-5 PMs what the others are asking?

A book just came out which addresses this: "Agorithms to Live By" (http://algorithmstoliveby.com/)

Just took a quick look at the link. Concept seems interesting. Have you read it, and if so, any opinion on it?

I've read it. It was an easy read. No mathematics. Every occurrence of "NP-complete" was replaced with "intractable" and there are tons of anecdotes, many I hadn't heard before. I didn't come away from the book feeling profoundly altered, but I didn't regard it as a waste of time either. If you're looking for something to read on the train, this will do a solid job.

Sometimes you encounter a book that covers material you already "know", but seeing it in a sort of coherent narrative structure can be the thing you need to change the way you think about and perceive the world.

I enjoyed it. Gives an interesting perspective on the mind and human behavior

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.

...memorising the standard library is to be done at other times to heighten your muscle memory when you need to tap into it during working days..

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!

This was very informative for me, thank you!

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

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!

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

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

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

By actually reading the article.

There is literally nothing in the article that comes remotely close to addressing amelius's point. Which is a pretty fair point, given the lofty title of the article.

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.

Me too! I find my speech center just turns off, and I'm quite unwilling to speak even when spoken too. I expect some people find this zombie mode rude, but you can't please everyone and hey that software ain't gonna write itself!

https://www.sciencedaily.com/releases/2012/10/121030161416.h...

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.

If you stop letting it bother you, you'll be conversing with normal people in no time flat.

Hardly.

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.

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.

You might listen to Bret Viktor's lecture on Seeing Spaces:

https://vimeo.com/97903574

Write code in your head while riding a bicycle. It's fun.

> 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

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

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

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

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

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

Reply on news.ycombinator.com