I built an open-source Chrome extension to track how much time I actually spend learning to code

Ibad ur Rehman — Thu, 22 Oct 2026 09:37:28 +0000

Completing a lesson tells you where you are in a course. It doesn’t tell you how much time you spent working through it.

I use Scrimba to learn programming, and I wanted to make that effort more visible, without remembering to start and stop a timer every session.

So I built ScrimTrack, a free, open-source Chrome extension for Scrimba learners.

What should count as learning time?

This was the most interesting question behind the project.

Having a learning platform open doesn’t necessarily mean you’re studying. But typing and clicking aren’t the only signs of learning either. You might be watching an explanation and following the code without touching your keyboard.

ScrimTrack automatically tracks focused learning time. It also counts lesson playback while Scrimba stays visible and focused, so following a lesson counts even when you aren’t actively interacting.

That distinction matters for a platform like Scrimba, where a session can involve moving between watching an explanation and editing code.

It’s still a measure of time, rather than proof of understanding. But it gives you another way to see the effort you’re putting in alongside completed lessons.

Daily goals without managing another timer

ScrimTrack lets you set a daily learning goal and see your tracked time against it.

I wanted the routine to stay simple: open Scrimba, learn, and see the time you put in. Tracking shouldn’t become another task you have to manage.

Why a short session still counts

Learning streaks count consecutive days with tracked learning activity. You don’t have to complete your daily goal for the day to count.

If your goal is an hour but you only manage 20 minutes, you still showed up. I wanted the streak to reflect that.

The daily goal and streak answer different questions:

Daily goal: Did I put in the amount of time I intended?
Streak: Have I been showing up consistently?

A small tool for a specific workflow

ScrimTrack focuses on Scrimba because that’s the learning workflow I wanted to improve.

It’s also a project that connects what I’m learning with something I can use myself, and now share with other learners.

This is my first time sharing it on DEV, and I’d love feedback.

You can find ScrimTrack here: https://scrimtrack.xyz

If you use Scrimba, does this solve a problem you’ve had? And if you’ve built an activity tracker, how do you think about the difference between interaction, attention, and time spent?

Conventional Commits: a beginner’s guide to writing useful commit messages

Ibad ur Rehman — Wed, 21 Oct 2026 18:00:37 +0000

A commit message is a small note to whoever reads your code history next. Sometimes, that person is you, three months later, trying to understand why something changed.

Messages like update code or fix stuff don’t leave much to work with.

Conventional Commits gives those messages a simple, consistent structure. Here’s how it works, and where it helps.

The basic format

type(scope): description

For example:

feat(goals): add a daily learning target

There are three parts:

Type: the kind of change.
Scope: the part of the project affected. This is optional.
Description: a short explanation of what changed.

You can also add a body when the change needs more context.

Types you’ll commonly see

Type	Typical use	Example
`feat`	A new feature	`feat(dashboard): add weekly learning totals`
`fix`	A bug fix	`fix(timer): stop tracking when the tab loses focus`
`docs`	Documentation	`docs: explain how to install the extension`
`refactor`	Restructuring without changing behavior	`refactor(timer): extract session calculations`
`test`	Test changes	`test(streaks): cover consecutive learning days`
`chore`	Maintenance	`chore: update development dependencies`

The specification defines feat and fix; other types are allowed, so teams can agree on additional categories that suit their work.

These are illustrative examples for a learning tracker, rather than a list of actual commits.

The description still does most of the work

Compare:

fix: fix timer

with:

fix(timer): exclude time spent in background tabs

Both follow the format. The second tells you what behavior changed.

A useful question before committing is:

Could someone understand the purpose of this change without opening the diff?

For changes involving a tradeoff or a surprising decision, add the reasoning in the body:

fix(streaks): count learning days independently of daily goals

A learner can study without reaching their daily target.
Use tracked activity to determine whether the day contributes
to their streak.

That explanation preserves a product decision that the code alone might not make obvious.

What about breaking changes?

A breaking change requires consumers to adapt their existing usage. You can mark it with ! before the colon and explain the migration in a footer:

feat(config)!: replace trackingInterval with trackingIntervalMs

BREAKING CHANGE: Rename trackingInterval to trackingIntervalMs
and provide its value in milliseconds instead of seconds.

Under the convention’s Semantic Versioning mapping, fixes correspond to patch releases, features to minor releases, and breaking changes to major releases. Release automation needs to be configured to apply those rules.

Why use this?

A consistent structure can help people scan project history. It also gives tools predictable information for generating changelogs and determining version bumps.

You can start by writing messages manually. A commit-message linter or release pipeline can come later if it solves a problem in your workflow.

Where the convention falls short

A Hacker News discussion about Conventional Commits raised a useful concern: it’s possible to spend more effort categorizing a change than explaining it.

Adding fix: to an unclear message doesn’t make it informative. And a generated changelog may still need editing before it helps users understand a release.

My takeaway is to keep the format simple and put care into the description and reasoning. The convention provides structure; the writer provides context.

For your next commit, try:

type: describe the specific change

Add a scope if it helps, and a body if there’s reasoning worth preserving.

Do you use Conventional Commits in your projects? Has the structure helped you, or do you prefer another approach?

DEV Community: Ibad ur Rehman