“Learning How To Learn” (LHTL), an online course freely available on Coursera, teaches techniques for becoming a better learner and thinker. Given by Dr Barbara Oakley (McMaster University) and Dr Terrence Sejnowski (University of California San Diego), the course covers the latest on how the brain works and suggests practices to make the best it.

Many of these practices are covered in numerous popular self-improvement books and you may be familiar with some of them, but it was great to have them collected in a single place, including explanations on why they work. Here are some that resonated the most with me.

Focused & Diffuse Modes

Keeping focused on a single task for hours ends up working against you. The brain needs time away to form new connections and get a sense of the big picture. Going against that flow will likely hinder your progress and leave you exhausted at the end of the day.

The evidence suggests that the brain works in either of two modes, which the instructors call “focused” and “diffuse”. In focused mode you concentrate on your task at hand, while in the diffuse mode you let go and give your mind a break; this is the kind of thinking you do when you are not consciously thinking, like when you go for a walk or take a shower. If you have ever enjoyed flashes of insights that came during such activities, it was probably diffuse mode at work.

I couldn’t help drawing obvious parallels with the rich vs linear modes of thinking described by Betty Edwards in “Drawing on the Right Side of the Brain“, and also neatly summarized by Andy Hunt in “Pragmatic Thinking and Learning“. It is obviously the explanation for techniques used by unusually creative people like Thomas Edison or Salvador Dali, who would take a nap and figured out tricks to wake up just at the onset of dreams; whatever they were thinking at that moment was probably the output of the diffuse mode. I believe Andy Hunt called that technique an “onar”, a portmanteau of oniric (which pertains to dreams) and sonar.

Deliberate practice

You might be familiar with the idea that it takes roughly 10’000 hours of practice to become a world-class expert at anything. Malcolm Gladwell is generally credited with popularizing this idea in his book “Outliers“, but later research has qualified this idea. As pointed out by Geoff Colvin in “Talent Is Overrated“, by Anders Ericsson in “Peak“, and by many others, any random kind of practice is not enough. Merely repeating the same skill over and over won’t do; one needs to be intentional, even deliberate about one’s practice. Hence the name Deliberate Practice.

I suspect that Deliberate Practice is far easier to apply in sports or arts than in knowledge work. Most sports and most arts have a long teaching tradition—there are moves, techniques, steps, swings, katas, scales, chords, chess tactics, strokes that can be practiced over and over again, often under a coach’s supervision. Identifying your weaknesses, and developing a workout routine to address them, seems to me to be far easier in, say, freestyle swimming than in computer programming.

So I’m not so sure how to best apply Deliberate Practice when learning a new subject such as mathematics, physics, computer programming, or any similar mostly-intellectual topic. I’m not sure there exists a body of, say, mathematical drills one can perform in order to become better at it. Computer programming might be an exception here: people (including me) have experimented with so-called code katas, where you solve (sometimes repeatedly) some programming problem. But that’s the closest thing to Deliberate Practice we have to date.

Procrastination

The course explains that procrastination is the brain’s natural defense mechanism against unpleasant tasks, such as sitting down to study. A valuable technique against this is the Pomodoro technique: you make a deal with yourself that you will only work for 25 minutes, then take a break. You might even bribe your brain with the promise of some treat after work: perhaps some social media time, or reddit, or twitter. (A very similar idea was proposed in The Power of Now.)

I’ve been using variations on the Pomodoro technique for many years now (I was introduced to it by the book of the same name published by the Pragmatic Programmers). I regularly work in 25 minute bursts, punctuated by 5 min breaks. During the breaks, I will frequently walk around, perhaps fetch fruit from the cafeteria three floors upstairs, or visit the bathroom. Of late I’ve experimented with the use of Brain.fm, setting their timer to 30 minutes. I find this very effective at improving my focus and blocking out distractions from the surrounding open space.

Metaphors

Metaphors are said to be a great way to internalize what you learn, though I don’t think I use that technique very much in my own learning. I have, however, been told that I’m pretty good at using metaphors and analogies when I explain technical concepts to a non-technical audience. Recently I’ve been working on a statistical model of the effectiveness of calls to action sent to customers, using a class of models called Survival Analysis. Originally developed to model the survival of patients in a clinical setting, it was rather easy to build the right metaphors: an email you send to your customer gives “birth” in his mind to a certain inclination to do something; that inclination can either “die” when it is acted upon, or “live on” forever if the customer never does anything about it. That kind of metaphor made it easy to communicate the gist of a highly technical subject.

