Programming Katas with Anki

Last year I was confronted with the fact that some of my technical skills have grown stale - at the point at which they were good enough to get the job done it seemed that all progress stopped.   I hadn't stopped learning - just stopped learning about certain technologies and products.   There were benefits to being in this rut like having extra time to spend on the needs of my organization and opportunities within my industry.   But all justifications aside the bottom line was that my productivity was being whittled away through small and continuous inefficiencies in my development methods.   I was using vim like a glorified notepad, I was using the mouse rather than keyboard short cuts on Firefox and Terminator, my use of Python was stuck in the 2.4 days, and I was consulting help on the find command far too often.

So, I settled on a strategy that I used many years ago - to learn one thing every day.   Which mostly worked.   Where it failed is in the specifics of the meaning of 'learn':  I was forgetting some things almost as quickly as I was learning them.   Certain items really required practice and repetition.

But why stop with just learning something well enough to do it slowly and painfully?   Ideally, I would know my tools so well that most common tasks don't require conscious thought at all.  This would eliminate unnecessary distractions and free me up to think about the harder problems at hand.   I want more of my development time to be in a mental state of flow.

Gristle Slicer - of Architects, Chairs and Unix Utilities

There's an old story about two senior architects that were friends in college, and met again thirty years later.   After a few minutes they started talking about their favorite achievements.   The first described office towers, airports, and universities he was quite proud of.   The second didn't have any monuments to talk about, but shared that he thought he may have designed the perfect chair.t chair.    Clearly trumped, his friend congratulated him, and asked to hear more - since the perfect chair is far more significant than yet another monument.

Sometimes, I feel that small unix utilities are to a programmer what a chair is to an architect:  they continue to be essential, and are typically small, spare, do just a single thing and can clearly show elegance.

I've written quite a number of them, and have recently started packaging those related to data analysis into a project called DataGristle.   My favorite utility of the set is gristle_slicer - a tool similar to the Unix program cut.   While cut allows the user to select columns out of a file, gristle_slicer selects columns and rows - and uses the more functional Python string slicing syntax to do it.  

It's no perfect chair but it might be a good utility.  

The Hidden Value of Crappy Experience

A friend was recently sharing his experience in helping his company fix a botched RAID recovery.  He was exhausted by the work and questioning the value of what he was learning from his employer.

But in our discussion we agreed that bad experience might be as valuable as good experience in some ways.    It might not be as fun, and you can certainly hit diminishing returns on it.   But the intense memories of those bad experiences are the basis for many of our most valuable instincts and judgements.

Well, at the time, it felt kinda nice to be able to help him put a happy face on his obnoxious job.

And then just this week I had the tables turned on me:  A server I depended on failed because a battery swelled, and then warped and took out the motherboard.   Even better, the backups only appeared to be working, but really weren't.   And that's not all: there was some code on that server that wasn't yet in version control because of chaos on the team at the time - after existing in limbo for two years it was slated to be added this week.    We were down for days replacing that server.   And I suppose we were lucky - it could have been worse.

All this got me thinking about my glib advice to my friend about the value of crappy experience.   Was there a silver lining for me in all this?   Did this week add to my mental catalogue of situations to avoid?   Well, just as an exercise I decided to write down what the catalogue might look like.   At least just the part that deals with backups & recoveries.   Here it is:

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.