DEV Community: MonoLisa

Organizational friction in development

MonoLisa — Fri, 03 Jul 2026 13:14:32 +0000

Developers work in all kinds of organizations as software development is a core skill needed in many places. Some might even argue that every business is a software business these days. For this reason, developers often exist within an organizational structure, unless you are going at it indie style and you are the organization. For the purposes of this post, I'll focus on organizations with multiple people as that leads to structures and all kinds of organizational friction.

Sources of organizational friction

Organizational friction is related to process friction, and it has more to do with the way an organization is structured to work and how people work within the organization. It is within these interfaces that you encounter friction. What makes organizational friction difficult is that it can even be cultural. Typically, organizations have their way of working, and it's not always the most efficient one, at least from the point of view of a developer.

Depending on your organization, there are likely some kinds of structures in place with some form of hierarchy and ways of working together. Often hierarchies come with incentives, permissions, and ways to perform decision-making to further the goals of the organization. Friction occurs when teams feel like they cannot make decisions fast enough or priorities shift without a clear reason, ownership is fragmented, or developers have responsibility without any authority to act. These issues can lead to decision latency, misaligned incentives between teams, blocking work, and even demotivation due to not understanding why something is happening. Therefore, organizational friction can be dangerous as it may harm the organization in the long run.

How to reduce organizational friction

Most of the ways how to reduce organizational friction have to do with understanding the situation and then addressing it. I've listed several ways to reduce organizational friction below:

Clarify how decisions are made and who can do it.
Align ownership with responsibility. If you are responsible for something without having true ownership, that can lead to trouble as you would have to seek permission elsewhere.
Make sure priorities are explicit and well understood, so work is not put into areas that are not considered important.
Consider how approvals are set up and why they have been set up that way. For example, pushing even the smallest purchases through the highest levels of a company can be considered wasteful in terms of time usage.
With delegation, consider accountability and how it has been set up so that people remain accountable for their decisions.
Instead of focusing on activity, for example producing lines of code, focus on outcomes instead.

Practical advice

To sum up, there are several ways you could try to address organizational friction:

Look at the organization and identify where developers are waiting for decisions or permissions. Match permissions with responsibility.
Clarify who owns each system and related responsibility.
See if your approval steps are actually doing what they are supposed to. Are they reducing risk or simply moving responsibility?
If priorities within an organization change, make the reason behind this visible, so there is less guesswork to do.
Consider incentives within the organization. It is easy to reward local optimization at the cost of the whole system so find ways to address these kinds of situations.

Conclusion

Out of all the types of frictions covered, organizational friction is perhaps the most nebulous one since it's difficult to avoid, and often we cannot do so much about it ourselves. That said, organizational friction is worth addressing as it affects our wellbeing.

You can refer back to the anchor post of this series for more ideas related to friction.

Communication friction in development

MonoLisa — Fri, 03 Jul 2026 13:14:30 +0000

Although software development, and especially coding, is stereotypically treated as lonely work, in practice it's anything but. Now that coding tasks are increasingly pushed to machines, there is more space for communication with different stakeholders. That in turn opens the way for communication friction as having the right information at the right time becomes the key issue. In this post, I consider communication friction in detail and what to do about it.

Sources of communication friction

Whenever we work with other people, or even with agents, communication between different parties has to happen. As famously formulated by Wiio, "communication usually fails, except by accident". Although meant humorously, there is a seed of truth in the statement since it is quite normal for something to be interpreted in a way we didn't intend, and that in turn can affect our communication. This theme is visible in many places from requirements to bug reports to documentation and to decisions that exist only in someone's mind.

To give a better idea, consider the software development lifecycle and all its steps. Each step in a process is a chance for a misunderstanding. It all begins from requirements where vital information might be missing. Perhaps only the solution was described without any context telling what the solution is actually solving. This in turn can lead to an implementation that was interpreted from a specific angle, producing an outcome that doesn't solve the initial problem at all or does so in a way that doesn't make sense. To make things worse, the user might report a bug about the new feature without describing the expected behavior or leaving reproduction steps out, making it highly frustrating for the developer who has to deal with the issue.

Documentation is another good source of communication friction since there are many things that can go wrong. It can, for example, be stale and simply contain information that's not true anymore. There might be a lot of information describing the "what" while leaving out the often more important "why". Worse yet, product related decisions might have been left undocumented, meaning the same arguments might come up again as the reasoning for decisions is forgotten. Often there are good reasons for certain decisions, so it's worth writing them down as some of the reasons might be related to the current context, and context can change over time. A decision that made sense yesterday might not make sense today.

With the introduction of chat based communication via tools like Slack to our industry, we created yet another source of communication friction. Typically, all the messages look the same regardless of their importance, meaning you have to read all the messages to stay in the loop. There is value in summarization and not forcing people to follow these kinds of channels too closely as that is mentally draining over the longer term. It may be worth making clear policies for using these kinds of tools and relaxing the expectation of keeping up. The most important pieces of information should be summarized clearly outside of streaming systems for this reason.

While coding agents can produce huge amounts of code, that can lead to new problems fast as most organizations still prefer to understand what is included in the changes. At the time of writing, GitHub style pull requests are used for this purpose with the assumption that developers go through the proposed changes, perhaps with coding agents that can point out issues developers might miss. Even then, it can still be a lot for developers to review. To make things worse, pull requests might be missing clear context or an associated deployment, making it even harder to evaluate the changes.

