Programmer Interrupted

http://blog.ninlabs.com/2013/01/programmer-interrupted/

by Off • 14 years ago

366 87 14 years ago

blog.ninlabs.com

fennecfoxen2• 14 years ago

I would like to point out in my experience that I've found pair-programming to provide excellent interruption-recovery capabilities. Even if both people in the pair are interrupted, they're very good at getting each other back on task and filling in the gaps left in each others' trains of thought.

(Disclaimer. The broader applicability, appropriateness, and overall desirability of pair programming, Extreme Programming, and other agile methodologies, or any of the other implications thereof, are not addressed in this post. Void where prohibited. No warranty, express or implied.)

lawnchair_larry• 14 years ago

I see it as one giant interruption. I'm not sure what I dislike more, "pair programming" or "open concept".

fennecfoxen2• 14 years ago

Indeed: Pair programming does not work for all programmers or all programming shops. It is possible to do it wrong, especially by making it mandatory for people who do not want to do it. Depending on its implementation it may have other negative properties that render it unsuitable for any given purpose. Its suitability for any particular purpose is a broad question which cannot be adequately addressed in the context of this little conversation!

But. In my experience, when I was pair programming, and the pair programming was effective to begin with, then: when there were interruptions, the interruption-recovery process was significantly streamlined. I infer that this is one of the ways through which teams that actually already do pair programming manage to improve their productivity enough (relative to singleton-programming) to justify the arrangement.

zaptheimpaler• 14 years ago

As a college student, I do a lot of pair programming. IMO, the efficiency of pair programming comes down to how well matched the two are in skill, and how well they can communicate with each other. Depending on those two variables, it can be much more productive than a single programmer, or a huge roadblock to getting anything significant done.

MattRogish3• 14 years ago

I wonder how much money is wasted via lost productivity due to open office plans. On a per-year per-programmer basis private offices are not very expensive.

http://blog.fogcreek.com/the-price-of-dev-happiness-part-two... http://www.joelonsoftware.com/items/2006/07/30.html http://www.joelonsoftware.com/articles/fieldguidetodeveloper...

trggrer• 14 years ago

Like life, balance is everything. If you want total privacy, better work from home but if you need physical presence/collaboration, regular cubicles in rooms/areas of 8-10 cubicles + a boardroom looks like a win-win to me.

I guess it depends on the kind of programming you're doing and the teams composition.

MattRogish3• 14 years ago

It has nothing to do with "privacy" and everything to do with un-necessary distraction.

Yes, face-to-face, voice-based collaboration can be a good thing, but very rarely do you need it 100% of the time. Need someone to look at your code? Ask them to come over and look at it. Need to chat with someone to discuss the design of some code? You can still do that.

Why folks somehow tolerate "everyone gets bothered by any side conversation" is beyond me, especially when you can have perfectly fine collaboration without open-plan offices.

It's incomprehensible why companies with "communication problems" think that will be solved by throwing everyone into one room. I bet good money the problem isn't that Jane isn't overhearing Joe and Bob's conversation. It's some deeper disfunction that is being exposed as "communication problems".

majormajor2• 14 years ago

I've been a developer with a private office and I've also been on a small (< 10 person) team in an open office plan. Give me the open office any day. If there's a side conversation not of interest to me, I tune it out. But frequently there are ones that are of interest to me that I'm able to either contribute to or learn something from. It's great for group troubleshooting of sudden issues, too.

mnicole2• 14 years ago

> I tune it out

Try as we might, some of us just can't do this.

mutagen• 14 years ago

I suspect the two parent comments (and several more here and every time this topic comes up) point to a fundamental difference between various people, some are more productive in silence and solitude and some thrive on the productivity around them.

While it might sound like the difference between introverted and extroverted, I suspect it isn't quite as simple. It very likely also depends on the job to be done (memory load), the content and quality of surrounding conversation and more ephemeral factors like company culture.

I suspect it also affects how well things like pair programming work out, conversations about it often elicit quite polarized viewpoints on the subject.

jonke• 14 years ago

The thing is that we (as a group in this thread) don't have a shared view what productivity is. That you feel more productive when you are allowed to interact with other fellow programmers maybe true or false. If you should deliver something in a short timespan that will allow your company to taker an order of 15M € and you get distracted by two junior programmers discussion C string concatenation I'm sure your Company owner would feel that you are 'not productive'. Most people outside the programming pack consider turning time at work into money as productive. Programmers usually don't use that definition for productivity.

