Applying the lessons of Learning How to Learn to Software Development

How to apply the lessons learned from Coursera course “Learning How To Learn” (LHTL) [1] — to Software Development (SD), especially the practices from Agile Software Development [2].

SD involves a lot of problem solving so it seems natural that the lessons and tips from LHTL are directly applicable to SD — the techniques related to shifting between Focused and Diffuse modes of thinking seems particularly applicable.


My own experience the technique of working intensely in debugging a bug and then going off to sleep on it to discover the fix the next morning when my mind is fresh now seems to have a solid scientific basis. [3]

It’s the sleep that allows my mind to shift from the FOCUSED mode where I’m tracing the program logic trying to find where the software went wrong to the DIFFUSE mode where I allow my mind to work on it subconsciously to make serendipitous connections that help me find the bug or improve my understanding of the code and make progress towards fixing the bug.

I’ve also learned from LHTL the importance of sleep in removing toxins [4] and putting our minds in the diffuse mode really helps a lot in coming up with novel and innovative solutions — bashing our brains on a problem using the focused mode needs to be augmented by diffuse mode thinking and relaxation in order to make good software designs or find and fix seemingly hard bugs.

This gives me more ammunition to my long held beliefs about working longer hours in software development projects (and cutting down on sleep in the process) to meet hard deadlines (which is a specially common practice in SD) actually creates bad software [5]. Developers and other members of the software development team need sleep in order to come up with good software.

This is specially important to counter the SD penchant for “hero programmers” who work for 36 hours straight to deliver something before collapsing. I know this, because I’ve done it myself lots of times through out my career.

Another counter-productive practice in addition to this practice of working overly long hours is the accompanying stress brought upon by impossible deadlines. In the SD industry, these projects are fairly prevalent that there is a term for them: “death march” projects [6].

The lesson from LHTL is that too much stress, anger, and fear have been clearly established to prevent the brain from focusing and therefore prevents the learning and creative problem solving that is needed in order to build good quality software [7]. As a result, many “death march” projects are doomed not only by delays but also by the poor quality of the software delivered [8].

One of the practices in Agile Software Development called Sustainable Pace was, in part, created to mitigate stressful situations where stress is managed in order to allow the team to be productive[9]. Sustainable Pace basically means that the team should work in a manner that allows them to work at that pace indefinitely — a repetitive consistent pace that allows stress to be managed to productive levels.


In SD, debugging is one of the hardest parts of programming — figuring out what went wrong in big program from the symptoms it displays is akin to finding a needle in a haystack — but once you’ve found it, fixing it is usually easy.[10]

Usually the process involves tracing the logical path that a program takes — more often than not its usually a program you didn’t write (or may have written months ago and have already forgotten about) — and trying to understand how its supposed to work — the bug usually occurs when how it actually written is different from how its supposed to work.

Figuring where this is occurring is the first part of debugging. Usually bugs occur in just one or two lines of code. Finding that line or lines of code that need to be changed can take anywhere from a few minutes to days or even weeks (in really hard bugs) and is responsible for much of why SD is expensive, hard to do and hard to predict (when it will be finished).[11]

Using the LHTL techniques regarding the FOCUSED and DIFFUSE modes will I think lead to major improvements in the speed at which we can improve the programmers’ debugging skills and fix bugs faster.


One of the recommended SD practices is to write tests first before implementing the actual code — this seems to tie in with the DIFFUSE mode concept of learning the CONTEXT — the road map of the field — before delving into the details.

Writing the tests first allows us to develop the BIG PICTURE of what the code is suppose to do before getting FOCUSED on implementing the details. This practice of writing the tests first in order to inform the implementation is known in Agile Software Development as Test FIRST Development or TFD[12]. Ha! — now I have a solid scientific basis for this practice and should make it easier for me to convince skeptics to adopt the practice.


Another practice that LHTL encourages is to work with groups in order to enhance our learning. For one thing, working in groups allows us to ask each other our understanding of the topic and helps us get unstuck in our learning (which happens a lot when you’re trying to learn a new topic).[13]

