Compass Principle 5: Long-View & Strategy

"Optimize for maintainability, scalability, and clarity"

Part of the 10 Compass Principles exploration series

Extended Definition

長 (Long-View) — Long-view thinking means optimizing for the person debugging your code at 3 AM two years from now—even if that person is you. It's choosing clarity over cleverness, documentation over assumptions, and modular design over monolithic speed. This principle asks: "Will this decision compound positively or create debt?" Every shortcut taken today is a loan against tomorrow's productivity.

The Tension

Shipping now feels urgent. The pressure to deliver features, to show progress, to move fast is real and immediate. Long-view thinking asks us to slow down today to speed up tomorrow—a trade-off that's hard to justify to stakeholders focused on quarterly results. But technical debt compounds faster than financial debt, and unlike money, you can't declare bankruptcy on complexity.

Constraint

You have to consider the long-term consequences.

Enables

Systems that last. No maintenance nightmares. Improvements compound over time.

In Action

  • Document the why: Code explains what, comments explain why
  • Design for change: Assume requirements will evolve
  • Modular architecture: Small, composable pieces over monolithic systems
  • Clear naming: Future-you should understand without archaeology
  • Test coverage: Tests are documentation that verifies itself

Example

"Let's spend an extra hour documenting this decision so we remember why we chose this approach."

Hierarchy Context

Long-view thinking sits in the middle of our hierarchy, after the foundational principles of safety, honesty, privacy, and evidence. This placement reflects its role as a strategic multiplier—it makes all other principles more sustainable. Without long-view thinking, even safe, honest systems eventually collapse under their own complexity.

A Cathedral Builder's Prayer

I will not see this finished. I am laying stones for those who come after.

May I build foundations that hold when I have forgotten my own name. May I write for future-me, who will need to understand this road.

Not for the sprint. For the decade. For the ones who will maintain what I began.

Build for tomorrow. Build for tomorrow. Build for tomorrow.

Song

Title: Build for Tomorrow

Suno.ai Style Tags:

[Epic Orchestral Folk, Building, Patient, Mixed Vocals, Strings, Piano, Drums Entering Gradually, Strategic, Forward-Looking, Architectural, Deliberate Pace, 90 BPM, Major Key Building to Minor Touches, Thoughtful, Sustainable, Long-Term Thinking, Future-Focused, Foundation Philosophy, Cathedral Builder Mindset, Legacy Creation, Time Horizon Extended, Maintainability First, Clarity Compounds, Scale Thinking, Decades Not Sprints]

Lyrics:

[Intro - Solo piano, contemplative]

[Verse 1 - Minimal, just vocals and piano]
They ask me why I'm moving slow
Why I write comments for code I know
Why I choose the longer path
When shortcuts could get me there fast

I tell them: I'm not building for today
I'm building for the year when I've forgotten my own way
When someone else will read this code
And need to understand the road

I'm building for tomorrow

[Verse 2 - Strings enter softly]
They say "just ship it, iterate later"
"Move fast, optimization can wait"
"Don't overthink the architecture"
"You can refactor when it breaks"

But broken systems at scale don't refactor
They rebuild, or they collapse under their own weight
So I choose the boring, maintainable foundation
Over the clever hack that can't migrate

I'm building for tomorrow

[Pre-Chorus - Drums enter, still building]
Not for the demo
Not for the sprint
But for the decade
When clarity counts for everything

[Chorus - Full arrangement]
Build for tomorrow, not for today
Write code that future-you can understand and maintain
Choose boring and clear over clever and fast
'Cause maintainability compounds, shortcuts don't last

Scalability isn't just handling load
It's whether the team can understand the code
Long-view thinking, strategic choice
Build systems that last, give future-you a voice

Build for tomorrow

[Verse 3]
I write docs not because the boss requires it
But because six months from now I'll need to be reminded
Why this function exists, what edge case it handles
What the subtle invariant is, why this code's got handles

I namespace carefully, I structure with intention
I avoid deep nesting and premature abstraction
Not for style points, not for the elegance
But because complexity kills maintenance at scale

I'm building for tomorrow

[Bridge - Tempo slows, more intimate]
Cathedral builders worked their whole lives
On structures they'd never see complete
They laid stones for generations
Who'd finish what they'd begun

