Distracted programmer
The author of the article - a programmer with sixteen years of experience - was faced with the impossibility of sitting 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 breaks do not harm 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 while distracting and not losing your thoughts became the news for me.
I can’t sit at a table for more than an hour without pain, and I can’t work more than a standard eight-hour day. The problem is that for the last 15 years my strategy of work has been to catch the “flow” and then code for a very long time without interruptions. This strategy is very popular with coders who like to lock themselves for a day, put on headphones and disconnect from the outside world - and that is 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 up, 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 I was doomed to low productivity. But over the past 6 months I have found that “slow warming up and long work without interruptions” is an acquired behavior, not innate, and it is quite possible to retrain to other rhythms of activity. It looks like a multi-phase dream - as soon as you are used to doing things in a certain way, any changes are very laborious, but possible - with enough motivation and time to get used to.
')
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 as people practicing multiphase sleep, quickly reach the REM phase. What methods did I use to achieve this?
This is not so much a technique as a psychological attitude, a thread running through all the following tips. Instead of avoiding interruptions at all costs, accept 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, you do not have time to do anything, and you will want to quit it and return to your usual pattern of behavior. You need to endure this stage and learn to take breaks as part of your rhythm.
The most annoying thing about being distracted from work is the loss of context. When you are “in the flow,” you hold most of the context in your head, constantly changing it and adjusting it to what you are doing. If you digress, the picture is lost, and its restoration requires a fair amount of time. My recipe for dealing with this is to bring out as much detail as possible on as many levels as possible.
I am my own chronicler. I write down all the time what I'm doing, be it a comment for the ticket, frequent commits with detailed comments or just notes on paper. For reference, approximately every half hour I have a new fragment of the external context, otherwise it will be harder to restore it after the break. It 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 “task” in the singular. Right. There are no “current assignments” - only the current assignment and distractions. We all use bug trackers to control what needs to be done, but when we work on one thing, we 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 idea, because it is trivial, or are we already in the subject line, or is it just so great that you want to try right now? I don't do that anymore; Any thoughts that are not related to the current task, regardless of their importance and size, are sent to the bug tracker and immediately ejected from the head until I finish the current task. The gain of this approach is that any new question adds one level to the context that you support, and complicates its recovery after the break. It sounds simple and obvious, and may even be a formal procedure in your company, but try saying that you are really doing it!
This is an item from Getting Things Done, but worth it to repeat. Half effective work is accurate knowledge of what to do next. When you return from a break, you should not waste time figuring out what you are doing next. If you have several current tasks, you will have to spend time choosing between them - and this is lost time. Here you should be helped by your bug tracker and those comments that you lead on the current task. If you were forced to switch to another project, the external context should help here too - 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 that is in the list, and should only evaluate what to do first of all. Over time, I found that inverting the selection process reduces the time spent on planning and gives clearer priorities. To do this, we must assume that I will not do anything from the list, and assess the negative consequences of the failure to comply with each item. Instead of “A or B is more important to do?” I decide the question “A or B gives the worst consequences, being unfulfilled?”. The difference may seem insignificant, but the second approach provides more accurate estimates.
This article deals with the negative aspects of interruptions and distractions from work. In fact, they have no less positive consequences. I can argue that all coders once stayed up late or all night, trying to fix some problem to no avail, and found that this was done in 15 minutes in the morning, or thought up a solution somewhere in the shower or on the road. This is explained very simply - long periods of concentration seem productive, and may even be so for actions that require consistent thinking, but for creative thinking and solving non-standard tasks, it is exactly the opposite. A tired brain works indistinctly, and the solution to your problem often does not lie in the same path that you have been breaking through for the last few hours, but to the side, and requires a look from a new angle. Periods of concentration usually limit thought to the framework of the current course of thought, and bouts of inspiration and brilliant insights become infinitely rare. That is why the interruption of concentration can be more beneficial than the painful extension for another couple of hours.
I can’t sit at a table for more than an hour without pain, and I can’t work more than a standard eight-hour day. The problem is that for the last 15 years my strategy of work has been to catch the “flow” and then code for a very long time without interruptions. This strategy is very popular with coders who like to lock themselves for a day, put on headphones and disconnect from the outside world - and that is 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 up, 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 I was doomed to low productivity. But over the past 6 months I have found that “slow warming up and long work without interruptions” is an acquired behavior, not innate, and it is quite possible to retrain to other rhythms of activity. It looks like a multi-phase dream - as soon as you are used to doing things in a certain way, any changes are very laborious, but possible - with enough motivation and time to get used to.
')
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 as people practicing multiphase sleep, quickly reach the REM phase. What methods did I use to achieve this?
1. Greet breaks
This is not so much a technique as a psychological attitude, a thread running through all the following tips. Instead of avoiding interruptions at all costs, accept 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, you do not have time to do anything, and you will want to quit it and return to your usual pattern of behavior. You need to endure this stage and learn to take breaks as part of your rhythm.
2. Store context in external memory
The most annoying thing about being distracted from work is the loss of context. When you are “in the flow,” you hold most of the context in your head, constantly changing it and adjusting it to what you are doing. If you digress, the picture is lost, and its restoration requires a fair amount of time. My recipe for dealing with this is to bring out as much detail as possible on as many levels as possible.
2.1. Comment on the current task.
I am my own chronicler. I write down all the time what I'm doing, be it a comment for the ticket, frequent commits with detailed comments or just notes on paper. For reference, approximately every half hour I have a new fragment of the external context, otherwise it will be harder to restore it after the break. It 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 “task” in the singular. Right. There are no “current assignments” - only the current assignment and distractions. We all use bug trackers to control what needs to be done, but when we work on one thing, we 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 idea, because it is trivial, or are we already in the subject line, or is it just so great that you want to try right now? I don't do that anymore; Any thoughts that are not related to the current task, regardless of their importance and size, are sent to the bug tracker and immediately ejected from the head until I finish the current task. The gain of this approach is that any new question adds one level to the context that you support, and complicates its recovery after the break. It sounds simple and obvious, and may even be a formal procedure in your company, but try saying that you are really doing it!
2.3. Always know what to do next.
This is an item from Getting Things Done, but worth it to repeat. Half effective work is accurate knowledge of what to do next. When you return from a break, you should not waste time figuring out what you are doing next. If you have several current tasks, you will have to spend time choosing between them - and this is lost time. Here you should be helped by your bug tracker and those comments that you lead on the current task. If you were forced to switch to another project, the external context should help here too - 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 that is in the list, and should only evaluate what to do first of all. Over time, I found that inverting the selection process reduces the time spent on planning and gives clearer priorities. To do this, we must assume that I will not do anything from the list, and assess the negative consequences of the failure to comply with each item. Instead of “A or B is more important to do?” I decide the question “A or B gives the worst consequences, being unfulfilled?”. The difference may seem insignificant, but the second approach provides more accurate estimates.
4. Recognize the benefits of breaks.
This article deals with the negative aspects of interruptions and distractions from work. In fact, they have no less positive consequences. I can argue that all coders once stayed up late or all night, trying to fix some problem to no avail, and found that this was done in 15 minutes in the morning, or thought up a solution somewhere in the shower or on the road. This is explained very simply - long periods of concentration seem productive, and may even be so for actions that require consistent thinking, but for creative thinking and solving non-standard tasks, it is exactly the opposite. A tired brain works indistinctly, and the solution to your problem often does not lie in the same path that you have been breaking through for the last few hours, but to the side, and requires a look from a new angle. Periods of concentration usually limit thought to the framework of the current course of thought, and bouts of inspiration and brilliant insights become infinitely rare. That is why the interruption of concentration can be more beneficial than the painful extension for another couple of hours.
Source: https://habr.com/ru/post/106523/
All Articles