The Best Developer Tools (According to You)

One of the things that developers love to discuss is the tools that we use. And why not, right? It’s fun to talk about what IDEs, minifiers, compressors, build tools, deployment utilities, and so on that we incorporate into our daily workflow.

It’s also fun to see what other people use to see if there isn’t something to be learned and gained from the way that other people do work.

But sometimes I think that we do cross a line: I think that many of us have a disposition such that we think “if they aren’t using what I’m using then they aren’t being as productive (read: they are as proficient) as I am.”

And this mentality is lame primarily because there are a number of factors that contribute to the tools that a developer opts to use when he or she is getting his or her work done.

The Best Developer Tools

More than ever, we have more tools at our disposal to help us get work done than we’ve ever had before. I mean, we even have code generators for certain things.

Yikes, right?

And don’t get me wrong: I absolutely love the fact that we have choice in the tools that we use.

After all, the fact that we’re able to choose the set of tools that we use on a daily basis directly contributes to our level of “programmer happiness” (a phrase that I’m not exactly sure I really like but whatever :), and productivity.

Programmer Happiness and Productivity

When we’re tasked with sitting in front of a computer for hours a day, we need to make sure that we’re surrounded by a number of things that help keep us focused, productive, and happy.

This includes anything from the music that we listen to, to the tools that we use, to the size of the screen that we have availability.

The goal is to minimize frustration.

“My Toolset is Just Too Good”

And if the IDE and other set of build tools that you work with don’t jive with, say, how a peer of yours thinks you should be working, then no big deal. If you’re productive, shipping quality code, and getting work done, that trumps how you’re doing it.

Of course, don’t take this as an indictment as to our peers who often recommend other software to us. After all, making sure others are aware of all of the tools that we use and how they may benefit us is being a good member of the development community.

The only thing is that you shouldn’t laugh at the tools that some developers opts to use because it undermines the idea that they’ve carefully selected the set of tools they’re using, and you’re essentially saying that the choices they’ve made are poor.

And if they’re generating high quality code and shipping good work, who’s to say it isn’t sufficient?

There Is One Caveat

When it comes to working with a team, I think that many people think that every developer needs to be using the same set of tools.

I get this and I don’t necessarily disagree with it; however, depending on the type of work that’s being done, I do think that the tools that are being used can be a little more subjective assuming that there are certain rules in place that all developers honor.

For example:

• How does your team treat white space in code (including trailing whitespace, tabs versus spaces, and so on)?
• Are you going to commit minified CSS and JavaScript files to the repository or let the deployment tool do that?
• What about images, sprites, or what ever other images you have: Does the build tool optimize them or do developers?
• …and more

The thing is, at some point, it can become less about the actual set of tools that are being used to build the software and more about the rules that govern how the software is built.

The majority of tools now allow for extensions or plugins that allow us to, say, strip white space during a save action. I think it would stand to reason that this would work just as well now as a standard set of tools.

Ultimately, My Point Is This…

There is a level of “Why do you use X? Z is so much better. You should be using Z to get your work done.” And that mindset, though I don’t believe it’s meant to come off this way, strikes me as “I know you have the tools that you like, but I know something that’s better for you.”

And who doesn’t like sharing things that they enjoy with their peers? We do it with things likes movies, music, and other things all of the time.

But here’s the thing: When it comes to getting developers to swap out applications that they use to get their work done, there’s a mental tax that comes with having to learn a brand new application or set of tools that can negatively affect the amount of time it takes them to get work done.

This is not an excuse as to why we should never change tools (because I think that we should, especially when something much better comes along), but I don’t think we need to do it every single time a new tool is released.

And right now, we’re in a state where new tools are being released faster than ever before. Ultimately, it’s about making sure that we have the ability to create the highest quality work with the most productivity possible.

Everything else should be secondary to that.