Papers: The Brutal Truth About Building a Real "Second Brain" After 8 Years

Honestly, when I first started Papers back in 2018, I thought I was being brilliant. "I'll build my second brain!" I told myself, completely missing the fact that I was about to embark on an 8-year journey of self-inflicted complexity. Here I am in 2026, staring at a system with 170+ technical articles and realizing that my "second brain" has somehow become more complicated than my actual brain.

Looking at these GitHub stats, I have to admit it's... underwhelming. 6 stars, 2 forks. My mom has probably starred it twice and maybe a colleague who felt bad for me. But this little project has survived through multiple major life changes, career shifts, and even a complete rewrite from scratch. That's gotta count for something, right?

The Dream vs. The Reality

The dream was simple: build a personal knowledge management system that would make me smarter, more productive, and basically the Tony Stark of my personal information universe. What I got was a complex system that occasionally helps me find that one article I wrote about Java concurrency three years ago, provided I remember exactly what I called it and which category I decided to put it in.

So here's the brutal truth: Papers isn't some revolutionary AI-powered knowledge management system. It's just a bunch of HTML files organized in a way that I, personally, can understand most of the time. It's basically my digital shoebox for thoughts, except the shoebox occasionally refuses to open and requires me to remember the exact combination of tags I used.

How It Actually Works (The Brutal Version)

Let me show you the reality of this "advanced knowledge base":

// This is what happens when I search for something in Papers
function searchMyBrain(query) {
  const results = [];

  // First, I panic a little
  console.log("Why did I write about this again?");

  // Then I try to remember what I called it
  const possibleTerms = [
    query,
    query + " java", 
    query + " tutorial",
    query + " deep dive",
    query + " I don't understand",
    query + " fix this mess"
  ];

  // And which category it might be in
  const categories = [
    "java", "concurrent", "database", "distributed",
    "ai", "oops", "experiment", "maybe-useful-one-day"
  ];

  // Then I cross my fingers and hope
  possibleTerms.forEach(term => {
    categories.forEach(category => {
      if (Math.random() > 0.7) { // 30% chance of finding something
        results.push({
          title: `${term} - ${category}`,
          relevance: "maybe?" 
        });
      }
    });
  });

  return results;
}

The reality is that Papers is essentially a glorified file system with a web interface. I organize articles into categories, tag them inconsistently, and occasionally remember what I called something when I need it. It's less "second brain" and more "filing cabinet that sometimes talks back."

The Brutal Statistics

After 8 years of development, here are some numbers that might make you reconsider building your own knowledge management system:

• Total Articles: 170+
• Articles I Actually Reference Regularly: ~15
• Articles That Are Outdated But I Can't Bring Myself to Delete: 47
• Categories I've Created and Forgotten About: 12
• Hours Spent Organizing vs. Actually Using: Roughly 4:1 ratio
• Times I've Completely Rewritten the System: 3 (including the current version)

Success rate: Maybe 15% if you're being generous. That's basically the same as building your own social network.

What Actually Works (The Surprising Bits)

Despite all this, there are a few things that Papers actually does reasonably well:

1. The "I'll Figure It Out Later" Archive

Articles I'm not sure about but might need someday get dumped into a general category. I tell myself I'll organize them later. Later rarely comes, but when I do need that obscure Java concurrency article from 2019, it's often still there, waiting for me.

// My "Maybe Useful Later" filing system
class FutureMeProblem {
    val articles = mutableListOf<Article>()

    fun dontKnowWhereToPutThis(article: Article) {
        articles.add(article)
        println("Future me will figure this out... probably")
    }
}

2. The "Oh Crap, I Need This Now" Search

When I'm in the middle of a crisis at work and need to remember how that database optimization worked, Papers usually has what I need. The search functionality is... functional. It's not fast, it's not intelligent, but it usually gets the job done eventually.

3. The "I Actually Wrote Something Smart Once" Motivation

Looking back at older articles, I occasionally surprise myself with something coherent I wrote. It's like finding money in your old jeans - unexpected but welcome. This little dopamine hit keeps me adding more articles even though I know most will never be read again.

The Dark Side (Why I Might Regret This)

Configuration Hell

Oh my god, the configuration. I've YAML'd myself into a corner so many times I've lost count. What started as a simple "organize my thoughts" project has turned into a complex web of configuration files that I'm terrified to touch.

# papers-config.yml
papers:
  organization:
    strategy: "whatever-makes-sense-right-now"
    categories:
      - "java"
      - "oops"
      - "maybe-useful"
      - "definitely-useful-i-promise"
    tagging:
      system: "if-i-remember-it-then-it-works"

search:
  effectiveness: "mixed-results" 
  speed: "depends-on-how-many-coffees-i've-had"

backup:
  frequency: "whenever-i-remember-to-do-it"
  reliability: "could-be-worse"

The "Digital Hoarding" Problem

