
The interruptible programmer - r11t
http://www.stevestreeting.com/2010/09/04/work-2-0/
======
wccrawford
I've always been an 'interruptible programmer'. While my bosses have really
loved it, they pay for it by my being less productive.

You see, the human mind can only hold so many concepts in active thought at
the same time. It's somewhere around 7. If paying attention to your
surroundings is 1, there's only 6 left. If someone -happens- in the
surroundings, there's at least 1 more gone. If something -interesting-
happens, there 2 or 3 more as you go off on tangents thinking about them.

Yeah, half your mind is taken with your surroundings at times.

My solution is to pay attention to my surroundings when working on easy
projects, and for projects that -really- need my attention, I put in earphones
and block everything out. I have a few different music sets that I've heard so
many times and/or they have a sound that doesn't ask my brain to process them.

With my earphones in, people have to yell (or call my phone or IM) to get my
attention. I don't check even check my email.

I usually don't have to resort to the earphones. One line of thinking is that
if it takes all your ability to write the code, you couldn't possibly fix bugs
in it. You should be writing well below your ability so that you can fix it
when it breaks. This usually means the code is easier to read as well. But
some things are just innately complex, and there's nothing you can do about
it.

~~~
gaius
It's 3 for lions. That's how lion taming works, the lion attempts to process
each of the chair legs as a seperate object and has no mental capacity left to
eat you.

~~~
philwelch
If you're worried about the lion eating you, you can just feed it until it's
not hungry.

Lions are surprisingly not vicious towards humans at all--since there's no
species that can fuck with them they don't have the vicious fear response most
animals have. That's the real trick to lion taming--and the reason you can
tame a lion but not a jaguar. Tigers are the same way. The big danger with
either of them is actually playfulness--they don't always realize how strong
they are.

~~~
gaius
I'm not worried - me and Aslan get on just fine. So long as you remember he's
not a tame lion.

------
singular
The problem arises when you are focused on something very specific, for
example designing a particularly complicated series of function calls, you
effectively have to keep a stack in your mind, think about locals, instance
variables, whatever, abstract stuff that the brain isn't so well designed at
retaining, which becomes very vulnerable to disruption.

If you are unlucky enough to be interrupted while in that kind of state, the
spinning plates effectively fall and break - it can almost be painful, and
certainly drudging to get back up to where you were before. I've found this
tends to take anywhere from 30 minutes to a day of time away from me because
getting back in that flow state can be so damn difficult.

I think a lot of the problem comes down to us using the brain for stuff it's
not _great_ at.

~~~
DTrejo
Maybe your code is too complicated?

I suppose the ultimate goal is too keep one's code clean and simple enough
that one does have to go into _super brain mode_ in order to solve a problem.
Sadly we don't live in an ideal world.

~~~
epochwolf
> I suppose the ultimate goal is too keep one's code clean and simple enough
> that one does have to go into super brain mode in order to solve a problem.

Let's drop back into reality for a minute. Just 15 minutes ago I was tracing
sql data converted to xml by a rails application which was processed by a perl
frontend. Yay legacy code.

It would really be nice for things to be simple but the reality is I'm dealing
with multiple erp systems that output mostly similar xml thanks to the people
that where here before me. It is not possible to not end up in _super brain
mode_ with some of the problems I deal with.

Now my latest project was rather complicated. I took a report that only showed
current inventories and converted it to display inventories at any specific
day. It was all fine and simple until I encountered a little off by one bug
which caused _most_ of the dates to be off by one. Tracing that error through
all the layers required a number of hours. I am thankful I was not interrupted
with an emergency fix to some production report so it only took hours to fix
instead days.

It would be nice if things were simple but not everyone gets to work with
clean environments and applications.

~~~
tel
_"It is not possible to not end up in super brain mode with some of the
problems I deal with."_

I'll argue that it is possible, just not necessarily preferable. You could
rewrite the whole thing. You could also focus on building a number of small
functions which brings the whole interface up to a human-digestible level.

The reality of the matter is not the realm of possibility, but instead that
you often _just want to get it working_ by whatever super-herculean effort it
takes. People are often very interruptible while fighting hydras or stealing
golden fleece.

So it's twofold. Ensure that as often as possible you've got the programmatic
infrastructure to only consider human-digestible chunks of complexity at any
given time and try not to be interrupted whenever that's not possible.

