Most developer “productivity advice” sounds like it’s trying to sell you a new framework. I’ve stopped chasing shiny. The tools that actually make me faster are quieter—little interfaces that remove friction from work I do constantly. After a year of experimenting, these are the five developer tools I’d miss first. Not because they’re glamorous, but because they compound: shave seconds off every task, and you magically earn back hours by the end of the month.

Warp Terminal: AI command search that actually feels instant⌗

I don’t use terminal menus. I use muscle memory—until I don’t. Warp Terminal fixed that gap with AI-powered command search, which is especially useful when you’re trying to remember the exact incantation you ran yesterday.

Here’s what this looks like in real life: I’ll be half-thinking about a task—“I need to tail logs for that service”—but I’m not sure which command I used last time. Instead of fumbling through history or scanning docs, I type a partial intent and Warp narrows down the candidates. It’s not magic; it’s fast retrieval. And fast retrieval beats slow recall.

Practical ways to lean into it:

  • Search by purpose, not by command. If you’re working with Docker, Kubernetes, or a custom CLI, use natural language like “restart api container” or “stream logs web worker.”
  • Keep your history clean enough to matter. If you run scripts that generate noise, consider aliases or wrapper scripts so your “searchable” history remains useful.
  • Use it as a bridge, not a crutch. I still memorize frequent commands, but Warp handles the long tail—the ones you only run occasionally.

Warp also improved my baseline terminal experience: speed, keyboard navigation, and a UI that encourages you to iterate rather than hesitate. In practice, it reduces the “I should look this up” moments that quietly steal focus.

Raycast: the Spotlight replacement that understands developers⌗

If Warp makes the command line easier to navigate, Raycast makes the computer itself easier to navigate. For me, it effectively replaced macOS Spotlight as the default “search and launch” surface—except it’s faster, more configurable, and built for repeatable workflows.

The difference is subtle: Spotlight is great for finding files and launching apps. Raycast is great for doing tasks. That means you don’t just open the thing—you get the right action immediately.

Concrete examples that show why I kept it:

  • Jumping between projects. Instead of digging through folders, I hit Raycast and type the project name. It opens the right directory, sometimes with a command to start the dev server.
  • Clipboard and snippet workflows. Copy something in one app and insert it into another without manually juggling context. If you do any kind of copy/paste-heavy work (migrations, config updates, API payloads), Raycast pays for itself quickly.
  • Command palettes for dev chores. You can build or install extensions that perform actions like “create branch,” “run test,” “open logs,” or “switch environments.” The win isn’t that it’s novel—it’s that it removes steps you repeat daily.

My rule: if I catch myself switching windows, hunting through menus, or retyping routine actions more than twice in a day, Raycast is where I fix it. I treat it like part of my workflow infrastructure, not a “nice-to-have launcher.”

Fig: shell autocomplete that turns typing into intention⌗

Autocompletion is one of those benefits that’s easy to underestimate until you use it for a week. Fig extends your terminal experience with smarter autocomplete, which helps when your CLI ecosystem is large: multiple package managers, internal commands, and a web of scripts that never quite share the same flags.

The best part is that autocomplete isn’t just about saving keystrokes. It’s about preventing mistakes. When you’re halfway through a command and you realize you forgot a flag—or you used a wrong argument—you can waste minutes rerunning. Fig reduces that by making the likely next tokens visible.

How I use it:

  • Autocomplete for flags and subcommands. If I’m working with tools like git, docker, or a framework CLI, Fig makes it easy to discover valid options without memorizing syntax.
  • Tab-completion for “where did this live again?” moments. When you have scripts across repos, Fig helps you navigate the landscape faster than searching by filesystem paths.
  • Speed during refactors. Renaming commands, changing environments, or swapping parameters becomes less scary because the shell can guide you as you type.

If you already have a great terminal workflow, you might think Fig is redundant. It isn’t. It’s the layer between “I know what I want” and “I can’t remember the exact text.” That layer saves time and lowers mental load.

TablePlus: database work that doesn’t feel like punishment⌗

Databases are where productivity goes to die—unless your tool gets out of the way. I use TablePlus for everything from quick inspections to more involved admin tasks. The key feature isn’t just that it works; it’s that it makes database work comfortable.

When I’m debugging, I want two things immediately:

  1. Fast visibility into what’s happening (tables, rows, indexes, schema).
  2. Low-friction editing (writing queries, running them, iterating, copying results).

TablePlus nails the loop: open connection → inspect schema → write query → run → adjust → repeat. The UI matters because database work is iterative by nature. When the tool is clunky, iteration slows down. When it’s smooth, iteration becomes normal.

A few practical workflows I rely on:

  • Inspect schema without tab-hopping. I can look up columns and constraints without bouncing between a migration file, an admin UI, and documentation.
  • Query iteration with results in view. I often build queries step-by-step. Being able to tweak and re-run with minimal friction reduces the “SQL downtime tax.”
  • Export and share results quickly. When debugging with teammates, sending the right snippet matters. TablePlus makes it easier to extract exactly what someone needs.

For a surprising number of developer tasks, the database is the source of truth—and TablePlus turns the source of truth into something you can access without suffering.

Obsidian: the documentation system that stays out of your way⌗

Codebases change. Your memory won’t. Obsidian is my technical documentation “home base” because it’s flexible enough to capture messy reality: notes, snippets, decisions, postmortems, and links between them. It’s not a formal doc platform. It’s better than that—it’s a living workspace.

I use it for exactly the kind of documentation teams avoid because it’s “not urgent.” That’s where Obsidian wins: it makes documentation feel lightweight and immediate, so you actually keep it current.

Examples of notes I maintain:

  • Runbooks for recurring problems. “How to reset X” or “What to check when Y fails” in a format I can search in minutes.
  • Project decision logs. When we choose a library, change an architecture, or decide not to adopt something, I record the reasoning. Months later, I can answer “why” without guessing.
  • Snippets with context. Not just code blocks—include where it came from and when to use it.

What makes it effective is the compound behavior: once you’ve connected related notes, you stop re-explaining the same concepts. Search becomes meaningful, not just a pile of text. And when you’re onboarding or debugging at 2 a.m., that “connected knowledge” matters more than any polished markdown page.

My approach is simple: if I fix something that future-me will have to do again, I write down the fix while it’s fresh. Obsidian makes that habit practical.

The real lesson: invest in the local dev environment before your stack⌗

None of these tools are frameworks or languages. That’s the point. They’re productivity multipliers in the most boring place possible: your local workflow. They reduce friction around the activities you repeat constantly—typing commands, switching contexts, querying databases, and finding answers later.

In my experience, “stack investing” is easy to justify because it’s visible: new framework, new library, new architecture. But the daily time sink is usually the environment around the stack—how quickly you can operate it, navigate it, and recover from mistakes.

If you want a practical starting point, do this:

  • Pick one bottleneck you hit daily (command recall, app switching, DB debugging, or documentation retrieval).
  • Trial one tool for a week.
  • Measure the time you spend on the annoyance, not the time you spend admiring the feature.
  • Keep the tool only if it becomes part of your default workflow.

Because the truth is, speed doesn’t come from doing more. It comes from doing less of what slows you down.

Conclusion: compound speed beats occasional heroics⌗

Warp, Raycast, Fig, TablePlus, and Obsidian aren’t flashy. They don’t rewrite your architecture. They just make routine work smoother—and that’s exactly what turns small improvements into hours over time. If you want to get faster in 2022, start by fixing your local environment. That’s where productivity quietly lives, and where it compounds.