abecedarius• 14 years ago

It's curious that nobody in this thread has mentioned visual distractions. For some of us they're a big deal too, and earplugs are no help.

rayiner2• 14 years ago

I understand private offices don't always work into the budget, but I'm always surprised that the companies that have giant suburban office parks still don't give their developers private offices.

prophetjohn• 14 years ago

Private offices sounds terrible to me. I wonder the extent to which silos of knowledge are created by confining every developer into their own office and discouraging outside communication. I would suffocate in that environment.

I vastly prefer open office where developers work in frequently rotated pairs, with separate pairs close enough to talk as necessary. It's a little bit harder this way, but I've found that it leads to higher quality software, higher diversity of knowledge and it's just made me a better programmer (and a better Vim user and a better Unix command line user, etc). I hope I don't ever have to take another job where I'm not forced to both teach and learn from all of my coworkers directly.

ericHosick• 14 years ago

The best work I've done is when I start in the morning and go for a break only to see it is now dark out.

guard-of-terra• 14 years ago

I seem to be much interruption-tolerant than all those articles imply. On other hand, I'm lucky if I get any code to write at all, because it's mostly communication, planning, system support and debugging that consume time.

danso• 14 years ago

I find it hard ever to program for hours straight, no matter what the external stimuli is. However, I've found that test-driven development has worked to get me back on task after I've strayed. The physical act of just entering in "rake test" and seeing "Tests passed" can be enough of a trigger for me to get back into coding...and if I've left some broken tests for me to fix, I have a much easier time remembering what I needed to do next...without the extra overhead distraction of finding my to-do list.

Of course, one could argue that the monotony of writing tests is what keeps me from being fully engaged to begin with :)

hkmurakami3• 14 years ago

I'm a PM, and I consider it my most important responsibility to prevent interruptions from reaching developers. By redirecting inwards-bound interruptions to myself, I've probably reduced developer interruptions by 80% since I started.

What I've found is that the typical developer/engineer is really bad at saying "no" or "not now" to others. The solution then is to work the other side (sales, marketing, etc) to interrupt someone else (me) instead. Even if it's a relatively simple technical question from sales, I can convert the in-person active interruption to a passive email notice (at the very least).

The typical office environment (and system) is not productive, so at this point it's up to the individuals to reduce the impact of the system on the team's productivity. (which is a sad reality...)

DrJokepu• 14 years ago

Curiously enough, in my experience, the vast majority of interruption I receive is not from "external sources" but rather from other developers, typically junior members of the team seeking advice or guidance. I wonder how you would address that?

epochwolf2• 14 years ago

I sit right next to a tester and he is a constant source of distraction.

gpcz• 14 years ago

Part of that depends on the type of advice or guidance. Some of it might be a symptom of the project's bus factor being too low (inadequate documentation, ambiguities or holes in processes, etc), which your organization can fix by paying down some of that technical/process debt. Other forms of advice (career-related, higher-level tech stuff, etc) would seem more like a mentor role. For that stuff, you may want to schedule "mentor time" in a slot advantageous for yourself, such as the last hour of the day.

falcolas• 14 years ago

Assigned mentors, perhaps on a rotating schedule. If I know I'm bound to be interrupted (in my case by a pager), I do work that I know won't require more than 5-10 minutes in "the zone".

The downside is that an assigned mentor will not get as much work done during that time.

bunderbunder• 14 years ago

Perhaps you deal with it by building it into the schedule: Set aside a specific time (or times) during the day where junior members have stand-up meetings with senior members.

Hopefully getting the interruption onto the schedule would have the benefit of allowing everyone to plan for it and try to minimize its cost. And it might also encourage junior members to try and work through problems themselves first (because they have to save questions for scheduled question times), but also make them feel less like an imposition when they do seek advice.

wting• 14 years ago

I find intra-organization chat rooms useful. Developers on their down time can answer questions while busy devs can minimize the window and focus.

polskibus• 14 years ago

This is why you would either have a "support" rota in a team or a dedicated resource for such queries. Interruptions are annoying , but they are much easier to bear if it's just a week in a month. Of course it's not perfect due to the lack of telepathy, exchanging knowledge is not immediate but such rota will help facilitate sharing inside the team as well. I've seen teams that did that, been a part of one for some time and it was really good compared to standard workflow (whoever is closest or nicest is being interrupted).