How to reduce communication friction

Since communication is so prone to friction at different levels, it's worth acknowledging and addressing the related friction. I've listed several ways below:

Document your decisions. I've used Architectural Design Records (ADRs) with great success to document what was done and why. They don't capture all the technical details, but they leave enough paper trail to give enough context for anyone who is working on the project. Besides this, a higher level vision document is useful, and I tend to maintain separate documents for competitor analysis to help with positioning for example.
Describe the problem, related constraints, and tradeoffs in technical communication. Having enough context is essential as it helps to understand what you are trying to solve and why.
To improve transparency and to avoid interruptions, find easy ways to make your current status visible. This can help clear misunderstandings and calibrate expectations.
Leverage templates in your documentation work to produce familiar structures that are easy to understand. For example ADRs follow a specific format typically, and you can create your own templates for bug reports and pull requests to ensure you capture the information you want.
Do not underestimate the importance of documentation. Maintaining documentation takes conscious effort, but it has become particularly important now that we work with agents that have the same problem of having to construct context before working.
When there's potential for ambiguity and misunderstanding, prefer synchronous direct conversation, and record the outcome. Text based communication is prone to misunderstandings because it is missing social cues, and it might feel harsh because it is often not well filtered. People tend to communicate differently in text than in person.

Practical advice

To sum up this complex topic, I've included concrete advice below:

Spend conscious effort to manage context for your communications. Typically, anything that is implicit can be misunderstood by different parties as there might be different expectations. In particular, make sure to consider the "why" as that often gives motivation and helps others understand the rest.
Record your architectural decisions for example by using ADRs so future maintainers can find your decisions.
Make sure your bug reports are reproducible by default to avoid back and forth.
Separate urgent communication from ambient discussion (i.e. casual Slack chat).
If communication fails, consider why it happened and find ways to avoid this in the future collectively.

Conclusion

A surprisingly big part of development work has to do with communication. Now that we deal with agents that can infer meaning and context based on documentation, clear communication has become even more important than ever.

You can refer back to the anchor post of this series for more ideas regarding friction.

Toolchain friction in development

MonoLisa — Fri, 03 Jul 2026 13:14:29 +0000

As developers, we use different types of tools constantly to produce working software. Tools go beyond what we use at our own machines as often there are tools available within our broader environments in the form of continuous integration servers and other pieces of infrastructure. It is within this context that toolchain friction occurs as our tools don't work in an ideal manner or slow us down.

Sources of toolchain friction

If you look at the way you work with tools, it is surprisingly easy to discover sources of friction as any place where we waste time or effort can be considered as such. At a broader scale, the idea of toolchain friction is related to process friction and understanding your process and the tools within it is valuable in terms of mapping your toolchain friction.

Since a lot of our work is automated and well containerized these days, it typically means there are many phases in the overall process where we have to wait for something to install, build, and get tested for example. The choice of tools matters as some are simply faster than others. It is not only about speed, though, as having any source of non-determinism in your process can lead to for example flaky tests or non-reproducible failures. All of that adds to toolchain friction.

Another good example of toolchain friction is formed by the differences between your local, CI, and production environments. Perhaps there are subtle differences that lead to different results. To make things worse, the users might be using your product in a considerably different environment than you are. You can notice this for example with mobile web applications in situations where the client hardware is low grade and connectivity is not good. That is far different from what you might experience during development. In a sense, the friction is pushed to the user in this case making it difficult to notice.

As developers, we have to keep our software up to date to pick up the latest security updates for example. The fact that we have to do this adds friction to the process as it's not always so clear what are the exact impacts of a simple upgrade. On top of this, we often have to deal with mysterious error messages and occasionally poorly documented software. All of these tiny details add up.

How to reduce toolchain friction

While there are many sources of toolchain friction, at least some of it can be addressed through awareness. As mentioned, a lot of this comes down to understanding your process and where you are experiencing most of the friction. For example, I use a tool called Agent CI to run GitHub Actions locally. Agent CI works well with agentic development flow for fast validation before you hit the relatively slow CI server giving me a fast development loop and allowing partially autonomous development of features. A part of this kind of work is separating fast checks from slow ones since if you can catch issues with fast checks, it's an overall win for your workflow.

In any case, I would heavily recommend documenting your toolchain well and making it easy to get started with your project. It can be a great idea to containerize your project using Docker or a similar tool so you have the project clearly isolated from the host system, and it is easy to manage its dependencies. Since error messages and documentation are common sources of friction, it is worth putting effort into that department. Again, this direction goes well with agentic development since the agent can greatly benefit from an explicit context and easy error messages to understand.

In short, look for toolchain friction wherever you use any kind of tools and consider if you can improve the way they are used somehow. Occasionally the best thing you can do is to replace a tool with another. There has been a strong trend towards more performant tools in JavaScript ecosystem for example, and often it is easy to swap an equivalent yet faster tool to your project to waste less time waiting.

Practical advice

To summarize, there are several steps you could do to address toolchain friction:

Time how long each portion of your development loop requires from installation, to running, testing, linting, and building.
Identify the slowest portions and see if there is something you can do. Perhaps there are some configuration options you could leverage, or perhaps you could run more specific analysis or even use another tool. In general, scoping tool runs to code affected by changes can yield nice performance improvements. There the challenge is detecting the radius of the impact.
If you have flaky tests in your project, consider fixing or quarantining them instead of relying on reruns.
Document your project well so it is easy to understand the toolchain of the project and what is used and why. This helps in improving the project further in the future besides having onboarding benefits.
Unless your project has been containerized already, consider containerizing it so it's easier to resume developing the project as this process isolates your project from the host system and removes implicit assumptions.