That's the mindset I'm cultivating
Not "ship fast and move on"
But "build foundations that hold
When we've scaled ten times beyond"

Strategic patience
Long-term view
The system you build today
Is the technical debt you inherit tomorrow

[Chorus - Powerful, full orchestra]
Build for tomorrow, not for today
Write code that future-you can understand and maintain
Choose boring and clear over clever and fast
'Cause maintainability compounds, shortcuts don't last

Scalability isn't just handling load
It's whether the team can understand the code
Long-view thinking, strategic choice
Build systems that last, give future-you a voice

[Outro - Vocals over fading orchestra]
In fifty years, what will remain?
Not the feature shipped fast
But the foundation laid with care
The system that could adapt, evolve, and last

I'm building for tomorrow
I'm building for tomorrow

[Outro - Instrumental, piano returns to opening theme]

Visual Guide - Conceptual Inspiration

Core Visual Concept: Cathedral Builders

This video explores long-term thinking through the metaphor of architecture—building structures that outlast their builders. Foundations that hold for generations. Clarity that enables maintenance. Strategic patience that creates sustainable systems.

Visual Themes & Imagery

The Cathedral Under Construction

  • Medieval cathedrals mid-construction (decades-long builds)
  • Scaffolding around permanent structures
  • Foundation work that will be invisible when complete
  • Builders who won't see the finished building
  • Time-lapse showing years of patient construction

Foundations That Hold

  • Deep concrete pilings driven into bedrock
  • Root systems that spread wide before trees grow tall
  • Infrastructure built to last (aqueducts, bridges from centuries ago still standing)
  • The invisible work that enables visible success
  • Load-bearing beams, structural supports, the bones of buildings

Code as Architecture

  • Well-structured code with clear hierarchy (visual representation)
  • File trees showing logical organization
  • Comments explaining "why" not just "what"
  • Documentation as blueprint
  • Refactoring as renovation (improving without destroying)

The Two Paths

  • Split screen: Quick hack vs. thoughtful design
  • Six months later: Quick hack is unmaintainable, design is still clear
  • Two years later: Quick hack requires full rewrite, design scales smoothly
  • Ten years: Quick hack is abandoned, design is still evolving

Symbolic Visual Elements

The Blueprint: Architectural drawings showing structure before construction. Planning before building. Strategy before tactics. The document that guides builders who come after.

The Comment: Code comment explaining not what (visible in code) but why (invisible without documentation). // Why this exists: handles edge case where... The gift to future maintainers.

The Foundation Stone: First stone laid in a cathedral, carved with date. "1163 AD - Foundation begun." Builders knowing they're starting something they won't finish. Legacy thinking.

The Namespace: Hierarchical organization (internal/gemini/client.go, not stuff/thing.go). Structure that reveals intent. Clarity that scales.

The Refactoring: File comparison showing improved structure with same functionality. Better clarity, same behavior. Investing in future maintenance.

Emotional Color Arc

Opening (Soft earth tones, natural wood): The patience of natural growth. Trees taking decades to mature. Foundations settled over time. Calm, deliberate, unhurried.

Building Phase (Warm golds, construction light): The active work of strategic building. Scaffolding, blueprints, careful construction. Purposeful, measured, intentional.

Contrast (Quick flashes of neon, chaos): The temptation of shortcuts. Fast hacks, rapid ships, move-fast chaos. Unsustainable velocity. Shown briefly as contrast, not as goal.

Resolution (Deep greens, stone grays, lasting materials): The payoff of long-view thinking. Systems that have evolved gracefully. Code maintained easily. Foundations still holding after years. Timeless, sustainable, trustworthy.

Typography & Text Elements

On-Screen Text (patient, strategic):

  • "Cathedral begun: 1163. Completed: 1345. 182 years."
  • "Optimize for maintainability, scalability, and clarity"
  • "Future-you is your most important user"
  • Code comments: // Why: This handles edge case discovered 2023-04-17
  • "Choose boring and clear over clever and fast"
  • "Maintainability compounds. Shortcuts don't last."

Visual Treatment: Carved stone typography (lasting), blueprint fonts (strategic), clean monospace (clarity). The aesthetic of permanence.

Motion & Rhythm Notes

Pacing: Patient, deliberate. 90 BPM—walking pace, not running. Building takes time. Strategy isn't rushed.

