No Mouse 30: A Quiet Experiment in Keyboard-First Work

Why I’m Doing This

A few weeks ago my wrist started hurting.

Not the sharp, obvious kind of pain. The dull kind that shows up halfway through the day and lingers. I checked the usual things. Keyboard height. Chair. Breaks.

None of it really helped.

What finally stood out was how often my hand left the keyboard. Not for long stretches of design work, but for constant small trips to the mouse. Clicking buttons. Closing panes. Grabbing UI controls I already knew how to use without leaving the keys.

The typing wasn’t the problem. The switching was.

How the Mouse Became the Default

Most developer tools are built for the keyboard. Editors, terminals, git. I know the shortcuts and I’ve spent years building muscle memory around them.

Still, when I’m tired or moving fast, I reach for the mouse. It’s easy. It’s visual. It feels like the shortest path.

But it quietly slows real work. Every click pulls attention away from whatever state I was in. The cost isn’t the click itself. It’s the context shift around it.

Do that a few hundred times a day and you feel it. In your head. And, apparently, in your wrist.

No Mouse 30

So I’m doing a 30-day “No Mouse” challenge.

The idea is simple: work keyboard-first wherever it makes sense and notice where the friction is.

I put it in a GitHub repo: \n https://github.com/alexcloudstar/no-mouse-30

This isn’t about purity or proving anything. It’s a small constraint to force better habits and see what breaks.

The Rules (Such as They Are)

There aren’t many rules.

I’ll avoid the mouse when I can. I’ll use it when I need to. If something becomes annoying enough, that’s a signal to fix the workflow instead of pushing through.

Exceptions are allowed. Perfection isn’t the goal. Awareness is.

If I end a day having learned one new shortcut or removed one small annoyance, that’s a win.

Why Keyboard-First Reduces Friction

Keyboard-first workflows keep your hands and attention in one place.

You don’t scan for buttons. You don’t aim a cursor. You don’t break focus just to do something small.

Examples from my own day:

• Switching files with fuzzy search instead of clicking a sidebar
• Running tests from the terminal instead of a menu
• Navigating git history without leaving the editor
• Jumping between panes with keys instead of dragging

None of this is new or impressive. The difference is doing it consistently enough that it becomes the default.

The Browser Is the Hard Part

The browser is where most mouse usage sneaks back in.

Docs, dashboards, GitHub, issue trackers. This is where things fall apart if you’re not careful.

A Vim-style extension helps a lot. I use Vimium.

A few examples:

• Press f to jump to links
• Use j and k to scroll
• / to search the page
• gg and G to jump to the top or bottom

It’s awkward for a few days. Then it stops being something you think about. The browser becomes less of a mode switch and more like another tool.

Why This Is Public and PR-Based

I’m keeping this challenge public and using pull requests instead of a form or an app.

The repo is here: \n https://github.com/alexcloudstar/no-mouse-30

A few reasons:

Developers already understand repos and PRs. Writing short notes scales better than tracking metrics. And reading other people’s setups and mistakes is often more useful than stats.

You can skim. You can contribute. Or you can just watch quietly.

Who This Is For

This is for developers who spend most of their day at a keyboard and feel small, accumulating friction in their workflow.

It’s for people who want to improve habits without turning it into a productivity challenge.

It’s not for designers who need a mouse for their work. It’s not for anyone dealing with serious pain who should be talking to a professional instead of running experiments.

If You Want to Join

I’m doing this for myself first.

If it sounds useful, you’re welcome to join or just read along. Try it for a few days. Take one idea. Ignore the rest.

No pressure. No streaks. No promises.

Just a quiet 30-day experiment to see if working closer to the keyboard makes things a little smoother.

\