The Unreasonable Speed of Rust

Rust is fast. No, not the systems language - I'm talking about rust in the sense of losing skills in programming languages when you're no longer actively working in them.

I've spent a bit of this week getting back up to speed with JavaScript. A couple of the teams I work with are going to be building a React app plus I have some personal projects on the horizon, and it's not going to be helpful for either of these if I'm spending half my time trying to drag the basics back into muscle memory.

Scary moment: I realised I'd clean forgotten about function hoisting. This is a core concept in JS, and one very easy to be bitten by if you're not defensive about scope. The details aren't that important, but essentially if you have a .js file containing something like this...

fn();
function fn() { console.log(x); }
var x = 1;

... it's actually treated by the interpreter as equivalent to this:

var x;
function fn() { console.log(x); }
fn();
x = 1;

Now, you'd probably be careful about scope and anyway since ES2015 we've had let and const to make our code slightly less likely to do face-bendingly insane things, but the point here isn't to illustrate technical concepts in JavaScript. The point is, a mere six months after working in this thing on a daily basis I had straight up forgotten one of its more important features. The bones of it were there in cold storage, but it had drifted completely from working memory.

Rust Never Sleeps

Maybe I hit this problem more than most because I polyglot a lot: since my last commercial JS work I wrote a Java print catalogue generator for simplified and traditional Chinese, implemented most of a game map pathfinder in Squirrel, had a play with Erlang and wrote a whole 2 lines of Elixir in iex which maybe counts for something. But whether or not you're actively trying to turn your memory into a disjointed mess of languages, this is something those of us who do vaguely managerial things or even just go on holiday for long enough will hit eventually: Forgetting Stuff.

It happens quickly, and with today's enormously broad stack of tools, there's a lot to forget.

Into The Black

How do you get round this? Maybe there's a good answer, but I don't have it. However, in the absence of a good answer I think it's useful to accept this process. Stuff will drop out of working memory, and the more new stuff you take on, the more old stuff this will happen to. The way I approach it is to prioritise:

• Decide what you really care about. Invest time in these things. Do hobby projects, practice kata, talk about them with other team members. Make sure to stay up to date too - there's nothing worse than the former expert who spends all their free time practicing C# but hasn't used any new language features since 2.0 shipped.
• Decide what to let go. I always let Python slip, because I was only ever at best a mediocre Python programmer. The world has plenty of mediocre Python programmers, I add nothing being yet another one. Occasionally I will need to do something in Python, and I accept I'll have to spend the first 30-60 minutes of the task asking the online help a bunch of noob questions until I remember def needs a colon, and so on.

These are the extremes, and between this is probably a whole bunch of stuff where you're happy to invest some time, and might seek out a bit of pair programming if you haven't used it in a while, but you're not going to be top kyu on Codewars any time soon. Just be aware of where things sit, and don't let them accidentally fall into the "let it slip" category when you don't want them there.

Sail Away

Closing out, here's a list of some of the things I find helpful in retaining existing knowledge, rather than learning new:

• Codewars/HackerRank: I love these, but they also come with a cautionary note: I find they tend to encourage code golf and clever solutions over well-structured, maintainable approaches. They're great for practicing problem-solving, but be aware these solutions aren't complete systems.
• Writing simple apps from memory without using documentation: Can you write an Express "Hello World" without resorting to StackOverflow or your bookshelf even once? I like this one as it can be quite affirming to realise how much you do actually know, or can figure out. Hard mode: do this in a text editor without auto-completion.
• Open Source: Not only contributing, I find it instructive to take a project and read through the source, especially if there's something I'm trying to find out.
• Discussion: Merely talking helps. One of the things I like doing is setting a challenge in a team chat - "find as many ways as possible of generating a sequence without using a for loop". This scales well as the entire team usually learn something. For anyone more on the managerial or architectural track, spend time outside the ivory tower talking about code (but resist the temptation to interfere or micromanage!).
• Pomodoro: This is more a complement to the others. One of the problems I have with keeping current is I can spend too much time - a short refresher can become an entire evening of coding and I find that discovering joy in the ... spread operator has resulted in it getting to 11pm with the dogs unwalked, the dishes unwashed and the spare room still needing painting. Setting a timer helps, especially if you're trying to cover multiple things in a session.

Do you have a favoured technique for combating the surprisingly fast creep of rust? I'd be interested to hear it.