On Tooling

I hate the word tooling. Tooling is a word that has been coming up over and over again lately. Developers have started to open their eyes to the mess that exists currently. This has brought us to a world in which a new 1000 word think piece enters the world about tooling.

Each new think piece attempts to tell us that we’re all doing it wrong and that we should do something about it. This leads to more think pieces about the problems.

Developers are going to overcomplicate things. Knee jerk think pieces about this situation are just a symptom of the problem.

Most of the pieces focus on not using any tooling, which is fine by me. I long for the days when things were simpler and we just wrote HTML, CSS, and javascript.

As with anything in life, there is a time and place for everything. Some days, just putting a bunch of static stuff in a folder works. There are times when you need a little extra oomph and automation to be most productive.

Complaining about tooling without solutions just leads to more tooling. Abstracting everything into an application that requires 2 lines of code, and 30,000 dependencies.

Think pieces about develop are quite pretentious. They act as if everyone’s code is shit because the choices made are not the choices of the author. As with anything, developers must make decisions based on their own productivity.

I hate tooling and process, but some times, it’s the best thing for the project that I’m working on. Tooling and process can be the key to delivering the best results for the users of the things that I’m working on. To that end, I’ll still Gulp, Browserify, Grunt, Broccoli, (but never Bower) projects. This shouldn’t make anything I do less awesome just because I didn’t go full bespoke on a project.

The best coding approach is the one that gets projects into the hands of the people that need it. Anything else is just analysis paralysis over minutia that just delays shipping projects.