~~~
LeBleu
I'm amused that you think it is possible to rewrite the whole thing without
entering super brain mode. In my experience, generally the only way to
reproduce such legacy reports is by reverse engineering how they currently
work. (which will require super brain mode based on the above described
current complexity) One would think someone in the business would know what
the report is supposed to do, but I frequently encounter cases where no one
does, they just want the report to work the way the old one did, whatever the
heck that was.

I know of no solution not involving time travel to solve that for legacy
reports and systems. Obviously going forward one can worry about
documentation, etc. but with legacy stuff it is already too late to implement
those rules.

~~~
epochwolf
Which describes what I was dealing with perfectly. Unfortunately the guy
before me was a rather brilliant python programmer writing rails code on an
extremely short deadline. I at least had the luxury of having a short in
person meeting with the person using the report which allowed me to clean up
some misfeatures that had been implemented due to miscommunication over the
phone. (Person using the report was out of state)

------
stcredzero
_Maintain context outside of your head at all times

Much of the problem with interruptions is that of losing context. When you’re
in that Zone, you’re juggling a whole bunch of context in your head, adjusting
it on the fly, and maintaining and tweaking connections between issues
constantly._

I find that there's an all-too common hair-shirted developer mentality that
glories in the stunt of keeping track of umpteen different entities and
variables at once. Mental/conceptual organization is an area where _work
smarter_ should definitely trump work harder. I think a part of the problem
has to do with the tendency for dramatic fire-fighting to be rewarded in
organizations. What results is like an emergency responder TV show. It's
exciting to watch the responders rappelling or doing something exciting and
unusual every week, but in reality a well run city would strive to make such
events as rare as possible and be boring as possible.

Think of it this way, if you ran a trucking company, would you want employees
who had a different hair-raising tale to tell on just about every trip? Do you
know developers who are full of such tales?

------
meric
I used to only be able to program in large blocks of time also.

Then one day I thought about the 66 minutes I 'waste' each day on the train to
university; 33 minutes per trip. I started to take out my laptop as soon as I
get on the train and try to work on programming. Initially I had very little
done, by the time I really start programming it was time to get off.

But now, 3 or 4 months into it, I seem to manage to get something done every
time; I'd say now the 33 minutes is worth at least 20 minutes of productivity
if I had been spending it in a 4 hour block.

~~~
mattm
Parkinson's Law - work expands (or contracts) to fill the time available for
its completion.

When I was teaching English, for one class, I gave groups a human-slide puzzle
activity. A group of 8 were given a number from 1-8 and arranged randomly on 9
numbered squares. They were to re-arrange themselves in order by moving one
person at a time to the empty square.

The last group to complete it was having a really tough time and kept
complaining to me that they couldn't do it. After all the other groups had
finished I announced they had 5 minutes left. They completed it just before
the time was up.

------
brc
All the good programming ideas I have ever had have occured away from a
computer. And I don't mean most, I mean _all_. I still remember my first
Eureka moment while waiting for a train to go home. I was so excited about it
I almost turned around and went back to the office. Instead I excitedly jotted
it down over about three pages of notebook and went in the next day and
implemented it.

You have to figure in some time each day away from the screen but still
thinking about work in a kind-of background task. And carry a notepad or make
voice memos when the light bulb moment strikes.

------
narag
IME, the most useful tip is "maintaining the context outside your head". The
article recomends a "running comment". I use a notebook, but anyway I find it
efective.

~~~
da5e
Good point. I use a large drawing pad and sort of sketch out and arrange
keypoints as I go along.

This recent HN item is relevant:
[http://calnewport.com/blog/2007/10/08/monday-master-class-
ho...](http://calnewport.com/blog/2007/10/08/monday-master-class-how-to-solve-
hard-problem-sets-without-staying-up-all-night/)

------
HeyLaughingBoy
_Maintain context outside of your head at all times_

I have a terrible memory and this is what I have learned to do. Long coding
sessions? No; I design, then plan out a short amount of coding at a time.
Especially if I'm modifying unfamiliar code, I'll make notes about what
functions I need to change and what changes need to be done and in what order,
and the possible side effects that may result so I can test for them. Leaving
for the day, I'll just write down what I was last doing and what's next on a
post it note and that removes the excuse of staying at work "just a few more
minutes until I finish up this method."

In the end I find it's far more productive than sitting down for hours coding
away. And a nice side effect is that it really doesn't matter if I'm
interrupted because where I am and what I was doing is already documented.

Doing this forces me to think at a higher level about overall data & control
flow instead of being down in the weeds all the time where it's hard to see
the big picture.

