Developer Productivity Tools for Senior Engineers

The best developer productivity tools don't make you type faster — they cut the friction between thinking and executing. That's the whole idea: fewer context switches, fewer manual steps, more time in flow. Below is the exact stack I use after 5+ years of building software professionally — editor, terminal, review habits, and focus systems, in one place. See also AGENTS.md Files Don't Work the Way You Think.

TL;DR

• An AI-native editor (Cursor) plus a terminal-first agent (Claude Code CLI) removes more friction than any keyboard shortcut ever will.
• fnm replaces nvm for near-instant shell startup — this alone is worth the five-minute switch.
• Clean git history and disciplined PR size make review faster for everyone, not just you.
• Protecting 2-3 hour deep-work blocks beats squeezing out marginal typing speed.
• Writing short decision records saves hours of re-explaining choices months later.

What Is the Developer Productivity Tools Stack?

Developer productivity tools are the editors, terminal utilities, and workflow habits that shrink the gap between having an idea and shipping working code. A good stack removes friction. It doesn't just bolt on more features.

Editor: Cursor AI + Claude Code CLI

I use AI-native editors that accelerate my workflow:

• Cursor AI for primary development — AI assistance woven into the editing experience for rapid prototyping, complex refactors, and context-aware code generation
• Claude Code CLI for terminal-based workflows — when I need to work through complex problems, review code, or make sweeping changes across a codebase directly from the terminal

Key Editor Settings

{
  "editor.formatOnSave": true,
  "editor.bracketPairColorization.enabled": true,
  "editor.minimap.enabled": false,
  "editor.stickyScroll.enabled": true,
  "typescript.preferences.importModuleSpecifier": "non-relative"
}

Why AI-Native Editors

Traditional editors are passive. They wait for you to type. AI-native editors are collaborative — they understand your intent and help you get there faster. For boilerplate, test generation, and refactoring, the productivity gain is substantial.

Terminal: iTerm2 + Zsh

My terminal is where I spend the second most time after the editor.

Shell Aliases That Save Hours

# Git shortcuts
alias gs='git status'
alias gc='git commit'
alias gp='git push'
alias gl='git log --oneline -20'
alias gco='git checkout'
alias gbd='git branch -d'

# Project shortcuts
alias dev='pnpm dev'
alias build='pnpm build'
alias test='pnpm test'
alias lint='pnpm lint'

# Navigation
alias ..='cd ..'
alias ...='cd ../..'
alias proj='cd ~/Projects'

Why fnm Over nvm?

I switched from nvm to fnm (Fast Node Manager). The speed difference is noticeable. Shell startup went from ~500ms to ~50ms.

# .zshrc
eval "$(fnm env --use-on-cd)"

The --use-on-cd flag automatically switches Node versions when you enter a directory with a .node-version file.

Git Workflow

Commit Conventions

I follow Conventional Commits for all personal projects:

feat: add search functionality to blog
fix: resolve hydration mismatch in SSR
refactor: extract shared form validation logic
docs: update API documentation for v2

Interactive Rebase for Clean History

Before opening a PR, I clean up my commits:

git rebase -i HEAD~5

A clean git history isn't just vanity. It makes git bisect actually useful when tracking down bugs months later.

Code Review Habits

As both a reviewer and author, I've developed habits that keep reviews effective:

As an Author

• Keep PRs under 400 lines when possible
• Write a description that explains the why, not just the what
• Self-review before requesting review — catch the obvious stuff yourself
• Add inline comments on tricky sections to guide reviewers

As a Reviewer

• Start with the PR description and linked ticket
• Read tests first — they tell you what the code should do
• Focus on logic, not style (that's what linters are for)
• Ask questions instead of making demands: "What happens if X?" not "Change this to Y"

Focus Management

Time Blocking

I protect 2-3 hour blocks for deep work:

• Morning (9-12): Complex coding, architecture, debugging
• Afternoon (1-3): Code reviews, meetings, collaboration
• Late afternoon (3-5): Documentation, planning, lighter tasks

Notification Management

• Slack: Check every 30 minutes during focus blocks, not continuously
• Email: Twice a day (morning and after lunch)
• GitHub notifications: Filtered to only PRs I'm reviewing or authored

Documentation as Productivity

Writing things down is the most underrated productivity tool.

Decision Records

For significant technical decisions, I write a short document:

## Decision: Use TanStack Query for Server State

### Context
We need to manage server state in the new dashboard feature.

### Options Considered
1. Redux Toolkit Query
2. TanStack Query
3. SWR

### Decision
TanStack Query — better devtools, simpler API, team familiarity.

### Consequences
- Need to add TanStack Query dependency
- Team needs brief onboarding on query patterns

This saves hours of re-explaining decisions months later.

Do You Need All of These Tools at Once?

No. Start with one change: switch to an AI-native editor, or fix your Node version manager. Add the rest only once the first change is a habit, not a project.

FAQ

Key Takeaways

• Use AI-native editors — they're a genuine productivity multiplier, not a gimmick
• Invest in shell aliases and git shortcuts — small savings compound daily
• Protect deep work time — context switching is the biggest productivity killer
• Clean git history pays off in debugging and knowledge transfer
• Write decisions down — your future self will thank you
• Code review is a skill worth developing separately from coding

Sources

• Cursor documentation
• Claude Code documentation
• fnm (Fast Node Manager) on GitHub
• Conventional Commits specification

Explore more: Claude Code — Guides & Deep Dives

---

Originally published at umesh-malik.com

Keep reading on umesh-malik.com:

• Qwen3-Coder: Run an 80B-Parameter LLM on Your Desktop
• Spec-Driven Development for AI Agents (Addy Osmani)
• AGENTS.md Files Don't Work the Way You Think — A 138-Repo Study

Comments

[Mihir kanzariya]

The context switching point is underrated. I used to keep like 5 tools open all day and never realized how much that killed my focus until I started consolidating. The deep work blocks approach is something I've been experimenting with too, but I find 3-5 hours is ambitious for most days tbh. Usually end up doing 2 focused hours and then smaller tasks the rest. Also +1 on the git bisect tip, saved me so many times when tracking down regressions in a large codebase.