add interruptions

README.md

@@ -16,6 +16,12 @@ We should reduce the cognitive load in our projects as much as possible.
 
 When reading code, you put things like values of variables, control flow logic and call sequences into your head. The average person can hold roughly [four such things](https://github.com/zakirullin/cognitive-load/issues/16) in working memory. Once the cognitive load reaches this threshold, a significant effort is required to understand things.
 
+<details>
+  <summary><b>Cognitive load and interruptions</b></summary>
+  <img src="img/interruption.jpg"><br>
+  Why developers hate being interrupted
+</details>
+
 *Let's say we have been asked to make some fixes to a completely unfamiliar project. We were told that a really smart developer had contributed to it. Lots of cool architectures, fancy libraries and trendy technologies were used. In other words, **the previous author had created a high cognitive load for us.***
 
 ![Cognitive Load](/img/cognitiveloadv4.png)
@@ -23,13 +29,13 @@ When reading code, you put things like values of variables, control flow logic a
 The tricky part is that the previous author may not have experienced a high cognitive load due to familiarity with the project.
 
 <details>
-  <summary><b>Familiarity vs Simplicity, Dan North's comment</b></summary>
+  <summary><b>Familiarity vs Simplicity</b></summary>
   <br>
   The problem is that <b>familiarity is not the same as simplicity</b>. They <i>feel</i> the same — that same ease of moving through a space without much mental effort — but for very different reasons. Every “clever” (read: “self-indulgent”) and non-idiomatic trick you use incurs a learning penalty for everyone else. Once they have done that learning, then they will find working with the code less difficult. So it is hard to recognise how to simplify code that you are already familiar with. This is why I try to get “the new kid” to critique the code before they get too institutionalised!<br><br>
   It is likely that the previous author(s) created this huge mess one tiny increment at a time, not all at once. So you are the first person who has ever had to try to make sense of it all at once.<br><br>
   In my class I describe a sprawling SQL stored procedure we were looking at one day, with hundreds of lines of conditionals in a huge WHERE clause. Someone asked how anyone could have let it get this bad. I told them: “When there are only 2 or 3 conditionals, adding another one doesn’t make any difference. By the time there are 20 or 30 conditionals, adding another one doesn’t make any difference!”<br><br>
   There is no “simplifying force” acting on the code base other than deliberate choices that you make. Simplifying takes effort, and people are too often in a hurry.<br><br>
-  <i>Thanks to <a href="https://dannorth.net">Dan North</a> for sharing his ideas.</i><br><br>
+  <i>Thanks to <a href="https://dannorth.net">Dan North</a> for his comment.</i><br><br>
   <blockquote>Once you onboard new people on your project, try to measure the amount of confusion they have (pair programming may help). If they're confused for more than ~40 minutes in a row - you've got things to improve.</blockquote>
 </details>