Categories
All Books English How I work

How I learned the NATO Phonetic Alphabet

Did it ever happen to you that during a phone call you had to spell something? An airline code, an email, an invoice number, etc. At those situations, I always regretted not having learned the NATO phonetic alphabet.

NATO Phonetic Alphabet

Flash forward to September 2019: I found myself in a talk about learning and memory techniques during the Automattic Grand Meetup. It picked my interest so I decided to investigate a bit and signed up for the Learning how to Learn MOOC.

In this post I’m sharing how I’ve applied my new gained knowledge to learn something useful that I had put off for a long time. I also hope to interest you in the topic of learning how to learn.

1 – Deal with procrastination

The main reason I had postponed learning the NATO Phonetic Alphabet is that I thought I had a bad memory and it’ll be a lot of work — I procrastinated. Procrastination is a mechanism our brain uses to cope with challenging feelings induced by certain tasks: perhaps we believe we can’t do something, maybe it’s boring, makes us feel anxious, etc. Essentially, procrastination is not about time-management, but about emotion-management.

To deal with procrastination means to deal with and rewire our emotions about the task. Doesn’t sound easy, right? The good thing is that there are a few practical things we can do:

  • Time-box short periods of focus, break and reward. Time 20 minutes during which you’ll exclusively focus on the task at hand and do whatever you can: no pressure in the output, just focus on doing anything. Then, give yourself a break and a reward — exercise a little, eat some chocolate, surf the web, whatever works for you. Do not forget about the reward! It’s a crucial part of rewiring your feelings about the task. Finally, repeat the process a couple of times more.
  • Focus on the process, not the product. Planning and have small wins/rewards is an important part of dealing with procrastination. Things like writing down the next tasks you’ll work on at the end of your day or cross-off the ones you’ve done help you focus on the steps. By focusing on the process, not the final goal, it’s easy to control our feelings of discomfort.

For me, the first focused session was about familiarizing myself with the NATO Phonetic Alphabet: essentially, I surfed the web and read about it. Then, I stopped and gave myself a reward. My second session was about how would one go about memorizing all the 26 symbols (see next tip). Break and reward. I spent the third session developing the system I had researched. Again, break and reward. By the fourth session, I was ready to start memorizing.

2 – Tap the visual and spatial memory

Through many thousands of years, our brain has evolved to be amazingly good at remembering places, visual things, as well as anything that involves the senses. When dealing with abstract concepts it’s useful to encode them into memory leveraging those abilities. For someone who hadn’t consciously done this before and feels that has an average memory, this is easier said than done.

If we look around us, though, there are multiple real-life examples we can draw inspiration from:

I hadn’t done it before, so I spent my second focused session thinking about how would I put in practice the things I had learned. I also reviewed what others did for inspiration: the NATO publishes a guide that links images to the words, some people create a song, etc. Of all the things that I found, the approach suggested by Nelson Dellis -4th time winner of the USA memory championship- was the most appealing to me: he creates an image by merging the letter and the word associated with it.

For example, for the pair A-Alpha he pictures sprouts of Alfalfa coming out of the A letter; for the pair P-papa he pictures a cartoon of his dad with the shape of the P; for the pair U-uniform he pictures the U being a basket where you’d store uniforms; and so on. I highly recommend the video if you’re interested in the mechanics of this.

After I knew the system I wanted to use, I decided it was time for a break (and a reward!). After a while I came back energized to create my own — actually, my unconscious brain already had already suggested some ideas (see next tip). Being my first time ever doing this kind of thing, it took around an hour to come up with my own memorable images for each one of the 26 letter-word pairs.

3 – Focus, rest, and recall

Now that I had a system in place, the next step was memorizing. I went through the phonetic list stopping a few seconds in each of the images I had created. After a few rounds, I stoped and did other things. Then I tried recalling them from memory: I didn’t get all of them but I did get many. I repeated the pattern (focus, rest, and recall) a couple of times during the day. The days after I mostly did recall using the Anki app where I had stored the pairs previously.

It turns out this strategy works a lot better than just going through the list over and over until you are exhausted. There are a number of things at play here:

  • Switching between focus and rest states helps your brain digest the information, so to speak. In the focus mode, you’re able to direct your thoughts to a problem. Although you can’t command your diffuse unconscious brain to work on the things you want, you can prime it to do it — aka make suggestions. How? For example, by taking a break after a focused session (go for a little walk, take a one-second nap like Dali or Einstein, do the home chores, etc.).
  • Space the repetition. Once you reach the point of almost no errors, repeating has diminishing returns — it’s just not effective and creates illusions of competence. To store something in long-term memory, you have to modify the forgetting curve instead. How? Spaced repetition. Instead of cramming a 2h session repeating the same material over and over, do smaller sessions spaced through several days. Useful ways to be deliberate about practicing is scheduling your review and study sessions in a calendar, use flashcards to keep track of progress, etc.
  • Recall from memory. Long-term memory is a storage mechanism that prioritizes which memories are consolidated and which ones aren’t that important. By recalling the information, we’re strenghthening the path to retrieve it later. In many ways the mechanism is very similar to paving a cowpath: a memory is strong when it was used a lot during different intervals. Recalling and testing yourself are the most effective techniques you can use to reinforce what you want to learn. Also teaching it to someone else, which is a good technique to uncover the holes in your understanding.

