Distributed

The pattern:

1. Identify a real pain point (not theoretical)
2. Build the simplest thing that solves it
3. Make it work so well it becomes the standard

Pragmatism Over Purity

BSD wasn't academically pure. It was practical. It shipped.

Not this:

// Theoretically perfect design
// - 18 months of architecture
// - Handles every edge case
// - Never ships

This:

// Pragmatic design
// - Solves the problem we have today
// - Ships in 6 weeks
// - Iterate based on real use

Performance Is a Feature

NFS was designed for performance. The BSD TCP/IP stack was optimized relentlessly. Joy's systems work under load.

"First make it work, then make it fast. But don't ship until it's fast enough."

VI Philosophy

Vi embodies Joy's design thinking:

Modal Interface

Separate modes for separate tasks:

• Normal mode: Navigate, manipulate
• Insert mode: Type text
• Command mode: Execute commands

The principle: Don't overload one interface. Let each mode excel at its purpose.

Keep Hands on Keyboard

Vi was designed for Lear Siegler ADM-3A terminals. But the deeper principle: efficiency comes from not breaking flow.

hjkl navigation: No reaching for arrow keys
:w saves: No Ctrl+S+mouse+menu
/ searches: Instant incremental search

Apply to any tool: Minimize mode switches. Minimize hand movement. Optimize for flow.

Composable Commands

d2w - delete 2 words. 3dd - delete 3 lines. ciw - change inner word.

Commands are a language: verb + count + motion. Learn the grammar, combine infinitely.

The principle: Small primitives that compose are more powerful than many special commands.

BSD Design Principles

From Joy's work on BSD Unix:

Interoperability First

BSD's TCP/IP stack had to work with other systems. Not just other BSD machines. Any system speaking TCP/IP.

The principle: Design for the ecosystem, not just your own use case.

// Not this: Works great with our systems
send_proprietary_packet(connection);

// This: Works with anything
send_tcp_packet(connection);  // Standards-compliant

Reliability Under Load

BSD systems ran universities, corporations, the Internet. They couldn't crash.

Design for:

• Graceful degradation (slow, not dead)
• Resource limits (prevent runaway processes)
• Predictable behavior (same input = same output)

Debug-ability

When systems fail at scale, you need to understand why:

• Comprehensive logging
• System introspection (ps, netstat, vmstat)
• Core dumps for post-mortems

NFS: Distributed Systems Lessons

Network File System taught distributed systems principles:

Statelessness

NFS servers are stateless. Each request contains everything needed to process it.

Benefits:

• Server crashes don't lose client state
• Clients can retry without side effects
• Scaling is straightforward (any server can handle any request)

Idempotency

NFS operations are idempotent. Doing them twice gives the same result as once.

READ file, offset=100, length=50

Execute this 10 times, get the same bytes. Safe to retry on timeout.

The principle: In distributed systems, make operations repeatable without harm.

Handle Failure

Networks fail. Servers fail. Design for it.

Strategy: Retry with exponential backoff
- Timeout after 1s → retry
- Timeout after 2s → retry
- Timeout after 4s → retry
- Eventually fail clearly

Joy's Law Applied

"No matter who you are, most of the smartest people work for someone else."

Implications for Systems

1. Open Source: Let others contribute and fix bugs you'd never find
2. Open Standards: Let others build compatible systems
3. Extensibility: Design for use cases you haven't imagined
4. Community: Build systems that attract contributors

Implications for Teams

1. Hire broadly: Intelligence is distributed
2. Listen externally: Users find bugs faster than tests
3. Share credit: Closed systems attract fewer talents
4. Stay humble: Someone else probably knows the answer

The Joy Test

Before committing system design, ask:

1. Does this solve a real problem? One that people actually have today?
2. Is this pragmatic? Will it ship, or is it academic exercise?
3. Will it work at scale? What happens with 10x users, 100x data?
4. Is it stateless where possible? Can servers crash without losing state?
5. Are operations idempotent? Can retries cause harm?
6. How does it fail? Graceful degradation or catastrophic failure?
7. Is it interoperable? Works with other systems, or locked in?
8. Can others contribute? Open interfaces, documented behavior?

When Reviewing Code

Apply these checks:

• Solves real problem, not theoretical one
• Pragmatic over pure (will actually ship)
• Considered behavior under load
• Stateless where possible
• Idempotent operations for retries
• Failure handling is explicit
• Interoperability with other systems
• Clear interfaces that others can implement
• Logging/debugging sufficient for production issues
• Composable primitives over special cases

Composable Design

Like vi commands, systems should compose:

Not this:

def do_everything(data, option1, option2, option3, option4):
    # 500 lines handling every combination

This:

def step1(data): ...
def step2(data): ...
def step3(data): ...

# Compose as needed
result = step3(step2(step1(data)))

When NOT to Use This Skill

Use a different skill when:

• Optimizing single-machine code → Use optimization (cache behavior, profiling, data-oriented)
• Writing kernel code → Use data-first (kernel style, data structures)
• Writing Go microservices → Use simplicity (Go Proverbs, small interfaces)—but distributed for distributed concerns
• Building CLI tools → Use composition (Unix philosophy, pipes)
• General code clarity → Use clarity (readability, naming)

Bill Joy is the distributed systems skill—use it when your system spans multiple machines, networks, or must handle failure.

Sources

• BSD Unix source code and documentation
• Joy, various interviews (Sun Microsystems era)
• Joy, "Why the Future Doesn't Need Us" (Wired, 2000)
• NFS protocol specification and design documents
• Vi documentation and tutorials
• Sun Microsystems technical documentation
• Oral histories from Computer History Museum

"In the future, I think it will be considered astonishing that we used to send astronauts into space in a vehicle whose computers had less power than a modern cell phone." — Bill Joy

"The purpose of computing is insight, not numbers." — (attributed, reflecting Joy's philosophy)