There’s an endless supply of “top 50 tools every developer needs” lists, and most of them are noise. New tools have a cost — learning them, configuring them, maintaining them — and most don’t pay it back. After years of adding and dropping tools, here’s what actually moves the needle on speed, and what’s usually just shiny.
Get fast where you spend the most time
The highest-leverage tools are the ones you touch hundreds of times a day: your editor and your terminal. A 2% speedup on something you do constantly beats a 50% speedup on something you do once a month. Learn your editor’s real shortcuts (multi-cursor, go-to-definition, project-wide search and replace), and get comfortable in the terminal instead of reaching for a GUI. This is boring advice precisely because it’s the advice that works.
Automate the commands you retype
Any command you type more than a few times a week should become one word. Shell aliases and a task runner (Make, or just) remove dozens of tiny frictions a day. The win isn’t the seconds saved — it’s never losing your train of thought to remember the exact flags.
# A few git aliases that earn their keep
git config --global alias.s "status -sb"
git config --global alias.last "log -1 HEAD --stat"
git config --global alias.undo "reset --soft HEAD~1"
# A tiny Justfile so "just up" / "just logs" just works
# up: docker compose up -d --build
# logs: docker compose logs -f --tail=200
# fresh: git pull && just upTreat Git as a precision tool, not a save button
Most developers use maybe 10% of Git and fear the rest. The payoff from learning a bit more is huge: small, focused commits with clear messages; git bisect to find the commit that introduced a bug in minutes instead of hours; git stash to switch context without losing work; interactive rebase to clean up history before a PR. Git isn’t just version control — it’s a debugging and collaboration tool. Invest the afternoon.
Make the boring stuff automatic
Formatting, linting, tests, and deployment shouldn’t rely on you remembering to run them. A formatter on save and a linter in CI end every style argument permanently. A simple CI pipeline that runs your tests on every push catches breakage before it reaches anyone. And a one-command (or push-to-deploy) release removes the single biggest source of deploy-day mistakes: manual steps. If a task is important and repetitive, a machine should own it.
When something breaks, see inside the system
The slowest debugging is guessing. The tools that pay for themselves here are the ones that let you observe: real logs you can tail, your framework’s debug output, the browser network tab, and a way to inspect what’s actually hitting your server. Half of “impossible” bugs evaporate the moment you stop assuming and actually look at the request, the response, and the logs. Learn your stack’s observability tools before you need them at 2 a.m.
What’s usually just noise
Be skeptical of tools that add a layer without removing a problem you actually have: the fifth note-taking app, elaborate dotfiles you copied but don’t understand, a new framework for a problem your current one already solves, or anything you’d spend more time configuring than it saves. A tool is worth it when it removes a friction you feel often — not because it trended this week.
The takeaway
Speed doesn’t come from collecting tools — it comes from mastering a small set that matches where your time actually goes. Get fast in your editor and terminal, automate what you retype, treat Git as a real tool, let machines own the repetitive stuff, and make your system observable. Add anything else only when you feel the friction it removes.