Most lists of "productivity shortcuts" are a hundred keybinds nobody actually memorizes. I use five things regularly enough that they've genuinely changed my week, and I can point to the specific repeated task each one replaced. Everything below is illustrative of my own workflow, not a benchmarked study — but the before-and-after steps are real, and I think that's more useful than a vague, unverifiable claim about total hours saved per week.
Text Expansion for the Replies I Type Fifty Times a Week
I use a lightweight text expander (Espanso, though the exact tool matters less than the habit) for the handful of messages I type in near-identical form constantly. Typing ";inv" expands into a full invoice follow-up message with placeholders for the amount and due date that I tab through and fill in. Typing ";bug" expands into a bug-report acknowledgment with a placeholder for expected turnaround. Typing ";sched" drops in my current availability blurb so I stop retyping the same three sentences every time someone asks to schedule a call.
Before: open a previous email, find one that's close enough, copy it, edit the specifics, hope I didn't leave a client's name in from the last recipient. That's a real mistake I've made, more than once. After: type four characters, tab through two placeholders, send. The snippet library only has about a dozen entries in it — I add one only after I notice myself typing the same thing a third time, which keeps the list from bloating into something I'd need to search through.
A Shell Function for Starting a New Feature Branch
Starting work on a new ticket used to be five separate manual steps: pull the latest main, create a branch named to match our convention, push it upstream so it shows up for teammates, open the ticket in the browser to copy its number, and open the project in my editor. I did this several times a week and always in the same order, which is exactly the kind of task a shell function should absorb.
Here's the function, trimmed to the relevant parts:
newbranch() {
git checkout main && git pull
git checkout -b "feature/$1"
git push -u origin "feature/$1"
code .
}
Running newbranch checkout-refactor replaces all five manual steps with one command and a few seconds of waiting. It's a small thing, but the actual win isn't the seconds saved typing — it's that I no longer occasionally forget to pull main first and end up branching from a stale point, which used to cost real time untangling later.
Window Management Shortcuts
I use Rectangle on macOS (the equivalent on other platforms is usually built into the window manager or available as a free utility) for a small set of binds I actually use daily rather than the full grid of options it offers:
Ctrl+Option+Left/Right— snap the active window to the left or right half of the screen, used constantly when comparing a doc against code.Ctrl+Option+Return— maximize, used when switching from split view into single-app focus.Ctrl+Option+C— center the window at a fixed size, used mainly for video calls so my camera framing doesn't shift every time.
Before these were bound to keys, arranging two windows side by side meant dragging each one to an edge and eyeballing the split, which I'd do wrong often enough to redo it. Three keybinds replaced a dragging habit I did dozens of times a day without ever quite doing it precisely.
The Script That Automates a Recurring Admin Task
The task I resented most was end-of-month invoicing across a handful of ongoing clients — pulling hours from a time tracker, calculating totals, formatting a document, and emailing it out. It wasn't hard, it was just tedious in a way that made me put it off, which meant invoices sometimes went out late, which is its own bad habit to be in as a freelancer.
I didn't write a custom billing system for this — that would have been solving a five-minute-a-month problem with a project-sized fix. Instead I generate the actual documents through the site's own invoice generator once the hours are pulled, which turns "format a professional invoice" from its own fifteen-minute task into something closer to two minutes of filling in numbers I've already gathered. The time tracker export is still a manual step, but cutting the formatting and layout work out of the loop was the part that made the whole task stop feeling like a chore I'd delay.
Browser Search Shortcuts I Didn't Expect to Keep Using
Most browsers let you assign a keyword to a custom search engine, and I underestimated this for years because it sounded like a marginal convenience. It stopped being marginal once I set up keywords for the handful of sites I search dozens of times a day: typing gh followed by a repo name jumps straight to that GitHub repository, ticket followed by a number opens that ticket directly in our issue tracker, and pkg followed by a package name opens its page on the package registry I use most.
Before: open a new tab, type the site name, wait for it to load, click the search box, type the actual query. After: type the keyword and the query in the address bar directly, hit enter once. It's maybe three or four seconds saved per search, which sounds trivial until you count how many times a day a developer searches a ticket tracker or a package registry — for me it's easily twenty or thirty times, and those seconds are also attention seams, small moments where a slow lookup invites a detour into an unrelated tab.
Setting one up takes under a minute: in most Chromium-based browsers, adding a custom search engine with a URL pattern like https://github.com/myorg/%s and a keyword like gh is all it takes, with %s substituted for whatever you type after the keyword. Firefox and most other browsers support the same idea under a slightly different settings menu, usually labeled something like "manage search engines" or "add a keyword for this search."
What Didn't Stick, and Why
Not everything I tried in this category earned a permanent spot, and the failures are worth naming because they explain the pattern behind what did work. A dedicated launcher app for opening applications by fuzzy-typed name looked useful in a demo and turned out to duplicate what my OS's built-in search already did adequately — I was maintaining a second tool for a problem that was already half-solved. A more elaborate snippet manager with folders, tags, and search across hundreds of possible entries got abandoned because I never had more than about a dozen snippets worth keeping, and browsing a tagging system for a dozen items is slower than just remembering four-letter triggers.
The pattern across both failures is the same one from the shell function and the text expander: the tools that stuck replace a specific, frequent, annoying manual sequence with something faster. The tools that didn't stick added a new interface to learn without removing an existing annoyance — they were solutions in search of a problem I didn't actually have often enough to justify the overhead of using them correctly.
There's a useful test hiding in that pattern: before adopting anything new in this category, I now try to name the exact manual sequence it replaces, in specific steps, the way I did for the branch-creation function above. If I can't list the steps it removes, it usually means I'm drawn to the tool itself rather than to a problem it solves, and those are the ones that quietly stop getting used within a month.
Illustrative Time Comparison
I want to be careful with numbers here, because I haven't run a stopwatch study on my own week — but roughly, and only as an illustration of the pattern rather than a verified figure: the branch-creation function turns what used to take two or three minutes into about ten seconds, several times a week. The text expander turns a two-minute email into a fifteen-second one, dozens of times a week. The invoicing change turns a fifteen-minute task into something closer to five, once a month per client. The search keywords save a handful of seconds dozens of times a day. None of these are individually dramatic. Added up over a month, they're the difference between admin work being background noise and admin work eating a visible chunk of a Friday.
How I Keep the System From Rotting
The failure mode with shortcuts and snippets isn't that they don't work — it's that they accumulate past the point of being memorable, and a text-expansion library with sixty half-remembered entries is worse than no library at all, because you spend time wondering if a shortcut already exists instead of just typing the thing out. Roughly every couple of months I go through my snippets and shell functions and delete anything I haven't used, which usually turns up two or three dead entries and confirms the rest are still earning their place.
None of this replaces having a sane system for deciding what to work on in the first place — shortcuts just make the mechanical parts of a day faster once you already know what you're doing. A fast branch-creation function doesn't help if you're not sure which branch is worth creating in the first place, and a snappy text expander doesn't fix a day that's already scattered across the wrong priorities. If the bigger issue is focus rather than friction, I broke down the actual tools I kept versus dropped for that in this piece on my deep work tool stack, and the two problems are worth solving separately rather than expecting one fix to cover both.
No comments yet.
Be the first visitor to add a thoughtful comment on this article.