Sessions is temporarily moving to YouTube, check out all our new videos here.

Hacking Your Head: Managing Information Overload

Jo Pearce speaking at Front-End London in April, 2016
Great talks, fired to your inbox đź‘Ś
No junk, no spam, just great talks. Unsubscribe any time.

About this talk

There are limits on our ability to learn and process information. Overloading ourselves with information can impact productivity by causing psychological and physiological stress. In this talk Jo will relate some findings from the world of cognitive psychology that can help us understand how, as developers, we might be overloading ourselves.


[00:00:10] My name is Jo Pearce. I’m non-binary. I’m a developer and consider myself a science womble. That is, I’m not an academic but I love to learn about a wide range of sciences and see if I can make good use of the things that I find. Recently, I’m been wombling around the field of cognitive psychology and I want to use it to explain some ways we can manage information overload. [00:00:35] What is information overload? Why do we need to manage it? Well, in 1970, futurist Alvin Toffler popularised the term, “Information Overload” in his book Future Shock. He considered the book a thesis on surviving the collision with tomorrow. In it, he wrote that there are discoverable limits to the amount of change that the human organism can absorb and that by accelerating change without first determining these limits, we may submit masses of people to the demands that they simply cannot tolerate. We might submit them to information overload. Among the symptoms Toffler described to it were: anxiety, hostility, apathy, physical illness, depression, and even senseless violence. Experimental psychology uses the term “orientation response” for our reaction to change or novelty. It’s also sometimes called, “Startle reaction”. Our pupils dilate, hearing becomes more acute, our muscles tense, blood rushes to the head, and our breathing and heart rate alter. The examples Toffler used to illustrate the effects of overloading the orientation response came from stories of extreme environments, like the battlefields of WWII, where a soldier falls asleep while a storm of machine gun bullets splattered around him. Not due to physical tiredness, but a sense of overpowering apathy. Soldiers became hyper sensitive and would hit the dirt at the slightest stimuli, increasingly showing anxiety and anger at the slightest inconvenience. [00:02:10] The source of overwhelming stimuli in extreme situations is clear, but what about here, now? Where there are no bullets or glass flying through the air around us. Toffler went on to say that the orientation response occurs not merely in response to simple sensory inputs, it happens when we come across novel ideas or information. Are we really faced with an overwhelming amount of new information 46 years later? 20 million words of new technical information are recorded each day. At a thousand words a minute, reading for eight hours a day, this is six weeks’ worth of reading. After reading the information without one day you would have fallen behind by five and a half years of reading. These statistics are from 2001. Toffler seems even more prescient as there is now a medically recognised condition called, “Information Fatigued Syndrome.” With symptoms that include: Hurry Sickness, the belief that one must constantly rush to keep pace with time and basic hostility, the chronic state of irritability or near anger or even rage. These might sound familiar. I believe we see evidence of information fatigue all around us. This is just a small sample which I think illustrates that symptom of pervasive hostility. The sad state of web development, random thoughts on web developments going to shit. 2015 is when web development went to shit. Programming sucks and why I quit. My own personal favourite, “A lot of work is done on the internet and the internet is its own special hellscape.” Remember that stuff about crazy people and bad code? The internet is that, except it’s literally a billion times worse. Take a look at how many tech blog writers use the word “rant” in the blog title as well. How might we, as developers, be overloading ourselves. Let’s look at front-end web development as an example. There has been a huge growth in the number of frameworks and tools. This means that it’s not only hard to keep up with what’s out there but that no one can know everything. If you ever work on a project with multiple unfamiliar tools and frameworks, information overload is a risk. Development is always going to be a learning process because there’s always a lot to learn. Perhaps that means that we can manage information overload by managing how we learn. [00:04:50] It helps to understand a little bit about how we learn in order to hack the process. The two partners of human learning are our working memory and long-term memory. Working memory is where we process information, it’s the site of our active, conscious thinking and learning processes and comprises visual and auditory subcomponents. Long-term memory has enormous capacity but cannot engage in conscious thinking or learning processes. They work together. Learning takes place in working memory and the results are stored in long-term memory. I want to briefly outline three of the main processes that we can hack to alter the way we learn. Attention, elaboration rehearsal, and encoding. Attention is critical to processing information. To illustrate how critical, in 1972, an eastern airlines flight crashed as a result of cockpit distractions. The crew became so preoccupied with a malfunction that no one noticed the altimeter warnings until it was too late. We can help focus attention with cues and signals. For example, bullet points, paragraphs and headings, visual indicators, like a great big red arrow, even signalling language, like, “It is important to note that.” We can also help focus attention by leveraging both the visual and auditory components of the working memory at once. As I’ve done here, giving you a diagram to focus on visually while I describe what it represents. This is called, “The Modality Effect.” Elaboration rehearsal helps promote automaticity, this is a mechanism that allows us to largely bypass working memory. Skills that are repeated often enough become established in long-term memory and can subsecuently be performed with little or no working memory resources, such as: Writing, reading, and speaking. When we encode information we create schemas, these are memory structures that allow us to treat a large number of information elements as though they’re a single element. We have schemas for everything. For example, while all trees are different and include an enormous amount of sensory information, we instantly recognise a tree because we have a schema for trees. Schemas are constructed additively. For a novice learner, every new thing is unconnected and must be managed separately, but as we gain experience, we form connections between the bits of information in our head, allowing us to treat these collections as single schemas. There are limits on our ability to learn. [00:07:47] Back in 1956, cognitive psychologist George A. Miller investigated these limits on our ability to process information. You may have come across Miller’s Law, the magical number seven, plus or minus two. Miller’s research suggests that there’s a definable limit on the amount of information we can usefully process in our working memory at any one time, but when that limit’s exceeded information overload leads to our learning becoming inefficient, if it even remains working at all. Some web designers have used Miller’s Law as justification for only putting seven or fewer things on a page. This is a misinterpretation. It wasn’t the number of things that was the important results but the fact that there was always a limit. We now equate the things, themselves, to the schemas I mentioned earlier. Someone with experience who has more connected schemas would be able to handle more complex information in working memory at once. How do we use the result of Miller’s research? Well, in the late 1980s John Sweller, an Australian educational psychologist, asked what we can do to learn more efficiently, given the limitations that Miller defined. Yes, that’s the journal that he published it in, if you’re interested. His research led to cognitive load theory. [00:09:07] What is cognitive load theory? Very simply, it defines cognitive load as a total amount of mental effort being used in the working memory and describes a universal set of evidence-based principals for managing cognitive load that lead to more efficient learning. I want to give you a brief overview of the core concepts. Total cognitive load is comprised of three types: Intrinsic load, extraneous or irrelevant load, and germane or relevant load. Intrinsic load is imposed by the complexity of the task being performed. Learning to juggle with ten balls is more complex than learning with three. We can only reduce intrinsic load by juggling fewer balls. In other words, if you’re faced with a large complex task, we want to break it up into smaller ones, we can then tackle these individually. You might be familiar with the agile hierarchy, where we define a high level epic which we then break down into user stories, which we then further break down into individual tasks. Estimating an epic would impose an extremely high intrinsic load. Estimating user stories or tasks should be more manageable. Extraneous or irrelevant load is imposed by distractions or tasks that are irrelevant to the goal. These could be noise distractions, needing to learn an unfamiliar tool or set of tools, or trying to decipher code that’s unreadable or difficult to follow. To manage irrelevant load, we can try working in a quieter environment or wearing headphones. Try reducing the number of tools so or libraries we use to a minimum. There’s actually a growing movement originating from Keith’s circle to use NPM scrips alone for front-end task running, thus eliminating grunt goal and Webpack. Make sure that the code we write is readable. Never forget that the person unable to decipher your code might be future you. We can do this by using better cues and signals in our code. It might not be immediate obvious that this function does two distinct tasks. The null check and throwing the exception for procreates and the actual work itself. By adding appropriate white space and line breaks, we cue the developer with the information that there are two distinct tasks here. Comments are also important to use wisely, as Jeff Atwood distinctly puts it, “Code tells you how; comments tell you why”. Don’t let anyone suggest to you that good code should be self-commenting. Good comments signal that all is not as straight forward as it might appear. This reduce the load on anyone trying to maintain your code. If you’ve ever spent more time than expected wondering why a section of code doesn’t do what it looks like it should do, you may understand what I mean. Consistency is also important to reduce load. Style performance tools can help without having to impose the extra load of learning a style guide. How many times have you seen a style guide that’s gathered dusk due to the extra effort required to maintain or learn it? By reducing irrelevant tasks and distractions, we focus attention. Germane or relevant load is a beneficial load. It’s imposed by tasks that are relevant to our overall goal. It helps us to connects bits of information and for more complex schemas. Repetition and context variation can give us the skills to apply knowledge in a wider variety of situation. By repetition, I mean practice. Schemas need reinforcing the repeated recall in usage. This makes them easier for the working memory to retrieve and process. You can vary the context by seeking out multiple sources of information. There is no such thing at the definitive tree. It might be that only after seeing something expressed in five different contexts that you’re able to confidently recognise it yourself in a sixth. This might be easy to understand if I give an example in different context. Say the goal of a developer is to better understand an existing code base. This might include understanding the framework that has been used, particularly if it’s nuanced. We might assist that goal by varying the areas of the code base that they’re assigned to work on, until they can competently develop a feature from scratch. We can also develop more flexible schemas through pairing. It can help us discover varied approaches and methods we haven’t yet encoded within our own schemas. This can also leverage both subcomponents of the working memory, auditory and visual. Particularly if you have one person visually examining the code while another person is explaining what it’s doing. Germane or relevant load helps us elaborate and rehears existing schemas, encode new information, and if we’re lucky, promote automaticity. To sum up, we constantly need to learn. Cognitive psychology can tell us how we learn but it also tells us that there are limits to our ability to learn. Cognitive load theory can help us work within those limits, giving us a set of guiding evidence-based principals. If we manage intrinsic load by breaking large tasks into smaller one, reduce extraneous load by eliminating irrelevant tasks and distractions, and increase relevant load with appropriate repetition and varied learning context we promote efficient learning, improved productivity, and escape the horrors of information overload. Thank you.