How I Use My Terminal

A developer's terminal workflow sparks debate about the value of custom configurations versus embracing software defaults and their historical reasoning.

How I Use My Terminal

A developer’s terminal workflow sparks debate about the value of custom configurations versus embracing software defaults and their historical reasoning. The discussion reveals deep philosophical differences about whether to build complex custom layers or understand and work within existing tool constraints.

The Maintenance Cost of Custom Layers

The author shares a sophisticated terminal workflow that has been refined over a decade, emphasizing the maintenance cost of custom layers and configurations. This perspective advocates for peeling back customizations in favor of understanding what stock tools can accomplish without modification.

Stock Vim can accomplish many advanced tasks without tmux using commands like rg --vimgrep and vim -c cb -, which are underutilized features that provide powerful functionality without additional complexity. The vim -c cb - command, in particular, represents a favorite feature that remains rarely discussed despite its utility.

This approach reflects a broader philosophy: rather than building elaborate custom solutions, invest time in understanding the capabilities of existing tools. The maintenance burden of custom configurations often outweighs their benefits, especially as tools evolve and configurations break.

The Defaults Debate

Community discussion emerges about whether to stick with software defaults or customize them extensively. Some argue that defaults in older software exist for good reasons and should be understood before modification, while others claim that many defaults are arbitrary historical accidents rather than thoughtful design decisions.

The vim hjkl key bindings serve as a case study for this debate. These bindings originated from the ADM-3A terminal’s arrow key placement, not from optimal ergonomic design. This historical accident became entrenched as a standard, raising questions about whether understanding the “why” behind defaults provides value or merely wastes time on useless trivia.

The tension reflects different approaches to tool adoption: some prefer to understand historical context and work within established patterns, while others advocate for immediate optimization based on current needs and ergonomics.

Touch Typing and Ergonomic Considerations

Touch typists debate whether hjkl is actually optimal for cursor movement. The standard places movement keys under the right hand’s resting position, but h isn’t actually on the home row, leading some to prefer jkl; (right home row) or other arrangements that better match finger strength and usage patterns.

Arguments emerge about finger strength and usage frequency. Some advocate for placing the most-used direction (down) under the strongest finger (index), while others prefer arrangements that group “forward” and “backward” movements logically or minimize finger travel from neutral positions.

These ergonomic discussions highlight how historical accidents in interface design can persist long after their original constraints disappear. The ADM-3A terminal that influenced vim’s key bindings is long obsolete, yet its layout continues to influence modern text editors.

The Philosophy of Tool Customization

The broader debate reveals fundamental philosophical differences about software tool usage. One camp advocates for minimal customization and deep understanding of default behaviors, viewing this as more sustainable and transferable across different environments.

The opposing view argues that blindly following defaults wastes productivity when better alternatives exist. This perspective prioritizes immediate optimization over historical understanding, suggesting that time spent learning arbitrary design decisions could be better invested in creating more efficient workflows.

Both approaches have merit: understanding defaults provides portability and reduces maintenance overhead, while thoughtful customization can significantly improve daily productivity. The optimal balance likely depends on individual work patterns and the stability of one’s computing environment.

Stock Tool Capabilities

The discussion reveals that many developers underutilize the capabilities of standard tools, instead building complex custom solutions for problems that existing features already solve. Vim’s quickfix list, buffer management, and command-line integration provide powerful functionality that many users never discover.

This pattern extends beyond vim to other terminal tools where advanced features remain hidden behind unfamiliar command-line options or key combinations. The investment in learning these built-in capabilities often pays dividends in reduced complexity and improved reliability.

However, discovering these features requires significant time investment and often involves reading dense documentation or experimenting with unfamiliar commands. The learning curve can be steep enough that custom solutions seem more approachable, even if they’re ultimately less efficient.

Historical Context and Design Evolution

The hjkl debate illustrates how interface design decisions become entrenched through historical accident rather than optimal design. The ADM-3A terminal’s influence on vi demonstrates how constraints from obsolete hardware can persist in modern software, sometimes long after their original justification disappears.

Understanding this history can inform decisions about when to embrace defaults and when to break from them. Some historical decisions reflect genuine design wisdom that remains relevant, while others are arbitrary constraints that no longer apply to current usage patterns.

The challenge lies in distinguishing between these categories without spending excessive time on historical research that may not improve daily productivity. The balance between respecting established patterns and optimizing for current needs remains a personal choice that depends on individual priorities and work contexts.