saraid2162• 14 years ago

> What I've found is that the typical developer/engineer is really bad at saying "no" or "not now" to others.

The reason for this, by the way, is roughly that it's short-term easier to think about how to solve their problem so that they'll go away rather than "waste time" arguing about priority. People outside the engineering department tend to be a lot more well-versed in making a case for priority and instinctively push more than the engineer pushes back.

Also, many thanks for being one of the awesome people who help deal with this. As a developer who has worked under a few great manager-types (and has a ton of trouble saying no to a request), you make all the difference.

hkmurakami3• 14 years ago

Firstly, thanks for the kind words :).

What's kind of funny is that while I'm pretty good at being a shit-umbrella for my team, I've found that I really really hate making urgent requests to other teams (HW, Applications, etc.) precisely because I know that they also have a lot on their plate already. In fact, I think I'm honestly really bad at 'pressuring' people in other teams to do things that our team needs. Everything comes with a cost, I guess.

> People outside the engineering department tend to be a lot more well-versed in making a case for priority and instinctively push more than the engineer pushes back.

I've also noticed that a lot of times, an individual sales/mktg/bizdev person actually doesn't know what the overall priorities are, since she is only aware of her customers and her items that need to be addressed. The person rarely has a sense for what the relative importance of her items are compared to those of the person sitting right next to her also asking the dev team for their time.

In a similar vein, I think it's very hard to push back as an engineer since she will rarely know all the projects that are going on concurrently, who the customers are, what the estimated revenues are for each project, etc. This is exactly the kind of information you need to fight against an interruption request: "Sorry but I'm working on item X for customer Y, with deadline Z, which is a higher priority item compared to your item W."

Now, an engineer probably shouldn't even have all this information, since the information is kind of a distraction in itself. So when a rogue customer-facing guy comes up to an engineer with a request, a much easier solution is to answer with, "Sorry I don't have the authority to change what I'm working on. Can you please go talk to my engineering manager A or my project manager B? I'll be happy to change course once I get updated instructions from them. Thanks."

malandrew• 14 years ago

This. When I worked as a PM, preventing distractions and "drive-by management" was also one of main focuses. My favorite quote about this is from Gmail PM Todd Jackson, who said, “You can either be a shit funnel or a shit umbrella”

dstorrs2• 14 years ago

As a developer, I'd just like to say: thank you for doing this. A good PM is literally worth their weight in silver (at today's price, anyway).

grecy2• 14 years ago

At my last company us developers complained that we were getting interrupted too much, so the boss asked us to keep a list of interruptions. By lunch on the first day we all had 3+ pages, so he believed us and we implemented the following:

Each week, one pair of programmers would be designated the "consulting developers", and a big sign would be put above their desk. They were the only developers that could be interrupted for the week, allowing the rest of us to get a lot of work done. If the consulting developers needed to ask something of other developers, we tried to save it up for lunch, as we mostly all ate together anyway.

This made an enormous difference to our productivity, which everyone in the company took notice of when the number of "development days" we got done each week increased dramatically.

At the start we thought of "sacrifice one for the good of all" and we didn't look forward to our turn. As time went on it actually turned out differently. We usually enjoyed the "consulting" time as it meant a break from the routine of working on endless tickets, and it also kept us in touch with what the rest of the company was doing with regards to deploys, environments, configs, etc. etc.

AFAIK they still do it today

bifrost• 14 years ago

This is actually pretty standard ops methodology. You designate an "intake" person, and then the rest of the group works productively while only one person gets harrangued with interrupts. Its very effective.

MatthewPhillips• 14 years ago

Don't you find it distracting listening to people ask the consultants questions all day? Often times about projects you work on? I don't think there is any cure for interruptions other than no at-desk meeting rules or private offices.

grecy2• 14 years ago

> Don't you find it distracting listening to people ask the consultants questions all day?

People are very respectful of the shared space and keep the noise down. Also, it's nice when you are not consulting to actively ignore whatever is being said to the consultants, so you can be more in the zone.

> I don't think there is any cure for interruptions other than no at-desk meeting rules or private offices.

That's what we do at my current company (try to limit drive-bys) and it's horrible - I just get people booking time in my calendar every 20 mins, so that it's not a drive-by when they want to interrupt me.

mtrimpe4• 14 years ago

