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.
How did you decide on "somewhere around 7" concepts in thought at once? What counts as a "concept"? If you are referring to the 1956 George Miller paper "The Magical Number Seven, Plus or Minus Two", then that really has little to do with "concepts".
"That essay reviews psychological experiments that discovered people had a hard time remembering more than about 7 unrelated pieces of really dull data all at once."
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.
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.
I’m not sure how you came up with “3” (or for that matter how objects in view of a lion is comparable to “concepts” in the working memory of a programmer). As far as I know this idea was popularized by Errol Morris’s film Fast, Cheap, & Out of Control: http://www.errolmorris.com/film/fcooc_transcript.html
“Dave Hoover:
“The chair has four legs... Now, an animal has a one track mind, For instance, the animal is coming after you with the idea of tearing your head off... You put the chair up, and all of a sudden, he has four points of interest. He loses his original train of thought because this agitates him. He can’t comprehend those four points of interest, so what he does he attacks the chair. He takes his wrath out on the chair. His mind now had been completely distracted from his original thought: ‘Eat the man in the white pants.’
“It’s basically animal psychology. You try to keep the animal afraid of you in that he does not understand you. He does not understand that you’re weaker than he is. [...]”
(The next few paragraphs are also quite interesting, and I recommend the film generally.)
Wasn't that the film that profiled MIT's Rodney Brooks? (robotic subsumption architecture, Roomba?). I think we watched it for a graduate class in AI. It was good.
This is why I sit at the desk with a pen and paper and my computer. When I'm trying to work something out, I write stuff out and make sure that my plans (and the stuff I have to keep track of) gets down onto paper. Sometimes I even draw a picture. Makes it much easier to refocus after being distracted (I just read my freaking notes). I'm interruptible, very productive, and I can refocus pretty much instantly.
//file this under benefits of a liberal arts education...
Yeah, I work that way as well. I have a nice pair of noise canceling headphones, and my co-workers (non-programmers) will have to tap on my shoulder or speak loudly for me to hear them.
They're often perplexed if I'm late to a meeting or aren't up to date on the latest email. I generally keep Outlook closed which manages my calendar and email.
Being prepared for an interruption does not mean paying attention to your surroundings or actively seeking distraction (e.g. checking email). The problem here is that even if you've made an attempt to block everything out but have not prepared yourself for an interruption, it still may happen and will severely hurt your productivity when you try to return to what you were doing. Keeping even very informal todo lists (e.g. comments in code, todo.txt) helps greatly when you need to quickly restore your context. Even if an interruption does not happen they give you a sense of direction and you can also use them to prepare future contexts for exploring ideas you came up with while working on the current task.
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.
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.
Let me ask this: after you've written such code, how is it for other people to read it? What is it like for people to debug it?
I think a lot of the problem comes down to us using the brain for stuff it's not great at.
I think good programming design tries to maximize the stuff your brain is good at and minimize the use of stuff your brain isn't good at.
Note he said "designing" not coding. When you design things, a lot of relationships and entities are in your head. If you are just fixing some unit tests or looking to do small cleanups or tweaks then yes, you can do that while chatting with your friend about the weather, and at the same time banging away at code in front of you. Your context is just 100 or so lines of code.
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.
> 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.
This is an appropriate working style for dealing with legacy code. The key is to be able to switch gears when you're writing new code that doesn't integrate so heavily and you aren't so constrained (more typical in a startup). Different environments require different working styles.
"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.
> I'll argue that it is possible, just not necessarily preferable.
No, it's not possible. I do my best to minimize complexity but it's hard.
I don't have access to most of the systems I interface with. This is what I am talking about. The complexity is not just in legacy code but in interfaces I don't have control over. The project I mentioned was a complete rewrite and I'm able to modify most sections of it without tons of brain power. It's just the main report that's confusing as hell due to requirements.
When things external to code are complex you need brain power. You need to create abstractions and your abstractions end up being complex because you can't mask some of the requirements behind simpler code. There is also a problem of lacking tools. I have no ability to use a real debugger on any of the programs I work with. Only one application will run on my laptop, everything else is sitting in a carefully deployed minefield of interconnected dependencies on various linux servers.
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.
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)
I don't think it takes very much complexity before this kind of situation arises (perhaps my example was a little contrived!), maybe it would be clearer to apply this to debugging where it certainly becomes very quickly apparent even with extremely simple code.
I don't think what you claim as ideal is possible - the only thing a programming environment can hope to offer is to eliminate as much accidental complexity as possible, leaving you to focus on essential complexity. The real-world problems we try to solve as developers are usually at least somewhat hard (even the seemingly simple ones), no getting away from that.
In no way intending to be condescending, I seriously recommend you read 'No Silver Bullet' by Fred Brooks if you haven't already - http://en.wikipedia.org/wiki/No_Silver_Bullet - an absolute classic (and important too I think).
What if we looked at it as a competitive advantage?
Teamwork is a competitive advantage because a good team can develop more complex systems than a single programmer.
Clean and simple code with good architecture is a competitive advantage, because using simpler more appropriate constructs, we can develop more complex systems (or our systems run faster, or take less resources)
If we are able to go into super brain mode we are able to deal with and build more complex systems.
I like clean code as a competitive advantage, or force multiplier, but I also like the ability to use super brain mode to be able to handle more complex systems.
The double edged sword is that you've made a more complex system requiring the focus of super brain mode to work with, but if you use it carefully, sparingly, and wisely, perhaps your system can do things that a constant interruption brain mode system just can't do. It's a dangerous but powerful tool in my opinion.
Perhaps working in that space is what separates the good or amazing developers from the code monkeys? Or is it always too much of a liability to have such a system?
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?
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.
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.
I have the same experience! You start to anticipate arrival and focus on "cleanup" work at some point. It happens so naturally that you hardly notice. If there is something left to be done, it's usually something small, like a 5 minute task.(maybe the train was early?)
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.
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.
A stack of Post-it notes is amazingly useful! IDEs need something like this. Just a command-key sequence on whatever, and a box pops up for a quick annotation, press return and it's saved. (Cue someone telling me that it's already a plugin in Eclipse.)
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.
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.
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.
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.
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/
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?
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.
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.
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.
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.
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.
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.
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.
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?
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.