HN user

Theaetetus

278 karma

www.natemeyvis.com

Posts18
Comments39
View on HN

This is great. I often want a low-latency, minimal-feeling option for this sort of thing. (And I get to use my Vim muscle memory less and less often these days!)

Really, thanks for making and sharing this; so far, I feel calm and happy when I'm using it.

Basically, yes, but:

1. You probably only need a few pieces of the framework;

2. "Vibe code" can mean "get Claude (or whatever) to help you with some AWS (or whatever) service."

Oops! I haven’t read the guidelines in a while, and for a long time I only lurked. Thanks for setting me straight. I’m accustomed to forums where there’s no problem with posting your own stuff. Obviously I’ll correct my behavior. Thanks again!

See my other comments here for some of my motivations, but also:

Even in the Internet age, getting the latency from "fast" to "effectively zero" has a lot of value for staying in flow, synethesizing information, etc. Your memory is the ultra-low-latency fact retrieval system you always have. No, you definitely don't want to use it for everything, but it definitely does complement modern tools in important ways.

This is a really good question!

1. As others have said, the idea is to study something before you forget.

2. It's hard to predict when you're going to forget something, so you do wind up studying a bunch of stuff before you really have to. It's a limitation of prediction (and also of the technology as developed so far).

3. It really is pleasant to work to recall things even when you succeed at it. It does "freshen them up" in your memory. And sometimes just the experience of seeing a fact can be pleasant. (A lot of us review familiar things for the joy of it in other domains--movies, etc.)

Yes, I can calculate that! I was a math major and have some basic literacy. I checked the LLMs' work. That said, I only did so with medium rigor, and I wanted to flag that I was speaking as someone who was assisted by AI, not someone who had done the process by hand.

1. I enjoy it.

2. I like trivia competitions.

3. I like making and using my own software.

4. Memorizing facts is an underrated way to become a better software engineer. Not the best way or even close to the best way, but an underrated way!

5. It enriches my experience of the world (I plan to write more about this soon).

1. My algorithm is probably inefficient, and a big Q1 2026 goal is to figure out where the inefficiencies are and (better) to get a better system for addressing and remediating them in an automated way.

2. A lot of my cards were also made in 2025 (and 2024), so I'm probably much farther to the left of you on the learning curve, on average.

1. I have a long commute, and I have about 45 minutes of walking per day, during which I like to do my reviews. 2. I've put serious effort into reducing the friction in my software in order to reduce time per review. 3. You've got to do something when you're on the toilet, right?

I prune some, but less than I probably should, and less than most other serious SR people do. I'm more interested in techniques for (i) raising the quality of even my lower-value cards and (ii) figuring out how to actually learn the stuff that people think of as "leeches."

1. I have always loved learning things, both big and small. 2. I enjoy trivia competitions. 3. I'm interested in human memory more generally. 4. I think that spaced repetition software could be a lot better, and I'm trying to make such software. So when I study, I'm also getting the value of using and improving my own software.

Are you the poker Matt Maroon? If so, I've been enjoying your writing for a very long time.

I definitely don't sit around doing nothing when I'm waiting for water to boil, but very often the water is still on the critical path (e.g., because I want the pasta to be done ASAP even if other things aren't done yet, or because it's on the critical path even if I can use all that time efficiently).

Yes, that's an important part of any system. It sounds like we agree that the traditional diagram, with some boxes and some arrows between boxes, is quite inadequate when you actually have a tough problem that needs solving.

Against SemVer 7 months ago

Some alternatives:

- Finger to the wind ("this feels like a big change"). - Domain-specific versioning scheme (so Ruff uses [this variant](https://docs.astral.sh/ruff/versioning/#version-changes) that seems reasonable to me; it's described as a SemVer variant, but the work to specify how various cases are handled seems very useful to me). - As you say, time stamps. FWIW I don't like that very much, because time is often so weakly correlated with progress / "breakingness," but it has its proponents.

I basically agree with this. Extra objects do carry costs. That said, usually the extra objects are necessary to make your code conform to reality. N things with N names in N files definitely carries overhead, but if the alternative is N things with 1 name in 1 file, and programmers carrying the complexity in their heads (or the complexity being a bunch of spaghetti in the one file), I'll happily accept the N - N - N side of the tradeoff.