> I don't think there is any cure for interruptions other than no at-desk meeting rules or private offices.

A simple feedback mechanism for this would get us quite far already. Just something that will glow red for 'dont disturb,' orange for 'only if you have to' and green for 'go right ahead.'

If someone wants to make (a Kickstarter for) a simple ball that does this I'll gladly transfer my domain names interruptiball.com and interruptaball.com to you by the way. ;)

neltnerb• 14 years ago

Nice idea. I'm sort of straddling the position between management and engineer at this point in my career, so I understand the utility of meetings but also definitely appreciate how much more I can get done when I'm allowed to just be in the zone and define my own objectives.

Do you think it would be feasible to have a competent manager assign somewhat high level tasks to engineer-managers, have them assign subtasks to engineers, and then have the engineer-managers deal with integration, systems design, and interfacing with real management?

It seems like if that situation works in practice (I'm too new to know, and didn't go to management school, so this is largely experimental or anecdotal for me), tasks can simply be assigned by someone close enough to understand the complexity and skill of the engineers actually doing the coding via something like exchange based tasks, a to-do list of open issues that need to be dealt with, etc.

Or do you think that the core engineer staff is not mature enough to handle that level of independence at most big companies? I would assume that at startups the structure is more flat in such a way as to make my suggestion less meaningful.

I ask this because I'd really like to be a better manager, and I find that for myself, having a list of goals (i.e. "define API and write spec", "draw out abstraction structure", "CAD up mechanical enclosure", etc) is more than sufficient for me so long as I'm in regular enough communication with the people around me to know what those shortened descriptions mean for sure.

sbilstein• 14 years ago

We do this at my startup. We call that developer the Sheriff and he/she sends a photo to the company chat with a sheriff hat on Mondays. They aren't expected to get anything done that week (although they typically try to do their work) and just deal with any live site issues or questions from the rest of our rather small company. Sometimes they end up implementing lots of quick fixes that other employees ask for.

troels• 14 years ago

We did this at one previous company I worked at. At my current company, I've introduced the same thing. The person also doubles as the "maintenance person", who will pick up minor production-level failures.

tseabrooks• 14 years ago

We're experimenting with something like this now. I'm currently acting as the "consulting" dev here. Our first experiment is on a quarterly basis. We'll reconsider after the quarter.

We're actually struggling with finding the right amount of time for this. A week didn't feel long enough for us because that person would also handle tier "3" support for the week. Any thoughts on finding the right amount of time for something like this?

lrem• 14 years ago

My wife's working in a major European corporation and they do one/two weeks shifts. They also have it divided into classes of problems they're fighting (the "need it solved now" vs "this weird thing happened and we think it's your team's fault" vs "OMG it's 3 am and the world is on fire!"). I can't recall now which class corresponds to which duration.

Edit: there's also one person who is the permanent point of contact for a single release. New releases are once per three months. This person obviously has one hot week, but the amount of contacts decays exponentially.

dickeytk• 14 years ago

Even though I rarely use headphones, the idea that there are actually companies that don't allow engineers to work with headphones blows my mind. I thought I worked in some pretty strict places, but never anything that extreme.

stevewilhelm• 14 years ago

Are there any studies that quantify the impact of Google Talk on programmer productivity?

KeyBoardG• 14 years ago

Unnecessary or poorly planned meetings are probably the biggest interruption here. God-forbid the pre-meeting meeting. I tend to stick to small, mundane work until a part of the day where I can focus for while. You can get more done instead of frustratingly failing to get deep into larger projects.

geophile• 14 years ago

Our scrums are typically 1-2 hours long, due to an accumulation of topics for "after-meetings". What a soul-sucking waste of time.

vpeters25• 14 years ago

You guys seem to be using the daily scrum as a planning meeting, I would suggest to add all the after-meeting stuff to the backlog and discuss them in the next sprint planning.

Daily scrums should not take longer than 15 mins. A good scrummaster will keep them under 5 mins in average for a 12 member team.

One thing I usually do when daily scrums start getting out of hand is to politely mention long meetings as a blocker to get my job done. After repeating the same for a few days it will start to sink in...

jgj• 14 years ago

Whenever possible, I delay interruption by taking 15-30 seconds to cache my current train of thought while holding up a "one moment" finger at the perpetrator. Just distilling my train of thought into a sentence or two, or a mnemonic device of sorts, helps me get back into what I was doing quicker.

