What helped me the most with sticking to SR and Anki over 6 months now was the tip by Michael Nielsen [0] to not use any plugins and to not personalize anything:
> I know many people who try Anki out, and then go down a rabbit hole learning as many features as possible so they can use it “efficiently”. Usually, they're chasing 1% improvements. Often, those people ultimately give up Anki as “too difficult”, which is often a synonym for “I got nervous I wasn't using it perfectly”. This is a pity. As discussed earlier, Anki offers something like a 20-fold improvement over (say) ordinary flashcards. And so they're giving up a 2,000% improvement because they were worried they were missing a few final 5%, 1% and (in many cases) 0.1% improvements. This kind of rabbit hole seems to be especially attractive to programmers.
I've seen the same reaction to learning VI-like editors. I've heard a few times variations on "I don't want to spend my time worried I could have done an editor operation in 2 fewer keystrokes" I sure as heck don't want to do that either and I've been using vi-like editors for almost 30 years now.
> Anki has some poor defaults for some parameters, which will cause you to be needlessly inundated with reviews.
The problem is that people incorrectly assume that they must "do something" about missed reviews. That's just not how it works; in fact, Anki will give you extra credit for recalling a card beyond the expected forgetting time, so working with a backlog of cards to review is a lot easier than it sounds.
The whole idea is that once the expected forgetting time for those "review" cards has been pushed far in the future, that's the best time to learn new, more challenging content. It works very well in my experience.
Where reducing the amount of reviews may well be justified is for cards that are "nice to have", but that you don't actually care about remembering. That's also the only sorts of cards for which "leech" protection makes sense, and that's a lot closer to a poor default in my view.
There are multiple problems. One is that if you have a card with a nice long interval, and you happen to lapse on it, the interval is trimmed to a very short value, by default.
Emoji might actually be usefull for quick oversight, but how can you include a reference to an issue for every commit? What if you are just adding more tests?
I've seen this kind of thing work really well for some teams. In that case there should be a "ref" for adding tests.
It tends to act as resource management, you shouldn't be working on things that your manager doesn't know about at least enough to make an "issue" for it.
But it's not a 100% must in all cases, just that there SHOULD be a ref there. The rule of thumb for us was if it's going to take more than 15 minutes, it needs an issue.
Edit:
I can't seem to reply any more, but this is just for organization. you can create your own issue and work on it on your own, this is just a way to organize and categorize the commits and provide an easy "parsable" way to give some context to them.
> The rule of thumb for us was if it's going to take more than 15 minutes, it needs an issue.
Gross. That sounds like process for process' sake. Or you could, you know, just trust that your developers are working on actually useful things because that's what you hired them to do, and we're all professionals here, one hopes.
Maybe something like this is useful for _very_ junior developers who need a bit of hand-holding before they're steeped in how professional development in a team setting works, but if you still need this sort of thing after even a year at work, that'd be a huge red flag to me.
> I know many people who try Anki out, and then go down a rabbit hole learning as many features as possible so they can use it “efficiently”. Usually, they're chasing 1% improvements. Often, those people ultimately give up Anki as “too difficult”, which is often a synonym for “I got nervous I wasn't using it perfectly”. This is a pity. As discussed earlier, Anki offers something like a 20-fold improvement over (say) ordinary flashcards. And so they're giving up a 2,000% improvement because they were worried they were missing a few final 5%, 1% and (in many cases) 0.1% improvements. This kind of rabbit hole seems to be especially attractive to programmers.
[0] http://augmentingcognition.com/ltm.html