Conclusion

Toolchain is a considerable source of friction for developers, and it is one of those we experience constantly. Therefore, it's worth considering its impact to our work, performing analysis, and improving where possible.

You can refer back to the anchor post of this series for more ideas regarding friction.

Process friction in development

MonoLisa — Fri, 03 Jul 2026 13:14:27 +0000

Often our work exists as a part of some larger process depending on our role in it. Sometimes the process is not even well understood by its stakeholders, and it might have been inherited from our predecessors.

It is within this framework that process friction exists. This post discusses process friction from a developer's point of view to understand where it shows up, why it accumulates, and what to do about it.

Sources of process friction

Typically, processes are defined by tasks, handovers, and feedback loops. Some of the tasks may occur in parallel even while having their own completion criteria. This simple definition gives us a way to think about process friction since it can occur within tasks themselves or handovers. For example, you might be able to complete your coding tasks so fast that acceptance and testing becomes a problem.

Optimizing a single part of the process may not make the entire process faster at all as described by theory of constraints. In short, friction may occur within a task, between the tasks, or when work is sent back in the process for revision.

There is also a whole meta-layer to thinking about processes since typically processes exist for a reason and there are specific characteristics the process tries to capture. It is normal there are multiple stakeholders to consider for example and there may be specific acceptance criteria in place to ensure high enough quality, so work items can progress through the process at a sufficient quality level.

It is these kinds of constraints that may add desirable friction to a process as specific inspections (security reviews or database migrations) may be needed especially if quality is an issue. A fast, friction-free process is not always even desired since you may want to give time for evaluation.

Sometimes a heavy process may imply low trust between participants. Perhaps something failed in the past, so the process had to be made more strict. Occasionally this may be fine, but with a heavier process you also tend to have more chances for friction. Therefore, focusing on how to reduce friction has particular value especially when the process is heavy to begin with.

How to reduce process friction

Before reducing friction, it is a good idea to perform process mapping. Process mapping allows you to consider who is doing what, when, and why. Essentially it allows you to write down the steps of your process while evaluating their relationships. This process of elaborating what is happening can be valuable in itself and help you gain a strong understanding of what is going on before you might want to change anything.

It is this kind of mapping that helps you appreciate the different parts of the process and allows you to change it. Perhaps there is something in the process that is now unnecessary, or perhaps some things could be done in an alternate order. There may also be room for some level of parallelization. On top of this all, you have to consider what kind of resources you have available as you might be able to leverage those to your benefit. Also reallocating resources to the slowest parts of the process may speed up the overall process at a minimal cost.

Besides analysis, there may be room for automation. Especially with current agentic development tools, it seems clear that tasks, such as testing, have become much cheaper to perform. Therefore, it is worth investigating where you can benefit from automation. As mentioned, automation alone may not speed up the overall process unless you are addressing something that was slowing down the overall process considerably. Improving the wrong part of the process may even increase stress at other parts of it as they have to deal with a higher volume of input and hence may become overwhelmed. A good example is the flood of automated pull requests encountered by open source maintainers.

Changing a process is never an easy task, and it should be done mindfully. Only optimizing your portion of the work may be missing the point. It is worth it to consider other parts of the process and look for the low-hanging fruit that improve the overall process without reducing its key attributes, such as security or quality. The key point is to optimize the whole process, not only your local convenience.

Practical advice

In technical terms, there are many ways to improve a process further. Our industry is often great at optimization at least locally. Optimizing the whole system may be another story. To keep it short, consider the following:

See if you can observe specific kinds of delays in your team workflow and measure where time is spent.
Clarify roles within a process to address bottlenecks. For example, it's possible that there are not enough people with review or release rights.
Make sure you have the right people in play at the right times of the process to avoid pushing work back in the process as that can be costly.
See if there are repeating tasks that could be automated or turned into guidelines to follow. Generally, rules have value especially when working with agents as they need strong guardrails to function well.
Separate active work from waiting time and measure both. It's possible a lot of time in the process is simply spent waiting. That's when you know there's something clear to optimize.
Perform process mapping to create an explicit view to your process. This is particularly useful for onboarding new developers to your process.

Conclusion

Processes are an important part of our daily work even if we don't think about them consciously. That is also the tricky part since it can be so easy to get accustomed to them and go with the routine. It is this psychological part that can make them difficult to change as you need conscious effort to understand what you are doing and why.

That said, focusing on your process can lead to significant improvements in terms of productivity. A good process also makes work less frustrating and more predictable, so this is not only about productivity. It is also about working conditions.

You can refer back to the anchor post of this series for more ideas.

Typography friction in development

MonoLisa — Fri, 03 Jul 2026 13:14:24 +0000

Typography sits at the crossroads of visual and cognitive friction. It shapes how quickly developers recognize characters, scan structure, and stay comfortable while reading code.

This post focuses on typography from a developer's point of view: typeface choice, glyph clarity, spacing, ligatures, and the tradeoff between compactness and legibility.

Why is typography important for developers

Typography matters because software development is full of text. Code, terminals, logs, documentation, comments, stack traces, pull requests, and issue trackers all rely on characters being easy to recognize and comfortable to read.

