I No Longer Write Book Reviews: How a Programmer Turned Reading into a Decision System - XBSTACK

I No Longer Write Book Reviews: How a Programmer Turned Reading into a Decision System

Release Date
2026-06-16
Reading Time
14分钟
Content Size
23,784 chars
知识书架
Decision System
Independent Developer
Personal Knowledge Management
Long-term Thinking
阅读线索

Reading 不是普通书评。每篇都要回答:我带着什么问题读,拿书里的观点做了什么实践,现实验证结果如何,以及下一次怎样修改自己的判断。

What This Guide Covers

  • Why traditional note-taking methods like underlining and excerpting fail to change our behavior when we face real-world decisions.
  • How to build a “reading as decision-making” feedback loop, physically mapping business and psychological theories onto technical R&D and systematic asset investment.
  • Which three core questions to use for filtering and selecting non-fiction books worth deep reading.
  • How independent developers can leverage the Reading section of their personal websites to convert cognitive gains into long-term, compounding digital assets.

Who This Guide Is For

  • Independent developers seeking a closed-loop architecture for knowledge monetization and personal knowledge management (PKM).
  • Those who have hoarded hundreds or thousands of clipped articles and highlighted quotes but still feel anxious and unable to make sound decisions when confronted with actual problems.
  • Thinkers attempting to establish a Reading section on their personal websites without reducing it to elementary school-style book reports.
  • Pioneers trying to physically integrate cross-disciplinary reading (business, investing, psychology) with technical development and asset allocation.

1. Why I No Longer Write Standard Book Reviews

Many book reviews I’ve written merely prove that I read the book; they don’t prove that I actually used the content.

In the past, when taking notes, I often fell into a trap of false self-satisfaction. Whenever I encountered a brilliant passage in a book—such as Nassim Taleb’s discussion on “fragility” versus “antifragility” in Antifragile, or Naval Ravikant’s assertions on “building leverage”—I would highlight it with various colored pens on my iPad or copy large chunks into Notion, categorizing them with tags. At the end of each year, I would write lengthy reviews on Douban, dissecting the author’s arguments layer by layer and adding deeply felt reflections.

But this method of reading quickly became ineffective.

Once, while debugging a Python script inside a Feiniu NAS Docker container to periodically scrape and analyze cryptocurrency on-chain data, I encountered continuous network timeouts. This caused errors that filled up my local logs and led to an out-of-memory crash. It was 2:00 AM; outside my window lay the distinctive wind noise of late-night Beijing, beyond the Sixth Ring Road in Changping District. Inside, only the hot air from the NAS cooling fans blew steadily. Sitting at my computer, staring at the dense stack traces on the screen, I felt a wave of intense physical nausea. My mind was a blur.

I should have immediately applied the logic from Antifragile—“gaining feedback through small-scale failures”—to design a distributed exception circuit breaker mechanism with exponential backoff retries. However, exhausted and frustrated, my first instinct was to emotionally fumble with configuration settings in the code, restart the container, and even doubt my own logic. By early morning, I had been banned by the service provider due to continuous errors.

In that moment, I realized an absurd physical truth: despite having read so much theory on antifragility and written thousands of words praising Taleb’s wisdom in my reviews, when I truly stood at a crossroads of decision-making, those underlined and categorized “knowledge” did not alter my subconscious behavior in the slightest.

My reading notes were scattered across the vast, chaotic directory structure of Notion, sinking rapidly over time. The reviews on Douban garnered a dozen likes and nothing more. They left behind only “empty shells of concepts” in my brain, never evolving into executable strategies.

Many book reviews I’ve written merely prove that I read the book; they don’t prove that I actually used the content. This is why I decided to completely abolish the habit of writing reflections and summary reviews. I no longer pursue metrics based on the number of books read. Instead, I treat reading as an input source, directly aligning it with my daily decisions, code refactoring, product design, and asset allocation.


2. If a Book Doesn’t Change Your Judgment, It Will Disappear Quickly

The utility of a book isn’t measured by how many sentences you remember, but by whether it changes a specific judgment.

For a programmer who deals with logic and state machines all day, information that cannot be instantiated as some form of “behavioral update” is merely invalid cache in memory, ready to be cleared by the garbage collector at any moment.

I began forcing myself to establish a feedback loop of “reading as decision-making.” Whenever I finished a book or encountered a particularly resonant logic within one, I stopped copying it down. Instead, I looked for: In my real life, is there a process currently running that needs to change direction because of this logic?

Within my personal system, I identified four real-world decision scenarios that were fundamentally altered by reading:

1. Homepage Redesign Decision for My Personal Website

During the refactoring of the entire AltStack site, I fell into a severe trap of perfectionism. I spent an entire week tweaking the border radius of glassmorphism cards on the homepage and refining CSS gradient transition animations. I even repeatedly modified the link preload code in BaseLayout.astro just to shave off a fraction of a second—reducing the load time for the “Hanshan Half-Round” font on the first screen from 1.2 seconds to 0.8 seconds.

Just as I was agonizing over whether to redesign the Lightbox preview effects for the bookshelf component, I reread the chapter on the “Minimum Viable Product (MVP)” in The Lean Startup. The author noted: Any effort beyond what is necessary to validate the core value is waste.

Those words pricked me awake like a needle. I was using “perfecting the website’s appearance” as an excuse to avoid “producing high-quality content.” So, I made a decisive physical decision:

  • Immediately halt all non-essential CSS fine-tuning.
  • Take the version of AltStack that had already been localized and had basic typography fixes applied, bind it to the new domain xbstack.com, and launch it.
  • Force my energy back into writing the cornerstone articles on Stack and Horizon.

It turned out this choice was entirely correct. After the site went live, users focused solely on the practical code and investment logic in the articles. Not a single person emailed to complain that my card border radius wasn’t round enough.

2. Field Design Decisions for the Compound Interest Calculator Tool

When developing our compound interest calculator page (/tools/compound-calculator/), my initial design logic was extremely complex. I wanted to cram simple vs. compound interest comparisons, inflation adjustments, multiple additional contributions, dynamic tax rates, and even Monte Carlo simulations into input fields for the user.

While debugging that massive, hard-to-hydrate React code, I came across The Design of Everyday Things discussion on “constraints” and “intentional guidance”: If a system’s control interface exceeds the user’s everyday mental model, their first reaction isn’t admiration for its power, but frustration and abandonment.

This led me to make a painful decision:

  • Removed 70% of the advanced configuration fields, streamlining the interface to just three core sliders: “Initial Principal,” “Annualized Return Rate,” and “Investment Term.”
  • Hid high-level options like Monte Carlo simulations and inflation adjustments behind a secondary collapsible menu.

After the simplified calculator went live, its average session duration and interaction frequency tripled. This experience profoundly taught me that the judgment gained from reading often manifests in your willingness to make the hard decision to “subtract.”

3. Stop-Loss and Dollar-Cost Averaging Decisions Amidst Market Volatility

At the beginning of 2026, the big tech sector experienced a brutal downward correction driven by geopolitical tensions and shifting interest rate expectations. The core tech ETF I held lost 12% of its value within three days. My heart began racing uncontrollably as I watched the charts, my palms breaking out in a cold sweat.

In the past, I likely would have let emotions drive me to either panic-sell out of pain or blindly go all-in to catch the falling knife.

At the time, I forced myself to close my laptop and read Daniel Kahneman’s analysis of “prospect theory” and “loss aversion” in Thinking, Fast and Slow. Kahneman points out that the pain of a loss is roughly twice as intense as the pleasure of an equivalent gain. This evolutionary psychological instinct drives us to take irrational risks when we’re down (such as holding onto losing positions or doubling down) and to become overly conservative when we’re up.

I realized that my urge to trade was driven not by rational expected value, but by an ancient genetic impulse to avoid perceived danger. So, I aligned my investment behavior with this insight:

  • I uninstalled intraday market refresh apps from my phone and forcibly limited my market-checking frequency to once a week.
  • I strictly executed my pre-established dollar-cost averaging strategy via automatic deductions, refraining from adjusting individual purchase amounts based on daily price fluctuations.

