< expLog

DevTools > Types of Opportunities

2021-06-11 – This series is a work in progress: I'm not as experienced at writing as I would like to be, and making something valuable, coherent and readable takes time.

To begin I'm simply trying get all my ideas typed out; I'll work on better composition and expression later. Send any feedback my way @kunalbhalla.

Developer tools greatly influence the type, quality and velocity of work engineers do. As a toolsmith, I like to break down opportunities into 3 main categories1: 1 These aren't perfect by any means, and often have areas of overlap.

Each of these can be extremely valuable depending on the circumstances. I'll start by diving into these categories, and then talk about how I tend to prioritize between them.

Enabling new, previously impossible work

I often find this to be the most exciting and most appreciated work. Most developer tools tend to take existing workflows and improve them in some way; a very few have the opportunity to enable something completely new.

Examples include the ability to inspect the state of programs: debuggers, record/replay debuggers; fleet-wide telemetry that tracks the lifetime of requests and allows observing global behaviors; easy access to eBPF-like instrumentation to understand exactly what's going on.

Completely automating manual workflows is something I also like to place in this bucket because that effectively removes a human bottleneck in the problem being solved, enabling much more scalability while freeing up engineers to identify and solve more valuable problems.

Speeding up existing workflows

I find this to be the type of opportunity that is most commonly identified by customers and toolsmiths. It's also remarkably easy to justify, validate and measure which makes it very execution-friendly.

At the order-of-magnitude improvement level, speeding up workflows can actually completely change user behavior and effectively translates to the previous category. Consider reducing analytics query times from 30 minutes to 5 seconds: at this point, executing a query is no longer a bottle neck and will potentially be used for much more exploratory work instead.

At a somewhat less exciting, but more frequent level – a lot of work in this space ends up revolving around consolidating tools, making them more usable and convenient, making it easy to navigate from one tool to the next.

Changing engineer behavior

Often enough there are certain actions engineers should be taking: to improve code quality, not break regulations, or simply best practices that make success much more likely.

Tools can guide people gently in these cases: linters, even smarter autocompletes, automated tests and deploys that guarantee broken code can't ship. Tools that can track data provenance, and automatically warn about data that could accidentally get persisted too long, or misused; tools that look for sensitive strings in logs.

Occasionally, you can even try and use these to change the broader culture of the company guide people towards the behavior you want to encourage. Examples include adding a required "Agenda" field in your meeting organization tool; or incorporating checklists and automated lints into your code review tool.

Prioritization

I often find that there's nothing as valuable as enabling otherwise impossible work; even if the tool is barely usable – as long as it makes it possible to get the desired information/result – it'll be used aggressively and provide a lot of value. Accordingly, I tend to prioritize these the highest for immediate Impact2. 2 The dreaded I-word

Right at the same level is an order of magnitude improvement in speed. This changes to the character of the tool completely, and is just as valuable.

And then there's everything else that you could do: UX, quality of life, or speed up people along their way. Eliminating – or reducing – the time people spend staring at their screen, waiting for results is always valuable.

I treat tools that help build behaviors somewhat outside the prioritization cycle: either you need to implement them quickly to respond to external forces, or you build them into your organization and see them change behavior over long periods of time.

Comments?

You can drop me a email or catch me on Twitter. (I still haven't found a comment system for static blogs that I particularly like.)