Choice is Evil

    I'll start with the main thing: if your programmers choose their own task, then you have big problems.

    We are used to looking at a choice as a conditional operator in a programming language or algorithm scheme. Well, remember, such a rhombus is drawn, it contains a selection condition, and two branches - yes and no. When the algorithm is executed, the condition is checked instantly, so its performance is usually not taken into account.

    And what is the choice made by man? This is not an instant algorithm, but a process. This process has a beginning, an end (God forbid), and, most importantly, duration. How long do you think the task selection can take?

    You can guess, but it's better to measure. I watched this process many times, and the conclusion is disappointing: the programmer can choose a task for several days.

    The selection process is bad because it is hidden from our eyes. If a person was wandering around the office, rushing from side to side, throwing up his head in a long howl, we would understand that he had a problem. But it happens differently.

    Programmers have long come up with such an algorithm as reconnaissance in battle. In relation to tasks, it means: not just read the condition, but go in and see. Take a look at the code, forms, links, metadata, playback examples, and analytical reports.

    You need to look in order to evaluate the task “as it should”, not by sight. If you catch a programmer in this occupation, he will say: I am a professional, and I can not take on the task without knowing all the subtleties. It would seem, why is this so? Is it right a man does?

    Of course it’s right. But only if, according to the results of his research, he makes the final decision - to take on the task, or not. As an option, take the task with reservations, such as the need to study additional mechanisms.

    If the programmer decided to take the task, and sat down to do, then everything is fine. If he abandoned the task, then everything is bad. The time spent on research will be wasted.

    There are two options. First, the programmer will refuse flatly, and someone else will watch the task. In principle, it is possible that the first programmer will simply retell the second results of his research, discovered pitfalls and associated difficulties. But in practice, programmers prefer independence from each other, including from the opinions of colleagues. Some even experience a certain excitement, understanding a task that a colleague did not undertake.

    The second option - the programmer did not refuse, but postponed the task until later. When this “later” comes - it is not known, but most likely - after a fairly long time. What will happen during the second iteration of reconnaissance in battle? Start where you left off in your research? Of course not - he will go the same way, from beginning to end. And, with a high probability, it will stall in the same place as for the first time.

    And so it turns out. There is time that programmers spend on solving problems. Normal, right, good time. As a rule, time is spent on solving a problem once.

    And there is time that programmers spend on multiple reconnaissance. There is no particular benefit at this time - neither for the programmer, nor for the client, or for your company. Time for reconnaissance in battle is almost a pure loss.

    But the problem is not only intelligence. It could be worse.

    For example, a programmer understands all the tasks on his list, but simply cannot choose what to do. The problem is compounded by the fact that the choice takes place as God puts on the soul - without a specific algorithm, criteria and priorities. And then there’s a lot of people.

    One chooses what is more interesting. Another chooses what is easier. The third chooses tasks by mechanisms that are familiar to him. The fourth chooses the tasks of his beloved client, because the result is easier to pass. The fifth chooses the most ambitious task to show himself.

    At the same time, which is important, almost each of them experiences serious mental torment due to the uncertainty of the criteria. He roughly understands what tasks he wants to solve, but either consciously or unconsciously feels that he is doing something wrong. It seems to him that we need to choose a completely different task, based on the strategy of the company, the state of the project, the plan for the development of our own competencies, etc. But I want to choose not what is needed, but what I like.

    Such mental torment aggravates the selection process even more. A person plunges into gloomy thoughts, weighing his choice on the scales of conscience. And so hours and days can pass.

    From the point of view of the manager standing on the sidelines, this whole process resembles a groundhog from one famous film that crawls out of a hole and “chooses the weather for the next six weeks.” What does he follow there, sees his shadow or not, and why does the groundhog do it at all? True, if the manager often looks at this process from the outside, then the question is more likely to him than to programmers.

    Also, in the context of choice, holiday is of great importance. A programmer is a person, first of all, and not a robot. What does a person want after completing difficult work? Holiday of course!

    The completed task should be noted. Go for a smoke, drink tea or coffee, chat with friends, brag about a solved problem, sit on social networks, read the news - in general, there are many options. Unfortunately, this holiday is sometimes delayed.

    It is especially bad if the task was completed in an hour, or even two before the end of the working day. Well, who, in their right mind, will choose a new task for themselves, if soon - home?

    How difficult it is to get out of the state of the holiday, every Russian knows - we all rest on New Year's holidays. In our case, it’s even more difficult, because the programmer should return not to solving the problem, but to choosing the next one. How painful the choice is, we have already discussed.

    If to summarize the losses from the choice, then they are always there. The only question is their quantity. To get you inspired, I’ll call you this figure: it takes up to 50% of the time to choose a task. Just think about this figure.

    But, in the context of our material, this figure is simply beautiful. By eliminating the loss of choice, you can double the efficiency.

    How to get rid of the choice? There is nothing easier. Actually, you yourself know how to do it. I will present my suggestions, and you will combine them with your own methods, and a decent increase in efficiency will result.

    The first and most important thing to start with is controlling. Whatever system of priorities and distribution of tasks you come up with, it will not work until the programmers “listen to you”.

    Controlling, in a nutshell, is numerical control. In this case, the figure will not be profit or the amount of sales, but the sequence number of the task in the queue. You need to manage the task selection based on this number, and be sure that the tasks are solved in the given order.

    Controlling is necessary if you manage a team, and even when you control yourself. After all, agreeing with yourself is easier than with a boss? “Yes now, for the last time, and then for sure!”

    In general, we will talk more about controlling in more detail, here I ran ahead, but it's worth it. If you came up with the rules for choosing a task, but no one executes them, then nothing will work.

    So, all that needs to be done is to line up the tasks in the queue and ensure that this queue is followed. In some sources, it is recommended to hide the queue from programmers, leaving only two tasks in sight - the current and the next. If you show the programmer all the tasks at once, then, no matter how hard you try, he will still “peep”, study what is ahead.

    The first method is the distribution of tasks by the boss, without using automation. You just say who does what and in what order. You can make simple plans - for example, in the form of small pieces of paper, such as work orders, or production tasks. You can simply dictate the task numbers for writing to a notebook.

    You can make a board, like scrum, and hang stickers there for the day. The method of scrum involves hanging a lot of tasks, for example - for a week or a month, but this does not suit us, because the choice appears again.

    Manual task allocation is very easy to start, and just as easy to stop, because you get bored quickly. You need to have significant willpower, or good regular management skills, to force yourself to distribute tasks daily. If the above is about you, you can start today.

    For lazy automation is suitable. In your information system, where tasks are stored, you need to put in place a mechanism for sorting them. How are you closer? Sort by production date? By deadline? Any way is good. The main thing is that it be determined and equally understood by programmers. Personally, I recommend not limited to sorting, but to store numbers in a queue as a separate field. Modern systems are too convenient for the user, and allow him to configure sorting independently. So you decided that you need to perform tasks in the order of receipt (FIFO), and the programmer accidentally, or intentionally, changed the sorting to the opposite, and received LIFO.

    If the number in the queue is saved, then sort, do not sort, it is difficult to make a mistake.

    You can not get attached to sorting, but set numbers manually. It also works if you have enough willpower to arrange these numbers.

    The principle, I think, is clear. Any queuing system understood by programmers and monitoring its compliance. This will be the first step in depriving a choice that takes efficiency.

    The second step we will consider further. It will allow us to derive much more benefit from the queues - not only to simplify the choice, but also to make it right.


    • Choosing a task is not an instant, but a lengthy process;
    • The programmer chooses a task based on his own ideas;
    • A huge amount of time is spent on the choice;
    • The selection process is neither good nor pleasure;
    • The choice must be deprived;
    • You can distribute tasks manually, like a foreman;
    • Automation can help queuing up.

    Also popular now: