I had the realization a year or so ago that much of the high-impact work I’ve done in my career has been related – directly or indirectly – to building developer tooling. I did not plan this, at all, but I’m quite happy to have found impact in this niche.
My first job outside of school was writing a developer tool for engineers building the Google Cloud Console, which is the frontend for GCP and (at least at the time) was likely the largest Angular app in existence1. The team I joined has been recently created and was building a set of tools to replace some hilariously unergonomic tools that had organically grown along with the problem space.
The result was an amazing (if modestly overengineered) tool which was legitimately delightful to use and resulted in a demonstrable productivity boost for the >1k internal developers who used it. I recently ran into a current GCP developer and was pleased to hear that this tool is still in active use – and not only that, but that this developer had a quite positive view of it.
Fast forward a couple of years, and my current team at Databricks2 works on internal infrastructure. More of our time is spent working on building platform-level components for dynamic service configuration, but we also build and maintain a set of tools for engineers to interface with these systems. And I think developing the UX of these tools has probably been some of my highest-leverage work thus far.
Why Devtools
So, why am I so enthusiastic about developer tools?
Developers will tell you their papercuts. One of the best parts of building tools for other engineers is that they readily tell you what’s not working. If a developer has to interact with a painful tool or process regularly, you’ll find out pretty quickly. This feedback is super useful, both at a product level (what features to add/remove/improve) and at a meta level (what are developers actually doing). I found this to be even more true when the tool was, well, actually useful. When the tool becomes part of a developer’s daily workflow, you start hearing very specific, granular feature requests and complaints, which are great! We can’t always fulfill these requests, but in aggregate, they give a directional sense of where to build next.
Great tooling is a force multiplier for the rest of the engineering organization. When internal developer tools are good, and they’re used consistently, they improve the productivity and efficiency of all downstream developers. This is most notoriously difficult to quantitatively measure – in theory, there should be a measurable improvement in developer velocity, but this is usually hard to get good numbers on. The real benefit is a “rising tide lifts all boats” effect – all developers on your team become tangibly better from using a well-designed tool, and those that weren’t efficient at a particular set of tasks become demonstrably more efficient using the tool.
There is cultural leverage to building tooling. Closely related to the force multiplier effect is the cultural effect of improving shared tooling. Developer “best practices” are just codified shared behaviors and tool usage. Tooling can be designed to encourage certain practices by reducing the friction to “do things the right way”. For instance, if your goal is to enforce that all code changes be linted, you can add the linter as part of your standard git commit hooks (reducing friction) at the same time as adding the lint check to be a PR merge precondition (ensuring compliance).
Infrastructure builders get to interact with a lot of other teams. Building internal tooling necessitates interfacing with many other teams to understand their use cases. This was an unexpectedly pleasant part of my experience building internal tools: I got to work with teams from all around my company, which can make you more aware of what other parts of your company are working on. There’s also just a nice social component to this; I’ve talked with likely hundreds of engineers in my product’s support channel, so whenever I travel to a new office I often run into familiar faces. This can also lead to opportunities to improve coordination between teams, increase your exposure to novel projects, discover opportunities for improvement of your tooling, and notice places where “competing” tools can be consolidated.
Working primarily on developer tools and internal infrastructure wasn’t something I planned, but it’s turned out to be a really satisfying niche. There’s something uniquely rewarding about creating things that directly help your peers get their work done more effectively. It has its own set of unique challenges, but the leverage you get and the direct feedback loop make it quite enjoyable.