One contract, many editions

Every article can expose a small common record: identity, dates, aliases, tags, and links. The ordinary edition uses the shared reading shell. A bespoke edition may instead be a complete HTML document with its own styles and scripts.

Isolation is a feature

Shared articles receive layered, scoped CSS. Bespoke documents live at separate paths. Neither side needs to win a specificity war, and the site can stay coherent without making every page uniform.

Grow in visible phases

• First, make reading excellent.
• Then make links and backlinks deterministic.
• Add graph views only after the underlying index is trustworthy.
• Treat a dashboard as an optional authoring client, never a runtime dependency.

The garden is static when published. Tools may help prepare it later, but a visitor receives durable HTML, CSS, and JavaScript that need no application server.

The page should yield

Comfort is not one fixed design. A bright page at noon may be glare at midnight. A generous line can become exhausting on a narrow screen. Theme, measure, type size, and rhythm belong to the reader.

Those controls should feel close at hand and then disappear. The interface is useful before reading and distracting during it, so focus mode treats chrome as a temporary guest.

The best reading interface leaves evidence of care, not evidence of machinery.

Motion with consent

Auto-scroll can make long-form reading feel like following a quiet current. It must remain predictable: steady speed, immediate pause, no leap after returning to a sleeping tab, and an obvious way out.

• Pause or resume without hunting for a control.
• Adjust speed while the text remains stable.
• Restore the last reading place without trapping the reader there.
• Respect reduced-motion preferences and ordinary keyboard navigation.

A site with memory

Progress is private browser state, not an account. The page remembers where this device stopped and keeps that record local. A thin line shows distance without turning attention into a score.

This first room is deliberately small. The future garden can add backlinks, maps, aliases, and strange editions, but the act of reading remains the foundation underneath them.

But what if the real magic happens at 85%?

The Curse of Completion

I've built dozens of projects. Learned half a dozen programming languages. Started blogs, YouTube channels, podcasts. Read hundreds of books—finished maybe half.

The productivity gurus call this "shiny object syndrome." The career advisors call it "lack of focus." My inner critic calls it failure.

I call it research.

The 85% Sweet Spot

Here's what I've learned about that 85% mark:

• You've mastered the fundamentals (the first 20% that gives you 80% of the value)
• You've hit the interesting problems (where real learning happens)
• You've built something tangible (proof of concept, working prototype, published draft)
• You understand the domain (enough to have informed opinions)
• You can teach it (to someone at 50%)

But you haven't yet hit:

• The tedious polish phase
• The diminishing returns of micro-optimization
• The opportunity cost of not exploring the next thing

Why Polymaths Choose 85%

The polymath isn't afraid of depth. They're strategic about depth.

Going from 85% → 100% in one domain often takes as much time as going from 0% → 85% in three new domains.

The math is simple: - Path A: 100% in one skill = mastery, narrow applicability - Path B: 85% in three skills = competence, combinatorial creativity

Which has more creative potential? Which leads to more interesting intersections?

The Specialization Trap

Modern society worships the specialist. The doctor who only does knees. The developer who only writes Rust. The writer who only does noir detective fiction.

And yes, specialists are valuable. But they're not the only valuable archetype.

History's most interesting contributors were generalists: - Leonardo da Vinci (artist, engineer, anatomist) - Benjamin Franklin (writer, scientist, diplomat) - Richard Feynman (physicist, safe-cracker, bongo player)

They didn't master every field to 100%. They went deep enough to see connections others missed.

Building in Public at 85%

This site exists because I'm tired of pretending I'm an expert.

I'm not. I'm a perpetual 85-percenter.

And that's not a bug—it's the feature.

Every post here is: - A snapshot of my understanding right now - Subject to revision as I learn more - An invitation to fellow travelers - A breadcrumb for future me

The Ambitious Polymath's Creed

1. Finish enough to learn, not to perfect
2. Document the journey, not just the destination
3. Value questions over answers
4. Celebrate the half-built
5. Ship at 85%

Welcome to the Web