For developers, typography is not only about taste. A programming typeface has to handle dense symbols, similar-looking glyphs, punctuation, mixed case, indentation, and long reading sessions. Small design decisions become practical because developers see them all day.

What to look at in typefaces

Many developers use whatever font ships with the editor. That is understandable, but it is worth knowing what to evaluate when trying alternatives.

For code, the usual starting point is a monospaced typeface because each character occupies the same horizontal width. This supports indentation, alignment, tabular output, and fast scanning. Beyond that, there are several features to inspect:

Character differentiation: compare 1, l, and I; 0 and O; quotes; commas; periods; colons; braces; brackets; and operators. If these blur together, the font is adding work.
Line height and spacing: line height is usually adjustable in the editor, but the underlying design still matters. A cramped typeface can feel efficient at first and tiring later.
Width: compact fonts fit more code horizontally, but they often reduce internal space inside wide characters such as m and w. Wider fonts use more space, but can be calmer to read.
Ligatures: many developer typefaces include optional ligatures. They can improve recognition for operators, but they can also hide literal character sequences. Try them rather than assuming they are always better or worse.
Feature control: good code fonts should let you choose alternates, disable features, and tune behavior across environments. In MonoLisa, for example, ligature behavior can remain subtle by default while stronger replacements stay optional.

Practical advice

Choosing a typeface is partly personal, but the experiment should be concrete:

Pick several typefaces with different characteristics and render the same real code snippet in each.
Include dense code, tests, logs, terminal output, and diffs in the comparison.
Try one typeface for at least a day before judging it. First impressions can be misleading.
Adjust line height, font size, and ligatures separately so you know what changed.
Treat typeface choice as part of ergonomics. Free fonts can be excellent, and paid fonts can be worth evaluating when they solve a problem you feel every day. Although the cost may feel substantial initially, consider it as a long-term investment in your wellbeing.

Conclusion

Typography is a small configuration detail with a large surface area. You see it in every line of code, every terminal command, and every review. That makes it worth tuning deliberately.

As there are more sources of friction in development, refer back to the anchor post of the series to learn more about the topic.

Context friction in development

MonoLisa — Fri, 03 Jul 2026 13:14:22 +0000

Context friction is the cost of switching, interruption, and attention recovery. It shows up when you move from implementation to Slack, from code review to a meeting, from a failing test to an unrelated support question, and then back again. The interruption itself may take only a minute, but it can take a long while to rebuild the mental model you were using before the interruption. Besides feeling annoying, this can feel draining over longer term and add up if interruptions are common.

Flowing alone

Mihaly Csikszentmihalyi's concept of flow is well known in creative work: the state of deep focus where time seems to move differently and the task has your full attention. Programming often benefits from this state because you are holding many details at once: the goal, the current implementation, constraints, edge cases, and the next step. Unfortunately it is easy to break flow. One notification at the wrong time can be enough to lose the thread, after which you have to reconstruct the context before you can make progress again.

My preferred way to protect flow is to split the working day into segments dedicated to different types of work. Lunch provides a natural boundary, and it is usually unrealistic to expect deep focus for an entire day. Some people prefer shorter blocks, such as Pomodoro sessions: 25 minutes of work followed by a short break.

The benefit of chunking is that it lets you decide what kind of work belongs where. I have learned that meetings are tiring for me, so I prefer to push them toward the end of the working day when I am less likely to do good deep work anyway. Other people may have different rhythms, but the principle is the same: place expensive cognitive work where your attention is strongest.

In short, protect the blocks where focused development can happen. Disable notifications, close unrelated tabs, and make your availability visible, so teammates know when to expect a response.

Flowing together – pairing, ensemble programming

Although programming is often treated as solo work, it does not have to be so. With a colleague who has complementary skills, pair programming can reduce context friction because decisions, implementation, and review happen in one shared loop.

Modern language models, or agents, can also fill part of this role when a human pair is not available. They can help explore options, draft code, explain unfamiliar APIs, or keep a task moving. This can be effective, but it requires discipline: you still need to review the output, understand the design, and keep ownership of the result, otherwise you risk producing what is commonly known as AI slop. So be mindful when working with machines and make sure you are sitting in the driver's seat.

Agentic tools introduce their own context friction. You may be tracking your own plan, the tool's plan, generated diffs, review comments, failing checks, and hidden assumptions at the same time. Used well, the tool reduces load. Used carelessly, it creates a new stream of work to supervise.

This kind of friction tends to add up especially if you are running multiple agents in multiple contexts at once, and it can easily become overwhelming to keep track of all the action. The machine can move far faster than you can so you have to find efficient ways to deal with this difference in available bandwidth without stretching yourself too far.

You can also combine human collaboration and machine assistance. In an ensemble or mob programming setting, the team can make product decisions, document them, and implement them while the shared context is still fresh. Besides speed, working together leads to fewer handoffs and a shared vision of what was done and why as work is shaped together.

Practical advice

The practical goal is to reduce avoidable context rebuilds:

Use timeboxes and focus sessions, such as Pomodoro blocks or 90-minute deep-work sessions.
Set expectation rules for communication channels. You do not have to respond immediately to everything.
Batch similar tasks: reviews together, meetings together, support work together, implementation together.
Leave breadcrumbs before switching: a failing test name, a short note, or the next command to run.
Treat unfinished work as a context object. Capture enough state that future you can restart quickly.

