October 20, 2010 at 15:30Programmer who is distracted
- Transfer
The author of the article, a programmer with sixteen years of experience, was confronted with the inability to sit at a computer for a long time (as many of us do). In this article, he talks about how to organize your workflow so that frequent interruptions do not hinder the ability to focus on work and work efficiency. In principle, quite well-known things, but for me personally, the inversion of priorities and the fact that you can work distracted while not losing your train of thought became news.
I cannot sit at a table painlessly for more than an hour in a row, and I cannot work more than a standard eight-hour day. The problem is that for the last 15 years my work strategy has been to catch the “stream” and then to code for a very long time without interruptions. This strategy is very popular with encoders who like to lock themselves for a day, put on headphones and disconnect from the outside world - and that's why they react so painfully when they are distracted. Programming requires concentration, and concentration works on the principle of a valve mechanism - it takes time to warm up and start, so it is better not to stop an already running mechanism.
I did not think that there were other ways of programming, and I was already beginning to accept the fact that it was doomed to poor performance. But over the past 6 months, I have found that “slow warming up and long work without interruptions” is acquired behavior, not innate, and it is quite possible to retrain on other rhythms of activity. This is like a multiphase dream - as soon as you are used to doing things in a certain way, any changes are very laborious, but possible - if you have enough motivation and time to get used to it.
So, my goal was to learn how to work with small approaches while maintaining efficiency. The trick is how to learn to return to the “stream” as quickly as possible - just like people who practice multiphase sleep reach the REM phase faster. What methods did I use to achieve this?
This is not so much a technique as a psychological attitude that runs through all the following tips as a red thread. Instead of avoiding breaks at all costs, take them and learn how to handle them. This is not easy - at first it will seem to you that you are distracted all the time, do not have time, and you will want to give it up and return to your usual model of behavior. You need to endure this stage and learn to take breaks as part of your rhythm.
The most unpleasant thing is to be distracted from work - this is a loss of context. When you are “in the flow”, you keep in mind a large part of the context, constantly changing it and adjusting to what you are doing. Should you be distracted, the picture is lost, and its restoration requires a fair amount of time. My recipe for dealing with this is to bring out as many details as possible on as many levels as possible.
I am my own chronicler. I keep writing down what I'm doing, be it a ticket comment, frequent commits with detailed comments, or just notes on paper. For reference, approximately every half an hour I have a new fragment of the external context, otherwise after a break it will be more difficult to recover. This is not so burdensome, takes very little time, and has other advantages - for example, it helps to systematize thoughts and better track the decision-making process.
You must have noticed that in the previous paragraph I used the "assignment" in the singular. Right. There are no "current tasks" - only the current task and distractions. We all use bug trackers to control what needs to be done, but when we are working on one thing, we very often notice another mistake, or a possible improvement, or a cool new chip. How often do we distract from the current work and switch to a new thought, because it is trivial, or we are already in the subject, or is it just so cool that I want to try it now? I don't do that anymore; Any thoughts that are not relevant to the current task, regardless of their importance and size, are sent to the bug tracker and immediately erased from my head until I finish the current task. The benefit of this approach is that any new question adds one level to the context that you support, and makes it difficult to recover from a break. It sounds simple and obvious, and it may even be an official procedure in your company, but try to say that you really do!
This is a point from Getting Things Done, but it's worth it to repeat. Half of the effective work is an accurate knowledge of what to do next. When you return from a break, you should not waste time figuring out what you do next. If you have several ongoing tasks, you will have to spend time choosing between them - and this is a lost time. Here your bug tracker and those comments that you keep on the current task should help you. If you were forced to switch to another project, the external context should help here - for each project there should be its own context and its current task. Moreover, at each moment of time there should be not only one current task, but also one next action on this task.
How to decide what to do next? It took me a lot of time to figure out the priorities: I proceeded from the fact that I want to accomplish everything on the list, and I only need to evaluate what to do first. Over time, I found that inverting the selection process reduces the time spent planning and gives clearer priorities. To do this, we must assume that I will not do anything from the list, and evaluate the negative consequences of failure to comply with each item. Instead of “Is it more important to do A or B?” I solve the question “Does A or B give the worst consequences if not fulfilled?” The difference may seem insignificant, but the second approach provides more accurate estimates.
This article is about the negative aspects of breaks and distractions from work. In fact, they have no less positive consequences. I bet that all coders once stayed up late or even all night, trying to fix a problem to no avail, and found that this was done in 15 minutes in the morning, or came up with a solution somewhere in the shower or on the road. This is explained very simply - long periods of concentration seem to be productive, and may even be so for actions that require consistent thinking, but for creative thinking and solving non-standard tasks, everything is exactly the opposite. A tired brain does not work well, and the solution to your problem often lies not on the same path that you have made your way through the last few hours, but on the sidelines, and requires a look from a new angle. Periods of concentration usually limit the thought to the scope of the current train of thought, and attacks of inspiration and ingenious insights become vanishingly rare. That is why interruption of concentration may be more useful than painful extension for another couple of hours.
I cannot sit at a table painlessly for more than an hour in a row, and I cannot work more than a standard eight-hour day. The problem is that for the last 15 years my work strategy has been to catch the “stream” and then to code for a very long time without interruptions. This strategy is very popular with encoders who like to lock themselves for a day, put on headphones and disconnect from the outside world - and that's why they react so painfully when they are distracted. Programming requires concentration, and concentration works on the principle of a valve mechanism - it takes time to warm up and start, so it is better not to stop an already running mechanism.
I did not think that there were other ways of programming, and I was already beginning to accept the fact that it was doomed to poor performance. But over the past 6 months, I have found that “slow warming up and long work without interruptions” is acquired behavior, not innate, and it is quite possible to retrain on other rhythms of activity. This is like a multiphase dream - as soon as you are used to doing things in a certain way, any changes are very laborious, but possible - if you have enough motivation and time to get used to it.
So, my goal was to learn how to work with small approaches while maintaining efficiency. The trick is how to learn to return to the “stream” as quickly as possible - just like people who practice multiphase sleep reach the REM phase faster. What methods did I use to achieve this?
1. Greet the breaks
This is not so much a technique as a psychological attitude that runs through all the following tips as a red thread. Instead of avoiding breaks at all costs, take them and learn how to handle them. This is not easy - at first it will seem to you that you are distracted all the time, do not have time, and you will want to give it up and return to your usual model of behavior. You need to endure this stage and learn to take breaks as part of your rhythm.
2. Store the context in external memory
The most unpleasant thing is to be distracted from work - this is a loss of context. When you are “in the flow”, you keep in mind a large part of the context, constantly changing it and adjusting to what you are doing. Should you be distracted, the picture is lost, and its restoration requires a fair amount of time. My recipe for dealing with this is to bring out as many details as possible on as many levels as possible.
2.1. Comment on the current task
I am my own chronicler. I keep writing down what I'm doing, be it a ticket comment, frequent commits with detailed comments, or just notes on paper. For reference, approximately every half an hour I have a new fragment of the external context, otherwise after a break it will be more difficult to recover. This is not so burdensome, takes very little time, and has other advantages - for example, it helps to systematize thoughts and better track the decision-making process.
2.2. Ruthlessly ignore neighboring questions
You must have noticed that in the previous paragraph I used the "assignment" in the singular. Right. There are no "current tasks" - only the current task and distractions. We all use bug trackers to control what needs to be done, but when we are working on one thing, we very often notice another mistake, or a possible improvement, or a cool new chip. How often do we distract from the current work and switch to a new thought, because it is trivial, or we are already in the subject, or is it just so cool that I want to try it now? I don't do that anymore; Any thoughts that are not relevant to the current task, regardless of their importance and size, are sent to the bug tracker and immediately erased from my head until I finish the current task. The benefit of this approach is that any new question adds one level to the context that you support, and makes it difficult to recover from a break. It sounds simple and obvious, and it may even be an official procedure in your company, but try to say that you really do!
2.3. Always know what to do next.
This is a point from Getting Things Done, but it's worth it to repeat. Half of the effective work is an accurate knowledge of what to do next. When you return from a break, you should not waste time figuring out what you do next. If you have several ongoing tasks, you will have to spend time choosing between them - and this is a lost time. Here your bug tracker and those comments that you keep on the current task should help you. If you were forced to switch to another project, the external context should help here - for each project there should be its own context and its current task. Moreover, at each moment of time there should be not only one current task, but also one next action on this task.
3. Set negative priorities
How to decide what to do next? It took me a lot of time to figure out the priorities: I proceeded from the fact that I want to accomplish everything on the list, and I only need to evaluate what to do first. Over time, I found that inverting the selection process reduces the time spent planning and gives clearer priorities. To do this, we must assume that I will not do anything from the list, and evaluate the negative consequences of failure to comply with each item. Instead of “Is it more important to do A or B?” I solve the question “Does A or B give the worst consequences if not fulfilled?” The difference may seem insignificant, but the second approach provides more accurate estimates.
4. Realize the benefits of breaks
This article is about the negative aspects of breaks and distractions from work. In fact, they have no less positive consequences. I bet that all coders once stayed up late or even all night, trying to fix a problem to no avail, and found that this was done in 15 minutes in the morning, or came up with a solution somewhere in the shower or on the road. This is explained very simply - long periods of concentration seem to be productive, and may even be so for actions that require consistent thinking, but for creative thinking and solving non-standard tasks, everything is exactly the opposite. A tired brain does not work well, and the solution to your problem often lies not on the same path that you have made your way through the last few hours, but on the sidelines, and requires a look from a new angle. Periods of concentration usually limit the thought to the scope of the current train of thought, and attacks of inspiration and ingenious insights become vanishingly rare. That is why interruption of concentration may be more useful than painful extension for another couple of hours.