Editorial starter example. Original guide created for the Devex launch; not research, a user testimonial, or a report of community activity.
Developer experience includes the work around writing code: understanding the system, setting up an environment, getting feedback, and delivering a change to users. Improving it starts with finding where people get stuck.
Record an event, not just a general feeling
Ask the team to note a few actual interruptions during their work. For each event, record the action, what blocked it, the workaround, and whether the obstacle recurred. There is no need to track every minute or rank people.
Separate different kinds of waiting
- Information: It is unclear where something lives or whom to ask.
- Environment: A dependency is missing, setup is unpredictable, or test data is unavailable.
- Feedback: A slow test, an unstable result, or a review waiting without an owner.
- Decision: An open requirement or unclear responsibility.
The category helps select an intervention. A faster tool alone will not resolve a decision with no owner.
Choose one source of friction
Look for a recurring problem that affects more than one person and offers a practical way to check an improvement. For example, test whether a short setup document with clear ownership lets someone start without a help call. Decide in advance what improvement would look like.
Test with the people who face the problem
Have someone who did not write the solution follow the process. Notice where they still have to guess. Measure the process rather than a person’s value: waiting time, repeated attempts, and requests for help can provide useful signals.
Return the learning to the team
Share the problem, the change, and the evidence collected. If the outcome did not improve, update the hypothesis. Protect participants’ privacy and avoid turning a single metric into a target that replaces the quality of the work.
A question for your team: In your last task, when did you know what to do but something around the code stopped you?