# Why Developer Tools?


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](https://console.cloud.google.com/), which is
the frontend for GCP and (at least at the time) was likely _the largest_
[Angular](https://angularjs.org/) app in existence[^1]. 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 Databricks[^2] 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.

[^1]: For good or bad.

[^2]: Obligatory "opinions my own, not that of my employer"