This decision helped me avoid the sharpest bottom of that sell-off and successfully lowered my average cost basis during the subsequent two-month market rebound.

4. Framework Selection Decisions When Exploring the AI Tech Stack

When AutoGen, CrewAI, and LangGraph are dominating GitHub feeds, it’s natural for a tinkerer like me—a full-stack engineer—to want to build demos with every framework, chasing the latest API features. This led to two weeks of configuring complex requirements.txt files and daily anxiety over an overwhelming flood of new terminology.

Later, while reading about “first principles” and the history of technological evolution, I asked myself a question: What fundamental physical constraints are these agent frameworks actually solving?

The answer is: building deterministic control flow and persistent state machines on top of unpredictable large model outputs.

Once I grasped this, I immediately cut my research on other flashy frameworks and locked all my focus onto LangGraph’s directed graph and Checkpointer state machine architecture. This focus proved to be exactly what allowed us to build highly available multi-agent approval flows and isolation systems, rather than just a bunch of toys.


3. The Three Questions I Ask Before Reading a Book

Whenever I start reading a non-fiction book, I write down three questions that force me to think critically on the first page or in my physical notebook:

1. What problem does this book solve?

I no longer care about “what the book says.” Instead, I look for “what specific pain point in human behavior or system operation the book is trying to address.”

If a book is just piling up correct nonsense (like “you need to improve your cognition”), I will toss it in the trash after reading 10% of it. Only when a book precisely defines a problem and provides a breakdown of its underlying logic is it worth continuing to read.

2. Can it change one of my decisions?

After finishing a book, if all I feel is “that makes sense,” but it doesn’t change my actions tomorrow, my next technical decision, or my next capital allocation, then that book hasn’t truly entered my system. It’s just occupying memory in my brain without generating any I/O output.

I force myself to write down at least one specific behavioral change. For example, after reading Refactoring, my change was: “From now on, any Node function exceeding 30 lines and containing more than two conditional branches must be immediately refactored and split after tests are written.”

3. Can it be solidified into website content, tools, or post-mortems?

The core advantage of an indie developer is the compounding effect of physical assets. If I read a book and keep the knowledge only in my head, it will quickly decay to zero according to the forgetting curve.

I need to convert it into:

  • A practical case study on my personal website, serving as a cornerstone for my personal IP.
  • A small tool (such as an algorithmic iteration of a compound interest calculator).
  • A rigorous investment or product post-mortem report.

Only reading that has been solidified can generate long-term compounding value for me around the clock on the server, much like code running 24 hours a day.


4. How a Book Enters My Personal System

To ensure reading generates real value, I have designed a physical conversion process similar to a data pipeline.

This system ensures that every step from “information intake” to “asset accumulation” is deterministic and addressable:

信息输入 (书籍 / 深度报告 / 文献)
  ↓
提取观点 (在边栏或物理本子上记录核心逻辑,拒绝大段摘抄)
  ↓
映射现实 (寻找目前正在做的项目、持有的资产、或遇到的痛点)
  ↓
写成判断 (例如:“当系统节点超过 3 个且有局部状态时,必须使用 Subgraph”)
  ↓
执行行动 (修改代码,调整仓位,更新网站排版)
  ↓
沉淀复盘 (在个人网站上写下实战复盘,作为物理数字资产)

In this pipeline, the two most critical steps are “forming a judgment” and “taking action.”

For example, when I read Principles, I didn’t copy down Dalio’s dozens of dense principles. Instead, I extracted his core methodology: turning decisions into algorithms and conducting systematic post-mortems after every decision based on the results.

I translated this logic into a hard constraint for my main repository, myblogAdmin, regarding git commit standards: every commit must include a Details section clearly explaining “why the change was made” and “what was changed.” This minor rule adjustment has multiplied my code debugging efficiency by several times. This is what it looks like to translate reading into concrete decision-making.


5. What Does Reading Have to Do with Indie Development?

