Writing — DevEx Research
Writing · field notes & essays

Writing

Short essays and field notes on developer-experience research — the method, the evidence, and what the work looks like in practice. Long-form pieces are still in progress; what follows is the shape of the argument.

Contents — 01 · Developer Experience Strategy 02 · Developer Experience at Splunk 03 · Developer Experience at Covlant
2026.05 — 6 min Strategy

Developer Experience Strategy

Two myths keep getting-started underfunded. Both are comfortable. Both are wrong.

The first myth is that documentation is the getting-started experience. It isn't. Docs are where a developer goes once they already believe the tool is worth their afternoon — and the experience that earns that belief happens earlier, in the gap between intent and the first thing that actually works.

The second myth is that adoption is a marketing problem. By the time a developer has typed your install command, marketing has done its job. What happens in the next hour is a product problem — and it is usually owned by no one.

Getting-started is the strategic battleground precisely because it is unglamorous. It sits between teams, rarely has a directly responsible owner, and almost never survives a roadmap that an engineering-led org prioritizes by feature. Research changes that by making the first hour legible — turning a vague sense that onboarding "could be better" into a ranked list of specific moments where specific developers gave up, and what each one cost.

That list is the strategy. Everything after it is execution.

// an expanded version of this essay is in progress

2026.04 — 5 min DEM

Developer Experience at Splunk

DEM is not org-visibility. The distinction matters more than it sounds.

Digital Experience Monitoring helped expert practitioners diagnose performance and reliability problems in complex enterprise systems. The user was never a casual one. They arrived with a hypothesis, a deadline, and a tolerance for depth that consumer software never has to design for.

That changes what AI features are for. Tag Spotlight auto-summarization, AI-assisted root cause analysis, URL grouping — none of these exist to simplify the tool for a novice. They exist to compress the distance between an expert's question and the evidence that answers it. The measure isn't "easier." It's "fewer steps between suspicion and proof."

"Don't make it simpler. Make it tell me where to look."

— research participant, paraphrased

This is what consumer UX research tends to miss about the expert practitioner: friction and difficulty are not the same thing. An expert will happily accept a difficult interface that respects their model of the system — and abandon an easy one that flattens it.

// an expanded version of this essay is in progress

forthcoming Draft

Developer Experience at Covlant

Strategic DX for an AI-native dev-tools startup from early stage — the first end-to-end workflow diagram, the Ship Risk metric, and prototypes shipped as merge-ready pull requests. Publishing pending a check on what is shareable.

Working on something a reader here would recognize?

Tell me what you're building and who it's for. I'll come back with where I'd look first.

Book a discovery call →