Papers has enabled my worst tendencies as a knowledge hoarder. I keep articles "just in case" I need them, creating a digital landfill of potentially useful but mostly irrelevant information. It's like having a spare tire for your bicycle that you never use but keep buying new ones just in case.

The "I've Solved This Before" Fallacy

This is the worst one. I'll look up something in Papers, find my old solution, and then spend hours implementing it again because I don't recognize my own solution. I literally argue with my past self about how to solve a programming problem.

The Honest Pros and Cons

Pros (Let's Be Fair)

✅ Actually Find Things Sometimes: When it works, it works

✅ Personalized Knowledge Base: It knows how I think (or at least how I used to think)

✅ No Monthly Subscription: I won't cry if I stop using it tomorrow

✅ Teaches You About Yourself: You learn what you actually find useful vs. what you think will be useful

✅ Creative Outlet: Sometimes writing these articles helps me think more clearly

Cons (The Brutal Truth)

❌ 6 GitHub Stars and 2 Forks: This is objectively not a popular project

❌ 8 Years for What? I could have learned three new programming languages in that time

❌ Maintenance Nightmare: Every time I change something, I break something else

❌ Search Is Unpredictable: Sometimes it finds everything, sometimes nothing, sometimes articles about cats when I'm looking for Java tutorials

❌ I Basically Built My Own Notion: And it's worse than Notion in every way

❌ Wasted Time: Hours spent organizing, categorizing, and maintaining when I could have been, you know, actually doing useful work

The ROI Analysis (Prepare to Cry)

Let me break this down financially:

• Hours Invested: Probably 400+ over 8 years
• Value of My Time: Let's say $50/hour
• Total Investment: $20,000+
• Actual Benefit: Maybe $100 in productivity gains
• Return on Investment: -99.5%

If I had invested that time in anything else, including learning to juggle while playing the ukulele, I'd be better off.

What I've Actually Learned (The Real Value)

After all this time building and maintaining Papers, here's what I actually learned:

1. Simpler is Better

Every time I tried to make Papers "smarter" or "more advanced," it became more complicated and less useful. The most valuable articles are the simple, straightforward ones that don't try to be too clever.

2. Consistency Matters More Than Complexity

Having a consistent tagging and naming system matters more than having fancy AI-powered search. I get more value from simple organization than from complex features.

3. Less is More

I've found that I use about 15 articles regularly, but I have 170+. The 155 others are basically digital hoarding. I should probably delete most of them.

4. Writing Helps Thinking

The act of writing these articles helps me organize my thoughts, even if no one ever reads them. The process is valuable, not just the result.

5. Tools Don't Solve Problems, People Do

Papers doesn't make me smarter. I make myself smarter by using Papers (and other tools). The tool is just the container; the thinking is what matters.

The Unexpected Benefits

Despite all this, there are some unexpected benefits to building and maintaining Papers over 8 years:

1. Personal Growth Timeline

Looking back at articles from different years shows me how my thinking has evolved. I can see where I was naive, where I was overconfident, and where I actually learned something useful.

2. Creative Sandbox

Papers became a sandbox where I could experiment with different writing styles, technical approaches, and organization systems without the pressure of production code.

3. Digital Legacy (For Myself)

If I ever need to remember how I solved a particular problem 5 years ago, there's a good chance it's documented in Papers somewhere. It's like having a conversation with my past self.

4. Teaching Resource

When I need to explain concepts to junior developers, I often have articles I can reference that explain things in my own words.

The Brutal Final Assessment

So would I recommend building your own personal knowledge management system like Papers? Honestly, probably not.

But here's the thing: I'm glad I did it. Not because it makes me more productive or smarter, but because the process taught me more about myself, my thinking patterns, and what actually works for me than any off-the-shelf system could have.

Papers isn't just a tool. It's a diary, a learning journal, and a monument to my own intellectual journey. It's messy, complicated, and objectively not very successful by traditional metrics, but it's mine.

Should You Build Your Own Knowledge Base?

Maybe, but only if you:

• Enjoy the process of building and organizing more than the result
• Are prepared to spend way more time maintaining than using
• Don't mind having a system with 6 GitHub stars
• Find value in the journey rather than the destination
• Are willing to admit that you'll probably use it less than you think

If you want something that actually works well and saves time, use Notion, Obsidian, or any of the other established tools. They're better in every measurable way.

But if you enjoy building things, learning by doing, and documenting your intellectual journey, then maybe, just maybe, building your own "second brain" is worth it.

The Interactive Part

Now it's your turn. Have you built your own knowledge management system? Are you thinking about it? What's your experience been like?

Questions for you:

• What's the single most valuable piece of knowledge you've captured in your system?
• Do you find that you actually use what you capture, or is it mostly for archival purposes?
• What's your biggest challenge with personal knowledge management?
• If you could go back, would you build your own system or use an existing one?

Let me know in the comments! I'm genuinely curious to hear about other people's experiences with this stuff.

---

Find the Papers project on GitHub: kevinten10/Papers

Check out the live version at: paper.rxcloud.group