<img src="http://counter.digits.com/wc/-d/4/-f/0/thebard">

The Notepad Era

Back in the late 90s and early 2000s, Notepad was the IDE of choice for many web developers. Not because it was particularly good at editing code, but because it was:

• Always available on Windows
• Lightweight and fast
• Forced you to learn HTML properly
• Had zero learning curve

<!DOCTYPE html>
<html>
<head>
    <title>My First Website</title>
</head>
<body>
    <h1>Welcome to my homepage!</h1>
    <p>This site is under construction.</p>
    <img src="construction.gif" alt="Under Construction">
</body>
</html>

Why It Was Better

1. You Learned HTML Properly

When you're typing every angle bracket by hand, you really learn the structure of HTML. You understand:

• The importance of closing tags
• How attributes work
• The semantic meaning of each element
• Why indentation matters (even when the browser doesn't care)

2. No Distractions

Modern IDEs are amazing, but they can be overwhelming. Notepad had:

• No autocomplete (so you memorized the tags)
• No syntax highlighting (so you read carefully)
• No plugins or extensions
• No notification popups

It was just you and the code.

3. Instant Gratification

The workflow was beautifully simple:

1. Type HTML in Notepad
2. Save as .html
3. Double-click to open in browser
4. See your creation instantly
5. Hit back, edit, save, refresh

No build processes, no compilation, no waiting. Pure, immediate feedback.

The Downsides

Let's be honest - there were some real problems with the Notepad approach:

Limited Features

• No syntax highlighting made it hard to spot errors
• No line numbers made debugging frustrating
• No find/replace across files
• No project management
• Definitely no version control integration

Prone to Errors

Without syntax highlighting or validation:

• Unclosed tags were common
• Typos in attribute names went unnoticed
• Browser compatibility was trial and error
• Debugging was mostly guesswork

Scaling Issues

For anything beyond a simple personal homepage:

• Managing multiple files was painful
• No code organization features
• No snippets or templates
• Collaboration was nearly impossible

The Modern Middle Ground

Today, we can capture the spirit of the Notepad era while avoiding its pitfalls:

Use Simple Tools

You don't need a full IDE for everything. Consider:

• VS Code with minimal extensions
• Sublime Text for its speed and simplicity
• vim/emacs for the true minimalist experience
• Or yes, even Notepad++ for nostalgia

Hand-Code When Possible

Even with modern tools, try to:

• Write HTML by hand sometimes
• Understand your CSS before using frameworks
• Know what your build tools are actually doing
• Keep some projects framework-free

Embrace Constraints

The limitations of Notepad forced creativity. Modern constraints might include:

• No CSS frameworks
• Maximum file size limits
• Browser compatibility requirements
• Performance budgets

The Zen of Hand-Coding

There's something meditative about typing HTML by hand:

<article>
    <header>
        <h1>My thoughts on web development</h1>
        <time datetime="2025-06-25">June 25, 2025</time>
    </header>

    <p>When you hand-code HTML, every element has intention.
       Every attribute serves a purpose. Nothing is accidental.</p>

    <footer>
        <p>Written with love in a simple text editor.</p>
    </footer>
</article>

Each tag you type is deliberate. Each structure you create has meaning. There's no generated code you don't understand, no magic you can't explain.

Lessons for Today

What can we learn from the Notepad era?

1. Understand your tools - Don't let abstractions hide the fundamentals
2. Start simple - Build complexity gradually
3. Value craftsmanship - Take pride in clean, semantic code
4. Embrace constraints - Limitations often lead to creativity
5. Know the basics - Frameworks come and go, but HTML is forever

Try It Yourself

This weekend, challenge yourself:

1. Open a simple text editor (not an IDE)
2. Build a small website by hand
3. Use only HTML and CSS
4. No copy/paste from frameworks
5. No external libraries

You might be surprised how satisfying it feels to build something from scratch, character by character, tag by tag.

After all, every great website starts with a single <html> tag.

This post was written in VS Code but could just as easily have been typed in Notepad. Some things never change.