Approachable Tooling

I’m lucky to be able to work with a wide variety of organizations and teams, with different architectures and workflows. I like it. It keeps things fresh.

I sometimes find it’s nice to have a version of their site running locally to make it easier for me to dig deeper and test different optimizations.

I see a lot of similar tech-stacks between my clients nowadays. The most common from the last year and a half has involved React/Vue.js.js, Node.js and webpack (with random tools sprinkled in of course). Despite the similar stacks, the process for getting things running locally ranges quite a bit. Usually, it involves a bit of back and forth with the team as we get access to the right repo’s and navigate the various different build tools and containers and configurations to get things all set. We get there in the end, but it’s rarely a quick process.

Our tools are more powerful than ever, and I’m grateful that they are! Particularly as someone who cares a lot about performance, accessibility and security—those three critical but often invisible considerations—I love how much testing and low-hanging fruit we can take care of automatically.

It’s fantastic that our web plumbing has gotten more powerful—tooling today is capable of so much. But all too often, that power comes with increased complexity that negatively impacts developer efficiency. Sometimes that’s unavoidable. The simplest approach doesn’t always win. But that should be the goal—to make things as simple as possible while still accomplishing what needs to be done. Like excellent plumbing, these systems should be as mostly invisible—chugging along, doing what we need them to do without getting in our way.

A good system not only considers the technical impact of the tools in use but the impact it has on the people who have to use it as well. The best systems don’t just automate a lot of setup, testing, and optimizations—they do it in a way that lets team members get on with their work as quickly and efficiently as possible.

Considering the cognitive overhead can also make your codebase more approachable to new hires. Having a good process in place reduces the time it takes for a new team member to be able to start making meaningful contributions.

When I started working with a recent client, I wanted to get a local version of their site up and running. They’re using Vue.js, Nuxt, webpack—as I mentioned, an architecture I’m pretty familar with. I expected there would be a little time involved in getting things set up and configured, as there usually is.

But there wasn’t. It just….worked, mostly. I had to tweak the Node.js version and get access to one more repo, but that was it. I had a local version of the site up and running in minutes. It was the most seamless onboarding experience I’ve had in a long time.

It wasn’t by accident.

Their documentation was pretty straightforward. The process and tooling itself were carefully considered to be as frictionless as possible. It was clear the intent here was not just to have a robust, flexible set of tools in place, but to make sure that set of tools was approachable. New team members, or folks like me looking to help out, can start making contributions almost immediately.

Making the approachability of our systems a priority lets us take advantage of their tremendous power without compromising on flexibility and ease of use.

This particular system stood out for its simplicity. It would be even better if it hadn’t.