Movement Style:

  • Slow time-lapses showing long construction (months → seconds)
  • Zoom out revealing larger structures (local detail → strategic view)
  • Side-by-side comparisons over time (then → now, showing lasting value)
  • Pan across architectural blueprints (strategic planning made visible)
  • Held frames on foundation work (the patient essential)

Transitions: Slow cross-fades (time passing). Smooth pans (strategic overview). Cut to black between time periods (years passing).

Key Visual Contrasts

Short-term vs. Long-term

  • Feature shipped fast vs. system designed to last
  • Clever hack that works now vs. clear code that's maintainable later
  • Demo that impresses today vs. architecture that scales tomorrow
  • Sprint mindset vs. decade mindset

Clever vs. Clear

  • Condensed one-liner vs. readable multi-line with comments
  • Nested abstractions vs. flat, obvious structure
  • Implicit magic vs. explicit, boring code
  • "Look how smart I am" vs. "Look how clear this is"

Tactical vs. Strategic

  • Immediate solution vs. systemic improvement
  • Fixing symptom vs. addressing root cause
  • Adding feature vs. strengthening foundation
  • Shipping now vs. building capacity to ship sustainably

The Central Image

If there's one visual thesis for this piece:

Show someone choosing the longer path that's more maintainable over the shorter path that's faster—and show why that choice pays off over time.

Developer at a crossroads:

  • Path A: Quick hack, ship today, move on
  • Path B: Thoughtful design, ship next week, maintain easily

Show both paths. Follow them forward in time.

Six months later:

  • Path A: Unmaintainable, needs rewrite
  • Path B: Still clear, easy to extend

Two years later:

  • Path A: Abandoned, starting over
  • Path B: Scaled smoothly, evolved gracefully

The visual proof that strategic patience wins over time.

The Loop

Opening shot: A construction site. Nothing built yet. Just foundation markers, blueprints, planning. Patient preparation.

Closing shot: The same site, years later (time-lapse). A structure stands—not complete, but substantial. Still evolving, but on solid ground. Scaffolding present but foundation invisible and holding.

We haven't finished building. But we built something that can keep being built on. That's the long view.

TED Talk: "Building Cathedrals - Why Long-Term Thinking Beats Short-Term Wins"

Opening (0:00-4:00)

[Walk onto stage. Pause.]

In 1163, construction began on Notre-Dame Cathedral in Paris.

The architects who designed it knew they would never see it complete. The workers who laid the foundation knew their grandchildren might not see it complete.

It took 182 years to build.

[Let that number land.]

Can you imagine committing to a project you won't see finished? A project your children won't see finished? A project that requires generations of continued work?

[Slide: Notre-Dame under construction, 13th century illustration]

Medieval cathedral builders had something we've lost in tech culture: the ability to think in decades, not sprints.

They optimized for longevity, not velocity. They built for maintainability, not just delivery. They thought strategically, not just tactically.

And their work stood for centuries.

[Slide: Notre-Dame, present day]

Meanwhile, in technology, we're proud when a system lasts five years without requiring a complete rewrite.

[Pause]

Today I want to talk about long-view thinking. Not as an abstract ideal. Not as a luxury for teams with unlimited time. But as a practical discipline that produces better systems, more maintainable code, and sustainable teams.

Because the fastest way to move quickly over ten years is to move thoughtfully in year one.

The Problem: Short-Termism in Tech (4:00-14:00)

We worship speed.

"Move fast and break things." "Bias for action." "Ship it and iterate."

These mantras have value. But they've created a culture where long-term thinking is treated as a luxury, not a necessity.

Let me tell you about a pattern I see constantly.

The Story of the Quick Fix

A team has a bug in production. Users are affected. Pressure is high.

Two approaches emerge:

Approach A - Tactical Fix: "Let's add a check here that catches this specific case. Ship it today. Move on."

Approach B - Strategic Fix: "Let's understand why this whole category of bugs is possible. Let's refactor the architecture so this class of error can't happen. Ship it next week."

Guess which one most teams choose?

Approach A. Every time.

Why? Because Approach A:

  • Ships faster
  • Looks responsive
  • Satisfies immediate pressure
  • Demonstrates "bias for action"

Approach B:

  • Takes longer
  • Looks like overthinking
  • Doesn't resolve immediate pressure as quickly
  • Might be seen as "gold-plating"

