A grader's toolkit beside the work

Problem

I work at a K-12 online learning provider: schools in the US and abroad partner with us so their students can take courses online. When students hand in assignments, a small team of staff grades them in a web-based grading tool. To grade well, a grader needs the answer key or rubric (the scoring guide) for that lesson, and sometimes the student’s record in the teachers’ part of the platform. Graders kept these open in separate places, searched for the rubric every time, and could not easily see whether ungraded work was building up.

Constraints

• The panel had to fit around a grading tool I do not own, without changing it.
• It could only ever show a grader what they were already allowed to see.
• Graders rely on it while they work, so a broken version would interrupt real grading.

What I built

A browser add-on panel written in JavaScript. I started it in June 2026, and it reached version 48 in November 2026. It does three things:

• Shows the grading files for the lesson on screen. The panel finds the answer keys and rubrics linked to that lesson, or to the whole course if there are none. Files nobody can open are hidden, so nobody clicks a dead link.
• Jumps between views. One button takes a grader from the grading page to the same student and lesson in the teachers’ view, and back.
• Charts the workload. A chart shows how much work was waiting to be graded each weekday morning, so the team can see a pile building before it becomes a problem.

The full chart page is deliberately simple. It only receives totals that are already added up, it has no way to fetch anything on its own, and it stores nothing. It never sees a student or a grader, and a test fails if that ever changes.

How I proved it worked

• Every change can be undone exactly. Each new version is made by a small script that turns the old file into the new one and can also run backwards. Getting the old file back exactly proves nothing else changed.
• Protected parts stay protected. Sections that must never change are compared with a saved earlier version, never with the file about to be released.
• What is running matches what I wrote. After each release, a check compares the live files with my saved code by their fingerprints (hashes: short codes that change if even one character changes) until they match.
• I test the tests. A new test must fail on the old version first, or it is not testing anything. When the jump button disappeared on one review page, the new test failed on the old version for exactly the two broken page layouts, and passed on the fix.
• I keep the record honest. Since the test suite was added in August 2026, about a third of releases went out with every test passing. Most of the rest went out with known failures written down, many of them caused by two wrong checks in one test rather than by the panel.

Outcome

• At version 48 in November 2026, guarded by more than 50 automated tests.
• A check of which lessons had a grading file showed that most waiting work was on lessons with no file of their own yet: missing files, not broken links. About nine in ten broken links came from one retired course, and each of those files matched a lesson in the live course.

What I would do next

• Run the tests automatically on every change, and block a release if any fail.
• Keep each rule in one shared place. Three times, the panel and the chart page each had their own copy of a rule, and only one copy got updated.
• Work with the people who own the grading files to fill the gaps, starting where the most work waits.

The demo it pairs with

Grader’s panel mock. A pretend grading page with made-up assignments and the panel open beside it. Pick a lesson to watch its files appear, jump to the same student in the teachers’ view, and scrub through the workload chart.