The Best Tools Reveal What You Did Not Know to Ask For

What if the most important feature in a tool is not the command it performs, but the possibility it quietly reveals?

A command line interface can expose dozens of operations through bash autocompletion. A browser can expose a single preference, such as extensions.ui.developer_mode, that changes what becomes possible every time an extension is loaded. These seem like unrelated details: one belongs to terminal productivity, the other to browser configuration. Together, however, they point to a deeper design question:

Should a tool merely help us perform known actions, or should it actively teach us what actions are available?

The answer determines whether software remains a passive instrument or becomes an environment for learning. It also explains why some tools feel expandable and others feel strangely closed, even when they contain comparable capabilities.

The hidden difference between access and discoverability

Most software has at least three layers of capability. First, there are the operations the system can technically perform. Second, there are the operations the interface makes visible. Third, there are the operations the user can imagine asking for.

These layers are often treated as if they were the same. They are not. A capability that exists but cannot be found is functionally close to a capability that does not exist. If a developer has to search documentation, inspect source code, or guess a command before using a feature, the software has transferred the cost of discovery to the user.

Consider a command line tool for managing projects hosted on GitLab. Its underlying interface may support actions involving issues, merge requests, pipelines, variables, repositories, and authentication. Yet a new user does not begin with that conceptual map. They begin with uncertainty: What verbs are available? Which nouns can follow them? What flags modify the operation? What information can be retrieved locally?

Bash autocompletion changes this relationship. It does not merely save keystrokes. It presents a live outline of the tool's grammar. After typing a partial command, the shell can show the next valid choices. The user is no longer required to know the entire vocabulary in advance. They can explore by asking the interface, in effect, “What can come next?”

That is a profound shift. The interface becomes a search surface for affordances. It turns command construction into a conversation between intention and possibility.

A browser preference such as extensions.ui.developer_mode performs a related transformation, but at a different level. It changes the default environment so that developer capabilities are visible without repeated manual intervention. Instead of treating development as an exceptional state that must be rediscovered each time, the configuration makes it part of the ordinary workspace.

One mechanism reveals possibilities during action. The other reveals possibilities through persistent context. Both reduce the distance between a system's actual power and the user's practical awareness of that power.

Defaults are not conveniences. They are theories of the user

A default setting is often described as a convenience. That description is incomplete. Defaults are also claims about what the software expects users to do, what it considers normal, and which capabilities deserve attention.

When developer mode is disabled by default, the system is making a reasonable but consequential assumption: most users should not need development features in their daily experience. When a command line tool exposes completion for its full vocabulary, it makes a different assumption: users benefit from encountering the system's possibilities while working, even if they do not yet understand all of them.

Neither assumption is universally correct. The important point is that both shape behavior before the user makes a conscious choice.

A hidden feature imposes what we might call a discovery tax. The tax is paid in documentation searches, failed guesses, context switching, and repeated setup. A visible default, by contrast, creates an attention cost. It can clutter the environment, overwhelm beginners, or make advanced options appear more important than they are.

Good design does not eliminate both costs. It allocates them intelligently.

For an occasional browser user, persistent developer controls may be distracting. For someone testing extensions every day, hiding those controls is wasteful. For a beginner using a GitLab command line tool, showing every possible subcommand may be intimidating. For an experienced operator, concealing the command tree creates friction and dependence on external reference material.

The real design challenge is therefore not “visible or hidden?” It is “visible to whom, at what moment, and with what opportunity for learning?”

This gives us a useful model:

Capability value = system power multiplied by discoverability multiplied by repeatability.

A feature with high power but low discoverability has limited practical value. A feature that is easy to discover but difficult to use repeatedly remains a novelty. A feature that is repeatable but invisible becomes something only specialists know exists. The best tools raise all three factors together.

Interfaces can be maps, doors, or teachers

Software interfaces generally play three roles.

A door lets users enter a capability. It is efficient when the user already knows where to go. A button labeled “Build” or a command such as glab pipeline can be a door. Doors are excellent for routine work, but they do little to explain what lies nearby.

A map shows the territory. Autocompletion is map like because it exposes the neighboring concepts around the user's current position. If a partial command reveals several valid continuations, the user can build a mental model of the tool as they navigate it.

A teacher changes what the user understands about the territory. A persistent developer setting can act as a teacher when it makes a previously invisible category of work part of the normal environment. It communicates that extensions are not only things to install and use. They are also objects to inspect, test, reload, and debug.

The strongest interfaces combine these roles. They provide a door for immediate action, a map for exploration, and enough context to teach the structure of the system.

This distinction helps explain why autocomplete is more valuable than a long reference manual in certain situations. A manual tells the user what the designers decided to document. Completion responds to the user's current location and reveals valid next moves. It is interactive, local, and available at the moment of uncertainty.

Likewise, a configuration preference can be more influential than a tutorial because it changes the environment in which every future action occurs. A tutorial may explain developer mode once. A persistent preference turns that explanation into a standing condition of work.

The best tools do not merely answer questions. They make better questions easier to ask.