Self-testing

When you sit down and study something, you will frequently end the study session overestimating what you’ve really internalized. This is also known as the illusion of competence. The best defense against this, and also a great way to consolidate what you have learned, is to test yourself: not only right after the course, but also at regular intervals thereafter. This is sometimes called Spaced Repetition.

Self-testing is, indeed, why the Cornell system of note taking works so well: you’re supposed to summarize, in your own words, the content of your notes at the end of the note-taking session. Recently I came across a fine piece on Medium by Robyn Scott who tells of a habit consisting of spending 30 seconds (not more, not less) after every important event in your life, writing down your own summary of the event.

Sleep

Nobody questions the benefits of sleep on thinking and learning, so I won’t berate the point. But the instructors included a little nugget of wisdom: before you go to sleep, they recommend going over your current to-do list (or personal kanban board, which is the only system that ever worked for me) and select 3-5 items that you commit to doing the next day. That way your brain won’t worry about what to do the next day; your “to-do” will be sitting there ready for you, and your brain will have more freedom to mull over more important things while you sleep—such as internalizing what you’ve learned during the day.

Conclusion

I don’t have time to cover all the tips and tricks, so I’ll have to stop here. The course is not over yet but I’m thoroughly enjoying it. There’s some material that I was already more or less aware of, and it’s great to review it again (spaced repetition, remember?) But there’s also plenty of genuinely new material, and I appreciate having it presented in such a clear and lucid manner by the instructors.

My son Nathan made this:

We made it by following the first project in the book 3D Game Programming for Kids by Chris Strom.

Adam Tornhill’s Your Code as a Crime Scene (YCAACS) has lain open next to my laptop for several months now. I’m usually a fast reader and a technical book rarely lasts that long, unless the book is crammed with practical tips and advice that I want to try as I go along. YCAACS is no exception.

The book introduces a technique completely new to me: the mining of your code repository’s history for patterns known to correlate with code defects. For example, do the most complex modules in your project tend to become even more complex over time, suggesting that your technical debt is growing out of control? Each self-contained chapter presents a different analysis you can try out. In this post I will walk through the most simple example: correlating the number of revisions to a module with that module’s complexity.

I’ll start with one of our current internal project called romulus. We begin the analysis by extracting the repository log for the last two months, formatted in a way to make the analysis easier:

git log --pretty=format:'[%h] %aN %ad %s' --date=short --numstat --after=2016-05-01 > romulus.log

The key argument here is --numstat: this reports the number of lines added or deleted for each file. It will tell us how frequently a given file, or module, has changed during that reporting period.

Next we use the code-maat tool written by the author of YCAACS. It’s a tool that will analyse the log of a code repository and extract different summary statistics. For our example, all we want to know is how frequently each module has been changed:

maat -l romulus.log -c git -a revisions > romulus_revs.csv

Next we need to correlate those changes with the complexity of each file. We won’t be using any fancy complexity metric here: the number of lines of code will suffice. We use cloc:

cloc * --by-file --csv --quiet > romulus_sizes.csv

We now have two CSV files:

• romulus_revs.csv: the number of revisions of each file in our repository
• romulus_sizes.csv: the size of each file

By doing the equivalent of a SQL JOIN on these files, you obtain for each file its number of revisions and size. You can do this in the analysis tool of your choice. I do it in Tableau and show the result as a heatmap, where each rectangle represents a module. The size of the rectangle is proportional to the size, or complexity, of the module and its color darkness is proportional to the number of times it has changed over time. With Tableau you can hover over any of these rectangles and a window will pop-up, giving detailed information about that module:

So what does this heatmap tell me? There’s no obvious outlier here; a couple of modules in the upper right corner have recently seen a lot of change, but I know that these modules implement some of the stories we are currently working on so no surprise there. This map has, however, a tendency to become darker towards the left side, where the largest modules are shown. This suggests that some modules have been growing over time, possibly out of control. Clearly, this must be investigated and these modules should perhaps deserve more testing and/or refactoring than the average.

“Your Code as a Crime Scene” is a fantastic book. Every chapter has a couple of ideas that you can try right away on your project. I suspect this will be of most value to technical leads and testers, both of whom I consider the guardians of code quality. I’m less sure that the other developers will be able to apply the ideas from the book that easily though. Doing it properly does take time, requires a certain mindset, and a certain familiarity with data analytics. But if your team includes someone willing and capable of doing it, I’m sure you will all benefit from it.