In SD, this encouragement towards group work to enhance learning is enshrined in practices such as Paired Programming where two people collaborate in fixing a bug or implementing a new feature [14].

It allows one person (known as the DRIVER) to be in the FOCUSED mode while the other (known as the NAVIGATOR) is in the BIG PICTURE mode and can interrupt the DRIVER to ask about why he’s doing something in a particular way and is helpful in preventing EINSTELLUNG.

EINSTELLUNG is the blocking of new learning or new way of solving the problem because of the brain being stuck in a particular pattern of thought that may be erroneous or just sticky because of the brain’s natural tendency to follow familiar patterns of thought when it is in the FOCUSED mode [15]. Building software in this way allows the programmers to discuss the work and can help the DRIVER defocus on possible blind alleys and try alternative ways of writing the program.

Another practice where group work and learning occurs is in the Agile Software Development Practice (specifically in SCRUM) in the Sprint Planning (Part II) [16] where the team (as a group) discuss the items they have to work on for the Sprint (a period of two weeks where they have to deliver an increment of the software functionality they are building)[17]. Here, they discuss and brainstorm as group — again this helps develop the BIG PICTURE context and prevent EINSTELLUNG before each team member goes in and FOCUSES on the individual items that they start working on in the duration of the Sprint.


One of the important practices in SD is called REFACTORING — the practice of reorganizing the code in order to make it more understandable [18]. One of the HARDEST barriers to making software MAINTAINABLE (that is, software that is easy to modify to add new features to, or software where it easy to locate and fix bugs on) is the programmers inability to comprehend what the program is doing [19]. Refactoring is reorganizing the code in order to make it easy for others (including yourself) to understand.

The way to organize code in order to make it easy to understand is to create small well-integrated pieces of code (called objects) that form larger objects [20]. Once you create an object — it becomes a CHUNK in your library — you’re no longer focused on the object’s internals — instead you become focused on it as a whole and it joins other objects in your library. You then use those objects in your library to form ever larger chunks or objects.

This resonates well in LHTL regarding concepts on how we form and use CHUNKs in our learning and how in order to gain mastery in a field, we need to build a library of chunks or concepts that we can combine in new ways to build or understand new concepts [21]. Similarly, libraries of objects allow us to combine these objects creatively in order to build better software.


One of the most important practices for improving the quality of software is known as Test Driven Development or TDD [22]. It combines the practice of writing tests first (Test First Development or TFD) and Refactoring (or reorganizing the code in order to make it more maintainable). I find that those two practices seems to be resonate with LHTL techniques regarding building the CONTEXT (BIG PICTURE or ROAD MAP) before delving into the details — as well as the process of CHUNKING (bottom up organization of bits and pieces into meaningful concepts and into useful libraries).


I’m pretty sure that with more time, I can unearth more useful practices I’ve learned in my LHTL class that I can apply to improve the way we build software. I hope I can inspire software developers to take a look at LHTL and help them learn to become better developers and learners.


[1] Learning How to Learn (LHTL) — Coursera —

[2] Agile Software Development —

[3] Importance of Sleep in Learning — video lecture from LHTL — Coursera —

[4] The role of sleep in removing toxins from the Brain — video lecture from LHTL — Coursera —

[5] Are long hours and no benefits the norm for a junior programmer? —

[6] Death March (project management) —

[7] Learning is impaired by anger, stress and fear — video lecture from LHTL — Coursera —

[8] Death March —

[9] Sustainable Pace —

[10]Debugging is like finding a needle in a haystack —

[11] Why is software estimation hard? —

[12] Test First Development —

[13] Turning Student Groups into Effective Teams by Richard Felder, Barbara Oakley, et al. —

[14] Pair Programming —

[15] Overlearning,choking, Einstellung and interleaving — video lecture from LHTL — Coursera -

[16] Sprint Planning Part II —

[17] Sprint —

[18] Refactoring —

[19] How to create maintainable software —

[20] Object Oriented Programming —

[21] The value of a library of chunks — video lecture from LHTL — Coursera —

[22] Test Driven Development —

Show your support

Clapping shows how much you appreciated Butch Landingin’s story.