If you've ever shipped a "typing speed" feature into a developer tool, an educational dashboard, or a hiring pipeline, you've probably noticed that the simplest-looking metric in computing — words per minute — is also one of the easiest to game and the hardest to defend in a code review. The original article in this series pushes past the 80 WPM plateau. This one is for the people building the measurement itself: how do you write a typing test that survives scrutiny from an accessibility lead, a data engineer, and a skeptical senior dev all at the same time?
We'll walk through the constraints, the formulas, the edge cases that bite in production, and a checklist you can paste into a PR description. Where the underlying mechanics of WPM calculation matter, I'll point to a thorough walkthrough at Lizely's WPM formula guide so you don't have to reinvent the theory from scratch.
The Two Meanings of "Word" You Need to Settle Before Anything Else
A typing test fundamentally answers "how many characters did a user commit, and over what interval?" Everything else is convention. Before you write a single line of measurement code, decide which of these two definitions your product will use, because they produce noticeably different numbers for the same user:
