Developer Tools I Actually Use: A Short List with Trade-offs

A practical developer-tool list organised by problem, ownership, reproducibility, security boundaries, and exit cost.

0xNN · July 16, 2026 · 6 min read

Tool lists are easy to write and easy to ignore. Instead of calling everything “essential”, I am listing tools by the problem they solve and the boundary I check before adding them to a project. Your stack, team, and threat model may lead to different choices.

Editor and terminal

Use an editor with language support, formatting, and diagnostics that run on save. Keep the terminal close enough that the real build and test commands remain visible. Extensions are code too: review permissions, update them, and remove what you no longer use.

Git and code review

Git is the history of decisions, not just a backup button. Small commits, descriptive pull requests, and a review checklist make changes easier to understand. Protect the default branch and require tests for changes that can affect production.

HTTP and API inspection

Browser DevTools, curl, and an API client help answer different questions. Inspect the actual request, status, headers, timing, and response body before blaming the frontend. Never paste production tokens into a shared workspace or a public collection.

Runtime and dependency checks

Use the package manager's lockfile and a reproducible install in CI. Check why a dependency is present, whether it is maintained, and what permissions it receives. A security scanner is a signal to investigate, not proof that an application is safe.

Notes and observability

Keep a short decision log for non-obvious trade-offs. In production, use structured logs, a health endpoint, and an error tracker with sensitive fields removed. A dashboard that cannot answer “which version failed?” is decoration, not observability.

How I decide whether to keep a tool

I ask whether it reduces a repeated problem, has a clear owner, works in CI, exports its data, and can be removed without rewriting the product. If a tool adds a second source of truth or hides a security boundary, the convenience must be unusually strong to justify it.

The best tool is the one your team can explain, update, and replace. A short list is valuable only when every item has a reason.

References

• Git documentation
• MDN: Browser DevTools
• OpenSSF Scorecard