Conclusion

Context friction is often invisible because interruption feels like a normal part of the job, but it doesn't have to be so. The more complex the work, the more valuable it becomes to protect attention deliberately.

You can refer to the anchor post of this series for more ideas.

Mechanical friction in development

MonoLisa — Fri, 03 Jul 2026 13:14:20 +0000

Software development looks like knowledge work, but it still happens through a body: eyes, hands, wrists, neck, back, ears, and voice. Mechanical friction is the physical cost of interacting with the machine. That cost is easy to ignore until it becomes pain, fatigue, or avoidance. This post looks at the physical side of development work and the places where small improvements can matter.

Mechanical friction in development

In simple terms, mechanical friction is the physical effort required to write, read, navigate, hear, and operate development tools. It includes hardware, posture, lighting, audio, keyboard layout, pointer use, shortcuts, and alternative input methods.

This is the most concrete source of friction in the series because it is about the interface between you and the machine.

How to address mechanical friction

A big part of mechanical friction is ergonomics. Hardware, software mechanics, and input modes all shape how much physical effort the work requires. The main areas to inspect are keyboard, pointing device, display, desk, chair, lighting, audio, and repetitive operations inside your tools.

Many developers prefer external keyboards because laptop keyboards force a narrow posture and fixed screen position. I have found that a slight angle is better for my wrists, and a simple laptop stand can already improve the relationship between keyboard, screen, and neck.

Keyboard layout can matter, but layout changes are only one lever. Shortcuts, macros, snippets, editor commands, and command palettes can remove repeated physical work without requiring you to relearn typing. Voice input and AI assistants are also worth exploring for tasks where typing is not the valuable part of the work.

A good display configured well can make a large difference. Resolution, scaling, text rendering, brightness, coating, refresh rate, and physical height all affect comfort. I have found 5K displays a good fit for Apple-based setups because scaling tends to behave nicely, while many Windows and Linux users are happy with 4K or other configurations. If possible, test a display in person because coatings, brightness, and text rendering are difficult to judge from specifications alone.

Desk setup matters because development often rewards staying still for too long. A useful ergonomic idea is that the best posture is the next posture and for this reason some developers alternate between sitting and standing. I have used a saddle chair for several years because it changes the leg angle and encourages a more active posture, but it is not the right choice for everyone. Therefore, before buying specialized furniture, it is better to borrow or test it so you understand if it's a good fit for you.

Lighting can either support the display or fight it. Avoid glare, direct light into the eyes, and large brightness differences between the screen and the room. I prefer indirect light with adjustable color temperature and intensity. You do not need a complex setup to benefit from this: even a better lamp position can reduce strain.

Practical advice

Mechanical friction is difficult to remove entirely, but many improvements are cheap:

Review your keyboard and pointer setup. Look for repeated motions that shortcuts, macros, snippets, or editor commands could remove.
Check display height, distance, scaling, font size, and brightness. Small adjustments can change how your neck and eyes feel by the end of the day.
Inspect your desk and chair setup. Add movement, alternate postures, and avoid long stretches in one position.
Fix lighting problems: glare, excessive contrast between screen and room, and direct light into your eyes.
Check audio comfort. Headphones, speakers, meeting rooms, and open-office call rules all affect physical and attention load.
Try alternative input for suitable tasks. Voice, dictation, and agentic tools can reduce typing when used deliberately.

Conclusion

Mechanical friction is worth addressing early because the warning signs can arrive late. Ergonomics is a large topic, and Repetitive Strain Injury is worth understanding before pain forces the issue.

The practical approach is to change one area at a time, observe the effect, and avoid turning ergonomics into an expensive shopping project. The goal is not a perfect setup. The goal is to make development physically sustainable.

Mechanical friction is only one source of friction in software development. You can refer back to the anchor post of the series to learn more.

Cognitive friction in development

MonoLisa — Fri, 03 Jul 2026 13:14:18 +0000

Cognitive friction is the extra effort required to understand what is in front of you. A familiar example is reading text in a language you only partly know: the words may be visible, but meaning arrives slowly if at all.

Developers run into the same problem in code. The compiler may understand the program, but the human reader still has to reconstruct intent, constraints, data flow, and tradeoffs. This post looks at where that effort comes from and how to reduce it.

Sources of cognitive friction for developers

Naming is one of the easiest places to create or remove cognitive friction. Good names do not have to be long, but they should match the level of abstraction around them. Algorithmic code can often use compact mathematical names because the surrounding concepts are abstract. Domain code usually benefits from more specific names because the reader is trying to connect code to business meaning. This is where domain-specific languages (DSLs) may have concrete value.

Friction appears when the abstraction level and the name disagree. Consider a function called processData in a payment system. To discover the real action, the reader has to open the implementation and read the function. In contrast, a function called captureAuthorizedPayment carries more context at the call site. That difference compounds when you return to a codebase months later or search for the place where behavior lives. This may also matter for coding agents that rely on names to infer intent.

Structure matters as much as naming. The more a reader has to jump between branches, callbacks, files, and abstractions, the harder the program is to hold in working memory. McCabe's cyclomatic complexity gives one measurable view into this, and many static analysis tools can track it.

Complexity metrics are not a substitute for judgment, but they are useful signals. Sometimes the best improvement is not another abstraction, but inlining a small helper so the local story becomes obvious. Performance-sensitive code may have different tradeoffs, which is why measurements, benchmarks, and profiling matter. The point is not to make every function tiny. The point is to make the important behavior easy to follow.