------
praptak
I have found the Pomodoro technique quite useful. Once I get off my ass to
actually start the 25 minute work interval, the conditioning kicks in and
concentration appears.

Surprisingly, the first part (just starting) is harder than following through.

~~~
mattm
Interesting. I have never heard of this technique. I prefer working in 3 x 45
mins blocks. At 25 mins, I'm just getting into things.

~~~
praptak
It's a valid concern. A single 25 mins block might indeed be too short for a
big task but in Pomodoro it's series of such blocks interspersed with 5 mins
breaks.

YMMV, but I've found out that the 5 mins breaks do not destroy my "state", as
long as I don't start anything that tends to suck in like playing games or
browsing the Web. Fetching coffee, going to the toilet, etc. is OK :)

Anyway, the hardest thing is usually starting the first block.

------
ajdecon
Semi-related question: can anyone suggest a lightweight, easy-to-manage
ticketing system that doesn't inspire hate? I've been seriously considering
setting something like this up on my own server as a personal TODO tracker,
but I don't know the space well.

~~~
d0mine
Org-Mode is for keeping notes, maintaining ToDo lists, doing project planning,
and authoring with a fast and effective plain-text system.
<http://orgmode.org/>

~~~
pronoiac
There's also an iPhone app for interfacing with Org-Mode, MobileOrg:
<http://mobileorg.ncogni.to/>

Note: Unfortunately, the Dropbox integration is currently kinda borked,
sometimes displaying the password in the clear, or with connection failures.

------
j_baker
I don't necessarily know if programmers need to go so far as embracing
interruptions, but I think the author makes a good point. In fact, this is the
challenge most introverts face in their careers. How do you remain focused in
your inner world without shutting your coworkers out?

Extraverts of course face the opposite problem. How do you remain focused on
the outer world world while not becoming completely dependent on your
coworkers?

------
peter_severin
Keeping context outside of your head is a really good advice. I've been using
Google Tasks for that and it works quite well for me. This way I also have the
context with me on my phone and I can quickly note down ideas when I am away
from my desk.While coding I progress through the list of small tasks and check
them away.

~~~
stcredzero
This is an excellent tip. Sometimes something that I need to be careful about
occurs to me on the way out the door. If I had the list accessible on my
phone, I could just enter it when it occurs to me and have it at my desk when
I return.

~~~
peter_severin
Exactly! I went through a lot of setups but I think I'll stick with this one
for a long time. I also use it to implement GTD for my everyday life by
creating different lists for different contexts.

------
parbo
Nobody should work more than 8 hours per day. Somewhere around that mark, you
start getting diminishing returns on additional hours. In Sweden, the work
week is 40 hours. The maximum overtime is 150 hours per year, extensible to
300 hours if the employee and the union allows it.

------
Tyrannosaurs
What I like about this article is that it's a bunch of helpful hints which are
largely inside your control.

There's no suggestion that you're going to change your environment in
unrealistic ways, it's more about dealing with the fact you don't work in a
perfect space.

------
jasonkester
This works great if you're plugging away on an existing system, knocking off
bug reports. But it doesn't work at all for prototyping cool new stuff on a
clean sheet of paper.

Ingenuity and Ticket Systems don't combine very well.

There's no list of action items for Truly Cool Stuff. You just dive in and
start messing around. You can probably externalize some context as you cross
off ideas and concepts that won't work. But there's no game plan, thus no
concept of a "Next Action". You're on a blank sheet of paper with a head full
of context, and any distraction will kill that.

So yeah, there are circumstances where you can survive interruptions. But
there are also circumstances where they'll kill you.

------
doki_pen
As I've gotten more programming experience, interruptions have become less and
less of a problem. As long as it's something that I've worked on in the last
few days, I can hop in and get working pretty quickly. I don't know if my
brain has just adapted to the environments I've been working in, or if I'm
just a better programmer now. Maybe I've just become really good at ignoring
people while seeming to be paying attention.

But taking a couple weeks off from a project really sets me back. It could
take can entire day to get back up to speed.

------
Sukotto
I'd like to read more detail about his setup.

What ticketing system does he use that he can "get in and out of in 30 sec"
... so that he can toss every new idea into it without breaking his flow?

How, specifically, does he track his context? In particular, how does he track
context across multiple projects while still being able to react to
interruptions in a timely way?

How does he track his one-and-only-one next action for each project in a way
that's simple/easy/fast enough that he doesn't give it up in disgust?

