Translation of the article “Work 2.0 - the interruptible programmer”
Posted by: Steve Streeting
Original article: www.stevestreeting.com/2010/09/04/work-2-0
I am 37 years old and I have been a (professional) developer for 16 years. You might think that during this time I have developed an effective style of work, bringing the desired result and not causing unpleasant side effects. But, unfortunately, it is not. It seems to me that the style in which I worked during the first 15 years of my career was almost the same as that of any other developer who was passionate about his profession: you spend a lot of time on work. 12-16 hours a day, programming marathons in the evenings and on weekends, pizza on the keyboard, heavy periods, debugging at 3 am, when you can not go to bed, because you feel that you are about to catch this fucking bug, desperate attempts finish the work a minute before the deadline, when you manage to complete the last piece of code, as in a famously twisted action movie, at the last second before the world was ready to go straight to hell. If you are one of those whom I speak about, you nodded understandingly and probably smiled slightly, recalling past trials and victories. Such insane dedication to work is respected in our circles and is largely expected from any developer with high karma.
But it turns out that all this is not very good for our health. Who knew? Those of you who are familiar with me or follow my blog are aware that I was forced to leave this style of work because of old problems that I initially ignored, then forced me to look for compromises, and, in the end, completely overwhelmed me . Being a freelancer, I ran into a big problem. Attempts to get out of the hole, which I dug for myself, took a lot of time and brought many disappointments. I read a decent amount of books on productivity in trying to find an answer as the question “how to continue to work”, and as a result I came to the conclusion that the best answers are those that you formulate for yourself. I would like to share one of the discoveries that I made on my way.
')
So, I would like to talk about the biggest problem I faced: periods of concentration. I can not sit at the table for more than an hour. If I don’t get up and walk at least once an hour, do small stretch marks and the like, then I will pay for it as soon as I take a step, and I’ll probably pay more within a few days. I also can no longer work without feeling pain more than the standard 8 hours a day. The problem was that the style in which I had been working for more than 15 years taught me to gradually enter a state of “hit” and continuous coding for a long time. This is a common theme for programmers who like to go to work with their heads for many hours, wear headphones to distract nothing, completely disconnect from the outside world and the like - and this is also the reason that we usually react badly when we are interrupted. . Programming requires concentration, and it appears that concentration puts pressure on the valve of the system: it takes some time to warm up, and when this happens you don’t want to turn it off, since restarting is a difficult task.
It seemed to me that there was no way around this problem, and I began to accept the fact that I would be less productive. However, during the last 6 months, among other things, I found that slow warming and long continuous work are more of a habit, and you can train yourself to do work for a friend. This is similar to how people learn multi-phase sleep . It’s not that you couldn’t do it, just when you’re used to doing things in a certain way, it’s very, very difficult to change it first. But this is not impossible with sufficient motivation and time to get used to.
So, my goal was to accustom myself to a lot of short sessions during the day instead of a few very large ones, while maintaining performance. The key to this was to find a way to quickly return to a state of concentration, just as people who are learning multi-phase sleep train themselves to reach the fast sleep phase faster. To a greater degree I have already learned this, or at least I can do it much better than before. So, what methods did I use to achieve this?
This is not so much a technique as a psychological attitude associated with all practical approaches, which I will discuss below. Instead of being a typical programmer who avoids interruptions at all costs, you must learn to accept them and more effectively manage them. It is difficult, you should try to set aside years of resistance to breaks, and as you adjust, you will feel that you don’t have time to do enough. Many people are likely to refuse to do this if they do not have something motivating to go through it. For me, daily pain was a great motivation. The main thing that I want to say by this is that this transition is just a stage, and that it is possible to be an interrupted programmer who still does the work. But you have to learn not to deal with interruptions. That is why this is the first point.
The main part of the problem with interruptions is the loss of context. When you are focused on something, you juggle a whole bunch of context in your head, correcting it on the fly, constantly maintaining and correcting the links between different issues. An interrupt will cause you to drop all this, and it will take time to put the whole thing together again. My answer to this was to get out of my head as much as possible, at all possible levels:
I am my own chronicler. I write notes all the time about what I'm doing: I add comments to the task, I often make commits and write detailed descriptions (you use distributed VCS to make frequent commits convenient, don't you?;)), I make sketches on ( ordered) scraps of paper. In fact, it is not so burdensome, and in fact, taking your thoughts out of your head can often help you clarify them. The basic rule is that approximately every 30 minutes I have to receive some new part of the context, which is saved somewhere other than my head. If this does not happen, then in the event of an interruption, I will have more problems, re-collecting the context in my mind. It does not take much time, and also has other advantages, such as recording your thoughts and decision-making process.
You may have noticed that in the previous paragraph I wrote the “current task” in the singular , and not the “task”. There is no such that there are several current tasks. There is only one task you are working on at the current time, and distractions .
We probably all use bugtrackers and task managers. But when you work on a task, a new bug is often found, or an opportunity for optimization, or an idea about a new interesting function comes. How many of us immediately grab it, because it is in the area we are working on now? I was among them, but I don’t do that anymore. Any indirectly related task that is not directly related to what I am doing right now is sent to the task list and instantly forgotten until I finish the current task, regardless of its size, relevance or priority. It seems simple and obvious, and it may even be the official rule in your organization, but let most programmers say that they really do. The advantage is that even the slightest distraction will add an extra level to the context that you need to maintain, and in the event of an interruption it will be even more difficult to assemble.
For this to work, you need a fast and easy task management system that doesn’t require you to be thorough in describing a new task. You must open it and close it within 30 seconds to unload the thought, without being distracted from the current task. You can come back to her later.
This is one of the rules of GTD (“Next steps”), but it is very useful. When you return to work after a break or interruption, you should not waste time figuring out what you need to do next. Your task system will help you with this, including comments, which hopefully you have not forgotten to add to the current task. If you were forced to switch between projects, and at the same time maintained an external context everywhere, you should not have problems defining the next action. It is important to have only one following action for each project. If there are several, you will have to spend time choosing between them, and this is wasted time (see the next section on priorities). At any given time, you must have not only one current task, but one unambiguous next action for this task. Half the problem of effective work is knowing what you will do next.
I mentioned the following actions in the previous section, but how to decide what will be next? You can spend a lot of time tormenting priorities, and I was looking for a way to avoid this. It seemed logical to proceed from the assumption that I would like to make everything from the list, and I only need to determine which items to carry out first. I found that you can save time on planning, and at the same time get more accurate priorities by inverting the decision-making process: based on the assumption that I may not perform any of the tasks, and evaluating the negative consequences of not completing each of them. Thus, the question "Which of functions A and B is more important" turns into "Suppose we do not implement function A and B. What will be the consequences of the absence of each of the functions?" This may seem like a minor difference. But my experience shows that the need to fully explain the importance of the task, instead of determining the relative order on the assumption that eventually everything will be done, as a rule, gives a more honest assessment.
We mainly looked at ways to avoid the negative effects of interruptions, but the fact is that they also provide many advantages in work. I can argue that all programmers stayed up late at work, or stayed up late at night trying to fix the problem, and the next day they solved it in 15 minutes, or found the answer in such unexpected places as a shower. The reason for this is very simple: long periods of concentration seem productive, and can be so for operational / consistent thinking, but for everything else, like creative thinking or problem solving, it is very often quite the opposite. Not only does a tired mind work less clearly, but often the solution to a problem is not more diligent thinking in the direction in which you have been working uselessly for the past few hours, but in looking at the problem from a different angle. Long periods of concentration, as a rule, block thinking in one direction, making inspirations and brilliant insights very rare. Creativity always happens at that moment when you are not trying, and it is often an undervalued, but very important tool in programming. Interrupting rectilinear thoughts can actually be very useful.
There are still a lot of things that I could talk about, but I think this will be enough for a start. I hope for someone it will be interesting and useful.
Original article: www.stevestreeting.com/2010/09/04/work-2-0
Work 2.0 - Interrupted Programmer
I am 37 years old and I have been a (professional) developer for 16 years. You might think that during this time I have developed an effective style of work, bringing the desired result and not causing unpleasant side effects. But, unfortunately, it is not. It seems to me that the style in which I worked during the first 15 years of my career was almost the same as that of any other developer who was passionate about his profession: you spend a lot of time on work. 12-16 hours a day, programming marathons in the evenings and on weekends, pizza on the keyboard, heavy periods, debugging at 3 am, when you can not go to bed, because you feel that you are about to catch this fucking bug, desperate attempts finish the work a minute before the deadline, when you manage to complete the last piece of code, as in a famously twisted action movie, at the last second before the world was ready to go straight to hell. If you are one of those whom I speak about, you nodded understandingly and probably smiled slightly, recalling past trials and victories. Such insane dedication to work is respected in our circles and is largely expected from any developer with high karma.
But it turns out that all this is not very good for our health. Who knew? Those of you who are familiar with me or follow my blog are aware that I was forced to leave this style of work because of old problems that I initially ignored, then forced me to look for compromises, and, in the end, completely overwhelmed me . Being a freelancer, I ran into a big problem. Attempts to get out of the hole, which I dug for myself, took a lot of time and brought many disappointments. I read a decent amount of books on productivity in trying to find an answer as the question “how to continue to work”, and as a result I came to the conclusion that the best answers are those that you formulate for yourself. I would like to share one of the discoveries that I made on my way.
')
But I am "in shock" !!!
So, I would like to talk about the biggest problem I faced: periods of concentration. I can not sit at the table for more than an hour. If I don’t get up and walk at least once an hour, do small stretch marks and the like, then I will pay for it as soon as I take a step, and I’ll probably pay more within a few days. I also can no longer work without feeling pain more than the standard 8 hours a day. The problem was that the style in which I had been working for more than 15 years taught me to gradually enter a state of “hit” and continuous coding for a long time. This is a common theme for programmers who like to go to work with their heads for many hours, wear headphones to distract nothing, completely disconnect from the outside world and the like - and this is also the reason that we usually react badly when we are interrupted. . Programming requires concentration, and it appears that concentration puts pressure on the valve of the system: it takes some time to warm up, and when this happens you don’t want to turn it off, since restarting is a difficult task.
It seemed to me that there was no way around this problem, and I began to accept the fact that I would be less productive. However, during the last 6 months, among other things, I found that slow warming and long continuous work are more of a habit, and you can train yourself to do work for a friend. This is similar to how people learn multi-phase sleep . It’s not that you couldn’t do it, just when you’re used to doing things in a certain way, it’s very, very difficult to change it first. But this is not impossible with sufficient motivation and time to get used to.
So, my goal was to accustom myself to a lot of short sessions during the day instead of a few very large ones, while maintaining performance. The key to this was to find a way to quickly return to a state of concentration, just as people who are learning multi-phase sleep train themselves to reach the fast sleep phase faster. To a greater degree I have already learned this, or at least I can do it much better than before. So, what methods did I use to achieve this?
1. Accept interrupts
This is not so much a technique as a psychological attitude associated with all practical approaches, which I will discuss below. Instead of being a typical programmer who avoids interruptions at all costs, you must learn to accept them and more effectively manage them. It is difficult, you should try to set aside years of resistance to breaks, and as you adjust, you will feel that you don’t have time to do enough. Many people are likely to refuse to do this if they do not have something motivating to go through it. For me, daily pain was a great motivation. The main thing that I want to say by this is that this transition is just a stage, and that it is possible to be an interrupted programmer who still does the work. But you have to learn not to deal with interruptions. That is why this is the first point.
2. Keep your context out of your head all the time.
The main part of the problem with interruptions is the loss of context. When you are focused on something, you juggle a whole bunch of context in your head, correcting it on the fly, constantly maintaining and correcting the links between different issues. An interrupt will cause you to drop all this, and it will take time to put the whole thing together again. My answer to this was to get out of my head as much as possible, at all possible levels:
2.1. Keep working notes for the current task.
I am my own chronicler. I write notes all the time about what I'm doing: I add comments to the task, I often make commits and write detailed descriptions (you use distributed VCS to make frequent commits convenient, don't you?;)), I make sketches on ( ordered) scraps of paper. In fact, it is not so burdensome, and in fact, taking your thoughts out of your head can often help you clarify them. The basic rule is that approximately every 30 minutes I have to receive some new part of the context, which is saved somewhere other than my head. If this does not happen, then in the event of an interruption, I will have more problems, re-collecting the context in my mind. It does not take much time, and also has other advantages, such as recording your thoughts and decision-making process.
2.2. Ruthlessly ignore indirect questions
You may have noticed that in the previous paragraph I wrote the “current task” in the singular , and not the “task”. There is no such that there are several current tasks. There is only one task you are working on at the current time, and distractions .
We probably all use bugtrackers and task managers. But when you work on a task, a new bug is often found, or an opportunity for optimization, or an idea about a new interesting function comes. How many of us immediately grab it, because it is in the area we are working on now? I was among them, but I don’t do that anymore. Any indirectly related task that is not directly related to what I am doing right now is sent to the task list and instantly forgotten until I finish the current task, regardless of its size, relevance or priority. It seems simple and obvious, and it may even be the official rule in your organization, but let most programmers say that they really do. The advantage is that even the slightest distraction will add an extra level to the context that you need to maintain, and in the event of an interruption it will be even more difficult to assemble.
For this to work, you need a fast and easy task management system that doesn’t require you to be thorough in describing a new task. You must open it and close it within 30 seconds to unload the thought, without being distracted from the current task. You can come back to her later.
2.3. Always know what you will do next.
This is one of the rules of GTD (“Next steps”), but it is very useful. When you return to work after a break or interruption, you should not waste time figuring out what you need to do next. Your task system will help you with this, including comments, which hopefully you have not forgotten to add to the current task. If you were forced to switch between projects, and at the same time maintained an external context everywhere, you should not have problems defining the next action. It is important to have only one following action for each project. If there are several, you will have to spend time choosing between them, and this is wasted time (see the next section on priorities). At any given time, you must have not only one current task, but one unambiguous next action for this task. Half the problem of effective work is knowing what you will do next.
3. Prioritize the contrary
I mentioned the following actions in the previous section, but how to decide what will be next? You can spend a lot of time tormenting priorities, and I was looking for a way to avoid this. It seemed logical to proceed from the assumption that I would like to make everything from the list, and I only need to determine which items to carry out first. I found that you can save time on planning, and at the same time get more accurate priorities by inverting the decision-making process: based on the assumption that I may not perform any of the tasks, and evaluating the negative consequences of not completing each of them. Thus, the question "Which of functions A and B is more important" turns into "Suppose we do not implement function A and B. What will be the consequences of the absence of each of the functions?" This may seem like a minor difference. But my experience shows that the need to fully explain the importance of the task, instead of determining the relative order on the assumption that eventually everything will be done, as a rule, gives a more honest assessment.
4. Recognize the benefits of breaks.
We mainly looked at ways to avoid the negative effects of interruptions, but the fact is that they also provide many advantages in work. I can argue that all programmers stayed up late at work, or stayed up late at night trying to fix the problem, and the next day they solved it in 15 minutes, or found the answer in such unexpected places as a shower. The reason for this is very simple: long periods of concentration seem productive, and can be so for operational / consistent thinking, but for everything else, like creative thinking or problem solving, it is very often quite the opposite. Not only does a tired mind work less clearly, but often the solution to a problem is not more diligent thinking in the direction in which you have been working uselessly for the past few hours, but in looking at the problem from a different angle. Long periods of concentration, as a rule, block thinking in one direction, making inspirations and brilliant insights very rare. Creativity always happens at that moment when you are not trying, and it is often an undervalued, but very important tool in programming. Interrupting rectilinear thoughts can actually be very useful.
There are still a lot of things that I could talk about, but I think this will be enough for a start. I hope for someone it will be interesting and useful.
Source: https://habr.com/ru/post/106510/
All Articles