Paradigm mismatch is another source of friction. Some problems fit naturally into declarative descriptions, some into pipelines, some into state machines, and some into plain imperative steps. Frameworks encode these preferences too. When you work with the framework, the code can feel direct. When you fight it, every feature starts to require exceptions and escape hatches.

Mixed paradigms can be a good choice when each part is doing a clear job. For example, a declarative UI can still call imperative code at the edges where the system talks to files, networks, or devices. Friction grows when the boundary is accidental rather than designed.

How to address cognitive friction

Start with naming because it is cheap and visible. Use nouns for things, verbs for actions, and domain terms where they clarify intent. Avoid catch-all names such as data, item, value, or handler when a more specific term is available. A good test is whether a teammate can understand a call site without opening the implementation.

Look at control flow next. Flatten deeply nested logic where you can, return early for invalid cases, and make invariants explicit. Design by contract, popularized by Eiffel, is still a useful mental model: state what must be true before and after an operation. That framing also connects well to property-based testing, where tests explore whether those invariants hold across many generated inputs.

Static analysis can help you see where cognitive friction is accumulating. Complexity scores, lint rules, type checks, dependency graphs, and dead-code detection all reveal different aspects of code shape. A related signal is churn: files that change often deserve extra design attention because small misunderstandings there are expensive.

When delivering features, consider a lightweight quality gate around complexity. It does not have to block every merge, but it should make complexity visible in review. This becomes even more useful with agentic development workflows, because clear constraints give coding tools something concrete to optimize against. In short, guardrails help keep your agents on track, especially when their outputs can vary between runs.

Conclusion

Cognitive friction sits at the center of software work because development is mostly structured understanding. You cannot remove it entirely, but you can make code easier to re-enter, review, modify, and trust.

You can learn more about the sources of friction in software development from the anchor post of this series.

Visual friction in development

MonoLisa — Fri, 03 Jul 2026 13:14:16 +0000

You encounter visual friction when something is technically visible but difficult to parse at a glance. For developers, this matters because a large part of the job is reading: code, diffs, logs, terminals, documentation, error messages, and pull requests. Visual friction does not have to make code impossible to understand. It only has to slow recognition slightly. Across thousands of small reads per day, that cost becomes real.

What is visual friction

A big part of development work is recognizing patterns. We split code into functions, modules, and files partly because doing so gives the reader structure. The same is true visually: indentation, spacing, syntax color, line length, and typeface choices all affect how quickly the structure appears.

It is useful to separate cognitive friction from visual friction. Cognitive friction is about understanding meaning. Visual friction is about seeing structure. They interact, but they are not the same problem.

You already use techniques to manage visual friction: syntax highlighting, indentation guides, monospaced fonts, diff colors, warnings, icons, spacing, and formatting tools. Good interfaces use these cues to help the important parts stand out.

Not all friction is bad. Interfaces sometimes add friction intentionally before destructive actions because slowing the user down is the point. But in normal reading and navigation, unnecessary visual friction makes development feel heavier than it needs to.

Examples of visual friction

To give you a better idea of what visual friction really is, consider the examples below:

Glyph ambiguity matters. Common checks include 0 versus O, 1 versus l versus I, and punctuation such as quotes, commas, periods, and colons. If characters are hard to distinguish, the reader has to spend attention on decoding rather than understanding.
Syntax highlighting can make structure faster to detect, but color is not automatically helpful. Too many strong colors create noise. Too little contrast hides useful distinctions. Hillel Wayne has a good critique of how syntax highlighting often wastes its information budget in "Syntax highlighting is a waste of an information channel".
Theme choice matters because developers stare at the theme for hours. Dark and light themes can both work well if contrast, saturation, and ambient lighting are handled carefully. I have found Catppuccin pleasant because it is not too loud and can be tuned across tools.
Lighting affects visual comfort. A glossy display in direct light, a bright monitor in a dark room, or a theme that fights the surrounding environment can all increase strain. Features such as Night Shift can help some people, but monitor brightness, room lighting, breaks, and daylight exposure matter too. Research increasingly suggests the problem isn't blue light alone but the exposure to the light at an appropriate time of the day.
Line length, spacing, and indentation matter. My preference for code is roughly 80 to 110 characters. Longer lines become tiring to scan, while very short lines can create excessive wrapping. For formatting, tools like Prettier reduce debate and keep code visually consistent across contributors.

How to reduce visual friction

The simplest improvements are often configuration changes: formatter defaults, theme tuning, line length, font size, line height, and typeface. Defaults are not always bad, but they are rarely chosen for your eyes, your display, your lighting, and your work.

Typeface choice deserves special attention because it affects every line of code you read. In general, it is a good idea to test different available options since a typeface that looks nice in a specimen may behave differently in dense code, terminal output, or diffs. MonoLisa was designed for code legibility in particular and may be an option worth benchmarking.

Beyond these, there are a few more actions you could consider:

Set a visible line-length guide around the range that works for your team. Around 100 characters is a practical starting point for many codebases.
Tune your theme so important structure stands out and comments, generated code, and secondary information recede.
Use a formatter consistently. Formatting arguments are rarely worth spending review attention on.
Check visual consistency across editor, terminal, browser, documentation, and pull request tools. Switching between very different visual environments creates its own friction.
Test code fonts with the files you actually edit, including dense code, tests, logs, and diffs.