The hardest part of indie development isn’t writing code; it’s judging what is worth building.

Many technically minded indie developers make the mistake of “looking for nails when you only have a hammer.” Because they are proficient in React or Go, they build flashy tools that lack genuine market demand. In the end, after spending half a year writing code, they might only garner a few lonely stars on GitHub, with zero commercial monetization.

Reading serves as a “decision-making sandbox” during this process.

  • Reading business and market books: Not to learn MBA jargon from big tech companies, but to build a filter for identifying “pseudo-demands.” For instance, reading From 0 to 1 taught me that if a product cannot be 10 times better than existing solutions in a specific niche, there is no need to write the first line of code.
  • Reading product design books: To curb the endless urge to add features. It reminds me that an indie developer’s survival depends on an extremely high efficiency ratio; every new feature adds infinite future maintenance costs and becomes a source of bugs.
  • Reading cybernetics and systems engineering books: To help me understand the boundaries of technical architecture. For example, while researching multi-agent collaboration, these books enabled me to design the hierarchy of Supervisors and Subgraphs from a system topology perspective, rather than writing out a chaotic mess of node calls.

Code is merely the execution tool; judgment is the rudder that determines whether a project lives or dies. And reading is the lowest-cost sandbox for training that judgment.


6. What Is the Relationship Between Reading and Investing?

The most expensive thing in investing isn’t ignorance; it’s knowing what to do but failing to do it.

In financial markets, publicly available information and analysis reports are severely overloaded. Almost everyone knows to “buy low and sell high,” to practice “long-termism,” and to “control position sizing.” So why do most people still go all-in at the peak of a bull market and cut their losses at the bottom of a bear market?

Because our brains did not evolve for modern financial markets. When we see our account balances shrink, the amygdala sounds the alarm, releasing large amounts of cortisol and adrenaline. This is an intense physiological panic that physically blocks rational thought.

At this point, the role of reading is to build a “psychological circuit breaker” for you.

  • Identify psychological anchors: After reading books on behavioral finance, when I feel the urge to catch a falling knife on a plummeting asset, my mind immediately flashes warnings about the “disposition effect” and “anchoring bias.” It forces me to stop and calculate the mathematical expectation rather than being misled by the illusion of “cheapness.”
  • Understand cycles and uncertainty: Re-reading The Cycle and Fooled by Randomness helps me understand that in complex nonlinear systems, short-term returns are often just the product of random noise, not proof that I have mastered the truth. This keeps me humble before the market, maintains a clear head during profitable periods, and curbs the impulse to add leverage indiscriminately.

Books won’t tell me directly which stock will rise tomorrow, but they can physically hold back my hand from clicking the buy or sell button when the market falls into frenzy or panic, helping me avoid many costly, elementary mistakes.


7. What Is the Relationship Between Reading and Personal Websites?

A personal website isn’t about uploading reading notes; it’s about turning reading into reusable assets.

This is the fundamental reason we established the Reading section in AltStack.

I don’t want this section to become a hollow display wall of book lists, nor do I want it cluttered with verbose text excerpts and superficial reflections like “this book was mind-blowing.” That offers no value to visitors and is merely dead information garbage for me.

On xbstack.com, the future Reading section will strictly adhere to the following curation guidelines:

1. Centered on “Decision-Making” and “Action” as the Core Framework

Every reading log must center on a single question: “How did this book change a specific parameter in my development, investing, or system-building?” For example:

  • Which book led me to refactor the CSS scrollbars and first-screen loading logic of my blog.
  • Which financial analysis book prompted me to adjust the allocation proportions of my household Barbell strategy.

2. Rejecting Golden Quotes and Vague Sentimentality

No isolated golden quotes without context. Every theory must be paired with real-world error logs and post-mortem data from my FlyNAS, code editor, or securities trading account.

This approach creates an organic ecosystem between the Reading column and the adjacent Thinking, Investing, and Tools columns:

  • The Tools column is the “code implementation” of my decision-making logic (e.g., compound interest calculators).
  • The Investing column represents my “capital deployment” in the market.
  • The Thinking column captures my “localized reasoning” on complex problems.
  • The Reading column serves as the “input source” and “algorithm library” for all underlying judgment.

