Programmers and Practice vs Training

Lately I've been trying to learn one new thing every day.   And one of the sad discoveries that I've made is that I'm capable of forgetting things almost as quickly as I learn them.

So, two months after I learned how to write vim macros - I've already forgotten the specific keys used to define and run them.   Now, I can re-learn this very quickly - I've got good notes, the memories are just slightly hidden, and I haven't forgotten any concepts, just simple keys.   But this will slow down my use enough that I probably won't pull this tool out when I need it.

This got me thinking about how I needed to complement training with some  some repetition, some practice.   That just learning something isn't good enough.   This is exactly what martial artists do - they would call these katas.    It's also what musicians do - they would call these scales.

There's a number of reasons why this kind of practice is uncommon in our field

  • Business, in general, doesn't get into practice - they do training instead.  Typically for a new skill, not as a refresher for an old one.
  • Unlike a martial artist a programmer seldom has to be prepared for a sudden surprise: they can take some amount of time to research the lapsed skill then apply it.   Certainly more than sub-seconds.
  • Unlike a musician, a programmer can sometimes automate a test of their performance.  If they care to - in many cases they may not have the same standard for perfection that a musician might have (so what if you fumbled a few keys being inefficient in running a command?).

But there are two cases in IT that really warrant practice

System Recovery - when a system crashes the clock often starts ticking because the outage can adversely affect the business.  There's a lot of pressure to get the system running as quickly as possible, and generally insufficient time and resources to test recovery scenarios.   The staff performing the recovery should have practiced this previously to ensure they make the right decision now.  I've seen the wrong recovery decisions result in permanently lost data, unrecoverable RAID arrays, and 4-day outages for critical Fortune-500 business resources.

Fortunately, most professionals and many shops that need to perform system recoveries understand this need.   Many do practice recoveries.   Very good DBAs in particular are likely to schedule time for practice.

Small Common Tasks - in the VIM edit macro example I gave above if I postpone refamiliarizing myself with edit macros until I truly need to then it will never happen.   There will be no point in time in which I have no choice but use edit macros.   Instead, I will always use some other method, that is faster once you consider the refamiliarization time.  And yet the time to relearn this could pay for itself very quickly - within just a handful of uses of it.   That 15 minutes to refamiliarize myself could pay for itself in 5 days.

Looking at it in common economic terms - the practice of small common tasks in which the pay-back takes more than a single use, but might happen within a month seems like it should be easy to justify.   The first step is to be aware of the need.

Examples of where I personally should be doing this include

  • vim features - there's probably 100 commands that I should know and practice.
  • python language features - there are dozen language features that I should be using but aren't - simply because I haven't practiced them enough to be comfortable when I need them.
  • bash features - I really only know the 10% of bash needed to create and maintain simple scripts.   I'm not into one-liners.   However, I could really benefit from increasing that 10% to 20% by learning another 10-20 features and rules.   But I just won't retain that without practice.
  • etc, etc, etc
I guess the next question is if there's a way to turn these features into a very concise sequence of commands that would permit one to perform them consistently in a very short period of time.   For example, if it only took 5 minutes to run through a vim kata I would probably do it almost daily.

Maybe I need to see if I can help resurrect that vimkata project.


  1. I believe the nature of my job no longer allows for much repetition. I'm constantly taking on new roles and tasks with each one seemingly like starting a new job if not new career. Or maybe my memory is fading faster than I realize.

  2. I wonder if the candidates for you are just different? Perhaps it's not programming tools as much as communication, writing, spreadsheet and presentation tools and techniques?