← Back

We aren't our tools

As developers we are often compelled either by a self-initiated, driving curiosity, or from the persistent, corporate anxiety to innovate rather than consolidate — in a bid to service or even manufacture ever-more nuanced needs in our clients.

Perhaps one reason for the frankly bewildering proliferation of tools we use on the front-end - all purporting to make our life easier and more efficient in some ever-granular aspect — and never right now. They are forever promising a utopia of productivity and maximal efficiency just over the horizon, making us neurotic productivity automatons, sinking hours into learning, configuring, teaching, troubleshooting and refining them. We love our microcosm of control in front-end— indeed I've often suspected this semblance as being what makes our work so addictive.
Good tools are the sign of a maturing industry, but these marginal gains and diminishing returns at some point may reach a tipping point where they become an inhibitor to effective teamwork and straight-up productivity. Maybe I can shoehorn more Gladwell in before we’re done here.

The value of the tools we implement, however, should not be considered in isolation; they have a cost. We don’t operate in our own utopian world of greenfield projects, equally enthused (or skilled) colleagues, or predictable build environments, which can put the brakes on a project pretty quickly if you try to deploy your front-end build to another machine and your npm commands don’t work as expected, or it pass to someone else — maybe to implement your front-end into a different context: Sharepoint or similar MVC project. How easily our ‘productivity’ tools become a significant barrier — they are often non-optional and a project simply cannot even be re-built without their use. The highly-dependant tools one could argue, become a liability to the flexibility of a project and a team.

The proliferation of tools and constant debate over best practice and ad-hoc standards mean that without guidance from technical leads to define a standard, it’s unrealistic to expect all levels of a design and development team to understand a given toolset too frequently.

All corporations of course want safety, redundancy in teams, and an arcane set of tools are a step away from this if unmanaged; it can alienate less-experienced devs and come as a surprise when a project is held up because only one person can build and edit a project’s code. It’s an issue of engaging a whole team around an agreed set of practices and simplest set of tools possible for the task at hand. Fragmentation of codebases and tools causes entropy, technical debt, and reduced redundancy in your team.

Everyone has an opinion about what tools developers ‘should’ learn. We should beware of this dogmatic tool favouritism; all tools and frameworks represent a compromise — and that could be something extrinsic such as the available skills in the team to quickly support it.

Frameworks and tools will be good at a handful of things, to the detriment of something else; it depends if you want a hammer or a screwdriver.

We've become a tooling-led industry rather than one based on fundamental knowledge of what makes it work. Indeed, having spoken to many candidates for front-end roles, knowledge of frameworks is fast becoming the currency with which fledgling developers are hoping to snag a gig with. The tools are defining the needs of what a web project should deliver rather than the specs of a job and the skill-set available dictating what tools we use.

There is I feel, a latent groundswell among front-enders to return to basics — like true crafters many of us aspire to be. It can be refreshing to simply start building with our vanilla tools again; the ones we used to love when we first got into this industry — unadulterated and un-abstracted control which put us back in touch with the underlying principles, and which we found so addictive in the first place.