Only in this way does a personal website cease to be a simple static business card and become a high-value digital asset that continues to grow online.


8. Books I Keep vs. Books I Discard

To prevent information overload, I enforce a strict “garbage collection mechanism” for both my physical bookshelf and digital reading library.

I have organized my criteria for retaining and discarding books as follows:

1. Books I Firmly Retain and Re-read

  • Books that repeatedly reshape your judgment: such as Antifragile, Thinking, Fast and Slow, and Principles. Each rereading reveals new mappings to current development or investment projects.
  • Books that provide foundational mental models: basic works on cybernetics, probability theory, and evolutionary biology. These help me construct universal filters.
  • Practical manuals with detailed troubleshooting and post-mortem analysis: whether covering technical architecture or business cases, only books that clearly document specific failure details offer real reference value.

2. Books to Ruthlessly Eliminate and Clear Out

  • Books offering only emotional value: bestsellers that sell courses by pumping you up or manufacturing anxiety. They leave you with a brief physiological spike in excitement but no actionable behavioral interface.
  • Books suitable only for quote-hunting: works whose viewpoints appear profound and grandiose but cannot be physically verified or algorithmized in reality.
  • Books completely irrelevant to the specific problems you face: unless you are trying to completely relax your brain, do not force yourself to slog through academic tomes unrelated to your current survival, product development, or investments just to appear erudite. Human energy and memory bandwidth are extremely limited; you must reserve your cache for the most critical tasks.

9. Common Pitfalls and “Cognitive Errors” (Mental Bug Logs)

As we convert reading into a decision-making system, our brains—functioning as biological computers—frequently trigger various “runtime anomalies” due to outdated evolutionary genes or cognitive habits.

I have outlined these three most insidious “cognitive bugs,” along with their symptoms and countermeasures, below for easy self-audit at any time.

1. CognitiveError: BufferOverflow (Information Overload with Zero Execution)

  • The symptom: Your bookmarks are overflowing with thousands of “to-read” technical and financial articles, you’re frantically subscribing to RSS feeds, yet you haven’t written a single line of code for your personal projects in the past month, nor have you conducted any systematic investment reviews.
  • Error log (Mental State Logs):
    CognitiveError: BufferOverflow. Internal memory full (99.8%).
    Information intake rate: 2.5MB/s. Action execution rate: 0.00KB/s.
    Decision processor is locked. Please flush caches or write code.
    
  • Root cause: Equating the “thrill of acquiring information” with “skill improvement.” When the brain consumes new ideas, it releases dopamine, creating an illusion of growth that allows us to avoid the execution phase, which requires intense cognitive effort.
  • Solution: Implement a physical circuit breaker for information intake. For one week, prohibit yourself from consuming any new content. Force yourself to actually run a feature in your local editor or write a complete post-mortem article.

2. MemoryLeak: NoteHoarding (Hoarding notes without ever reviewing them)

  • Symptom: You’ve created hundreds of beautifully formatted card notes in Obsidian or Notion, using incredibly complex bidirectional linking and tagging systems, but these notes have never been opened since the day they were created.
  • Error Log (Mental State Logs):
    MemoryLeak: NoteHoarding detected. Found 1024 orphan nodes in database 'PKM'.
    Last access time for 95% of nodes is > 180 days ago.
    System efficiency degraded due to excessive cognitive bookkeeping.
    
  • Root Cause: Mistaking “organizing notes” for “mastering knowledge.” Complex management systems consume significant energy, and the tediousness of organizing itself kills the impulse to instantiate knowledge into action.
  • Solution: Delete the 80% classification tags. Keep only a “Problem Area” and an “Action Area.” Any note that cannot be categorized as a specific to-do task or a current project bug fix should not be recorded or organized.

