I’ve solved my need for fast navigation with my own tool named “wd” (on github).
If your brain works better with numbers than with “human-readable” mnemonics then give it a try. For example, wds2 will save the current directory into $WD2, and you can jump back to it with wd2. Slot zero is even shorter with just wd.
It supports named schemes with autocompletion, so you can make one for each “project” context.
“one person in a pair can hold the context while the other person in the pair gets interrupted. We could get back to work in seconds.”
(Comment by James Grenning)
I totally agree with this.
I have to disagree, strongly. Pair programming as an 8-hour-per-day pattern is a terrible idea. It’s good to pair occasionally when it’s useful, but it shouldn’t be the default. After about 2 hours, it starts to burn people out and, as they tire, the “passenger” turns into a nonparticipant anyway. As a constant arrangement, it’s just another way for MBA-culture colonizers to shove mandatory extroversion (open-plan offices!) down programmers' throats.
Also, environments that expect programmers to be constantly available are inherently broken and founded on culturally harmful assumptions (that programmers are low-status peons who can be expected to be available, and evaluated on their pliability, because they aren’t doing anything important). I might be completely wrong here, but it sounds like you’re trying to save “Agile”/open-plan culture and it isn’t worth saving. I don’t want to “get back to work in seconds” when pinged for an impromptu status update or context switch; I want a level of respect that makes them not happen (except in emergencies, of course).
I’m pretty enthusiastic about pair programming, but I don’t think you can do it more than about 5 hours per day, and reaching that level requires constant attention to fatigue, hunger, and your partner’s feelings; and it also almost certainly requires switching pairs at least once a day.
Fair enough. To make it clear, I think that pairing to solve a specific objective is a good thing. Making software environments more collaborative in general is also good. When two or more programmers realize that the most efficient way to achieve a specific task is to set aside time and pair, that’s exactly what they should do.
I don’t like mandatory or permanent pair programming, because people often get their best work done alone, and I especially don’t like the idea that pair programming should be used as a patch to allow business people to treat us badly because one person can take the silly interrupt and the other, supposedly, can hold the context. That’s an unrealistic expectation, first of all, because the other person’s going to want to know about the Political Event That Just Happened; secondly, we should really be focused on getting our status to a point where we’re not interrupted over executive nice-to-haves, but only when the business situation absolutely requires it and we can “save the day”. One hopes, of course, that the number of days that need saving is small.
I think there are some kinds of work that are best done alone, and other kinds that are best done in pairs.
I’m glad I’ve never worked in the kind of workplace you’re talking about.
It would be great to see that studied like the other topics in the article. I’ve only liked pair programming for knowledge transfer, but if reducing interruption cost is a replicable effect of pairing that’d be great evidence for its value. Fingers crossed some researcher takes it up. :)
Subjectively, I think pairing does reduce my distractibility a lot. Like, my focus with pairing and my focus without pairing are not even in the same ballpark. It’s not because one member of the pair takes the distraction while the other sits there meditating, though. It’s because I don’t read Lobsters or listen to the conversation in the other room when I’m working to communicate with my pair; it might also be because third parties are more reluctant to interrupt our conversation than they would be to talk to one of us alone.
For many people, the biggest benefit of pairing may be knowledge transfer, instant code review, uniform coding standards, or bringing to bear a greater diversity of experience on the problem at hand. For me, it’s focus, by a mile.