Once you publish a paper in a journal, you are expected to regularly review papers for that journal. It’s part of the normal scientific process. Some may consider it a chore, but I see it as an opportunity to keep in touch with my field and to help quality papers get published.

When I was first asked to review a paper there was very little help available on the subject. Things have considerably improved since; for example, Elsevier maintains an Elsevier for Reviewers website with plenty of information. I recommend you start there for some basic reviewer training. But the last time I checked, that site would not yet tell you anything about how to read a paper or how to actually write a reviewer report.

Here is a workflow that works for me. Once I receive a reviewer invitation, here’s what I do:

Accept a reviewer invitation immediately

The whole scientific process depends on reliable and speedy reviewers. Do unto others as you would have them do to you. When I am invited to review an article, that takes priority over any other writing.

I usually read articles as PDF on my iPad, with the GoodReader app. I immediately accept reviewer invitations and download the PDF version of the article, save it to an iCould folder where GoodReader can find it, and download it to my iPad.

Read a first time generously

As soon as possible I read through the article, from beginning to end. Ideally in a single sitting, but if that’s not possible I do it in several. The goal is to form a general idea of what the article is about, how it is structured, and to prime my mind for what to look out for on the next reading.

Read a second time more critically

Next I re-read the article, but far slower and more critically. This is where I use GoodReader’s annotation tools: I highlight passages that I think need to be mentioned in my report; I strike through passages that I think can be omitted; I underline with squiggly lines passages that don’t read well and deserve to be changed. Sometimes I add a comment box summarising a point I don’t want to forget in my report.

When I highlight a passage I seldom record why I highlighted them. If I cannot remember why I highlighted a passage by the time I write the report, it probably wasn’t important.

Write the report

I don’t know how it goes for other journals, but the one I review most frequently for (Energy & Buildings) provides the reviewer with a free-form text field in which to enter their observations. (There is also a text form for private comments to the editor, but I seldom use that.) It’s important to realise that the comments from all the reviewers will be collated together and sent to the author, and sometimes also to the reviewers to notify them of the editor’s decision.

You can also include supplementary files with your review. The only time I’ve found this useful was when I needed to typeset mathematics in my review. However, I discovered that the supplementary files are not forwarded to the other reviewers, and I now avoid them.

Your report will therefore be written in plain text. I try to stick to the following template:

<express thanks and congratulations for the paper>

<summarise the paper’s main points>

<if there are major concerns about the paper, enumerate them here as a numbered list, most important ones first>

<for each section of the paper, enumerate the other (minor) suggestions/remarks as a numbered list, in the order in which they are found in the paper>

Keep in mind that the author will be required to respond to each of the reviewer’s comments. If you provide them in a numbered list you make life simpler for them.

When I write the report I go through each of my annotations, one by one, and write a comment for each of them, either to the list of minor comments or to the major ones. By the time I reach the end of the paper, all my annotations will have a corresponding comment.

I write my report in Markdown with Vim. That way I do not need to worry about getting the numbering of the comments correct; I am free to re-order my comments, especially the ones that deal with major concerns, so that the most important ones come first. When I am satisfied I run the report through pandoc, and generate a text file:

pandoc -o %:r.txt %

After a final check I copy/paste the contents of that text file into the review submission platform.

Language issues

To this day I’m not sure whether the reviewer or the editor is responsible for fixing typos or other language errors. These days I tend to skip them, unless I find sentences whose meaning has become completely obscure. Otherwise I usually add to my list of major concerns a sentence such as:

There are many typos and grammatical mistakes throughout the paper. For example the last sentence of the first paragraph of the Introduction reads as follows:

> … that allows for a more active participation of the demand side in the operation a control task of the power system.

or even:

The language quality of this paper does not meet the standards for
an international journal, and I found the paper very hard to follow.

In general I do not try to reformulate any passages. For many authors, English is a second language and I appreciate how hard it can be to communicate with clarity, even for native speakers. When necessary I might suggest that the authors have the paper reviewed by a native speaker.

Summary

That, in a nutshell, how I review papers. I know it can feel like a chore, but I strongly encourage you to participate in the process. I hope this workflow might help you get started. If you have any comments, I’d love to hear them.

