Over the past few years, I – like pretty much every other developer ever – have given my tools a fair shake to determine what it is that I like working with the most.

But what’s funny is that “what I like working with the most,” is a phrase that carries a different connotation with different people.

For example, for some, it means that the tool could be completely ugly but if it gets the job done then it’s good enough. For others, it means that it needs to look good and function well in order to help them feel productive about getting their work done.

Case in point: Look at some of the build tools that we have available. We have Bower, Grunt, CodeKit, and more all of which essentially offer much of the same thing, but how they go about offering said functionality is different.

For some, one way is great; for others, it’s not so great. So what’s a developer to do?

The Best Developer Tools

When I was in college, I primarily worked with Eclipse (vim elitists, say what you will). I know the usual complaints – slow, Java-based, etc. Whatever. The application’s integration of a console, source control, was everything I needed in an IDE.

Then, out of college, I worked for years with Visual Studio. I can’t say that I loved the interface, but I absolutely loved the toolset. I felt spoiled. Arguably my favorite features were background code compilation and the debugger (especially when it allowed you to change the values of watches on the fly). I still miss working with it.

Fast forward a few years, and I’ve was doing work with Rails, JavaScript, PHP, and some other odds and ends. A few years later than that and I’m pretty much working with PHP as my primary server-side language right now.

Broken Tool

Oh, and just as people can hate on your toolset, they can hate on your language, too. So much hate, huh?

Anyway, on a more serious note, I’ve given a number of different IDEs a try – some are minimalistic, some offer tons of fantastic functionality, some are gorgeous but skimp on some major functionality (thus requiring additional tools), and some simply do things differently than other tools.

The problem with this is that it gives developers a superiority complex. I mean, I’m only half-kidding, but how many times have you been asked “Oh what tool(s) do you use for X?” only to be met with “You should totally be using [this tool] instead.”

First off, this implies that I haven’t tried that tool. Secondly, it implies that I’m not as effective, skilled, or powerful with what I do for a living with my current set of tools. Third, it carries with it the connotation that you’ve found the superior tool and people should really only use it.

That’s actually kinda harsh – I don’t completely mean it. Only to some degree. That is, there are some people who are simply just excited about what they use and they want you to be excited, too, right?

There’s nothing wrong with that – I love that attitude. But remember, I’m also able to have that about the tools I use and you don’t have to necessarily agree with it.

On the other hand, there are others who are convinced that the tools and the stack that they use are the de-facto, a cut-above-the-rest set of tools that you should be using in order to do the work that you’re doing and if you’re not using them then you’re less of a developer.

But remember: We’re in the business of solving problems. If you’re able to solve more problems effectively with your toolset and you feel better doing so because the application looks, feels, or performs a bit better to you, then that’s fine.

No one can really tell you otherwise.

Take that shiny IDE that might be lacking a feature or three and a stack of web hosting tools and solve those problems. As long as you’re doing it well, efficiently, and professionally, the code is being written, and problems are being solved.

Customers are [ideally] happy with what they’re getting, and you’re happy with the environment in which you’re working.