# Simplifying My Toolset as a Software Engineer

> Reviewing my tool stack during the transition from senior to staff level, I realized fewer tools lead to clearer decisions.

- Published: 2021-12-05
- Category: Journal
- Tags: Araçlar
- Reading time: 4 min read
- Source: https://www.muhammetsafak.com.tr/en/blog/simplifying-my-toolset-as-a-software-engineer/
- Language: en-US
- Author: Muhammet Şafak

---
I have a habit of doing a year-end review. The first tool decision in this journal was [switching to Composer](/en/blog/switching-to-composer-stop-managing-php-dependencies-by-hand/); in the years since, my tool count kept growing — this year I decided to shrink it. 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.