Tools: Developer Productivity Tools I Use as a Senior Engineer

Editor: Cursor AI + Claude Code CLI ## Key Editor Settings ## Why AI-Native Editors ## Terminal: iTerm2 + Zsh ## Shell Aliases That Save Hours ## fnm Over nvm ## Git Workflow ## Commit Conventions ## Interactive Rebase for Clean History ## Code Review Habits ## As an Author ## As a Reviewer ## Focus Management ## Time Blocking ## Notification Management ## Documentation as Productivity ## Decision Records ## Key Takeaways 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 4+ years of building software professionally. I use AI-native editors that accelerate my workflow: 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. My terminal is where I spend the second most time after the editor. I switched from nvm to fnm (Fast Node Manager) and the speed difference is noticeable. Shell startup went from ~500ms to ~50ms. The --use-on-cd flag automatically switches Node versions when you enter a directory with a .node-version file. I follow Conventional Commits for all personal projects: Before opening a PR, I clean up my commits: A clean git history isn't just vanity — it makes git bisect actually useful when tracking down bugs months later. As both a reviewer and author, I've developed habits that keep reviews effective: I protect 2-3 hour blocks for deep work: Writing things down is the most underrated productivity tool. For significant technical decisions, I write a short document: This saves hours of re-explaining decisions months later. Originally published at umesh-malik.com Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to ? It will become hidden in your post, but will still be visible via the comment's permalink. as well , this person and/or CODE_BLOCK: { "editor.formatOnSave": true, "editor.bracketPairColorization.enabled": true, "editor.minimap.enabled": false, "editor.stickyScroll.enabled": true, "typescript.preferences.importModuleSpecifier": "non-relative" } CODE_BLOCK: { "editor.formatOnSave": true, "editor.bracketPairColorization.enabled": true, "editor.minimap.enabled": false, "editor.stickyScroll.enabled": true, "typescript.preferences.importModuleSpecifier": "non-relative" } CODE_BLOCK: { "editor.formatOnSave": true, "editor.bracketPairColorization.enabled": true, "editor.minimap.enabled": false, "editor.stickyScroll.enabled": true, "typescript.preferences.importModuleSpecifier": "non-relative" } COMMAND_BLOCK: # 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' COMMAND_BLOCK: # 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' COMMAND_BLOCK: # 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' COMMAND_BLOCK: # .zshrc eval "$(fnm env --use-on-cd)" COMMAND_BLOCK: # .zshrc eval "$(fnm env --use-on-cd)" COMMAND_BLOCK: # .zshrc eval "$(fnm env --use-on-cd)" CODE_BLOCK: feat: add search functionality to blog fix: resolve hydration mismatch in SSR refactor: extract shared form validation logic docs: update API documentation for v2 CODE_BLOCK: feat: add search functionality to blog fix: resolve hydration mismatch in SSR refactor: extract shared form validation logic docs: update API documentation for v2 CODE_BLOCK: feat: add search functionality to blog fix: resolve hydration mismatch in SSR refactor: extract shared form validation logic docs: update API documentation for v2 COMMAND_BLOCK: git rebase -i HEAD~5 COMMAND_BLOCK: git rebase -i HEAD~5 COMMAND_BLOCK: git rebase -i HEAD~5 COMMAND_BLOCK: ## 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 COMMAND_BLOCK: ## 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 COMMAND_BLOCK: ## 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 - 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 - 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 - 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" - Morning (9-12): Complex coding, architecture, debugging - Afternoon (1-3): Code reviews, meetings, collaboration - Late afternoon (3-5): Documentation, planning, lighter tasks - 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 - 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