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.
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.
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.
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.
> 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.
> 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. ;)
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.
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?
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.
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.
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...)
> 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.
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."
> I've found that I really really hate making urgent requests to other teams
For me what ended up working by far the best is to always and for every request try to:
1) Give an honest summary of the negative consequences of your request being delayed/ignored
2) Ask for an honest summary of the negative consequences of your request being honored.
3) Continue calibrating the relative importance until the higher priority task is obvious for both parties.
At first you might get run over a few times but if you don't accept politics (also not your own!) to enter the equation and consistently do this eventually people will be very accepting and these request can be made very efficiently.
What you're talking about is a great example of good-faith communication. Unfortunately, it relies on both parties dealing in good faith, and I've had too much experience with people who won't do that -- they won't give an honest assessment of what happens if their request isn't met. I wish I knew how to handle that.
In this case you should trust but verify: ask the person to detail his sources (he is making the request on behalf of someone after all) and approach them directly to get a better picture of the situation.
If his sources are outside of the company or also not truthful then I'd also be at a loss :)
Well, there's nothing intrinsically wrong with an engineer having the information if they're interested. It's often useful to have a larger picture. However, for the purposes of dealing with interruption, calling in an ally is basically the most efficient way to make it go away. (The caveat being that sometimes the interruption really is more important.)
I've also heard managers chewing out or giving educative talks to others in order to remind them that the correct person to make the request to is the manager, not the engineer.
> I've also heard managers chewing out or giving educative talks to others in order to remind them that the correct person to make the request to is the manager, not the engineer.
Haha, funny you say this, since I also 'educate' others about this on a monthly basis (it's become much better compared to 12 months ago though, so credit to the customer facing teams who are generally reasonable people).
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?
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.
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.
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.
This. It was a new idea to me when I started at my current place, now I can't imagine living without it. We've also been through a merger with another similar sized company (with a very different culture, in a substantially different timezone) during my tenure, and evangelising the IRC network was a big thing. The difference in communication efficiency between teams who were quickly convinced that group chat was a positive vs those that weren't was pretty noticeable.
The etiquette thing is important, and varies team by team. Our team has several channels to ourselves with varying levels of formality, and company wide channels similarly (#techteam, title line: "No banter" vs. #companyname, title line: <insert latest in-joke>)
Not only does the group element allow anyone who's taking a quick break to offer some help, it often draws in advice from across the organisation, including people you'd never have thought of asking, who just happen to be dipping in to the channel at the time.
Edit: The office wide "banter" channel's primary purpose most days (so like, not Friday afternoon) is the distribution of fresh coffee, prepared in 5 mug cafetieres, announced and claimed here. So many people have IRC bings on the word "coffee" that it's best discussed in some form of leet substitution if you're not offering to make some.
I've tried, and failed, twice, to introduce IRC into organizations. The first organization wanted policy and procedures around logging all chats - ugh ( yes, I know how to set up logging bots.) At the second, I had most of the team balking on the 'ugliness' of (whatever) IRC client they installed and insisted we use campfire.
I'm more than a little jaded at this point, and would love to hear if anyone has faced and solved these sorts of issues.
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).
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”
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.
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.
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.
I think there's some level of cognitive bias here with respect to social interaction preferences.
I certainly prefer to hang out with folks in a social setting compared to sitting in an office all day. I understand folks who prefer to do this in a work environment from a camaraderie and a "I'm not in a cave" perspective. That's totally fine and understandable.
But from a real, practical standpoint - are folks that "prefer" to be in an open setting actually more productive than those not?
What type of programming lends itself better to a distraction-filled environment?
How does "culture" fit into the distraction equation, other than "we tolerate more distraction-killing productivity here than elsewhere"?
(We have a chat room where we try and put all side discussions, so folks can virtually "overhear" conversations and chime in if applicable).
I concede that there could be some people who will get so antsy in an office all day that the mosh pit-style work environment "feels" better. I'm not discounting that some folks prefer to be in a noisy environment. I just question whether or not they're actually more productive there or that the organization is better off in total with a noisy environment.
The difficulty I have is that I cannot find any studies that show that a distraction-filled environment creates more knowledge-worker productivity than a quiet one. Mountains of studies scream the opposite.
Personally, I'd rather find other ways to channel that ADHD energy in a more productive manner. :D
I would guess it has a lot to do with the team, especially the size but also the level of commitment to the work of the other devs. I've never been around a loud team or in a noisy environment (I'm not counting the sound of other people typing). Blocking out 50 conversations in a day, many of the much more inane or pointless, may be much harder for me than 5 business/tech-related ones. But I've never had to try to deal with that.
Though I doubt that it would be much different for me, personally, because when I'm really in the middle of an interesting problem and cranking stuff out, I just don't notice background noise in the same way I don't notice that it's suddenly four hours later... I mean, maybe I'm just lucky in that, but my own coworkers have never expressed frustration with the environment either, so I don't know just how rare it is. (So I guess the key thing is that if the environment is getting to you, don't just keep it to yourself!)
I also have a (maybe overly cynical?) hunch that in addition to the "ease of distraction by external noises" spectrum there's also a "desire to goof off more if nobody's going to notice" spectrum that comes into play. (He says, as he posts on HN in the middle of the day, heh...)
I've never bothered to look into research on it, but I also don't see any trends of companies with private offices outcompeting ones without. I know the output of the team I was on at the company I worked at where I had a private office was not great, but there are other factors involved there too, of course.
I also think the rotating "consulting developers" idea from grecy above sounds like a pretty good idea, regardless of office layout.
The point of being in a room with others isn't mainly about productivity. There can be a few benefits sometimes, the ease of asking a question. "Hi, this SnowClassifierFactor instance in the audio lib, is there any specific reason it is there?" and overhearing discussions as mentioned in other posts.
However, the important thing to consider is the fact that humans in general prefer to be among others. Even sitting quietly staring at a wall is more preferable in company than alone. So I don't really care if I'd be 10% less productive, being amongst others is good for my mental health.
However, this should of course mean that for those who don't enjoy company of others there should be a way to be alone. Just having a "silent room" where you can go to not be disturbed might be a way.
Some people prefer a quiet environment versus listening to something, even if that's white noise. So, while getting a good pair of headphones is great for those who like having some auditory stimulation while they work, it just doesn't compare to having a quiet office if that's how you work best.
There is basically no such thing as "quiet environment", unless it's a library. There will be some noise from the neighbors, from the street or whatever. I find that I can tune out easily enough if the noise is beyond my control. If, on the other hand, it's someone whom I can ask to keep it down (but would rather not to), then noise cancelling headphones is the best option there is.
Ok, you're getting into semantics now. I think most people reading that would understand what I mean when I say a quiet environment, especially vs a library where the only sounds tend to be the information desk, the hum of computer fans, photocopiers and the heating/cooling system.
The quiet environment I was describing can be found in an office where the majority of people are heads-down working and not on the phone. This is harder to find when you're in an office that's setup as a cube-farm or an open layout. But this can be easily found at the beginning or end of the day and especially on work days that bookend holidays or three day weekends - days that lots of people typically take vacation. Those are the times when I find I get my best work done because it is the closest to quiet and distraction-free that one can find, other than working remotely where you can control the environment.
....and then you're sitting there working while loud, open-plan loving boss is having an impromptu with a few people in the middle of the floor, you catch his eye a few times and take off the 'phones to see what's up, and it's nothing of your concern. Many times the difference is simply a people problem.
I've literally worn noise-canceling earbuds inside of over-ear Beyerdynamics to keep the noise out and ensure that people can see that I am distracted/not listening/not available, but if someone really wants to hang over your cube wall to try to have a conversation with you instead of just emailing you, nothing stops them and it's considered rude to suggest anything otherwise. That's the reason we have an open floorplan to begin with; the company's attitude is that everyone is available at all times. To non-technical staff, it's "faster" for them to walk up to us than it is to write it out. It's also worth mentioning that headphones were outright banned from the office for this reason, but slowly the creative departments have taken to ignoring it.
As far as the "go-to" person people have noted having above, everyone on my team works on different aspects of what we do, so no one person can answer every question. Our PM is also not super familiar with what those roles are nor are they technically competent enough to answer those questions on their own (as of now, anyway).
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.
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.
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".
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.
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.
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.)
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.
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.
The problem is the business isn't paying for a single programmer's value, it is paying for two. The only time I have known pair programming actually worked pretty good was when a senior would take a junior under their wing when the junior was first hired. This would facilitate quick ramp-up for the junior to know all practices and the vast amount of things that are not documented (or updated). Keep in mind this only lasted a couple of months max, and not necessarily every day.
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.
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 :)
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.
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.
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.
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.
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.
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.
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...
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.
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.
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.
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.
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.
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
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...
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.
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).
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.
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