Or, “Why Web development can only move so fast”.

Browsers and, to a lesser extent, networks are getting ever faster. In the arms race that is the web, we are able to offload more and more to the client for processing than ever before. This is amazing, and truly essential for us to continue forging paths ahead in creating rich, innovative experiences for users.

But if this is true, why is our development getting slower?

The State of Affairs

We create beautiful tools like Less, Sass and Uglify, some of which are geared toward saving us as developers time and sanity, while others save on network bandwidth, making our sites faster. But manually processing those components to be usable on the Web is tedious and slows us down.

In response, we created task runners such as Gulp and Grunt, leveraging the power of the command line to automatically do those things for us. These perform admirably (and some better than others, to be sure), but they add an intrinsic amount of overhead for both new and experienced developers.

XKCD "Compiling" comic
Obligatory XKCD reference

And those are just the basics, powerful and heavily used though they may be. It doesn’t even touch on working with large applications such as Jive, offloading them to virtual environments using Vagrant and the like, or compiling and deploying to cloud applications like Salesforce.com that don’t have a concept of a local instance.

Processes and workflow

So we have some pain points identified. We look for ways to speed up the process and work around the choke points. Unfortunately, this oft results in us spending a lot of time “working on working” (i.e. putting effort against the meta of what we’re doing).

It can seem like it is all in vain, that we could have completed the work by now - and with less resistance - if we did it the “conventional” way. However, if the nut can be cracked, it can dramatically enhance not just your, but our entire industry’s workflow. And while a smooth workflow doesn’t necessarily guarantee happy developers, a lot of friction well definitely lead to grumpy ones.

Tools that support the tech

Okay, that’s great, but how do we actually achieve this bliss?

See what’s out there

Maybe something addressing this exists, or maybe just partially. Can you improve upon it, or adapt it to a wider range of use cases? If so, fork it, build, publish, and refine the tool. Submit pull requests and foster a conversation with the project’s maintainers and community.

If there are no discussions surrounding this tool, start one! Don’t be turned away by a lack of existing engagement; maybe you will be the catalyst that sheds some light on the solution for others!

Roll your own

If nothing exists - or it isn’t going to quite fit the bill - don’t despair. Implementations don’t always exist for your tool, workflow, or style. Maybe your particular ask hasn’t been solved using your particular tools – yet.

Things often start strong. You reach for our favorite tool and get rolling along, feeling great and pumped to solve this problem. Then you hit a wall. You back up and try a different path, but it’s another dead end. You shift again, but find another. So what happens when you get 75% of the way there and don’t see a way around?

Do not let this deter you. Instead of stopping there, consider moving forward. Ask if a solution can feasibly exist; do some research to find out. Maybe ask on Stack Overflow or other communities to generate some ideas. Heck, you might just inspire somebody to post their own solution, saving you quite a bit of work!

Are you knowledgeable about the possibilities? If so, is it worth spending some time on to solve? Great, forge your path ahead. If you’re not versed in the tech needed, are you interested in getting up to speed? Start with something super simple to get your feet a little wet, then dive in with your goal in hand.

Always moving forward

Building and learning are crucial to having a fulfilling career as a developer (and not to mention other professions as well). Step out and take a couple hours exploring opportunities. Document what you find, write about your experience, and share what you learned - even if it didn’t turn out exactly as you intended.

But maybe you pulled it off! In fact, knowing you, I bet you did. Let people know you created something they might find useful. Submit it to package repositories like npm or Bower. Post on Twitter and #tag it so people can find it. Tell your co-workers. Answer questions on Q&A sites where this would be a good fit (just don’t be a jerk and spam it - the goal here is to help others by sharing useful info).

Your project might just end up being used by hundreds or thousands (or more!) of devs to come. Our industry’s constantly changing – you can be a part of that.