Hacker News new | past | comments | ask | show | jobs | submit login
Spaced Repetition to Increase Programmer Productivity (1993) (super-memory.com)
37 points by galephico on Dec 22, 2015 | hide | past | favorite | 17 comments



I actually made an Anki deck when I was learning CSS two and a half years ago and I found it was well worth the effort. Since CSS isn't something I'm nearly as interested as programming, I didn't go that far with it—just the basics of the flow, the box model, display, positioning and the most frequently used portions of CSS.

Absolutely everything I memorized, I could have just looked up. I still did have to look things up sometimes. But it really is a lot better to know something than to have to Google it. Not only is it faster, but it also lets you start grouping the things you know well together and think in larger chunks. Just SRS isn't enough to learn anything, or especially how to apply it. But SRS is super efficient at improving you on one dimension that has a positive effect on others. In that sense, it's much like weightlifting is for sports.


This paper was published in 1993, and not 1998, as the HN title currently says.

You may wish to read the excellent Wired article from 2008 about the somewhat eccentric author of this paper, Piotr Woźniak.

http://www.wired.com/2008/04/ff-wozniak/


Thanks; year fixed.


Oh jeez, if I ever needed spaced repetition to be a programmer, I'd find a new profession, stat.


Every programmer needs to memorize the core of their language and framework. Sure, you can use documentation and IDE suggestions, but having plenty in your memory will make you much more productive, and if it need be the case that you need space repetition to memorize, then it's worth the effort.


I feel that using spaced repetition is counter-productive to learning a language / framework, meaning that using it would be worse than not using it. That is directly counter to the article's argument, though I'll admit to not having actually read it.

But even if it wasn't, then the time trying to memorize things would assuredly be better spent solving problems using whatever recall you already have and referring to the documentation when you come up short.


Truth be told, our only saving grace is having documentation at the touch of a key. Remembering the API calls of a single framework is a monumental task.


I'd write my own documentation in that case.


I have seen 'Janki method' earlier: - http://www.jackkinsella.ie/2011/12/05/janki-method.html


I can see how a memorization aid like spaced repetition could actually improve your productivity in 1993, but in 2015, it's neither feasible nor necessary for programmers to memorize all the stuff we use, so I'm not seeing this as terribly useful nowadays.


So, I'm a SysAdmin, and compared to my UNIX knowledge, I'm a terrible programmer, so it's possible that everyone else is just using better tools than I am, but I've had jobs that were more programming than systems.

My impression was that in the '90s, when I started my career, everyone used IDEs where you could type your object and it would bring up a menu showing you the methods and the options to that method. I mean, with something like FoxPro or Borland Delphi, even 16 year old me could whip out CRUD apps with very little programming knowledge at all, and without spending too much time looking shit up in the documentation. It was easy

But... my impression is that nearly everyone has switched away from the IDE, and especially has switched away from editors that reduce the need for memorization. Most of the programmers I know spend most of their time in text editors that only do a very minimal amount of the programming work, meaning they've gotta memorize (or look up) a lot more than I had to when I was writing CRUD apps in the '90s. I spend a lot more time in documentation now than I did then, when I'm learning a new language or writing in a language I haven't used recently.

I mean, this is just my impression... maybe I'm just not watching the right programmers. But yeah; my impression is that the need for memorization is growing, not shrinking.


Depends on language; what languages are used in your company?


>Depends on language; what languages are used in your company?

Python, mostly.

We do a little bit of bash and a fair amount of proprietary internal-only DSL, and a fair bit of non-proprietary DSL like puppet. Maybe a homeopathic amount of C. (I actually got them to let me write something in C the other week so that I could interface with the C api of a mostly closed-source thing we use, rather than using the really hokey and broken python-to-C auto-API-generator thing, and it was totally the highlight of the month, maybe the year.)

But really, python is my problem. The other stuff it's generally acceptable for me to look up, it's just all my reflexes are still perl reflexes, so things that would take me ten minutes in perl end up being half-day projects or better, 'cause I have to look everything up (or because something doesn't quite translate) - I think a good editor could help a lot with the former (the latter, probably, much less so.)


If I took my OO components and looked up how to make it functional while changing it, does that mean I can do functional? No. Too many devs I work with would say so though. However if I spent 30 minutes each day turning one of my OO components into a functional equivalent, then after 6 months or so I'd have a good handle on it. When you combine spaced repetition with something like chunking, it becomes very powerful.


You don't need to memorize ALL the stuff you work with. But it will help to memorize the CORE of the stuff you work with. If you are a Swift or C++ programmer. Knowing/Mastering the core of the language is very doable. it's worth doing it. If you write network programming, memorizing most of the socket functions will help. Improved memory capacity improves productivity.


But wouldn't spaced repetition be useful to master C++?


Fair enough, that might actually be a counterexample; C++ has a lot of rules, which aren't quite so easy to look up as you need them compared to API calls.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: