I've always been an 'interruptible programmer'. While my bosses have really loved it, they pay for it by my being less productive.<p>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.<p>Yeah, half your mind is taken with your surroundings at times.<p>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.<p>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.<p>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.
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.<p>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.<p>I think a lot of the problem comes down to us using the brain for stuff it's not <i>great</i> at.
<i>Maintain context outside of your head at all times<p>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><p>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 <i>work smarter</i> 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.<p>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.<p>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.<p>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.
All the good programming ideas I have ever had have occured away from a computer. And I don't mean most, I mean <i>all</i>. 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.<p>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.
<i>Maintain context outside of your head at all times</i><p>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."<p>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.<p>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.<p>Surprisingly, the first part (just starting) is harder than following through.
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.
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?<p>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.
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.<p>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.<p>Ingenuity and Ticket Systems don't combine very well.<p>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.<p>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.<p>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.
I'd like to read more detail about his setup.<p>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?<p>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?<p>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?