This is the intersection between command discovery and configuration. Both are methods for externalizing the system's possibilities so the user does not have to carry the entire interface in memory.

The paradox of expert workflows

There is a common misconception that advanced users want fewer visible options. Often they want fewer irrelevant steps, not fewer possibilities.

Experts dislike friction because they know exactly what they are trying to accomplish. But they also value powerful environments because they have learned to navigate complexity. A sparse interface can feel simple to a beginner while feeling restrictive to an expert. Conversely, a richly discoverable interface can feel overwhelming at first but become faster and more educational over time.

The distinction is between operational simplicity and conceptual visibility.

Operational simplicity means that the routine path is short. Conceptual visibility means that the larger space of possible actions remains accessible. A well designed tool can offer both: a concise command for a known task and completion for discovering adjacent tasks; a clean browser experience for ordinary use and a stable developer configuration for those who need it.

This is why advanced environments often rely on layers of configuration. The user may begin with a safe general default, then establish a personal environment in which relevant capabilities remain available. The goal is not to customize everything. It is to customize the points where repeated rediscovery is most expensive.

Imagine a developer who tests a browser extension several times each day. If enabling developer mode requires navigating through settings every time, the repeated action becomes a tax on attention. Once the relevant preference is set, that tax disappears. The gain is not merely a few saved clicks. It is a reduction in the number of times the developer must remember that the environment needs preparation before work can begin.

The same principle applies to command line workflows. If a user repeatedly consults documentation to remember whether a GitLab operation is represented as a command, a subcommand, or a flag, the tool is creating memory overhead. Autocomplete lowers that overhead by turning recall into recognition.

Recognition is generally easier than recall. But the deeper benefit is that recognition can become understanding. Seeing related commands together reveals the system's conceptual organization. The user begins to predict capabilities rather than merely retrieve them.

A practical framework for designing your own tools

The ideas above are not limited to browser settings or terminal programs. They apply to scripts, dashboards, internal platforms, and personal workflows. Whenever you build or configure a tool, ask four questions.

1. What capability is currently hidden?

List the actions your system supports that users are unlikely to discover. These may include debugging controls, inspection commands, export paths, recovery operations, or ways to retrieve information from a local environment.

Do not assume documentation solves the problem. Documentation is valuable, but it is external to the moment of action. Ask whether the interface itself can reveal the capability when it becomes relevant.

2. What should become a default?

A default should be stable, frequently useful, and cheap to reverse. If a setting supports a recurring workflow and does not compromise safety or clarity, making it persistent may be justified. The extensions.ui.developer_mode preference is a concrete example of this reasoning for users whose ordinary work includes extension development.

Defaults should be chosen based on actual practice, not an abstract ideal of untouched configuration. The best environment is not the one with the fewest changes. It is the one that removes needless preparation while preserving deliberate control.

3. Where can the interface teach structure?

Completion, grouped commands, contextual suggestions, meaningful names, and visible state all help users understand how a system is organized. The question is not merely whether an action is available. It is whether the user can infer the relationships among actions.

A completion list that exposes valid GitLab operations can teach the difference between managing issues, inspecting pipelines, and working with project variables. A visible developer environment can teach that an extension is a package with a lifecycle, not just a button that appears in a browser.

4. How quickly can the user recover?

Discovery is valuable only when experimentation feels safe. A user will explore more freely when commands are inspectable, changes are reversible, and the current state is visible.

This is especially important for configuration. A persistent setting should be easy to locate, verify, and reset. Otherwise, the user gains convenience at the price of uncertainty. Good configuration reduces friction without creating invisible magic.

Key Takeaways

1. Treat discoverability as part of functionality. A capability that users cannot find has little practical value, even if the system supports it.

2. Use completion as a learning interface. Bash autocompletion is not only a typing aid. It can reveal the conceptual grammar of a command line tool.

3. Promote repeated preparation into configuration. If a workflow requires the same setup every time, consider making that state persistent, provided it is safe and easy to reverse.

4. Separate simple operation from visible possibility. Keep routine actions fast while preserving maps, suggestions, and context for exploration.

5. Design for recognition, not perfect memory. Users should be able to identify the right action from the environment instead of recalling its exact name from scratch.

The deepest lesson is that software does not merely provide capabilities. It distributes knowledge about those capabilities. Some tools force users to memorize the system. Others place enough of the system in view that users can gradually learn it through use.

A command completion system and a developer mode preference may appear to solve different problems. One helps you find the next command. The other keeps a development environment ready. But both address the same human limitation: we cannot repeatedly reconstruct an invisible system from memory.

The most generous tools therefore do something subtle. They do not expose everything all the time, and they do not hide everything behind documentation. They create reversible visibility: the right possibilities become apparent at the right moment, and advanced users can choose to keep them close at hand.

Once you see interfaces this way, configuration stops looking like housekeeping and autocomplete stops looking like convenience. They become two forms of the same design practice: turning potential into something a person can notice, understand, and use.

The question to ask of any tool is no longer simply, “What can it do?” Ask instead: What can it help me discover before I knew to ask?