Coda

Although the tips I suggested here are universal, how do you apply them to a specific situation varies from problem to problem.

Take memorization techniques, for example: PAO, Major System, Mnemonics, Memory Palace, etc. Some are useful to convert concepts into images, others to link or inter-connect different ideas. It takes time to know which technique is more adequate to a specific problem. That intuition is only built with practice.

Other essential functions of learning that I didn’t use in this process were understanding and chunking. I had a list of 26 symbols that matched a letter in the alphabet and they didn’t have any other meaning; I also didn’t have any pre-requisite knowledge, so to speak. If I was trying to understand a mathematical formula or how a web-browser works, chunking would have been essential. The process is similar to putting together a puzzle and involves compressing the information, learning to deconstruct the concept you’re trying to understand, reason by analogy, transform the concept to a different mode/language (from a formula to a graph, from graph to simple words), etc. It’s a messy process.

The topic of Learning How to Learn is fascinating. There is so many practical things you can do to improve and some of them are so counterintuitive. It’s also a fun way to challenge the pre-conceptions about yourself and indulging a bit of goofyness while you work hard to grok something.

If this post picked your interest, I recommend checking the Learning How to Learn MOOC and/or the book is based from, A mind for numbers. They are comprehensive and contain extensive documentation and research, while keeping things actionable.

Categories
All English How I work

Dvorak two years after

In November 2016, I switched from QWERTY to Dvorak. The past year, the change wasn’t noticeable yet, so I was hoping this year would.

This is the completely unscientific test I run: I visit TypeRacer and record races – I’m going to settle at 20 from now on. The texts aren’t the same from year to year, I just trust the random nature of TypeRacer to give me different kind of them: short, large, with tons of punctuation, with very few breaks, and so on.

It looks like I’ve already surpassed my previous baseline after two years using Dvorak – both in terms of speed and accuracy. I had been using QWERTY for about 15 years before switching, so that’s impressive. I guess I’m able to introduce bugs in my code faster!

In a more qualitative note, 2018 has been a year of consolidation. Unlike in 2017, I haven’t changed my input devices and my keyboard configuration has remained the same – that has probably helped my muscle memory to develop faster. I still don’t have a steady rhythm and there are some characters I struggle to type. The accuracy results are more meaningful to me than the speed, as that speaks about my finger health long-term, which was the main reason I was interested to give Dvorak a try.

Categories
English How I work

Function keys in Thinkpads

I usually work with an external ThinkPad keyboard, which matches the configuration of my laptop’s. Lately, though, I’ve been using my laptop’s keyboard more and more. At some point, Lenovo decided to design the 6th keyboard row in a slimmer way and switched the standard F1-F12 keys to function keys (volume, brightness, etc). This is very inconvenient if your work involves typing a lot, as editors tend to offer handy shortcuts with the F1-F12 keys.

This is how you change the default configuration: FN + ESC.

Categories
All English Programming pills

On JavaScript modules

Next week I’m going to participate in a session about package managers for different languages – we’ll present pip (python), composer (PHP), and npm (JavaScript). In sharing ideas with my colleagues I realized how many of the struggles of modern JavaScript tooling and workflow is based upon the fact that the language didn’t have a built-in module system until recently, so I’ve decided to write down my thoughts as preparation for the talk.

A brief history of modularity

For a more in-depth explanation, please, check this evolution of modularity in JavaScript – it has many details hard to find in other places.

JavaScript was created in 1995 without modules, and every <script>  shared the same global scope. We learned how to work with functions and namespacing to gain a minimum ability to divide our code into pieces, but as the importance of JavaScript grew, the pressure to have better alternatives was more intense as well.

In the server, Node.js became the de facto standard and its module choice, CommonJS, the format used in the incipient node package manager,npm . That was 2010, 15 years after the JavaScript release. Browser-side nobody could afford or was interested in a unified module system, so alternatives bloomed and the market became more fragmented. With time, the use of npm skyrocketed and so the importance of CommonJS, even for browsers.

How to make CommonJS available in the browser

It may be worth to pause and remember that at that point we still didn’t have a module system for browsers. We had something that was simple enough to work with and hack. The core of the CommonJS API is quite simple, and has two pieces:

  • require: a function to import some code that’s somewhere else.
  • module.exports: a variable to hold the code to be exported.

Let’s say that I have an input.js file in CommonJS format:

var constants = require( './constants' );
console.log( constants.HELLO + ' ' + constants.WORLD );

And the corresponding constants.js contains:

module.exports = {
    HELLO: 'HELLO',
    WORLD: 'WORLD',
};

I can’t add those files to the browser through the <script>  tag and expect them to work. That’s invalid JavaScript as browsers understand it.