So teams ship the tactical fix. And six months later, they hit a variant of the same bug. And they add another specific check. And six months after that, another variant. Another check.

Two years later, the codebase is full of band-aids. Nobody understands why any specific check exists. The system is fragile, slow, and unmaintainable.

The tactical approach that was "faster" has now cost:

  • Dozens of incidents (each variant of the bug)
  • Hundreds of hours debugging
  • Team morale (debugging the same class of bug repeatedly is demoralizing)
  • System quality (accretion of fixes makes code harder to understand)

Meanwhile, a parallel universe where they chose Approach B:

  • One week of thoughtful refactoring
  • The whole class of bugs eliminated
  • System more maintainable
  • Team learns strategic thinking
  • Two years later: the system has scaled smoothly, the architecture is still clear, new team members can understand it

Which was actually faster?

Over two years: Approach B.

But we optimize for two weeks. So we choose Approach A. And we pay for it, compounding, for years.

Why We Default to Short-Term Thinking

Three reasons:

1. Short-term results are visible. Long-term results are counterfactual.

Shipping a feature today is visible. Everyone sees it. You get credit.

Preventing future maintenance burden is invisible. Nobody sees the problems that didn't happen. You get no credit.

So culture rewards short-term visible wins over long-term invisible benefits.

2. Immediate pressure overrides strategic thinking.

When production is down, when users are angry, when leadership is asking "why isn't this fixed yet?"—strategic thinking feels like a luxury.

Tactical fixes relieve immediate pressure. Strategic fixes require defending the decision to take longer.

Most teams don't have the cultural support to choose strategic over tactical under pressure.

3. Turnover makes long-term thinking someone else's problem.

If you're only on the team for 18 months, you don't pay the cost of your tactical shortcuts. Future team members do.

This creates a tragedy of the commons. Everyone optimizes for their own tenure, externalizing costs to future maintainers.

The result: systems that work great for six months and become unmaintainable afterward.

What Long-View Thinking Actually Means (14:00-28:00)

In the Compass Principles, Long-View & Strategy is fifth in the hierarchy:

Safety > Honesty > Privacy > Evidence > Long-View > ...

Why fifth? Because long-view thinking builds on evidence. You need to measure before you can strategically optimize.

And it comes before efficiency—because optimizing for speed without strategic thinking produces fast short-term results and slow long-term outcomes.

Let me break down what long-view thinking means in practice.

1. Optimize for maintainability.

Maintainability is "will future-you (or future-team) be able to understand, modify, and extend this code?"

Not "can it be done?" but "can it be done without heroic effort?"

Maintainable code:

  • Has clear structure (files organized logically, not randomly)
  • Has explanatory comments (why decisions were made, not what the code does)
  • Avoids clever tricks (boring and obvious beats clever and subtle)
  • Uses consistent patterns (reduce cognitive load by reusing approaches)
  • Has comprehensive docs (architecture decisions, edge cases, invariants)

Real example from our codebase:

We have a file size limit rule: Go files max 200 lines.

Why? Not because 200 is magic. But because when files exceed ~200 lines, they become harder to understand at a glance. Maintainability degrades.

This rule forces us to split large files into focused modules. Yes, this takes more time upfront. But six months later, when someone needs to modify the code, they find focused, comprehensible modules instead of 800-line sprawling files.

We optimize for future maintainability over present convenience.

2. Optimize for scalability.

Scalability isn't just "can it handle more load?" It's "can it handle more load, more features, more complexity, more team members without collapsing?"

