Choosing the Right Dev Tools Without Wasting Time
As you learn how to code, you will eventually run into a wide variety of development tools. Pretty soon, you start asking yourself questions like: Which dev tools should I use? Which ones actually matter? Which ones will make me better or faster?
When I say “dev tools,” I’m talking about things like the terminal, the IDEs you use, tools like Visual Studio Code, Visual Studio, Eclipse, or even how you use Git. These tools are meant to help you write better code and be more efficient, but beginners often end up overwhelmed or chasing perfect setups that don’t actually help.
I ran into this early in my career.
The Terminal vs IDE Debate
At my first company, one of my coworkers came into my office and proudly told me that he did everything in the terminal. In university, that was also how I worked, mostly because I didn’t really know about IDEs yet. I coded in Emacs or Vim, compiled everything in the terminal, and that was all I knew.
But my coworker had taken this to another level. He made the case that “real developers” only use terminal. He bragged about not needing a mouse, opening windows directly inside the terminal, creating aliases for faster Git commands, and customizing every part of his workflow.
Some of the things he showed me were genuinely helpful, and I tried them out. But I also started running into problems.
When “Optimizing Your Setup” Becomes a Distraction
For example, I created Git aliases like gc for commit or ci for commit with message. But after a while, I forgot which alias stood for what. I would sit there wondering, “Did GC mean git commit… or git clone?”
I also wrote bash functions to automate things I did repeatedly, like checking out master, pulling the latest changes, rebasing my feature branch, and pushing updates. It worked well at first… until it didn’t. Merge conflicts broke the function. Behavior changed depending on the state of the repository. I kept having to patch and re-patch the automation.
And then the real problem hit.
The Problem With Custom Setups
In real companies, you rarely work on only one machine. I had a corporate laptop, a desktop, and multiple lab machines. Each machine had a slightly different setup, and it became a hassle to recreate my perfect environment everywhere I went.
Every time I switched machines, I had to reinstall tools, rewrite functions, and adjust configurations. Eventually I realized something important:
Your tools don’t matter if you can’t work productively on any machine.
So I changed my approach.
Instead of forcing every machine to match my personal setup, I looked at what was already installed. For quick codebase searches, I used Notepad++ because it was always there. If a preferred tool wasn’t available, I adapted. It made my workflow simpler and more consistent no matter where I worked.
A Better Way to Think About Dev Tools
Over the years, I came up with a few principles that helped me stay focused and avoid wasting time.
1. Don’t spend more time debugging your tools than debugging your actual code
If your terminal, IDE, plugins, or setup keep breaking, they’re no longer helping you. The goal is to spend most of your day writing and understanding code, not fixing your environment.
2. Focus on adaptability, not perfection
Sometimes your IDE needs an update. Sometimes your machine crashes. Sometimes you’re moved to a lab computer with none of your customizations. If you can’t work because you lost your setup, that’s a huge problem. Being able to develop on any machine makes you far more resilient.
3. Use what’s available
If a tool is always installed on the machines around you, learn it. Get comfortable with it. It makes your workflow portable and keeps you productive no matter where you’re assigned.
Dev tools are important, but only to the extent that they help you build real software. Don’t let them become a distraction from what actually matters: improving your coding skills and producing high quality code.
If you can stay adaptable and avoid obsessing over the “perfect” setup, you’ll move faster, learn more, and write better software in every environment you touch.