How do we make it valid JavaScript? Well, something we can do is to copy the modules to the same file, wrap them in a function (so their internal variables don’t collide) and expose the necessary keywords through the function arguments:

// Scope the first module
function( require, module ) {
    var constants = require( './constants' );
    console.log( constants.HELLO + ' ' + constants.WORLD );
}

// Scope the second module
function( require, module ) {
    module.exports = {
        HELLO: 'HELLO',
        WORLD: 'WORLD',
    };
}

This can be included in the browsers! It won’t fail, but it will also do nothing.

OK, next step, let’s implement require : it is a function that takes a module identifier and returns its module.exports object. We can do that:

// Implement require
var modules = {};
var require = function( moduleId ){
    var tmpModule = {};
    modules[ moduleId ]( require, tmpModule );
    return tmpModule.exports;
}

// Scope and register the first module
var input = function( require, module ) {
    var constants = require( './constants' );
    console.log( constants.HELLO + ' ' + constants.WORLD );
}
modules[ './input.js' ] = input;

// Scope and register the second module
var constants = function( require, module ) {
    module.exports = {
        HELLO: 'HELLO',
        WORLD: 'WORLD',
    };
}
modules[ './constants' ] = constants;

It looks a bit better, but still does nothing and we ended up adding a lot of variables to the global scope.

Let’s fix this by scoping the code within an IIFE (so it doesn’t pollute the global scope) and execute the main module, the entry point of our program (./input.js in our example):

(function() {
  // Implement require
  var modules = {};
  var require = function( moduleId ) {
    var tmpModule = {};
    modules[ moduleId ]( require, tmpModule );
    return tmpModule.exports;
  };

  // Scope and register the first module
  var input = function( require, module ) {
    var constants = require( './constants' );
    console.log( constants.HELLO + ' ' + constants.WORLD );
  };
  modules[ './input' ] = input;

  // Scope and register the second module
  var constants = function( require, module ) {
    module.exports = {
      HELLO: 'HELLO',
      WORLD: 'WORLD',
    };
  };
  modules[ './constants' ] = constants;

  // Execute the main module
  var module = {};
  modules[ './input' ]( require, module );
})();

This is it! We’ve transformed our initial CommonJS modules into something that is executable in today browsers.

This exercise would need quite a bit of work to be production-ready, but the fundamental steps are there and it’s not difficult to see that’s easily automated by tools. This is mostly what Webpack does when it transpiles CommonJS to IIFE. Rollup seems to be a bit more elegant but its strategy is similar. If you’re curious, check the runnable code they generate.

The transition to ESModules

The success of npm and CommonJS  taught the browser ecosystem a valuable lesson: a better workflow was possible. Some attempts were made to replicate the registry plus format formula but, eventually, npmCommonJS won .

Flash forward to 2015 and the ES6 standard introduces modules in the JavaScript language. Three years after that, browser adoption and node support are still not universal or complete, but everybody agrees that it will. The whole ecosystem seems to be on board and execution environments, toolslibraries, and authors are preparing for what that means.

If we believe that, npm will continue to be the central registry to distribute JavaScript for the foreseeable future, but CommonJS will no longer be the default module format. In this moment of transition, not everything is clear or necessarily better. The ashes of the module wars are still warm, but they won’t be forever.

Categories
All English Radar

JavaScript in use 2011-2017

According to the HTTP Archive, the top 1.000 websites download 5 times more JavaScript today than seven years ago – HTML grew 2x and CSS 3x. Combining that with the fact that the mobile web is more present than ever, the result is that the main bottleneck for the websites we create and consume is the CPU.

Categories
All English Radar

Input lag: 1977-2017

Input lag: 1977-2017 is an essay about the time it takes several computers to display a character from a keypress. A lot of newer computers take 3 to 5 times more than 30 to 40 years old computers.

Categories
All English Radar

Google Maps’ Moat

2-18+-+Detailed+Shapes.gif

Google Maps’ Moat, by Justin O’Beirne. On the competitive advantage that Google Maps has over Apple Maps – equally interesting for map nerds and business people.

Categories
All English Radar

Agile according to Basecamp

Running in Circles is Basecamp’s view of agile product management. They acknowledge the value of working in cycles, but add three pieces: having the time to focus, being able to modify the original plan, and tackle the core unknowns of the feature first.

The first two are enablers that are provided to the makers by management. The last part is how the maker make the most of those powers. Together, they form a process that is nicely captured with the uphill / downhill metaphor. Uphill you are discovering the unknowns and making decisions about what goes in, downhill everything is clear and you are implementing it at warp factor 10:

Categories
All Radar

Ten years of mobile

10 years of mobile by Luke Wroblewski packs a lot of knowledge in one hour and a half. If I could only watch one talk about mobile, I’d make it this.

Categories
All English Radar

Software architecture failing

Software architecture failing: tech writing is biased towards what the big ones do, which usually doesn’t fit most other contexts – but, who got fired for choosing IBM, right? Although I feel connected to this rant at an emotional level, I do think it’s necessary to elaborate more and make a positive contribution: help to create and spread that alternate history of software development. How do you do it? Hat tip: Fran.