Good progress since last time.

To start with, I had to fix a bug in the sentence reporting code. The current implementation had an issue that I have noticed myself.

Basically it would refetch the sentences every time a user would complete the previous sentence. That in itself was not a reall issue, but it could cause the sentence to change while the user was assessing it, which was annoying.

The fix was simple. Just needed to adjust the variables used for the useQuery hook such that it wouldn't be triggered by the change on the selectedSentenceId.

Then I had time to start the work on the ELO system. To recap, the idea was to implement an ELO system that would allow for two things:

1. Track the user's progression on a given language
2. Progressively increase the difficulty of the content while still keeping it engaging

ELO systems are used in many games, most famously in chess. The main concept is quite simple; each user gets assigned an initial score. Then when users play against each other, the scores are adjusted. When a user wins against another one whic has a higher ELO score, then the winner gets more ELO. Conversely, when the same user wins against another user with lower ELO the gains are more modest.

But here we don't have an opponent, so how to use ELO?

This question lead me to a solution that addresses both goals: to assign an ELO score for each sentence as well and use the sentence as the oponent.

In practice it means that:

• If a user gets a sentence that has an ELO larger than her own and she marks it as correct; her ELO will increse. The increase will be proportional to how much larger the sentence's ELO was compared to her own.
• On the other hand, if she gets one that is lower, the ELO increase will be smaller.
• If she gets it wrong, the decrease in her ELO is inversely proportional to the difference in ELOs.

So on and so forth.

For this implementation I decided to rely heavily on TDD. So I started by using Claude to help me map all the functions and utilities that I would need, which was a very good starting point. Then wrote the stubs and started writing the tests for it.

Why not vibe code? I specifically decided to minimize vibe coding on this project because here is where I want to learn things. I do use claude extensively for brainstorming and for when I am stuck. I do however code by hand all the interesting parts as well as make sure to do the architecture decisions myself and use AI to challenge it only. AI is a great servant but a poor master.

The implementation is mostly complete by now. At the moment we are keeping track of all the ELO changes on the card changes. There are two improvements I want to implement in the coming weeks:

1. Keep track of streaks and use that to influence the changes in ELO
2. Expose the user's progress in the UI somehow.

Other chores

I also used the time this week to move the project into using pnpm as the package manager. The reason simply being faster speeds, less space usage and a better workspace support, which leads me to...

...since I've been thinking about making the landing page for this app, I am considering simply turning my corrent repo into a monorepo such that I can re-use the ui and utilities for the landing page. I haven't decided on it yet. Let's see what happens.

---

That was it for now. See you in the next one.