Friction in software development
Written by Juho Vepsäläinen on . Last updated on .
Tags: productivity
Productivity is often framed as a tooling problem: better editor, faster build, newer framework, stronger assistant. Those matter, but a lot of developer productivity is lost in smaller sources of friction that are easy to ignore because they feel normal. This series looks at those sources of friction from a developer’s point of view. The goal is not to build a grand theory of productivity, but to give you a practical vocabulary for noticing what slows you down and what you can change. This post is the anchor for the series. It gives the taxonomy and points to the deeper articles you can study as you have time and interest.
How to use this guide
- Start here to understand the taxonomy.
- Pick the friction area that feels most visible in your daily work.
- Apply one small change: a font switch, naming cleanup, keyboard shortcut, focus block, or typography test.
- Notice whether the work feels easier, then repeat.
Quick practical advice
Before you go into the specific articles, here are the key highlights:
- Visual: choose code-friendly fonts, set a comfortable line length, and use enough contrast to scan without strain.
- Cognitive: name things at the right level of abstraction, keep control flow understandable, and choose patterns that fit the problem.
- Mechanical: consider keyboard, display, desk, chair, lighting, and input methods, so the body is not the bottleneck.
- Context: batch similar work, set communication expectations, and reserve no-meeting focus blocks to protect your time.
- Typography: test several monospaced typefaces on real code and prioritize glyph clarity over visual novelty.
- Process: reduce avoidable handoffs, make ownership visible, and match process weight to change risk.
- Toolchain: optimize the common development loop and treat flaky feedback as a product defect.
- Communication: capture decisions, clarify requirements, and make review context easy to recover.
- Organizational: align responsibility, authority, ownership, and incentives so developers can act.
What this series covers
- Visual friction: how code rendering and layout affect readability and quick comprehension.
- Cognitive friction: naming, complexity, and paradigm mismatch that increase mental effort.
- Mechanical friction: ergonomics, input flow, and physical comfort when coding.
- Context friction: flow, context switching, and managing your time.
- Typography friction: a dedicated look at typeface details and why they matter for developer flow.
- Process friction: how work moves through reviews, handoffs, approvals, and release paths.
- Toolchain friction: build, test, dependency, CI, and environment problems that slow feedback.
- Communication friction: missing context, unclear requirements, noisy channels, and undocumented decisions.
- Organizational friction: decision latency, fragmented ownership, permissions, and misaligned incentives.
Conclusion
Developer experience is not only one thing. It is the sum of many small interactions with code, tools, teammates, hardware, and attention. Improving one source of friction will not transform your work overnight, but it can make the next hour of development easier. By paying attention to ergonomics, you will improve the way you work, and even your wellbeing, over time so it’s worth the investment.