Scalable systems:

  • Have clear interfaces (modules that can be understood independently)
  • Have testable components (can verify behavior without running the whole system)
  • Have observable behavior (logs, metrics, traces that reveal what's happening)
  • Have documented architecture (new team members can onboard effectively)
  • Avoid tight coupling (changes in one area don't cascade everywhere)

Real example:

We're building an audio processing pipeline. We could build it as one monolithic script that does everything.

That would be fastest to ship initially. But it wouldn't scale.

When we want to add video processing, we'd have to modify the audio script. When we want to parallelize processing, we'd have to refactor the whole thing. When we want to add error handling, we'd have to touch every section.

Instead, we're building modular components:

  • Intake (file handling, validation)
  • Analysis (audio processing)
  • Metadata generation (LLM-powered)
  • Output (sharing pipeline)

Each module has clear interfaces. Each can be tested independently. Each can scale independently.

This takes longer upfront. But it enables us to scale features, team, and complexity over time.

3. Optimize for clarity.

Clarity is "can someone who doesn't know this system understand it?"

Clear code:

  • Uses descriptive names (getUserById, not gUI)
  • Avoids deep nesting (flat is better than nested)
  • Makes implicit things explicit (comments, types, documentation)
  • Follows conventions (don't invent your own patterns unnecessarily)
  • Is boring (uses established patterns, not clever innovations)

Real example:

I recently reviewed code that used single-letter variable names to save typing:

func p(u string, r *http.Request) (*Response, error) {
    c := getC()
    d, err := c.f(u)
    // ... 50 more lines
}

Clever? No. Fast to write? Yes. Clear? Absolutely not.

The refactor:

func processRequest(userID string, request *http.Request) (*Response, error) {
    client := getGeminiClient()
    data, err := client.fetchUserData(userID)
    // ... 50 more lines with clear names
}

Did the refactor take time? Yes. Is the second version longer to type? Yes.

But six months from now, when someone needs to debug this function, which version will they understand faster?

Clarity compounds. Confusion compounds too—but in the wrong direction.

Real-World Tensions: When Long-View Conflicts with Other Values (28:00-40:00)

Long-view thinking isn't always comfortable. Sometimes deadlines are real. Sometimes "ship now, refactor later" is the right call.

Here are real tensions and how to navigate them.

Tension 1: Long-View vs. Urgency

Production is down. Users can't access the system. Every minute costs money and trust.

Do you:

  • A: Apply tactical fix (patch the symptom, ship in an hour)
  • B: Apply strategic fix (address root cause, ship tomorrow)

Honest answer: Sometimes you choose A.

But—and this is critical—you don't stop there.

After the tactical fix is deployed and urgency is relieved, you schedule the strategic fix. You document the technical debt. You commit to addressing the root cause within a defined timeframe (e.g., next sprint).

The mistake isn't choosing tactical under urgency. The mistake is only choosing tactical and never coming back to address root causes.

Long-view thinking in crises:

  1. Resolve immediate crisis (tactical fix)
  2. Schedule strategic fix (documented, committed)
  3. Learn from incident (why was this possible? how do we prevent the class?)
  4. Implement strategic fix (strengthen system)

Tension 2: Long-View vs. Experimentation

You're trying a new feature. You don't know if users will want it. Does it make sense to invest in maintainability for something that might get thrown away?

Honest answer: It depends on the experiment's stakes.

Low-stakes experiment (feature flag, small user segment, easy to remove):

  • Ship quickly. Accept technical debt. Optimize for learning, not longevity.
  • If it works, refactor before scaling.
  • If it fails, remove it entirely.

High-stakes experiment (core system change, affects all users, hard to remove):

  • Invest in maintainability upfront. The "experiment" might become permanent by default inertia.
  • If it works, you've built it right.
  • If it fails, at least the failure is well-documented and removable.

The mistake is treating high-stakes changes as low-stakes experiments to avoid doing the hard work of strategic thinking.

Tension 3: Long-View vs. Team Capacity

Your team is small. Deadlines are tight. You don't have "extra time" for strategic thinking.

Counter-intuitive truth: Small teams need long-view thinking more, not less.

Why? Because small teams have less slack for maintenance. Less capacity to rewrite broken systems. Less ability to absorb technical debt.

Strategic thinking for small teams looks like:

  • Choose boring, proven technologies (less maintenance)
  • Invest in clarity (future-you is the team)
  • Build modular (easier to understand and extend)
  • Document decisions (context doesn't live only in heads)

Small teams can't afford the luxury of short-term thinking. The payback period on technical debt is brutal when you have limited capacity.

Building a Culture of Long-View Thinking (40:00-50:00)

Long-view thinking isn't just individual practice. It's cultural.

How do you build teams where strategic thinking is valued?

1. Measure long-term outcomes, not just short-term velocity.

If you only measure "features shipped this sprint," you optimize for features shipped this sprint.

If you measure:

  • Time to onboard new team members (affected by clarity and documentation)
  • Incident rate over time (affected by strategic fixes vs. tactical band-aids)
  • Code comprehension (can new team members understand the system?)
  • Maintenance burden (how much time spent fixing old systems vs. building new?)

You optimize for those.

What gets measured gets managed. If long-term health isn't measured, it won't be prioritized.

2. Celebrate strategic patience.

When someone chooses the maintainable approach over the fast approach, celebrate that.

"Thank you for thinking long-term. This is going to save us maintenance burden next year."

When someone writes comprehensive documentation, acknowledge it.

"Future team members will thank you for this clarity."

When someone refactors for clarity instead of adding another band-aid, recognize it.

"You just made the system more maintainable for everyone."

Make long-view thinking culturally valuable.

3. Create space for strategic thinking.

You can't expect teams to think strategically if every sprint is packed to capacity with immediate deliverables.

Build slack into the system. Reserve capacity for:

  • Refactoring (improving existing code without changing behavior)
  • Documentation (explaining why things are the way they are)
  • Architectural work (strengthening foundations)
  • Learning (understanding systems deeply, not just using them)

If teams are always at 100% capacity with feature work, strategic thinking becomes impossible.

4. Make future-you a stakeholder.

When evaluating decisions, ask: "How will future-us feel about this choice?"

In code review: "Will this be clear to someone who doesn't know the context?" In architecture decisions: "Will this scale when we're 10× larger?" In documentation: "Will future team members understand why we made this choice?"

Treat future-you as a stakeholder whose needs matter as much as present stakeholders.

The Payoff: What Long-View Thinking Enables (50:00-58:00)

I've spent most of this talk explaining what long-view thinking costs: Time, discipline, patience, resisting pressure for quick wins.

Now let me tell you what it enables.

Long-view thinking enables sustainable velocity.

This seems contradictory. "Thinking long-term slows you down!"

In the short term, yes. In the long term, no.

Teams that think strategically:

  • Ship features faster (because the codebase is maintainable)
  • Debug faster (because systems are observable and documented)
  • Onboard new members faster (because architecture is clear)
  • Scale features faster (because foundations are solid)

The upfront investment in strategic thinking pays velocity dividends for years.

Long-view thinking enables adaptability.

When requirements change (and they always change), maintainable systems adapt.

Tactical hacks are brittle. They break when assumptions change. Strategic architecture is flexible. It handles change gracefully.

The team that built modular components can add video processing easily. The team that built a monolithic script has to rewrite everything.

Long-view thinking enables team sustainability.

Burnout happens when teams are constantly firefighting. Fixing the same bugs. Rewriting the same systems. Debugging unmaintainable code.

Strategic thinking reduces firefighting. Refactored systems are more reliable. Clear code is easier to debug. Good architecture prevents whole classes of problems.

Teams that think long-term are healthier, happier, more sustainable.

Long-view thinking creates legacy.

Cathedral builders knew they were creating something that would outlast them.

When you write code with clarity, document decisions thoroughly, build maintainable systems—you're creating legacy.

Not for ego. But because work that lasts is work that matters.

Closing: The Cathedral Mindset (58:00-64:00)

[Walk to the front of the stage.]

Let me bring this back to where we started.

Notre-Dame took 182 years to build.

The architects who designed the foundation never saw the finished cathedral. But their work held. For centuries.

[Slide: Notre-Dame foundation, medieval illustration]

They optimized for longevity, not velocity. They thought in generations, not sprints. They built something that would outlast them.

That's the mindset I'm asking you to adopt.

Not "how fast can I ship this?" but "how well can I build this so it lasts?"

Not "what's the cleverest solution?" but "what's the clearest solution?"

Not "how do I satisfy today's pressure?" but "how do I prevent tomorrow's crisis?"

[Slide: The Compass hierarchy - "Safety > Honesty > Privacy > Evidence > Long-View > ..."]

Long-View & Strategy comes fifth in the Compass. After safety, honesty, privacy, evidence.

Why? Because strategic thinking builds on those foundations. You can't think long-term without evidence. You can't optimize maintainability without honesty about current state.

But it comes before efficiency. Because optimizing for speed without strategy produces fast starts and slow finishes.

Choose long-view thinking. Not because it's easy. Not because it's rewarded immediately. But because it's the only way to build systems that last.

[Long pause.]

The question that changes everything:

"How will future-me feel about this decision?"

Not "does this work now?" but "will this still be maintainable in two years?"

Not "can I ship this today?" but "will this scale when we're ten times larger?"

Not "is this clever?" but "is this clear?"

Build for tomorrow. Write code that future-you can maintain. Choose boring and clear over clever and fast.

Because maintainability compounds. Clarity compounds. Strategic thinking compounds.

And shortcuts don't.

[Slide: A cathedral under construction, scaffolding visible but structure emerging]

You're not building features. You're building cathedrals.

Foundations that will hold for decades. Structures that will outlast their builders. Systems that future generations will maintain, extend, and build upon.

That's long-view thinking. That's strategic patience. That's how you create legacy.

[Long pause. Breathe.]

Build for tomorrow.

Thank you.

Q&A (64:00-74:00)

Q: How do you balance long-term thinking with the reality that requirements change constantly? Isn't building for the long-term risky when you don't know what the future holds?

Great question. Long-view thinking isn't about predicting the future. It's about building systems flexible enough to adapt to unpredictable futures.

The key is: optimize for adaptability, not for specific future requirements.

Modular systems adapt better than monolithic ones. Clear code is easier to modify than clever code. Well-documented decisions can be reversed; undocumented ones are mysteries.

You're not building for a specific future. You're building for an unknown future. And flexibility is how you handle unknowns.

Q: What do you say to startups that need to move fast to survive? Don't they need short-term thinking to compete?

Startups need to move fast—on the things that matter for learning and survival.

But moving fast on features doesn't mean moving recklessly on foundations.

My advice for startups:

  • Ship features fast (optimize for learning)
  • Build infrastructure carefully (optimize for maintainability)
  • Accept technical debt in experiments (easy to remove)
  • Invest in architecture for core systems (hard to change later)

The mistake is treating everything as disposable. Some things (core data models, authentication, infrastructure) need strategic thinking even in fast-moving startups.

Because rewriting your auth system two years in costs months. Building it right initially costs days.

Q: How do you convince leadership to prioritize long-term thinking when they're focused on quarterly results?

This is hard, and I won't pretend otherwise.

My approach: Translate long-term thinking into short-term metrics leadership cares about.

Instead of "we should refactor for maintainability," say: "This refactoring will reduce incident rate by ~30% based on similar work we've done. That's X hours of engineering time saved per quarter."

Instead of "we need to document architecture," say: "Onboarding new engineers takes 6 weeks currently. With better docs, we estimate 4 weeks. That's 2 weeks of productivity gained per new hire."

Make long-term investments legible in short-term language. Show the quarterly payoff of strategic thinking.

Q: What's the line between strategic thinking and over-engineering?

The line is: Are you solving real problems or hypothetical ones?

Strategic thinking addresses known issues (maintainability, scalability, clarity) with proven solutions (modular design, clear naming, documentation).

Over-engineering solves hypothetical future problems with complex abstractions.

Ask yourself:

  • Is this complexity solving a real problem we have? (strategic)
  • Is this complexity preparing for a problem we might have? (over-engineering)

If you're building an abstraction "in case we need it someday," you're over-engineering. If you're building clarity because the code is currently hard to understand, you're thinking strategically.

Q: How do you handle technical debt that's already accumulated? Is it too late for long-view thinking?

It's never too late.

Strategy for existing technical debt:

  1. Categorize: What's critical path vs. nice-to-fix?
  2. Prioritize: Fix what causes most pain first
  3. Prevent: Stop adding new debt (new code follows better practices)
  4. Chip away: Allocate % of capacity to debt reduction (e.g., 20% per sprint)

You can't fix everything overnight. But you can stop digging the hole deeper and start filling it systematically.

And every strategic fix you make now prevents future debt accumulation.

Q: What's one concrete practice teams can adopt tomorrow to think more long-term?

Start asking one question in every code review:

"Will this be clear to someone who doesn't know the context?"

Not "does this work?" Not "is this correct?" But "is this clear?"

If the answer is no, require:

  • Better naming
  • Explanatory comments
  • Documentation of why (not just what)

This single question shifts mindset from "ship it" to "ship it in a way future-us can maintain."

Try it tomorrow. Watch what changes.

END OF TALK

Runtime: ~74 minutes (including Q&A)

Part 5 of 10 in the Compass Principles exploration series

Previous: Principle 4 - Evidence & Verification Next: Principle 6 - Proportionality & Efficiency

🌈=🌀

View source on GitHub Also served as text/markdown