Visual tradeoffs

It is one thing to optimize visuals for yourself and another to optimize them for a team. Formatting rules, generated-code markers, review settings, and documentation layout are good team-level decisions because consistency helps everyone. Font, theme, and ligature choices can usually remain personal unless the team is producing shared screenshots, demos, or documentation.

Some font features come with tradeoffs. Ligatures can improve pattern recognition for operators, but they can also hide the literal characters being typed. A good compromise is to start with subtle spacing improvements and only enable stronger substitutions if they genuinely help you read. Good developer typefaces expose these choices instead of forcing one style on everyone.

Conclusion

Visual friction is easy to underestimate because developers adapt to bad defaults. That adaptation has a cost. Small improvements to rendering, spacing, contrast, and type can make code easier to scan all day.

If you want to investigate other sources of friction, refer back to the anchor post for more ideas. The closest related article is typography friction, which looks more closely at typeface choices for developers.

Friction in software development

MonoLisa — Fri, 03 Jul 2026 13:14:14 +0000

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.

MonoLisa version 3 – now with MonoLisa Text family

MonoLisa — Wed, 17 Jun 2026 12:14:40 +0000

MonoLisa is a typeface that has been in development since 2020. Over five thousand software developers and companies have adopted it since as their font of choice. Now with version 3, the family expands yet again and in this post we show you how the font has evolved now to cover design tasks as well. It is quite rare that a typeface receives continuous care and effort from its creators but here we are still at it six years later. Without you, the community who gave us so much valuable feedback, MonoLisa wouldn’t be where it is now.

TLDR; Read the migration guide if you are coming from version 2 and just want to see the changes.

Versions 1 and 2

The first version published in 2020 included a monospaced version aimed specifically at developers. The key point of version 1 was to offer a razor sharp monospaced font with clear focus on distinction and legibility.

The second major version released on 2022 went a notch further by enabling variable weight. In other words, it became possible to make the font as thick or thin as you like since sometimes that's all you need to squeeze out that last bit of legibility. The introduction of variability also made the font useful for web related tasks as by shipping a variable version to your client, you can access all its weights without having to deliver multiple files.

The second version also included a customization tool that lets you freeze font features since many editors and other applications available today have limited options on how to access your font features. Freezing solved this problem as it literally froze font features, such as specific characters, directly to the font itself thereby working around limitations of software.

Version 3 – the family grows with MonoLisa Text

Now with version 3, the family grows with a new member besides MonoLisa Code, the original typeface. The new font family called MonoLisa Text covers the other half of common usage where a monospaced typeface reaches its limits. In other words, MonoLisa Text is a proportional family designed for use cases where you might have regular text and therefore completes the family while working as a complementary pair to the original version. This makes it ideal for use cases such as prose, user interfaces, presentations and any sort of printed items like books, magazines and the like.

The introduction of MonoLisa Text makes the type family useful beyond programming as now it covers a wide range of design tasks making it a handy tool for designers to wield in their arsenal. Besides this major addition, we have made series of smaller changes that expand the usefulness of the original font family MonoLisa Code.

New, more adjustable ligature behavior

Ligatures are a typography feature that allows replacements of multiple characters, such as ===, into a single one. Some people greatly prefer this behavior while others find it distracting. Therefore, it is always an optional feature in typefaces.

If you use an editor like VS Code, then the typical way to enable ligatures in your editor is to set "editor.fontLigatures": true. This is the equivalent to setting "editor.fontLigatures": "'liga', 'calt'" so in other words it is enabling two sets of features, ligatures and so-called contextual alternates. The liga set typically contains replacements like fi or fl to improve character flow in a subtle manner while calt goes further and typically in programming fonts it is that set that contains combinations like === or \>\= (>=).

The problem is that typically ligatures are "all or nothing" kind of deal meaning even if you liked some of the replacements, you will also get ones that you don't like, meaning enabling the whole set is not useful to you. To address this issue, we decided to go against the norm in version 3 and changed the behavior so that liga and calt do only slight space altering adjustments that you barely notice while moving specific groups of ligatures behind character variants known as cvs in OpenType specification. This goes well with MonoLisa since it is a combination of a typeface and a service that allows you to customize the font to your liking. If you are using an editor other than VS Code or some other that lets you adjust font behavior at a great detail, you can still freeze the specific ligature groups you prefer to your static font files.

More distinct characters are now available

Since legibility is one of our key concerns when designing MonoLisa, version 3 was a great point to revisit some of the characters to make them more distinct. These changes are particularly useful for dyslexic users while benefitting others as well as tends to be the case with accessibility improvements. In specific, letters a, b, d, e, p, q, and similar across all languages and scripts have been adjusted as shown by the visual comparison below:

In addition, selected letters in the light master have been widened:

Vertical metrics have been adjusted to allow easier usage in a UI context:

Grade axis – Adjust glyph weight without changing line breaks

Version 3 includes a new axis called grade (GRAD in OpenType). Essentially it allows you to subtly nudge lightness/darkness of a font. The feature is particularly useful if you work with MonoLisa Text and want to tune weight without changing your line breaks as described by web.dev. Why would you do this, though? It turns out there are subtle differences in how people perceive weights against dark and light backgrounds. Sometimes a small bump to a direction or another is all you need and in VS Code you could for example set "editor.fontVariations": "'GRAD' 25" to bump a notch up or "editor.fontVariations": "'GRAD' -25" to bump a notch down. In our case the scale goes from -50 to 50.

