Simplifying My Toolset as a Software Engineer

I have a habit of doing a year-end review. This year feels like a turning point in my career — the closing chapter of my senior years. I sense that in the years ahead, my focus will shift more toward system and team scale. During this transition, I took a hard look at my toolset and found a significant amount of noise.

By noise, I mean this: I was carrying far more tools than I actually used, justified by “might need this someday” or “everyone uses it.” Every tool represents a learning cost, an update burden, and a decision surface. Reducing that burden contributes to keeping your mind clear.

Editor: PhpStorm Only

I went through a phase of editor-hopping. I went back and forth between VS Code and PhpStorm. Both have their strengths — VS Code is light and fast, PhpStorm goes very deep on PHP analysis. Opening one for one project and the other for another effectively meant never truly mastering either.

My decision: PhpStorm is my main editor. It handles Go files well enough too. I dropped the habit of reaching for VS Code for TypeScript; PhpStorm is in a very good place there now as well. Knowing one editor deeply is worth more than knowing two superficially.

Knowing an editor well means: using refactoring tools with keyboard shortcuts, preferring the debugger over the terminal, and taking code inspection suggestions seriously. Reaching that level across two tools is much harder.

Terminal Tools: Fewer, but Right

I had been carrying dozens of oh-my-zsh plugins for years. I never used most of them — I wasn’t even aware they existed. This year I started from scratch: only what I genuinely use every day.

Seeing that removing things made no difference showed me how much unnecessary weight I had been carrying. What I actively use now: git aliases, z (directory history), fzf (fuzzy finder), basic docker aliases. That’s it.

I was on the fence about tmux for a long time. I wasted too much time tweaking the configuration trying to set up the ideal workflow. I’m not using it right now; multiple terminal windows is sufficient.

Browser Extensions

This was the category where bloat had accumulated the most. I was running fifteen extensions. Deleting half of them changed nothing. I temporarily disabled five of the remaining eight; after two weeks, I haven’t missed any of them.

What I keep permanently enabled now: JSON formatter, color picker, ad blocker. Everything else falls into the “I’ll enable it when I need it once” bucket.

Productivity Apps

I tried a lot of things in the “task manager” category — Notion, Obsidian, Things, plain text files. Learning each new tool’s system and migrating to it took serious time. Even the worst features of a system, used consistently, produce better results than the best features of a system used haphazardly.

This year I made a simple decision: plain text for tasks, Obsidian for notes. Both open instantly, no sync issues, no waiting for tool updates.

What I Traded for Simplicity

This simplification comes at a cost: in some edge cases, without a specialized tool, I have to take a longer path. Sometimes I notice that a plugin I’d prefer isn’t there. These are real costs.

But in return, I get mental clarity. When starting a new project, if there’s no “which tool should I use?” question, more time goes toward creating rather than deciding. Mental bandwidth is freed up to solve the actual problem instead of making toolchain decisions.

”Fewer Tools” as a Pattern

The conclusion I’ve reached by year-end: there is no linear relationship between the number of tools and productivity. Usually the relationship is inverse. Every new tool brings an integration burden, a learning burden, and a decision burden.

This isn’t about abandoning the pursuit of excellence. It’s about using the right tools for the job — but stopping the search for a specialized tool for every job. As I approach the staff level, the number of decisions I make increases; anything that reduces decision fatigue becomes valuable.

If I’m going to add something new to my toolset in 2022, the question I need to ask myself is: “Does this replace something I’m already using, or does it stack on top of it?” The second answer is a red flag.