5 exercises — vocabulary for designing, running, and presenting developer experience surveys, including eNPS, Likert scales, friction points, and journey mapping.
DX survey vocabulary at a glance
eNPS — Employee Net Promoter Score (−100 to +100)
Likert scale — ordered 5- or 7-point response options
Friction point — a step causing unnecessary delay or frustration
Developer journey map — visual workflow from idea to production
Cognitive load — mental effort to navigate systems and processes
0 / 14 completed
1 / 14
A DX lead reports in an all-hands: "Our eNPS dropped 12 points this quarter — down from +32 to +20. That's still in the positive range, but the downward trend is a signal we can't ignore." What is eNPS (Employee Net Promoter Score) and how is it calculated?
eNPS (Employee Net Promoter Score) is the internal adaptation of NPS for measuring employee loyalty and satisfaction. The key question: "On a scale of 0–10, how likely are you to recommend this company as a great place to work?" Scoring: 9–10 = Promoters, 7–8 = Passives (ignored), 0–6 = Detractors. Formula: eNPS = % Promoters − % Detractors. Range: −100 (all detractors) to +100 (all promoters). Benchmarks: below 0 is poor, 0–30 is acceptable, 30–70 is good, above 70 is excellent. In the example, a drop from +32 to +20 in a single quarter is significant. Presentation language: "Our eNPS dropped 12 points this quarter — we ran qualitative follow-up interviews and identified tooling reliability as the primary driver."
2 / 14
A developer experience researcher explains their survey design: "We use a Likert scale rather than free text for most questions because it gives us data we can trend over time — but we always include open-ended follow-ups to understand the 'why'." What is a Likert scale in the context of DX surveys?
A Likert scale (named after psychologist Rensis Likert, pronounced "LICK-ert") presents a statement and asks respondents to choose from ordered options: Strongly Disagree / Disagree / Neutral / Agree / Strongly Agree (5-point) or with additional gradations (7-point). In DX surveys, example questions: "I have the tools I need to do my work effectively" or "I can complete a feature without waiting on other teams." Why Likert scales are preferred for DX: they produce quantitative data that can be tracked over time, compared across teams, and correlated with business outcomes. Limitation: they capture what developers say, not what they do — always pair with behavioural data. Key vocabulary: response options, ordinal data, trend analysis, benchmark comparison, statistical significance.
3 / 14
In a DX survey analysis session, a researcher says: "The highest-rated friction point this quarter was the local development environment setup — 68% of developers called it a significant obstacle to their daily work." What is a friction point in developer experience vocabulary?
Friction point is a UX concept applied to the developer experience: any place in the developer's workflow where unnecessary effort, waiting, confusion, or frustration occurs. Identifying friction points is the core purpose of DX surveys. Common categories: tooling friction (slow builds, broken local environments), process friction (excessive approval gates, unclear ownership), knowledge friction (missing documentation, tribal knowledge silos), social friction (PR review delays, unclear code review expectations). Presentation language: "We've mapped seven friction points in the feature delivery workflow — the top three account for 80% of the delay." Related concept: developer journey mapping — creating a visual representation of every step a developer takes from idea to production, marking friction points along the way.
4 / 14
A DX programme manager introduces a new initiative: "This quarter we're running a developer journey mapping workshop — we want to walk through the entire experience from onboarding to first production deployment and identify where developers get stuck." What is developer journey mapping and where does the concept come from?
Developer journey mapping is adapted from customer journey mapping — a UX research tool that documents every touchpoint a user has with a product or service. Applied to developer experience, it maps the steps a developer takes across key workflows (onboarding, daily coding, PR process, deployment, on-call). Each step captures: what the developer does, what tools they use, how they feel, and what pain points arise. Output: a visual map that makes invisible friction visible to leadership. Key phases in a typical developer journey: onboarding → local dev setup → feature development → code review → CI/CD → production monitoring → incident response. Facilitation language: "Let's walk through the journey from branch creation to merge and note every point where someone had to wait, ask for help, or work around a broken tool."
5 / 14
A DX lead presents quarterly survey results: "The survey data shows high cognitive load scores — developers report that understanding how to deploy a service requires knowing at least six different systems." What does cognitive load mean in a DX survey context?
Cognitive load (from educational psychology, originally described by John Sweller) refers to the mental effort required to process and work with information. In DX, high cognitive load means developers must hold too many complex, interconnected pieces of information in working memory — architecture decisions, tool quirks, process exceptions, undocumented behaviours — just to complete routine tasks. This causes errors, slowdowns, and exhaustion. DX survey questions that measure cognitive load: "I understand how to deploy a service without asking for help", "Our systems are easy to reason about", "I can make changes confidently without fear of breaking something I don't know about." Presentation language: "Our cognitive load scores indicate our internal platform is too complex — developers need a simpler, paved-road deployment path."
6 / 14
PR Description: 'Fix: Updated the API endpoint for user profiles. Resolved a bug where the avatar URL was sometimes incorrect. Performance improvements achieved.'
During a code review discussion, Sarah asks, "What does 'performance improvement' actually mean in this context? Are we talking about reduced latency, or something else?", and Mark replies with:
'A' – It just means the API is faster now.
'B' – It refers to a measurable reduction in response time, ideally below 200ms for most requests.
'C' – It indicates that we've optimized the code and reduced the number of lines of code.
'D' – It means the API is more stable and reliable, with fewer errors.
The term 'performance improvement' in DX often refers to measurable changes in system behavior. While reducing latency (Option B) is a common understanding, it's crucial to define what 'faster' means quantitatively – typically measured by response time metrics. Options A and C are too vague; Option D focuses on stability rather than actual performance gains. It's important to understand that DX metrics require specific, quantifiable improvements to be truly meaningful.
7 / 14
PR Description: 'Fix: Updated the API endpoint for user profiles. Resolved a bug where the avatar URL was sometimes incorrect. Performance improvements achieved.'
During a code review discussion, Sarah asks, "What does 'performance improvement' actually mean in this context? Are we talking about reduced latency, or something else?", and Mark replies with:
'A' – It just means the API is faster now.
'B' – It refers to a measurable reduction in response time, ideally below 200ms for most requests.
'C' – It indicates that we've optimized the code and reduced the number of lines of code.
'D' – It means the API is more stable and reliable, with fewer errors.
The term 'performance improvement' in DX often refers to measurable changes in system behavior. While reducing latency (Option B) is a common understanding, it's crucial to define what 'faster' means quantitatively – typically measured by response time metrics. Options A and C are too vague; Option D focuses on stability rather than actual performance gains. It's important to understand that DX metrics require specific, quantifiable improvements to be truly meaningful.
8 / 14
PR Description: 'Fix: Updated the API endpoint for user profiles. Resolved a bug where the avatar URL was sometimes incorrect. Performance improvements achieved.'
During a code review discussion, Sarah asks, "What does 'performance improvement' actually mean in this context? Are we talking about reduced latency, or something else?", and Mark replies with:
'A' – It just means the API is faster now.
'B' – It refers to a measurable reduction in response time, ideally below 200ms for most requests.
'C' – It indicates that we've optimized the code and reduced the number of lines of code.
'D' – It means the API is more stable and reliable, with fewer errors.
The term 'performance improvement' in DX often refers to measurable changes in system behavior. While reducing latency (Option B) is a common understanding, it's crucial to define what 'faster' means quantitatively – typically measured by response time metrics. Options A and C are too vague; Option D focuses on stability rather than actual performance gains. It's important to understand that DX metrics require specific, quantifiable improvements to be truly meaningful.
9 / 14
PR Description: 'Fix: Updated the API endpoint for user profiles. Resolved a bug where the avatar URL was sometimes incorrect. Performance improvements achieved.'
During a code review discussion, Sarah asks, "What does 'performance improvement' actually mean in this context? Are we talking about reduced latency, or something else?", and Mark replies with:
'A' – It just means the API is faster now.
'B' – It refers to a measurable reduction in response time, ideally below 200ms for most requests.
'C' – It indicates that we've optimized the code and reduced the number of lines of code.
'D' – It means the API is more stable and reliable, with fewer errors.
The term 'performance improvement' in DX often refers to measurable changes in system behavior. While reducing latency (Option B) is a common understanding, it's crucial to define what 'faster' means quantitatively – typically measured by response time metrics. Options A and C are too vague; Option D focuses on stability rather than actual performance gains. It's important to understand that DX metrics require specific, quantifiable improvements to be truly meaningful.
10 / 14
Mark asks in a Slack channel: 'Anyone else struggling with the new terraform plan output? It's returning way more warnings than usual.' What does Mark likely mean when he mentions 'warnings' in this context?
Mark's use of 'warnings' indicates that the terraform plan command isn't producing an error message but highlighting potential problems. These warnings aren't necessarily critical failures, but they represent areas where the infrastructure configuration might not be ideal or could lead to issues if not addressed. He needs to investigate these messages before proceeding with deployment.
11 / 14
During a standup meeting, Alex says: 'I'm still seeing high 'cognitive load' scores when onboarding new developers to our microservices. They're spending a lot of time just figuring out how the authentication service works.' What is 'cognitive load' in this scenario?
'Cognitive load' refers to the amount of mental energy a developer uses when learning or performing tasks. High cognitive load suggests that the system is complex and difficult for developers to grasp quickly – this can significantly impact their productivity and onboarding experience.
12 / 14
In a code review comment on a PR, David writes: 'This change introduces significant improvements in API response time. However, the documentation doesn't reflect these changes, leading to confusion for users consuming the API.' What is the primary issue highlighted here?
David's comment focuses on the discrepancy between the updated API implementation and its associated documentation. This misalignment creates uncertainty for developers consuming the API, as they rely on accurate information to understand how it functions. Maintaining consistent documentation is crucial for effective developer adoption.
13 / 14
During a discussion about DX metrics, Emily asks: 'How do we measure the impact of our developer training programs?' Which metric would BEST capture whether developers are effectively applying new knowledge in their daily work?
Measuring the effectiveness of developer training requires assessing whether developers are actually applying their newly acquired knowledge. Self-reported confidence levels provide a direct measure of this – if confidence increases after training and correlates with improved task performance, it indicates that the program is successful.
14 / 14
A developer, Liam, reports in a Slack channel: 'I'm spending way too much time debugging intermittent issues with our production deployments. It's incredibly frustrating!' What is Liam MOST likely referring to when discussing 'intermittent issues'?
'Intermittent issues' describe problems that don't happen predictably. These bugs are often complex because they depend on a combination of variables – making them difficult to diagnose and reproduce consistently in a controlled environment. This is a common source of frustration for developers.
What does the "Developer Experience Survey Language" exercise practise?
Practice DX survey vocabulary: developer NPS (eNPS), Likert scales, friction points, cognitive load, and developer journey mapping language for presenting survey results.
How many questions are in this exercise?
This exercise has 14 questions, each multiple-choice with a full explanation shown after you answer.
What English level is this exercise for?
This exercise is tagged Intermediate. If the vocabulary feels difficult, browse the Developer Experience Metrics category page for an easier module to start with.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free with no account, sign-up, or paywall.
Do I get feedback if I answer incorrectly?
Yes — whichever option you choose, right or wrong, you'll immediately see an explanation clarifying the correct term and why the other options don't fit.
Can I retry this exercise?
Yes — once you finish all the questions, a "Try again" button on the results screen resets the exercise so you can practise as many times as you like.
Do I need an account to track my progress?
No account is required. Your progress bar and score for this session are tracked in the browser as you go, but nothing is saved once you leave the page.
Is "Developer Experience Survey Language" part of a larger series?
Yes — it's one exercise in the Developer Experience Metrics category on CoderSlingo. See the category page for the full list of related exercises on similar terminology.
Can I link directly to this exercise?
Yes — this exercise has its own permanent URL, so you can bookmark it or share the link directly with a colleague or study partner.
Where can I find more exercises like this one?
See the Developer Experience Metrics category page for related exercises, or browse the main Exercises hub for other IT English topics.