In technical terms, the feature affects stroke thickness while retaining character widths and spacing and avoiding breaking your line breaks for MonoLisa Text. So consider it especially as a design feature that allows you to do subtle tweaks depending on the context while retaining the same font weight.

Other changes

Besides these bigger changes, there have been other smaller changes we have listed below:

We reorganized and cleaned up stylistic sets, so the order makes sense again.
Figure 7 (seven) with a middle stroke was introduced as ss14.
Plain 0 (zero with no center element) was introduced as ss15. In MonoLisa Text the plain zero is the default and the dotted version is the variant.
The support for historical Greek was extended and the support for Armenian, Hebrew, and Braille has been added.

You can find full details and a migration guide at the release log.

New website

As we worked with the additions to the typeface, we realized it's not enough to update only the font, but the website has to be made to fit it and showcase the new features well. Compared to the earlier one, you will likely notice that sections, such as the landing page or specimen, have received major updates. We also had to make sure the customization tool works with the new additions.

Refreshed plans

The new version is available in three plans: Trial, Developer, and Creator. The Trial plan includes a subset of both Code and Text, and it has been limited in terms of weights (Normal and Bold). The key point is that Trial gives enough of an idea of what it's like to work with MonoLisa on your own system.

The new Developer plan replaces our earlier plans as it bundles all the features for personal usage (including websites) so there's no need to think about which plan to pick. There are two variants of the Developer plan. One with Code only and one including both Code and Text. It's also possible to upgrade to the version with Text later on if you are unsure of it.

The Creator plan has been designed for commercial use cases, and it allows you to buy exactly what you need for a specific case, such as a logotype or using a font in a book. It also allows designers to buy a font to use for their clients. Essentially this plan replaces our earlier commercial subscription options. If you are on an earlier commercial subscription, we recommend buying a fixed license, although you can still keep your earlier subscription in place if you prefer that instead.

Upgrade policy

A major version like this is always a major undertaking in terms of development time. We came up with a simple model for upgrades to take into account when and what you bought:

If you bought Complete starting from the beginning of this year, you'll have a free upgrade to Developer.
For anyone else, you'll get a discount based on proximity so that if you own version 2, you'll get a bigger discount than version 1 owners towards version 3.

Note that even if you decide not to upgrade, your current version will remain accessible. To ease maintenance burden, we'll sunset customize tool for version 2 in the coming months since the variant for version 3 has its own added complexity.

Conclusion

Version 3 is a major milestone for MonoLisa as it expands the family while improving the pre-existing one. Especially if you haven't tried MonoLisa, we recommend testing out the trial as it gives you an impression of how the typeface can work on your system since it's one thing to see and another thing to experience.

What are font ligatures?

MonoLisa — Tue, 22 Apr 2025 11:29:12 +0000

Font ligatures are a type feature where two or more glyphs are joined together. The resulting glyph, the ligature, replaces the matched glyphs. In this post, we will explore this type feature and explain its pros and cons while showing how to enable the feature. Some developers find ligatures useful in their workflow as they can improve the legibility of their code, so it is worth it to understand what the feature is about.

When are ligatures used?

If you look closely, you might notice that many fonts do something special with combinations of fi and ft. You might notice how letters are subtly joined together. Historically speaking, early typesetters would model the replacement letter as a single block for their printing machine, as mentioned by I love typography. Another interesting tidbit is that ampersand (&) started as the combination of E and t and was a ligature before being formalized as an official letter. Similar examples can be found from Nordic letters of Æ,Œ, and the German letter ß, which started as ligatures to improve legibility. The example below showcases several common ligatures from the MonoLisa typeface.

How are ligatures visible in the OpenType font specification?

If you look at the OpenType font specification carefully, you can notice it contains liga and dlig features. Both groups are meant for ligatures, and liga contains combinations that should be used in normal conditions, while dlig has been reserved for discretionary usage, and it is up to the user’s preference per the definition.

MonoLisa typeface includes both, and the idea is that liga contains more radical replacements while dlig has been reserved for spacing-related tweaks, making it more subtle. It is possible that typefaces interpret the rules for your convenience like this, and it is a good idea to check what OpenType features they offer and how if you want to get the most out of the typefaces you use.

What are coding ligatures?

Now that you understand what ligatures are and why they are used, it is good to consider how they can be used for programming. Several coding fonts contain these combinations as ligatures to improve the legibility of common combinations, such as !=. In other words, after replacement, the combination would stand out on its own, and often, you end up with a more mathematical look for your code that some programmers prefer. Given it is not a look all programmers like, it is possible to toggle the feature using liga and dlig OpenType flags, and even if a typeface contains ligatures, they aren’t enabled by default. Consider the figure below to get a better idea of what kind of coding ligatures are possible.

From the type designer’s point of view, providing ligatures for a coding font comes with some challenges. There is limited space to use since coding fonts are monospaced by definition and, therefore, take a fixed width. The key issue is to get the spacing and proportion right so that the resulting glyphs fit their context well.

Conclusion

Ligatures are a type feature that many typefaces contain to improve the legibility of certain letter combinations. Coding fonts provide ligatures specific to the task. In coding fonts, ligatures are an optional feature you can enable if you prefer the more math kind of look.