Programming, fast and slow: the developers and the psychology of self-confidence
Today I am going to talk about what is happening in the heads of program developers, at the moment when they are doing preliminary calculations; why it’s so hard for them to fix all the ideas in their head; and also about how I personally resolved this situation for myself, learned how to live and write software (for happy business owners), but I am sure that my own estimations of labor intensity are as unreliable as ever.
But first, the story ...
It was <insert a period of time that would not make me ridiculously old> at the time when I was a young developer (1). In college, I was the best in programming classes, being a junior developer, I could crack the code and solve any problem I had before faster than anyone expected. Over the weekend I could learn a new language and work productively on it (or at least it seemed to me then).
')
Thus, as it should have happened, I had my own project. The large client manager explained to me in general terms what the client wants, we discussed this, and I said: “It will take 3 weeks to do this work.” “Good,” he answered. And so I started programming.
How do you think, how much time it took me to this project? Four weeks? Maybe five?
Um, actually: three months.
I still have clear memories of that time - my self-image was closely related to the feeling that I was a “good programmer,” in which I was very disappointed. I lost sleep, I had small panic attacks. And this was not the end. I remember that I was sucking under the spoon when talking with that manager, I explained again and again that I still have nothing to show him.
In one of these black periods, I decided that I would never make such mistakes again.
Unfortunately, in the course of my career, I learned something very difficult: I constantly make such mistakes.
In fact, I even learned something better: we all make these mistakes.
Recently, I read a book by Daniel Kaneman “ Thinking, Fast and Slow ” - an extensive study of what psychology is aware of about human cognitive processes, about his amazing strengths and (surprisingly predictable) weaknesses.
My favorite part is about Self-confidence. It showed, let's say, some connection with the way developers do calculations.
For a start, I believe that in reality, there are only two reasons why our calculations are so bad. The first reason, in a way that cannot be improved: writing software is a process in which you have to figure out how to describe something in incredibly precise details so that you can explain to a computer how to do it. And the problem is that in those parts that you do not fully understand at the initial stage of work, and there are difficulties that will come out and have a hard time.
And this is completely impossible to improve in any way. And only if you really “fully understand what to do,” or you have a library or there is a part of software that can do it for you, then you do not write anything. Otherwise, the unknown appears, and often it detonates. And you may not know how long it will take to solve these problems, maybe one day, one year, or you may not have enough time for the thermal death of the universe.
For example, in the case when it turns out that some involved from the development side are unreliable ... then you have to rewrite the entire array containing errors; or, when the database does not understand some critical parts of the encoding ... then you have to rebuild all your schemes from scratch; or, a real classic of the genre, when you show work to clients, but they do not accept what they ordered themselves, but they want a little bit different ... something that is much harder to do.
When you first encounter such a difficulty, you think, “From now on, you should be more attentive at the stage of developing a specification.” But this is not the best idea. Why? The main reason is that, as can be seen from the above examples, if you write the specification in such detail that you take into account all these accidents, then in fact it turns out that you are already writing software. And, really, there is no way to solve this problem (if, reading this article, you try to challenge this statement, then I will tell you - for sure, absolutely for sure, there is no way. Full specifications are a utopian economic idea. Below I will show you more favorable, from an economic point of view, options).
But this is where the fun begins. Every programmer who has worked in the real world for more than a couple of months has encountered the problems described above.
And yet ... we continue to make such impressively bad calculations.
And even worse, we believe our own calculations. I myself believe my, at the moment when I produce them.
So, wait, what am I suggesting that all developers somehow fall victim to the same, predictable mistakes in thinking?
Yes, this is exactly what I offer.
Kahneman says quite a lot about the problem of "experts" making predictions. In a shockingly wide variety of situations, these predictions turn out to be completely useless. In particular, in many, very many situations, the following three statements hold true:
1- The forecasts of “experts” about any future events are so unreliable that they are essentially meaningless;
2- Nevertheless, the experts discussed are incredibly confident in the accuracy of their forecasts;
3- And the best of all: it seems that absolutely nothing can diminish this expert self-confidence;
And the last statement, truly outstanding, is that even if experts try to face their own failures honestly, even if they are deeply aware of this lack of human thinking ..., they nevertheless remain deeply confident in the accuracy of their predictions.
Here is how Kaneman explains this after telling a striking story about his own failures in this field:
"The confidence that you will feel in your future judgments will not be understated by what you have read now, even if you believed every word."
Interestingly, there are situations for which expert forecasts are quite good, and I am going to demonstrate these situations below, as well as how to use them to improve my development processes. But before doing this, I would like to go through some of the details of how erroneous self-confidence works, in practice, you may be able to find it in yourself.
In Thinking Fast and Slow, Kahneman explains much of psychology as an interaction between two “systems” that control our thoughts: System I and System II. My very brief summary on this subject would be: “System II is responsible for accurate, rational, analytical thinking, and System I is responsible for fast, heuristic and comparative thinking.”
And it is critical that evolution seems to have designed everything with one sole purpose — that System II should not have to do too much. Which is very logical from the point of view of evolution - System II is slow as molasses, and incredibly expensive, it should be used in very, very rare cases. But you see problems, without a doubt, without much thought, how, then, should your mind understand when to run System II? From this point of view, many of the various “cognitive distortions” of psychology can be perceived as subtle engineering solutions to such a cruel life problem, as the distribution of attention in real time.
To see how the interaction of Systems I and II can lead to truly awful, and at the same time honest and trustworthy calculations, I am going to pass the microphone for a short time to my friend (and Hut8Labs colleague) Edmund Jorgensen . He described it to me in his letter as follows:
“When I asked myself“ how long will this project take? ”System I had no idea about it, but wanted to get an answer, and recoded the question. What? I suspect that in something like "how much I am sure of myself that I can do this thing," and this, in turn, recoded into the calculation of time with a certain coefficient that is relative (for example, when Bob feels the degree of X’s confidence, he always responds 3 weeks; when Suzy feels X’s confidence, she always responds 5 weeks). ”
Raise your hand, if you gradually realize that you have two "big" time meters? For example, for me it is “3 weeks” and “3 months”. The first implies that "it seems complicated, but essentially I think I know how to do it"; the second implies: “Wow, this is difficult, I’m not quite sure that I need to do this, but I’m willing to bet that I can find out.”
Aha, I think Edmund is completely right.
(For those who spend time at home: my “3 week” projects seem to take 5-15 weeks, my “3 months” projects usually take 1-3 years, in those rare cases when someone wants to pay me for it ).
You might think from this point of view: “Well, I see where you're going, Dan, we need to approach these calculations in accordance with the principles of System II instead of System I. Thus, our attentive, analytical minds will make the best calculations”.
Congratulations, you just invented Waterfall.
Essentially, this is an application of a “complete specification specification prior to programming”: do not allow your team to do intuitive calculations, get everyone to accurately mobilize their analytical skills and approach the issue of detailed specifications and calculations that are divided into smaller parts.
However, this is doomed to failure. As usual…
The real problem here is the interaction between two sources of erroneous measurements: a human error in relation to one’s self-confidence, and an inherent element of uncertainty inherent in every real software development project. This uncertainty is so serious that even a careful rational System II cannot provide accurate predictions.
Fortunately, there is a way to combine the use of the strengths of thinking, and at the same time, cope with the impermanence of the real world.
First, how to use the strengths of your thinking.
Kahneman and other researchers could determine situations where expert judgment is not completely erroneous. According to him:
“To find out if you can trust a certain intuitive judgment, you need to ask two questions: Is the environment in which the judgment takes place is constant enough to make predictions based on the available evidence? The answer is "yes" - for the Diagnostic, "no" - for the drain-picker. Do professionals have an appropriate opportunity to study signals and patterns? ”
“Appropriate opportunity” means a large number of predictions made, as well as close feedback for studying their accuracy.
Now, 6-18 monthly software writing projects do not satisfy all these criteria at all. As I said earlier, the environment is not quite “permanent.” In addition, experts do not have a combination: make a lot of predictions and get quick reviews. If something takes a year or more, then the feedback is too long to train your intuition (plus, you will need a large number of examples).
However, there is a form of calculation, applicable to software development, which is suitable - 0-12 hour tasks, if they are then immediately implemented. From this angle, things work differently:
From this point of view, you are using the strengths of System I - there is an opportunity to train it, it has many examples available, and it contains informative models that can be selected. And thanks to short sprint segments, you very quickly receive feedback on the quality of your calculations.
How can I say that you can make these micro calculations, but somehow you cannot apply them to 6-18 monthly calculations? Are the error values ​​not averaged?
Essentially, although I think that calculations on a similar scale are usually correct, in the case when they are not correct, there is simply no limit to how wrong they may be. In mathematical terms, I suspect that actual times follow the distribution of a power law. And the power law distributions are known for not having a stable value and infinite dispersion, which, frankly speaking, seem to me the same calculations of the project of a large waterfall.
You may think: how is it even possible that something that can be done in 4 hours can take a month or two?
It happens all the time: you are going to move on to the final stage, but suddenly you will find out that some hidden obstacles radically change everything. For example, in a recent startup, when we tried to fix certain errors in the system, we went to put a load balancer in front of the IMAP server that we wrote. So that when one server crashes, the load balancer smoothly transfers the processes to another, and the clients would feel nothing.
And it seemed to us a 4-hour task.
But when we arrived at the scene, we realized / remembered that the IMAP server uses the connection state, unlike the HTTP servers we are used to. It turns out that if we want to switch to the backup server in transparent mode, we will have to manage the connection status on the two servers or write a similarity of the proxying load balancer, which would be responsible for the connection status and installed before the IMAP server.
What seemed to us a 3-month project (2).
Here is another reason why short sprints are the key to all this: they put a tight limit on the price of terribly erroneous calculations.
So what do we do? To accept the fact that all our projects are doomed to failure; that we will ruin the relationship with the rest of our clients, because we cannot fulfill our promises?
The key is to first accept the fact that it is impossible to make accurate long-term calculations. Once you realize this, you can take on the following task, which, however, is rather difficult to handle: how can you force your development team to produce tons of values, even though you cannot make more or less significant long-term calculations.
What we have come to is basically an explanation of the first principles of why the world adopted various flexible development methodologies. In more detail about this I will tell in the next topic: “Project Deadlines No! How to Make Clients Love You, Even With That You Do Not Perform Your Obligations. ”
1. (group <insert dated musical link> played on the radio, and everyone discussed <long forgotten TV show>.
2. If you think: “Wait, what about 3 months, as one of your 3-month calculations?”, Then I have no idea what you are talking about.
The translation was made as part of the Tolstoy Summer Camp start-up summer school.
But first, the story ...
It was <insert a period of time that would not make me ridiculously old> at the time when I was a young developer (1). In college, I was the best in programming classes, being a junior developer, I could crack the code and solve any problem I had before faster than anyone expected. Over the weekend I could learn a new language and work productively on it (or at least it seemed to me then).
')
Thus, as it should have happened, I had my own project. The large client manager explained to me in general terms what the client wants, we discussed this, and I said: “It will take 3 weeks to do this work.” “Good,” he answered. And so I started programming.
How do you think, how much time it took me to this project? Four weeks? Maybe five?
Um, actually: three months.
I still have clear memories of that time - my self-image was closely related to the feeling that I was a “good programmer,” in which I was very disappointed. I lost sleep, I had small panic attacks. And this was not the end. I remember that I was sucking under the spoon when talking with that manager, I explained again and again that I still have nothing to show him.
In one of these black periods, I decided that I would never make such mistakes again.
Unfortunately, in the course of my career, I learned something very difficult: I constantly make such mistakes.
In fact, I even learned something better: we all make these mistakes.
Recently, I read a book by Daniel Kaneman “ Thinking, Fast and Slow ” - an extensive study of what psychology is aware of about human cognitive processes, about his amazing strengths and (surprisingly predictable) weaknesses.
My favorite part is about Self-confidence. It showed, let's say, some connection with the way developers do calculations.
Why your calculations suck, part I: writing software = knowing something you don’t know
For a start, I believe that in reality, there are only two reasons why our calculations are so bad. The first reason, in a way that cannot be improved: writing software is a process in which you have to figure out how to describe something in incredibly precise details so that you can explain to a computer how to do it. And the problem is that in those parts that you do not fully understand at the initial stage of work, and there are difficulties that will come out and have a hard time.
And this is completely impossible to improve in any way. And only if you really “fully understand what to do,” or you have a library or there is a part of software that can do it for you, then you do not write anything. Otherwise, the unknown appears, and often it detonates. And you may not know how long it will take to solve these problems, maybe one day, one year, or you may not have enough time for the thermal death of the universe.
For example, in the case when it turns out that some involved from the development side are unreliable ... then you have to rewrite the entire array containing errors; or, when the database does not understand some critical parts of the encoding ... then you have to rebuild all your schemes from scratch; or, a real classic of the genre, when you show work to clients, but they do not accept what they ordered themselves, but they want a little bit different ... something that is much harder to do.
When you first encounter such a difficulty, you think, “From now on, you should be more attentive at the stage of developing a specification.” But this is not the best idea. Why? The main reason is that, as can be seen from the above examples, if you write the specification in such detail that you take into account all these accidents, then in fact it turns out that you are already writing software. And, really, there is no way to solve this problem (if, reading this article, you try to challenge this statement, then I will tell you - for sure, absolutely for sure, there is no way. Full specifications are a utopian economic idea. Below I will show you more favorable, from an economic point of view, options).
But this is where the fun begins. Every programmer who has worked in the real world for more than a couple of months has encountered the problems described above.
And yet ... we continue to make such impressively bad calculations.
And even worse, we believe our own calculations. I myself believe my, at the moment when I produce them.
So, wait, what am I suggesting that all developers somehow fall victim to the same, predictable mistakes in thinking?
Yes, this is exactly what I offer.
Why your calculations sucks, part II: self-confidence
Kahneman says quite a lot about the problem of "experts" making predictions. In a shockingly wide variety of situations, these predictions turn out to be completely useless. In particular, in many, very many situations, the following three statements hold true:
1- The forecasts of “experts” about any future events are so unreliable that they are essentially meaningless;
2- Nevertheless, the experts discussed are incredibly confident in the accuracy of their forecasts;
3- And the best of all: it seems that absolutely nothing can diminish this expert self-confidence;
And the last statement, truly outstanding, is that even if experts try to face their own failures honestly, even if they are deeply aware of this lack of human thinking ..., they nevertheless remain deeply confident in the accuracy of their predictions.
Here is how Kaneman explains this after telling a striking story about his own failures in this field:
"The confidence that you will feel in your future judgments will not be understated by what you have read now, even if you believed every word."
Interestingly, there are situations for which expert forecasts are quite good, and I am going to demonstrate these situations below, as well as how to use them to improve my development processes. But before doing this, I would like to go through some of the details of how erroneous self-confidence works, in practice, you may be able to find it in yourself.
What it feels like to feel that you are wrong: systems I and II, and the problem of 3 weeks and 3 months
In Thinking Fast and Slow, Kahneman explains much of psychology as an interaction between two “systems” that control our thoughts: System I and System II. My very brief summary on this subject would be: “System II is responsible for accurate, rational, analytical thinking, and System I is responsible for fast, heuristic and comparative thinking.”
And it is critical that evolution seems to have designed everything with one sole purpose — that System II should not have to do too much. Which is very logical from the point of view of evolution - System II is slow as molasses, and incredibly expensive, it should be used in very, very rare cases. But you see problems, without a doubt, without much thought, how, then, should your mind understand when to run System II? From this point of view, many of the various “cognitive distortions” of psychology can be perceived as subtle engineering solutions to such a cruel life problem, as the distribution of attention in real time.
To see how the interaction of Systems I and II can lead to truly awful, and at the same time honest and trustworthy calculations, I am going to pass the microphone for a short time to my friend (and Hut8Labs colleague) Edmund Jorgensen . He described it to me in his letter as follows:
“When I asked myself“ how long will this project take? ”System I had no idea about it, but wanted to get an answer, and recoded the question. What? I suspect that in something like "how much I am sure of myself that I can do this thing," and this, in turn, recoded into the calculation of time with a certain coefficient that is relative (for example, when Bob feels the degree of X’s confidence, he always responds 3 weeks; when Suzy feels X’s confidence, she always responds 5 weeks). ”
Raise your hand, if you gradually realize that you have two "big" time meters? For example, for me it is “3 weeks” and “3 months”. The first implies that "it seems complicated, but essentially I think I know how to do it"; the second implies: “Wow, this is difficult, I’m not quite sure that I need to do this, but I’m willing to bet that I can find out.”
Aha, I think Edmund is completely right.
(For those who spend time at home: my “3 week” projects seem to take 5-15 weeks, my “3 months” projects usually take 1-3 years, in those rare cases when someone wants to pay me for it ).
Fine! Now let's stop being so self-confident!
You might think from this point of view: “Well, I see where you're going, Dan, we need to approach these calculations in accordance with the principles of System II instead of System I. Thus, our attentive, analytical minds will make the best calculations”.
Congratulations, you just invented Waterfall.
Essentially, this is an application of a “complete specification specification prior to programming”: do not allow your team to do intuitive calculations, get everyone to accurately mobilize their analytical skills and approach the issue of detailed specifications and calculations that are divided into smaller parts.
However, this is doomed to failure. As usual…
The real problem here is the interaction between two sources of erroneous measurements: a human error in relation to one’s self-confidence, and an inherent element of uncertainty inherent in every real software development project. This uncertainty is so serious that even a careful rational System II cannot provide accurate predictions.
Fortunately, there is a way to combine the use of the strengths of thinking, and at the same time, cope with the impermanence of the real world.
First, how to use the strengths of your thinking.
When experts are right, and how to use it to your advantage
Kahneman and other researchers could determine situations where expert judgment is not completely erroneous. According to him:
“To find out if you can trust a certain intuitive judgment, you need to ask two questions: Is the environment in which the judgment takes place is constant enough to make predictions based on the available evidence? The answer is "yes" - for the Diagnostic, "no" - for the drain-picker. Do professionals have an appropriate opportunity to study signals and patterns? ”
“Appropriate opportunity” means a large number of predictions made, as well as close feedback for studying their accuracy.
Now, 6-18 monthly software writing projects do not satisfy all these criteria at all. As I said earlier, the environment is not quite “permanent.” In addition, experts do not have a combination: make a lot of predictions and get quick reviews. If something takes a year or more, then the feedback is too long to train your intuition (plus, you will need a large number of examples).
However, there is a form of calculation, applicable to software development, which is suitable - 0-12 hour tasks, if they are then immediately implemented. From this angle, things work differently:
- Although there are still many accidents (for more details see below), there is still hope for a “constancy of the environment”. Two two-hour tasks have much more in common than two six-month projects;
- You can imagine making hundreds of similar calculations in a few years;
- You get very quick feedback on the accuracy of the calculations.
From this point of view, you are using the strengths of System I - there is an opportunity to train it, it has many examples available, and it contains informative models that can be selected. And thanks to short sprint segments, you very quickly receive feedback on the quality of your calculations.
Stop, stop, stop! Let's just do a thousand 4 hour calculations!
How can I say that you can make these micro calculations, but somehow you cannot apply them to 6-18 monthly calculations? Are the error values ​​not averaged?
Essentially, although I think that calculations on a similar scale are usually correct, in the case when they are not correct, there is simply no limit to how wrong they may be. In mathematical terms, I suspect that actual times follow the distribution of a power law. And the power law distributions are known for not having a stable value and infinite dispersion, which, frankly speaking, seem to me the same calculations of the project of a large waterfall.
You may think: how is it even possible that something that can be done in 4 hours can take a month or two?
It happens all the time: you are going to move on to the final stage, but suddenly you will find out that some hidden obstacles radically change everything. For example, in a recent startup, when we tried to fix certain errors in the system, we went to put a load balancer in front of the IMAP server that we wrote. So that when one server crashes, the load balancer smoothly transfers the processes to another, and the clients would feel nothing.
And it seemed to us a 4-hour task.
But when we arrived at the scene, we realized / remembered that the IMAP server uses the connection state, unlike the HTTP servers we are used to. It turns out that if we want to switch to the backup server in transparent mode, we will have to manage the connection status on the two servers or write a similarity of the proxying load balancer, which would be responsible for the connection status and installed before the IMAP server.
What seemed to us a 3-month project (2).
Here is another reason why short sprints are the key to all this: they put a tight limit on the price of terribly erroneous calculations.
Are we in full ass?
So what do we do? To accept the fact that all our projects are doomed to failure; that we will ruin the relationship with the rest of our clients, because we cannot fulfill our promises?
The key is to first accept the fact that it is impossible to make accurate long-term calculations. Once you realize this, you can take on the following task, which, however, is rather difficult to handle: how can you force your development team to produce tons of values, even though you cannot make more or less significant long-term calculations.
What we have come to is basically an explanation of the first principles of why the world adopted various flexible development methodologies. In more detail about this I will tell in the next topic: “Project Deadlines No! How to Make Clients Love You, Even With That You Do Not Perform Your Obligations. ”
1. (group <insert dated musical link> played on the radio, and everyone discussed <long forgotten TV show>.
2. If you think: “Wait, what about 3 months, as one of your 3-month calculations?”, Then I have no idea what you are talking about.
The translation was made as part of the Tolstoy Summer Camp start-up summer school.
Source: https://habr.com/ru/post/182432/
All Articles