muhuk• 14 years ago

This would also communicate you are being interrupted and it's not nothing. I would expect it to at least filter the stuff that can wait.

rkb• 14 years ago

Interesting blog post presenting different types of memory and the use of these types by programmers. However, the introduction of the piece feels a bit off, and the overall coherence is somewhat lacking. It is as if the writer was being interrupted continuously while writing it...

_Benjamin_• 14 years ago

I don't understand why companies don't try an approach more like what Universities provide their students. If you need a quiet place to study, you can go to the library, where you may often find private rooms for even more seclusion and quiet. If you prefer someplace busier, try the student union or the food court. Right after getting my CS degree, my boss pointed me towards a desk in an open office environment and I was supposed to start cranking out value for the company in that one environment. Sometimes I like it, I like the impromptu conversations with fellow developers. But other times I need to shut out all distractions and outside noise and movement but I don't have that option.

K2h• 14 years ago

1) As part of a budget I am charged for the floor space that my team uses in the facility. I would welcome open space and closed space, but don't have the space in this facility to make closed spare look like more than a closet - something most won't respond well to working in.

2) Many tasks (especially engineering that deals with work in the physical domain) require tools, items, equipment of more than just a computer. While we can do shared lab space for development - it does get tricky when you need certain hardware or test setups to do design/work.

It did take me time to adjust outside of academia too.

switch007• 14 years ago

Money. They'll dress it up in many other ways, but it's all down to money.

agentultra2• 14 years ago

Working from home can be the worst (especially so if you have kids). There is nothing more frustrating than not being able to concentrate on a task for more than 45 minutes when your, "warm-up," time is about half that time... effectively giving you 20-some-odd minutes of actual work at a time. In fact it can be down-right torture.

The best, "snake-oil," solutions I have are:

1. Well-delineated boundaries for interlocutors. This means scheduling my, "off-limits," time and communicating those boundaries to the people around me. Concessions are made by appointment and I try to plan out my time a few days to a week in advance depending on how busy I am.

2. Write everything down. I try to be methodical about this but I am characteristically spontaneous and disorganized. Therefore I keep notebooks nearby when I'm not at the computer, I have a whiteboard near my computer, and I have a very organized filing system on my computer where all of my thoughts eventually end up. I find that having different mediums that I can switch between very helpful -- many an algorithm has been conceived of in the shower, doodled on a piece of graph paper (I'm a very visual thinker) over breakfast, and eventually compiled before lunch after I've finished with my emails for the day. Having record of it in multiple places seems to reinforce my memory and after reading this article I suspect I now have an inkling as to why.

3. Never leave a thought unfinished. This can be frustrating both for myself and my spouse sometimes when it's near the end of the day and I'm only half-way through something important. However I cannot enjoy myself and let my mind wander if I have some half-finished thought still rummaging around in my head. It's easier to let the mind relax and be creative if you can finish each thought... even if it's simply writing the rest of it out or hammering out all of the test cases you can think of. As long as there is some record of it in its entirety my mind seems to be able to be satisfied with it and leave it alone. It also helps so that when I get back to work on the problem that I'm able to get up to speed and not having to, "finish my own sentences."

After reading this article I began to wonder if there were any cognition-enhancing tools that are integrated with popular development environments for assisting programmers in remembering where they were in a large refactoring or what they still have yet to do in various locations of a code-base, etc.

ww520• 14 years ago

I think working at home doesn't mean you work while babysitting your kids. It should be like working at office, minus the commute and seeing your colleagues. If you need to babysit the kids for a while, do that as it is then make up for the development time later on.

I found org-mode to be great in tracking todo items, general note taking, and organizing thought.

agentultra2• 14 years ago

org-mode is my go-to, I use it for quite a lot of stuff!

houshuang• 14 years ago

Most of the comments are discussing interruptions in general, and could have been posted on any article about programmer working situation etc, but I think some of the most interesting in this blog post is the attempt to measure cognitive/memory load (both retrospectively, in a research situation, and perhaps eventually live).

Imagine something like the ubiquitous sleep trackers for mobile devices which can track your sleep pattern, and both give you feedback on how you sleep, and also select the best time to wake you up within a certain boundary.

Could we imagine something similar for engineers? We already have very rough tools to provide feedback on productivity, like RescueTime, but a context-aware tool that can model cognitive activity based on edits, switching from one function to another, viewing two files simultaneously, git commits, etc, is far more advanced.

