A Confession About Tool Hoarding
I used to install every shiny tool I found. 90% were a waste of time. My dock was crammed with apps I opened once, my terminal had aliases pointing to utilities I’d forgotten existed, and my VS Code sidebar looked like a plugin graveyard. Sound familiar? Probably does, if you’ve been writing code for more than a couple of years.
Somewhere around 2023, I started doing annual audits. Brutal ones. Every tool that hadn’t earned its spot in the last 90 days got uninstalled. No exceptions. What remained was a tighter, faster, more deliberate setup. And honestly? My output went up. Not because I had fewer distractions — though that helped — but because the tools that survived the purge were ones I actually understood deeply.
So here’s my 2026 list. Fifteen tools that stuck. Not because they’re trendy or because someone on Twitter told me to install them. They stuck because I reached for them almost daily, and each one solved a problem I couldn’t solve as well without it.
I’ve grouped them into four buckets: browser extensions, CLI utilities, editor extensions, and productivity tools. Some of you will know most of these already. A few might surprise you.
Browser Extensions That Actually Earn Their Keep
1. React Developer Tools
Still here. Still irreplaceable for React developers. The 2026 update did something I’d been wanting for years though — proper Server Components visibility. You can now see exactly which pieces of your component tree rendered server-side versus client-side, and the boundary is highlighted right in the tree view.
But the real upgrade? Profiler integration with Core Web Vitals. Say a layout shift tanks your CLS score. Previously, you’d be squinting at a waterfall chart trying to figure out which re-render caused it. Now the profiler traces the chain: this component re-rendered, which triggered a DOM mutation, which caused the shift. Direct line from code to metric. I caught three CLS regressions last month that would have taken me hours to find the old way.
Worth noting: the extension is heavier than it used to be. If you’re not actively debugging React, consider disabling it to keep your browser snappy.
2. Wappalyzer
Call it a guilty pleasure. Wappalyzer tells you what tech stack any website is running — frameworks, CMS, analytics, CDN, hosting provider, the lot. Is it strictly necessary? No. Do I click it on every interesting site I visit? Absolutely.
Where it actually pays for itself is client work and competitor research. Last quarter, a potential client said they were “on WordPress.” Wappalyzer showed me they were running a headless WordPress backend with a Next.js frontend, behind Cloudflare, with Segment analytics. That five-second glance saved me from writing a proposal that assumed a traditional WordPress theme.
Detection accuracy for server-rendered frameworks has gotten noticeably better this year. It’s not perfect — it still misses some custom setups — but for a quick read on someone’s stack, nothing else comes close.
3. JSON Viewer Pro
Small tool. Big impact. Raw JSON in a browser tab is unreadable garbage. JSON Viewer Pro gives you syntax highlighting, collapsible nodes, and a search function. It handles large payloads without choking. And the JSONPath query support lets you filter through deeply nested structures without copying everything to another tool.
I probably use this thirty or forty times a day during active API development. It’s one of those utilities where the time saved per use is tiny, maybe a few seconds, but multiplied across a full workday it adds up to something real. There are alternatives — JSON Formatter, JSON Lite, a handful of others — but Viewer Pro handles edge cases better than most. Deeply nested arrays of objects with mixed types, payloads over 5MB, responses with Unicode characters that trip up simpler parsers. It just works.
CLI Utilities Worth Learning
4. Warp Terminal
Warp rethinks what a terminal should be. Instead of a continuous scroll of text, every command and its output lives in its own block. You can scroll through blocks independently, copy an entire block’s output, or share it with a teammate. It sounds like a gimmick until you try it. Then you wonder how you tolerated the old way.
The AI command suggestions are polarizing. Some developers find them helpful — you describe what you want in natural language, and Warp suggests the right command. Others consider it a crutch. I land somewhere in between. For commands I run rarely (obscure ffmpeg flags, niche Docker networking), the suggestions save real time. For my everyday workflow, I ignore them.
Big news for 2026: Windows support finally shipped. It had been macOS and Linux only, which limited adoption. If you’re on Windows and still using the default terminal or even Windows Terminal, give Warp a week. The block-based model alone might convert you.
5. lazygit
A terminal UI for Git. Open it and you get an interactive interface with panels for files, branches, commits, and stashes. Interactive rebasing becomes a matter of moving lines around instead of memorizing arcane command sequences. Cherry-picking is drag-and-drop (well, keyboard-driven drag-and-drop). Conflict resolution shows you both sides with inline editing.
I resisted this one for a while. Felt like “real” developers should use raw Git commands. That’s nonsense, of course. lazygit doesn’t dumb anything down — it makes the same operations faster and more visual. My interactive rebases went from “okay let me think about this carefully” to “done in ten seconds.” Diffs render inline. Branch graphs display clearly. Submodules work without pain. If you’re doing anything beyond basic commit-push workflows, lazygit is worth your time.
6. HTTPie
HTTPie replaces curl for API testing. The syntax alone justifies it:
http POST api.example.com/users name=anurag email=anurag@byteyogi.comCompare that to the curl equivalent with its forest of flags. HTTPie formats JSON responses with colors, handles authentication cleanly, and supports sessions for stateful testing. The desktop app adds request collections and environment variables, turning it into a lightweight Postman alternative that lives closer to your terminal workflow.
I’m not saying curl is bad. curl is phenomenal. But for interactive API exploration — the kind you do while building and debugging — HTTPie’s developer experience is just better. You’ll still need curl for scripts and automation. And that’s fine. Different tools for different jobs.
7. fzf
Fuzzy finder. Pipe any list into it, get instant interactive filtering. That description undersells it dramatically.
fzf transforms your shell. Search command history with fuzzy matching instead of pressing up-arrow forty times. Find files across your entire project without typing exact paths. Switch Git branches by typing fragments of the name. Select Docker containers from a filtered list. Pick Kubernetes pods without copy-pasting UUIDs.
It integrates with Bash, Zsh, and Fish. And because it’s a Unix filter — takes stdin, produces stdout — you can compose it with any other command. git branch | fzf | xargs git checkout gives you an interactive branch switcher in one line. docker ps | fzf | awk '{print $1}' | xargs docker logs lets you pick a container and see its logs. The composability is where fzf goes from “nice to have” to “can’t work without it.”
Editor Extensions That Changed How I Code
8. GitHub Copilot / Cursor AI
Let’s skip the philosophical debate about whether AI code completion is “real programming.” It is. Move on.
In 2026, the question isn’t whether to use AI assistance — it’s which one. Copilot inside VS Code and Cursor’s native AI features are the two front-runners. Both understand your codebase context. Both generate boilerplate, write tests, and explain unfamiliar code. Both have gotten significantly better at suggesting code that actually works on the first try.
I bounce between Copilot and Cursor depending on the project. Copilot feels more natural for quick completions — it stays out of the way and fills in the obvious next line. Cursor shines when you need broader context awareness, like refactoring across multiple files or asking questions about a codebase you’re new to.
One thing I’ve noticed: developers who get the most from these tools aren’t passive about it. They write clear function names and comments that give the AI better context. They reject bad suggestions quickly. And they review generated code with the same scrutiny they’d apply to a junior developer’s pull request. The tool amplifies your skill. It doesn’t replace it.
9. Error Lens
Tiny extension, outsized effect. Error Lens shows diagnostic messages inline — right next to the line that caused them. No hovering over red squiggles. No checking the problems panel. Errors and warnings appear immediately as you type, in colored text right there in your editor.
Sounds minor. It isn’t. The feedback loop tightens dramatically. You introduce a type error. You see it instantly. You fix it before you’ve even finished writing the function. Without Error Lens, you might not notice that red squiggle for another five minutes, by which point you’ve built three more things on top of the broken assumption.
Fair warning: some people find it visually noisy. I’d suggest trying it for a full week before deciding. The initial overwhelm fades once your brain adjusts to the information density.
10. GitLens
GitLens puts Git history directly in your editor. Inline blame shows who changed each line and when. File history lets you step through every revision. Comparison tools let you diff branches, commits, or stashes without leaving VS Code.
Where it really earns its place is on team codebases. You’re reading a function that looks wrong. GitLens tells you who wrote it, when, and in what commit. You click through to the commit message and understand the reasoning. Maybe it’s not wrong after all — maybe there’s a constraint you didn’t know about. That kind of context prevents a lot of unnecessary “fixes” that break things.
The extension has gotten heavier over the years. I’d suggest tweaking the settings to disable features you don’t use. The blame annotations and file history are gold. Some of the other features — the graph view, the remotes panel — I could probably live without.
11. Thunder Client
REST API client inside VS Code. Supports collections, environment variables, tests, and GraphQL. Replaces Postman for maybe 80% of what most developers use Postman for.
The killer advantage is context switching. Or rather, the absence of it. You’re writing an API endpoint. You want to test it. Tab over to Thunder Client, fire a request, see the response. Tab back. No separate app to open. No alt-tabbing. No losing your place. For iterative API development — write a handler, test it, fix it, test again — that seamlessness (pardon the word) matters more than you’d think.
Request collections can be committed to your repo, which means your team shares the same set of test requests. New developer joins? They pull the repo and have every API call ready to go. That alone saves hours of onboarding.
Productivity Tools Beyond the Editor
12. Raycast (macOS) / PowerToys (Windows)
If you’re on macOS, Raycast replaces Spotlight with something built for developers. Search GitHub PRs without opening a browser. Create Jira tickets from a keyboard shortcut. Manage your clipboard history. Switch windows. Run scripts. It integrates with GitHub, Linear, Notion, Jira, Slack, and dozens more.
On Windows, PowerToys fills a similar niche, though it’s a collection of utilities rather than a unified launcher. FancyZones handles window management — snap windows into custom grid layouts. PowerToys Run is a quick launcher with plugin support. File Locksmith shows you which process has a file locked (something every Windows developer has needed at 2 AM while debugging a build failure).
Either way, the point is the same: reduce mouse usage. Every time you reach for the mouse to do something you could do with a keyboard shortcut, you’re losing a little momentum. These tools make keyboard-driven workflows practical.
13. Obsidian
Markdown-based notes. Local storage. Bidirectional linking. Graph visualization. Plugin ecosystem rivaling VS Code’s. That’s Obsidian in one breath.
I use it for architecture decision records, meeting notes, debugging journals, and learning notes. The bidirectional linking is what makes it stick — when I write a note about a design decision, I can link it to the project, the ticket, and the related technical concepts. Over time, you build a knowledge graph that’s genuinely useful for answering “why did we do it this way?” six months later.
The local-first approach matters. Your notes aren’t in someone else’s cloud. They work offline. They’re plain Markdown files you can grep, version control, or migrate to another tool. No lock-in. For a developer, that philosophy resonates.
14. Excalidraw
Whiteboard tool. Hand-drawn aesthetic. Architecture diagrams, flow charts, database schemas — they all come out looking approachable rather than formal. I’ve found that hand-drawn-style diagrams actually get more engagement in pull request descriptions and design docs. People look at a polished diagram and skim it. People look at a sketchy diagram and study it. Weird, but consistent in my experience.
Collaboration works in real time, so you can sketch with your team during a call. And the VS Code extension lets you embed .excalidraw files directly in your project repo. Architecture diagrams that live with the code they describe? Yes, please.
15. Linear
Project management that doesn’t make you hate project management. Linear’s interface is keyboard-driven, fast, and opinionated. It makes decisions for you about workflow stages, which sounds annoying until you realize those decisions are usually right.
Cycles (their version of sprints) work well for teams that don’t want heavy Scrum ceremony. Roadmaps connect to actual issues. GitHub integration syncs PR status with issue status automatically. It feels like a tool built by developers who were frustrated with Jira. Because, well, it was.
I will say: Linear works best for teams under ~50 people. If you’re at enterprise scale with complex reporting needs and cross-team dependencies, Jira’s flexibility probably still wins. But for startups and small-to-mid teams, Linear is a breath of fresh air.
The Real Secret: Depth Over Breadth
Here’s what I’ve learned from five years of annual tool audits. The number of tools you have doesn’t matter. What matters is how deeply you know the ones you keep.
A developer who understands five tools thoroughly will outpace someone juggling fifty shallow ones. Every time. I’ve watched it happen on teams I’ve led and teams I’ve been part of. The person who knows their editor’s keyboard shortcuts, who’s customized their terminal, who’s built muscle memory around their core utilities — that person ships faster and with fewer errors.
So don’t treat this as a shopping list. Treat it as a starting point. Pick two or three you’re not already using. Learn them for real — read the docs, customize the config, push past the initial awkwardness. If they stick after 90 days, they’re keepers. If not, uninstall them without guilt.
One more thing. Your tools should evolve as your work evolves. When I was writing mostly frontend React code, my toolkit looked different than it does now that I’m doing more backend and infrastructure work. The CLI utilities got more important. The browser extensions got less so. A tool that’s perfect for you today might be dead weight next year, and that’s okay. The audit process catches these shifts before they become clutter.
The best toolkit is the smallest one that covers your actual needs. Everything else is noise.