We are involved in DEBORAH, a Eurostars project nr E!10286,  led by EQUA Simulation AB, the vendor of the highly regarded IDA ICE building simulation software. Together with CSEM and Bengt Dahlgren AB, a Swedish consultancy firm specialised in buildings, the project’s stated objective is to optimise the design and operation of district thermal energy systems.

We held the project’s kick-off meeting on Thursday 16th June, 2016, in EQUA’s offices in Stockholm. Neurobat’s role in the project will consist in providing short- and long-term estimates of heating loads, and to extend IDA ICE with the Neurobat control algorithms.

A pilot site has been identified in Krokslätt, a district in the city of Göteborg, where heating to several buildings is provided by heat pumps combined with a system of boreholes: narrow shafts drilled through the rocky ground, where the water fed to the heat pumps have their temperature raised by the surrounding heat. Besides “pre-heating” the water, this also has the benefit of improving the heat pump’s coefficient of performance (COP). But few studies have been done regarding the optimal design (and operation) of such a system of boreholes, a negligence that this project hopes to address.

This 3-year long project is a great opportunity for us to work with some of the domain’s thought leaders, and to integrate IDA ICE in our own product development workflow.

The big problem with Building Science is that we call it Building Science.

The academic study of buildings and their inhabitants is a young discipline; possibly even younger than Computer Science. The earliest articles in Building and Environment appear to date from 1966; Building Research & Information, from 1973. Like Computer Science, we have no single word for our field and are stuck with a compound. Most people seem content with Building Science, or perhaps Building Physics. The former has even been enshrined in a Wikipedia article.

But I dislike “Building Science”. I think it neither conveys the breadth of our field (ranging from the study of individual households to the optimal planning of cities) nor its depth. I find it to be both too vague and not specific enough.

But what, then, shall we call the study and science of buildings? Chemists study chemistry; biologists study biology; geologists study geology; is there an -ology that would describe our field?

I asked that question on English Language & Usage (one of my favorite Stack Exchange sites, by the way). My question didn’t quite get the attention I hoped for. I was expecting someone would come up with a nice-sounding greek root to which we could affix -ology and have a proper term, but the best we could come up with is the following:

• Oikosology, from Oikos, “house, dwelling place, habitation”
• Weikology, from the Indo-European root weik (house)

I admit I am less than enthusiastic about them. I have to confess that another reason why I started this inquiry was that, just as there’s such a thing as Computational Chemistry and Computational Biology, I wanted a two-word phrase that would mean the application of computing techniques to the study and science of buildings. But I doubt we will be seeing the Journal of Computational Oikosology anytime soon…

If you have any better proposals, feel free to post them in the comments.

I’m pleased to report that CARNOT, the Simulink library of models for HVAC systems, has now an official home. You can find it by visiting its page on the MATLAB Central. On that page you will also find a link to the official releases, hosted by the Aachen University of Applied Sciences.

HVAC systems, in spite of their importance in the global energy supply and demand, remain poorly underrepresented for the MATLAB & Simulink platform. This is a problem to us (at Neurobat) because we develop new HVAC control algorithms, and few simulation environments exist that will let you define new control schemes. MATLAB & Simulink offers us the flexibility we need, but we were not able to find a well-regarded library of models for buildings and HVAC systems, until we were introduced to CARNOT.

We’re very glad that CARNOT is now back in the public light and look forward to its continued development and success.

I’ve uncovered evidence that Linus Torvalds, creator of Linux, may entertain a secret hobby.

An interview of Linus Torvalds in a recent issue of IEEE Spectrum had the following passage:

I’d rather make a decision that turns out to be wrong later than waffle about possible alternatives for too long.

On the surface, this sounds like your usual admonition against analysis paralysis (Wikipedia). But what Linus said echoes something that Alexander Kotov (Wikipedia), former chess grandmaster, wrote in 1971 in his Thinking like a Grandmaster (Amazon):

Better to suffer the consequences of an oversight than suffer from foolish and panicky disorder in analysis.

If I didn’t know better I would conclude that the same person wrote these two passages.

When you just fix a programming bug quickly, you lose. You waste a previous opportunity to think and reflect on what led to this error, and to improve as a craftsman.

Some time ago, I discovered a bug. The firmware was crashing, seemingly at random. It was eventually resolved, the fix reviewed and tested, and temptation was high to just leave it at that and get on with what was next on the backlog.

This is probably how most programmers work. But it’s probably wrong. Here’s Douglas Crockford on the topic, interviewed by Scott Hanselman:

