# Nonstandard Deviations

## Flashcards programmers might actually use

Inspired by an old Reddit post on using flashcards to learn programming, which I think is a very bright idea implemented in a way nobody else but him and I would ever do.

## Motivation

I love flashcards. I love apps like Anki for timing its flashcards so that I see them less and less as they sink into long-term memory, a la the spacing effect. And I love sites like Quizlet for doing the opposite, and providing me the convienience to cram flashcards on whatever dumb little language feature is stuck in my craw this time. (Believe me, there's no shortage of those.)

You know what I hate? Learning new software libraries. No, not the libraries themselves – just the process of grinding your way through them. For me, at least, learning a new library more often than not looks like this:

1. Spend too much time trying to code something buggy and error-prone, and decide that somewhere, someone must have already done a better job than me.
2. Google around and pick the best of maybe 3 or 4 library options based on surface characteristics, while choking down the fear that maybe I didn't choose the best one for my needs. That maybe fate itself wants me to suffer.
3. Get it installed, and start flipping through the documentation for something vaguely related to what I want to do.
4. Grab the first example that crosses my vision that I can remotely think of a way to solve my problem with.

And then I make a small amount of headway on the problem, and then I return to the documentation, and make a small amount of more headway, and then I return ot the documentation, and ... realize there was a function that made this whole problem so much easier to handle that I didn't see on the first time around.

Maybe instead of awkwardly throwing around string splits and findlasts, I find its older, more general cousin, findnext. Maybe instead of iterating through all the nodes of a graph to count them up, I just find |nodes(graph)|. Maybe these two examples feel so simple, you can't believe anyone would ever be so impatient as to try to work like that, right up until the next time you're up at 3 in the morning desperately crunching through your CS assignment due the next day and all you want to do is go to sleep and put this coding nightmare behind you and at least the mental energy of rolling your own tiny solutions can keep you going whereas reading more than 6.257 words of documentation will 1,000% put you to sleep and make you miss your deadline.

When I grab a library, I'm usually already pretty impatient. I don't want to have to book out an hour to read the documentation. But neither do I want to skim through documentation of a tool I'll most likely have to use again in the future anyway, and leave without understanding half of the baked-in power the library has to offer.

If only there were a better way.

## A better way

Let's say we have a library that defines 20 new functions.

The documentation has the following information:

• The type signature of the function.
• A short description of what the function does.
• A few basic examples of code implementing that function, combined with return values.
• Maybe a few more advanced examples if the function has any subtle gotchas with elements of the base language, or other functions in the library.

You can make 1 flashcard per function where you get shown the description, and you're asked for the name of the function that does what's described. The answer side can show the full type signature.

Then, you can take 2 or 3 of the basic examples, and make that many flashcards where you get shown the code with one of the return values omitted, and you're asked for the return value. The answer side can show the code with the return values filled back in.

If you use a Quizlet-like flashcard system which only allows you to hold a few cards in your hand at once, and you run through these autogenerated cards, you can first go through the new cards to see what's on the other side – then, when they come around again, try to actually answer them based on what you saw 30 seconds ago. (You can mark it right if you got the gist of the thing; we're not looking for memorization here, we're just looking to build familiarity with everything at our disposal.) This works a lot better than you would think, especially if you do it right before you actually dive into using the library.

In my experience, 80 flashcards doesn't actually take all that long when you are only asking yourself to remember one minimal nibble of information per card, even if it's your first time seeing them. The active mental effort you need to expend looking at the various cards helps keep you actually focused on the task at hand, which is much better than reading through documentation, at least for me. And at the end, you'll have effectively gone through and given your brain a succinct overview of the basic capabilities of all 20 functions in the library. When you run across a problem where the author intended a nice, idiomatic-sounding approach, you'll be far less likely to pass it up just because you didn't see it.