For a quantified-self or developer learner, the dream is to wire Hanzi practice into the whole productivity stack: a daily GitHub commit, data export, an API, webhooks, time tracking. It is a fun, motivating idea and largely doable. The one thing to get right is the metric, because the most tempting thing to track, manual tracing time, is the wrong one. Here is the honest take.
Yes, you can integrate practice into your stack
The plumbing is realistic: a practice session can fire a commit to a habit repo, export your data, hit a productivity API, or trigger a webhook, so your Hanzi practice shows up alongside the rest of your tracked life. For someone who runs their habits through a dashboard, that integration is genuinely motivating, because a visible streak and data sustain the routine, and consistency is what learning rewards, per the spacing effect. The integration instinct is sound, the same developer-friendly spirit as wanting a Yomichan or Pleco API workflow.
The trap: tracking tracing time
Here is the catch the keyword names, exact manual tracing time. Time spent tracing is a vanity metric, because it measures input, not skill, and tracing in particular builds recognition, not the recall writing needs. So a dashboard proudly logging hours of tracing can look productive while building little, the same illusion as in logging 10,000 hours of tracing. If your integration optimizes for time, you will optimize the wrong behavior, doing more low-value tracing to make the number go up.
What to track instead
The metrics worth piping into your stack are about recall, not time:
| Vanity metric | Useful metric |
|---|---|
| Manual tracing time | Characters you can write from memory |
| Total session minutes | Per-character recall accuracy |
| Streak length alone | Which characters are slipping |
| Commits for showing up | Commits for from-memory mastery |
If your commit or dashboard reflects from-memory recall and accuracy, the integration reinforces real progress; if it reflects tracing time, it reinforces busywork. Tie the data to production, which engages the generation effect and the testing effect.
Keep the practice from-memory
Whatever you pipe out, the practice underneath has to be from-memory production, since handwriting beats typing for learning words precisely because you produce the character. So integrate the data, but let a commit or a logged session represent a real from-memory session, not tracing minutes, the same standard as in syncing GitHub commits to a habit tracker honestly. The stack should celebrate the right behavior.
A plan for a quantified-self learner
- Decide your metric: from-memory recall and accuracy, not time.
- Let a commit or log represent a real from-memory session.
- Export recall and accuracy data, not tracing minutes.
- Use the dashboard to spot which characters are slipping.
- Keep the practice production, so the data means something.
How Hanzi Write Practice fits
Hanzi Write Practice centers the production your stack should measure. It hides the character, you produce it from memory, and it checks stroke order and structure with spaced repetition, so what it tracks is recall and accuracy, the right metric, not tracing time. Rich export, an API, and integrations like GitHub or webhooks are the kind of developer-friendly features that fit the roadmap, and even now you can commit after a real session yourself; the principle is that the metric is recall, on the foundation of the case for a writing app.
Bottom line
You can wire Hanzi practice into GitHub commits, exports, and productivity APIs, which is motivating for a quantified-self learner, but tracking manual tracing time is a vanity metric; track from-memory recall and accuracy instead, and keep the practice production. Hanzi Write Practice centers that, with export and API integration on the roadmap, and it is in early access, so join the list.
Frequently asked questions
Can I integrate Hanzi practice with GitHub commits, exports, and a productivity API?
Yes, the plumbing is realistic: a session can fire a commit, export data, or hit an API and webhooks, and for a quantified-self learner that is motivating. The key is the metric: tracking manual tracing time is a vanity metric, since time spent does not equal skill and tracing builds recognition, so track from-memory recall and accuracy instead. Hanzi Write Practice centers from-memory practice and measures recall, with rich export and API integration on its roadmap.
Why is tracking tracing time a bad metric?
Because time spent is an input, not an outcome, and tracing in particular builds recognition rather than the recall that writing requires. A dashboard logging hours of tracing can look productive while building little, so optimizing for time pushes you toward low-value busywork. Track recall and accuracy, which reflect the actual skill.
What should my dashboard or commits represent?
A real from-memory session and the recall it produced, not tracing minutes. If a commit or logged session reflects from-memory mastery and accuracy, the integration reinforces genuine progress; if it reflects time, it reinforces busywork. Tie the data to production.
Does Hanzi Write Practice support these integrations now?
Its core, from-memory practice that measures recall and accuracy, is ready, and you can commit after a real session yourself today. Rich export, an API, and integrations like GitHub or webhooks are developer-friendly features on the roadmap. The important part, that the tracked metric is recall rather than tracing time, is already the design.
Wiring practice into your stack? Join early access and track recall, not tracing time.