There’s a lot of Groundhog’s Day in the way that we work. One thing you can do is, every time you make a mistake, write it down. Keep a bug journal.

I wanted to give it a try. So what follows is my best recollection of how I solved the bug.

First, the observations. You cannot be a successful debugger if you are not a successful observer. My firmware wasn’t quite crashing at random. It would crash and reboot 18 times in very quick succession (less than a few minutes) following a firmware update. Once this tantrum was over it would behave normally again.

It was a new firmware version. The same firmware had been deployed on other devices, but without the same problem. So why should it happen on some devices but not all of them?

There are some useful heuristics to keep in mind when debugging. I’ve said it before, but if you don’t observe carefully and keep notes, you’re just not a good debugger. I’ve found the following heuristics useful when debugging:

1. What changed between this release and the previous one?
2. What is different between this environment and another where the failure doesn’t occur?
3. Carefully go through whatever logfiles you may have. Document anything you notice.
4. How often does the failure happen? Any discernible pattern?

In this case, the software changes introduced by this release were relatively minor and I judged it unlikely that those changes were the cause of the problem. If they were, I would expect to see the same problem on all devices.

Now when I say that something is “unlikely”, I mean of course that there must be something else that is more likely to be the real explanation. Nothing is ever unlikely by itself, and if you can remove feelings from your day-to-day work you’ll be a better engineer. But more on this in another post.

I next examined the logfiles, and noticed that the first recorded crash was not a crash. It was the normal system reboot when a new firmware was installed. The second crash was not a crash either. It was a factory reset of the system, performed by the person who updated the system to the new firmware. It’s an operation that can only be done manually, and the only crashing device was the one that had been factory-reset right after the firmware update.

So someone had logged into that device and factory-reset the system. Going through the /var/log/auth logfiles I could determine who had done it. When confronted, he confirmed that he had reset the system in order to try an improved version of our heating schedule detection algorithm.

Now there’s nothing wrong with that; but it’s well-known that bugs are more likely in the largest, most recently changed modules. The module doing heating schedule detection was relatively large, complex, and recently changed.

Now experience had shown that only two events could cause the firmware to crash and reboot:

• a watchdog reset;
• a failed assertion.

(A watchdog is a countdown timer that will reboot the system after a given timeout, typically of the order of the second. You’re supposed to manually reset the timer at regular intervals throughout your application. It’s meant to prevent the system from being stuck in infinite loops.)

At this point I went through the implementation of that algorithm very carefully, keeping an eye on anything that could be an infinite loop or a failed assertion. When I was done, I was fairly confident (i.e. could almost prove) that it would always terminate. But I also came across a section of code whose gist was the following:

float child[24]; // assume child[] is filled here with some floating-point values
float sum = 0;
float avg;
for (int i = 0; i < 24; i++) 
  sum += child[i];
avg = sum / 24; // compute the average of the elements of child[]

int n_above_avg = 0; // count how many elements are greater than the average
int n_below_avg = 0; // count how many elements are less than or equal to the average
for (int i = 0; i < 24; i++)
  if (child[i] <= avg)
    n_below_avg++;
  else 
    n_above_avg++;
assert(n_below_avg > 0); // at least one element must be less than or equal to the average

That was the only place where an assertion was called. Could this assertion ever fail? This code calculates the average of a set of floating-point values, and counts how many elements are less than or equal to the average (n_below_avg), and how many are greater (n_above_avg). Elementary mathematics tells you that at least one element must be less than or equal to the average.

But we’re dealing with floating-point variables here, where common-sense mathematics doesn’t always hold. Could it be that all the values were greater than their average? I asked that question on Stackoverflow. Several answers came quickly back: it is indeed perfectly possible for a set of floating-point numbers to all be above their average.

In fact, it’s easy to find such a set of numbers if they are all the same. One respondent gave a list of floating-point values that, when averaged, turned out to all be greater than their average. For example:

#include <iostream>
#include <cassert>

using namespace std;

int main() {
  int sz = 24;
  int i;
  double values[sz];
  for (i = 0; i < sz; i++) values[i] = 0.108809;
  double avg;
  for (avg = 0, i = 0; i < sz; i++) avg += values[i];
  avg /= sz;
  assert (values[0] > avg);
  return 0;
}

Once the root cause of the problem was identified, it was relatively easy to write a failing unit-test and implement a solution.

Well, that’s the news from the world of programming where all the floating-point values can be above average. Who said Lake Wobegon was pure fiction?