Developer Productivity Tools I Use as a Senior Engineer

Productivity as a senior engineer is less about typing faster and more about reducing friction between thinking and executing. Here are the tools and systems that work for me after 5+ years of building software professionally.

PRODUCTIVITY SYSTEM IN ONE SCREEN

Senior-engineer productivity is usually a systems problem, not a hustle problem. The biggest gains come from reducing repeated friction across your entire day.

EDITOR

Use tools that collapse thought-to-code latency

AI-native editors and terminal workflows help most when they remove boilerplate, speed up refactors, and keep context close to the work.

• Primary editor for deep coding
• CLI tools for repo-wide changes
• Settings tuned to reduce visual clutter

TERMINAL

Small shell improvements compound daily

Aliases, fast runtime switching, and clean command habits save seconds that add up across dozens of repetitions.

• Git shortcuts
• Project command aliases
• Faster Node version management

COLLABORATION

Review quality and documentation are productivity tools

Good PR descriptions, disciplined review habits, and short decision records save future time just as much as they save present time.

• Explain the why
• Keep reviews scoped
• Record important decisions

FOCUS

Protect attention like a limited resource

Deep-work blocks and notification discipline matter more than squeezing marginal speed out of typing or memorizing more shortcuts.

• Time-block complex work
• Batch notifications
• Separate deep work from collaboration windows

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'

fnm Over nvm

I switched from nvm to fnm (Fast Node Manager) and 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.

AMPLIFIERS VS DISTRACTIONS

The best productivity tools are not the ones with the most features. They are the ones that reduce friction without fragmenting your attention.

AMPLIFIERS

Keep the tools and habits that compound

• Editor and CLI workflows that remove repetitive work
• Clean git habits that help future debugging and review
• Protected deep-work blocks for architecture, debugging, and coding
• Lightweight written decisions that reduce re-explaining later

DISTRACTIONS

Avoid productivity theater

• Constantly swapping tools instead of improving one stable setup
• Treating notifications as real-time obligations all day
• Opening oversized PRs that guarantee slow review cycles
• Optimizing typing speed while ignoring context-switch cost

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