Perhaps if you wanted to ask a programmer a question, you could ask for him to be interrupted sometime during the next half hour, and the system would choose the time where it would be least disruptive?

And I'm also interested in the discussion of ways in which it would be easier to remember/reestablish context. I wonder if some of this is transferable to other domains, for example deep academic "knowledge work" - working with annotated articles, several windows of notes, trying to synthesize ideas etc.

noknockers• 14 years ago

The interruption issue has plagued me for the last 10 years. Firstly working at home with flatmates or wife, then with children and now at an office next to the marketing team.

Instead of trying to fight the interruptions themselves, I decided to try and become better/faster at context switching by training myself to compartmentalize the jobs on hand (programming/helping kids/answering questions).

It took a while to figure it out and i'm still getting better at it, but so far it works pretty well and I can jump between contexts much better than i could before. When I get interrupted, I'll take a snapshot of where i am, store it away and 'switch' to the new issue.

pbiggar• 14 years ago

This might not be the appropriate thread for a job post, but if you are the kind of programmer who likes library voices, quiet concentration, and no interruptions, this is something we're trying to cultivate for ourselves at CircleCi. Job post here: http://news.ycombinator.com/item?id=4993738

rachelbythebay2• 14 years ago

I saw an interesting situation at Google many years ago. There was a "bullpen" in which 8-10 people sat. That was for my team, a bunch of pager monkeys with a rotating on call rotation. We were operation-oriented as you would expect. Not too far away, the developers for one of our services had their desks.

At least one of the ops people on my team and at least one of the devs on the other team were, well, loud. I don't know if they had hearing issues or what, but they were significantly louder than most people. You know the type. That's just how they are.

Immediately over the cube-wall from us on the other side was a bunch of technical writers. They couldn't get any work done because of the racket from us. We got complaints. My boss used to keep a tally on one of his whiteboards. This is the thing where you go |||| and then put a slash across for the fifth for those who aren't familiar (is this a local culture thing?). I think they ultimately tried to get moved to another building, away from the people they supported.

On a third side, there was a bunch of project managers. This was back in 2007, so OpenSocial was the "big thing" then. So we had to deal with the blathering coming out of them most afternoons: "what if this person is friends with this person on this service, but isn't friends with this person on this other service, and then this third person shares this thing to the second person, does the first person get to see it?"

I'm surprised ANYTHING got done there. Come to think of it, that might explain a few things. Another team up in that same space was the Lively group, and everyone knows what happened with that project.

swah• 14 years ago

Did you try telling the guys they were loud?

rachelbythebay2• 14 years ago

Those guys didn't listen when I told them our servers were being hit too hard due to <thing> and <other thing>, so I don't imagine that raising a purely social/meatspace concern would have done any good.

strictfp• 14 years ago

When talking about productivity, it's important to acknowledge the difference between speed and progress. While working uninterrupted is great for development speed, it might also lead you down the rabbit hole, working with irrelevant features of your liking. I find that regular interruptions helps setting a new course before going too far in the wrong direction.

This is one of the reasons why agile methods work so well. Small tasks limits the scope of concentrated work, reducing the risk of going astray. Pair programming offers a watching party, who can guide and direct while you are busy tunnel-visioning some small method.

rjzzleep• 14 years ago

there you go, scientific proof that the whole microsoft enterprise stack is counterproductive. every debugging step involves 20 distractions.

potomak• 14 years ago

I think Pomodoro Technique works well against interruptions or at least against unintended interruptions. That's why I made and use regularly Tomatoes[1] pomodoro time tracker (now I'm on my long break).

[1] http://tomato.es

n3rdy• 14 years ago

Do these numbers get inflated for a programmer with ADHD?

I find it takes me much longer to get back on track after interruptions. I work from home and deal with a ridiculous amount of interruptions. After 9am, I usually have to just give up for the day.

follower• 14 years ago

I found this section of the article of particular interest:

"A code narrative is an episodic memory aid that helps a developer recall contextual details and the history of programming activity."

I created Labradoc (http://labradoc.com/) to encourage a form of manual "code narrative" (e.g. a form of development journal).

Here's an example from one of my personal projects: http://www.labradoc.com/i/follower/p/android-arduino-handbag

I find it really valuable for context-switching between projects.

Programmer Interrupted

Related Stories