5 exercises — Practice the language used to measure, discuss, and improve developer productivity: DORA metrics, the SPACE framework, flow state, cognitive load, toil, and engineering effectiveness.
Key Developer Productivity vocabulary clusters
DORA metrics: deployment frequency, lead time for changes, change failure rate, MTTR (Mean Time to Recovery) — the four measures of software delivery performance
SPACE framework: Satisfaction, Performance, Activity, Communication/Collaboration, Efficiency — a holistic view of developer productivity beyond output
Developer experience (DX): inner loop vs outer loop, flow state, context switching, cognitive load, toil, onboarding time, time to first PR
An engineering director reviews the quarterly metrics report: "Our DORA metrics have improved significantly. Deployment frequency is up to 12 times a day, lead time for changes is down to 45 minutes, our change failure rate is 3%, and MTTR is under 30 minutes — we're firmly in the Elite tier." Which of the following is not one of the four official DORA metrics?
Sprint velocity is a Scrum metric, not a DORA metric. The four DORA metrics are: deployment frequency (how often you deploy to production), lead time for changes (commit → production), change failure rate (% of deployments causing a production incident), and MTTR / time to restore service (how quickly you recover from a failure). DORA (DevOps Research and Assessment) research identifies Elite, High, Medium, and Low performance bands for each metric. Elite teams deploy multiple times per day, have lead times under one hour, a change failure rate of 0–5%, and MTTR under one hour. In conversation: "We track all four DORA metrics — they give us a balanced view of speed and stability."
2 / 5
A developer experience researcher presents findings to the leadership team: "We can't measure productivity with a single number. The SPACE framework gives us five dimensions. We look at whether developers feel satisfied with their tools, whether features actually reach users (performance), their daily activity levels, how well teams communicate and collaborate, and how efficiently they move work from idea to production." What does the letter E stand for in the SPACE framework?
Efficiency — in SPACE, efficiency measures how smoothly work flows: minimal context switching, low wait times, unblocked pull requests, and fast feedback loops. SPACE in full: S — Satisfaction and wellbeing: do developers find their work meaningful and their tools adequate? P — Performance: does the developer's output produce the intended outcome for users? A — Activity: quantifiable outputs — commits, PRs, deployments, code reviews. C — Communication and Collaboration: how effectively do team members share knowledge and work together? E — Efficiency and Flow: minimal interruptions, short feedback loops, ability to enter flow state. The SPACE framework (Nicole Forsgren et al., 2021) was designed to counter single-metric traps — no one dimension tells the whole story. In conversation: "Our Activity score is high but Efficiency is low — developers are busy but constantly blocked."
3 / 5
A senior engineer explains the difference between two productivity concepts during a team retrospective: "There are two loops in our daily work. The inner loop is what I do dozens of times a day — write code, run tests, get feedback, fix, repeat. The outer loop is less frequent — opening a PR, waiting for CI, getting a review, merging, watching the deployment. Slow outer loops kill momentum just as much as slow inner loops." Which statement best describes the inner loop vs outer loop distinction?
Inner loop: the rapid local feedback cycle a developer repeats many times per hour — write code, compile/lint, run unit tests, see output, fix. A fast inner loop keeps developers in flow state. Outer loop: the broader delivery cycle executed less frequently — open PR, wait for CI pipeline, receive code review, address comments, merge, watch deployment, confirm in production. Both loops matter for DX. Optimising the inner loop: faster builds (incremental compilation, watch mode), instant test feedback, hot reload. Optimising the outer loop: shorter CI pipelines, async code review culture, automated deployment. Vocabulary note: feedback loop is a general term; inner/outer loop is the DX-specific refinement. In conversation: "Our inner loop is fast — tests run in 4 seconds locally. Our outer loop is the bottleneck — PRs sit for 2 days waiting for review."
4 / 5
An SRE team lead discusses operational overhead in the weekly engineering meeting: "A large chunk of our week is spent on toil — manually rotating secrets, restarting crashed pods, resizing volumes because autoscaling isn't configured, manually approving deployments in a ticket queue. Every hour on toil is an hour not spent improving the platform. Google SRE recommends keeping toil below 50%." According to Google SRE, what is the defining characteristic of toil?
Toil (Google SRE definition) has six properties: manual — requires a human to execute; repetitive — done again and again; automatable — a machine could do it; tactical — reactive, no enduring value once done; no lasting value — finishes and immediately needs doing again; scales with service growth — more services, more toil. Toil is distinct from overhead (meetings, admin) and from valuable operational work (genuine incident response that teaches something). The SRE toil budget: keep toil below 50% of an SRE's time. Above 50%, the role becomes pure operations — no platform improvement happens. Toil elimination vocabulary: runbook automation, self-healing systems, operator pattern (Kubernetes), ChatOps, auto-remediation. In conversation: "If we automate the secret rotation, that removes about 3 hours of toil per week per engineer."
5 / 5
A Head of Engineering explains the DX programme to new engineering managers: "We measure developer experience through a combination of system metrics and human perception. We track time to first PR for new joiners, context switching events captured by our IDE plugin, cognitive load surveys, and flow state time — the percentage of the day developers report being in deep, uninterrupted focus. Context switching is our biggest problem: every Slack interrupt costs roughly 23 minutes of recovery time." In a developer productivity context, what is cognitive load?
Cognitive load (from cognitive psychology): the mental effort required to hold information in working memory while performing a task. In software engineering, high cognitive load comes from: complex or poorly documented codebases, context switching between unrelated tasks, unclear ownership, excessive meeting interruptions, and too many tools. Reducing cognitive load is a central goal of platform engineering (Team Topologies). Related DX vocabulary: flow state — a mental state of deep, immersive focus where productivity peaks; disrupted by interruptions. Context switching — shifting attention between tasks; research suggests it takes ~23 minutes to fully regain focus. DX (Developer Experience) — the overall quality of a developer's interaction with their tools, processes, and environment. Time to first PR — onboarding metric: how quickly a new hire makes their first merged contribution. Onboarding time — the full period until a new developer is independently productive. Engineering effectiveness — an organisational discipline combining metrics, tooling, and culture to improve developer output and satisfaction. In conversation: "Reducing cognitive load is not a nice-to-have — it directly reduces bug rates and increases throughput."
These modules build the same on-the-job skills as Developer Productivity Vocabulary
— work through them together for a fuller vocabulary set.
Developer Experience— useful for Developer experience (DX) vocabulary (Technical Writer)
Frequently Asked Questions
What does the "Developer Productivity Vocabulary" vocabulary exercise cover?
This exercise tests real IT vocabulary related to developer productivity vocabulary through 5 multiple-choice questions, each built from realistic workplace sentences rather than abstract definitions.
Is this vocabulary exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 5 questions. Each one shows a real-world sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question, and a full results screen at the end.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Are these vocabulary exercises connected to other topics?
Yes — this module shares real-world context with 1 other vocabulary module. See "Related vocabulary" below to keep building a connected skill set.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more vocabulary exercises?
Browse the full Vocabulary exercises hub for hundreds of modules covering Agile, DevOps, security, databases, architecture, and more — organised by IT role and skill.