3. ExecutionError: OpinionAsDecision (Blindly trusting others’ opinions as your own judgment)

  • Symptom: Buying into an investment because a prominent influencer recommended it, or blindly refactoring a tech stack based on a blog post from a major tech company, only to find yourself completely unsure how to handle the situation when the market drops or you hit an architectural bottleneck.
  • Error Log (Mental State Logs):
    ExecutionError: OpinionAsDecision. Current state logic imported from external source without local validation.
    Crash occurred at step 'handle_exception': missing local handler.
    
  • Root cause: Directly adopting someone else’s “conclusions” without also adopting the “inputs and logic verification flow” they used to reach those conclusions. When external conditions shift, the brain crashes instantly due to a lack of underlying logical support.
  • Solution: When incorporating any external viewpoint, you must run it through your own local data (e.g., compound interest calculator formulas, real-world performance benchmarking results) in a “local sandbox.” Only logic that passes this local validation should be written into your decision-making database.

10. General Reading vs. Decision Systems (Comparison)

To make the physical differences between these two reading modes more intuitive, we can compare them using the table below:

DimensionCasual Reading (Read for Fun/Info)Systematic Decision-Making Reading (Read for Decision)
Ultimate GoalFinish a book and gain the self-satisfaction of expanded knowledgeAlter a specific judgment or behavioral parameter in real life
Note FormatCopying long passages of quotes and writing vague reflectionsWriting “decision rules” and “action checklists” that map directly to project bugs or assets
Knowledge FlowOne-way intake, eventually decaying to zero in brain memory following the forgetting curveClosed-loop circulation, solidified into articles, tool algorithms, or investment reviews on a personal website
Filtering MechanismFollow the crowd: read whatever topic is trending or has an attractive cover.Problem-oriented: only read books that address your current core pain points and long-term themes.
Facing VolatilityStill dragged by emotions and instincts, making irrational choicesActivate the instantiated “psychological circuit breaker” and strictly adhere to system parameters

XI. Conclusion: Reading Is Not About Appearing Profound

I hope this Reading column will never become a dusty e-bookshelf or a collection of hollow reading reflections.

It reads more like a long-term system log for a programmer: documenting which books truly informed my judgment while building the AltStack website, developing multi-agent tools, and managing household asset allocation; which theories helped me withstand the panic of real-world volatility; which seemingly grand ideas were ruthlessly overturned by reality; and which bore fruit over the long term through the power of compounding.

The ultimate goal of reading isn’t to appear profound or to show off new jargon at dinner parties. It’s so that when we face our next choice, we make slightly fewer of the same mistakes as before.


FAQ

Will the Reading section feature standard book reviews?

No. This section focuses on how a book maps to and influences my product judgment, investment post-mortems, personal website development, and long-term decision-making. I do not write pure summaries or reflections that lack real-world alignment.

Should programmers read technical or non-technical books?

Both are equally important. Technical books address how to implement (How), while non-technical books (business, investing, psychology, systems engineering) address what is worth doing (What) and how to make the right choices.

Should reading notes be published publicly on the website?

They can be, but simply posting excerpts isn’t recommended. It’s far more valuable to explain on the site how a book solved a specific, current real-world problem for you, and what changes it prompted in your codebase or asset allocation.

What is the difference between the Reading and Thinking sections?

The Reading section starts with “books” and “system inputs,” documenting how knowledge is digested and converted into rules. The Thinking section starts with “actual pain points and practice,” recording local reflections and architectural explorations during the process of getting things done.

Can reading directly improve my investment returns?

It cannot guarantee direct results. However, reading helps you establish clear psychological defense boundaries, allowing you to identify emotions, cycles, position sizing, and decision biases. In the long run, these are key determinants of your portfolio’s survival probability.

Keep Reading

A previous attempt failed validation: short-output:7->19. Correct those issues while preserving all content.

下一步阅读

返回专题入口 →

继续探索

XBSTACK Paths
Xiaobai

Xiaobai

Full-Stack AI Engineer

Xiaobai, a full-stack AI engineer building production Agent systems, product tools and independent software assets.

About Xiaobai & XBSTACK →
Written by Xiaobai on 2026/06/16
Discussions