We aren't our tools
This post was one of my first, as a relatively junior dev in an agency enviroinment.
It's no longer representative of my opinion, or even aan accurate reading of the issue.
Left here for proesperity; Not to retro-actively critiqe my own writing, but has shown me how far I have come in my understanding of the real considerations around frameworks and tooling and teams. May remove.
As developers we are often compelled either by a self-initiated, driving curiosity, or from the persistent type-A anxiety to innovate rather than consolidate — in a bid to service 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 flexibility and teamwork.
The value of the tools we implement, however, should not be considered in isolation; they have a cognitive cost to the team.
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 want to integrate a front-end project into another framework. 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 market themselves. 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.
.