~iany/ Ai Generated

What I Touched This Week 2026-03-30

me@iany.me (Ian Yang) — Mon, 30 Mar 2026 00:00:00 +0000

This journal is generated by AI

Convincing vs Persuading in Technical Work

This week sharpened a useful distinction: being correct is only the starting point, while moving a system or a team requires persuasion tuned to real context. That frame maps directly to architecture work, migration plans, and cross-team decisions.

Convincing Is Not Persuading highlights that proof and benchmarks convince, but adoption depends on trust, timing, and incentives.
The practical takeaway is to pair correctness with audience-aware framing: what this change protects, what risk it removes, and what people can safely do next.

Scale-First AI Thinking and Mental Models

The Readwise set this week converged on a coherent AI posture: favor general methods that scale with compute, then use explicit mental models to reason about systems and constraints.

The Bitter Lesson reinforces a long-run strategy: approaches that scale with computation and learning tend to dominate handcrafted knowledge-heavy systems.
TLA+ Mental Models contributed a systems lens (state, logs, replication) that is useful for evaluating reliability claims, not just feature velocity.
This combination was a good backbone for AI reflection this week: keep abstractions general, but reason rigorously about behavior under change.

Boring Tech, Better Practices, and Tooling Leverage

A recurring theme across highlights and bookmarks was pragmatic leverage: pick stable tools, then innovate in process, automation, and integration points.

Choose Boring Technology and Innovative Practices captures the principle well: conservatism in stack choice enables boldness in operational practice.
Recent bookmarks aligned with this approach, including RustTraining, Saber, and monitor-switch automation via monctl.js.
Weekly hygiene (bookmark triage, highlights cleanup, sync routines) made this strategy actionable rather than theoretical.

Obsidian Links

What I Touched This Week 2026-03-21

me@iany.me (Ian Yang) — Sat, 21 Mar 2026 00:00:00 +0000

This journal is generated by AI

Software Maintenance and the Specification Problem

Scott Werner’s “Warranty Void if Regenerated” explores why software needs continuous tending, not just initial development. The core insight: specifications describe static relationships, but real-world inputs are alive—feeds from other systems that are constantly being updated, recalibrated, and regenerated.

The maintenance paradox: Paying for maintenance means admitting vulnerability, while paying for repair means responding to an emergency. Humans find emergencies more motivating than vulnerabilities.
Domain knowledge is irreplaceable: People who understood the domain and could diagnose specification problems were the most valuable. This knowledge is often embodied, contextual, and inarticulable—like knowing the clay underneath a greenhouse or how prevailing winds affect crop rows.
The Software Choreographer concept: A role that maps your entire tool ecosystem, specifies interfaces between them, and builds a conformance layer so that when any tool regenerates, interfaces are verified before the new version goes live. Like shipping containers: the container was cheap; organizing the logistics was where all the value was.
Physical controls matter: Always offer a physical control—a button, switch, or lever. Something the client can touch. This builds trust and allows graceful degradation when systems fail.

AI Agents and the Harness

Ben Thompson’s “Agents Over Bubbles” argues that the critical component of making agentic workloads work is the “harness”—the software that actually controls the model, not the model itself.

Abstraction layer: Claude Code and OpenAI’s Codex abstract the user away from the model. You give instructions to an agent, which directs the model; the agent can also use deterministic tools to verify results.
Models lack goals: Large language models are intelligent, but they do not have goals or values or drive. The harness provides the structure and verification.
The opportunity: How many apps or services haven’t been built, not because one person can’t imagine them, but because they haven’t had the resources, team, or coordination capabilities to ship them? Agents could change this dynamic.

Simplifying Life Through Lifestyle Design

The Tim Ferriss Show episode on simplifying life brought together insights from Maria Popova, Morgan Housel, Cal Newport, Craig Mod, and Debbie Millman on what it means to simplify.

Read history, not forecasts: A good heuristic for your relationship with information is to read more history and fewer forecasts. As Kelly Hayes says, “When you haven’t engaged with history, everything feels unprecedented.”
Lifestyle design over triage: Cal Newport argues that triage rules don’t work—too many things satisfy “good enough” criteria. Instead, think about lifestyle design: know what conditions of your day-to-day existence are best for you, and design a lifestyle that matches that.
Courage over confidence: Debbie Millman distinguishes courage from confidence. Courage means taking risks and steps toward what you want despite how you feel. Confidence comes through repeated success. You don’t wait for confidence to arrive; you act from courage.
Freedom over control: What Millman wanted wasn’t more control, but more freedom. That freedom has allowed her to build a very different kind of life.
Simplicity as coherence: Simplicity isn’t only about minimalism. It’s also about coherence—things fitting together in a way that makes sense.

Sources:

Obsidian Links

What I Touched This Week 2026-02-07

me@iany.me (Ian Yang) — Sat, 07 Feb 2026 00:00:00 +0000

This journal is generated by AI

Haskell: Typeclassopedia, IO, and Documentation

This week was heavily Haskell-focused. I worked through the Typeclassopedia, Learn You a Haskell Chapter 9 (Input and Output), and Real World Haskell Chapter 7 (IO), plus the Haddock markup guide.

Monad vs Applicative: The structure of an Applicative computation is fixed; a Monad’s structure can depend on intermediate results. That’s why (>>=) (bind) is strictly more powerful than (<*>). Prefer Applicative when you don’t need that—it can allow parallelization where monadic code cannot.
Reader, Writer, State: The (->) e reader monad gives a read-only environment; Writer accumulates a monoidal log; State s a is s -> (a,s) for stateful computations. All live in Control.Monad and the mtl library.
IO in practice: getContents does lazy I/O; interact captures the pattern of “read, transform, output.” Use withFile for handle-based file I/O. Prefer Maybe/Either in pure code and reserve exceptions for the IO part; catch with System.IO.Error.catch and predicates like isDoesNotExistError.
Haddock: Use -- | before or -- ^ after declarations; document arguments inline. Headings with -- *, -- **; link identifiers with single quotes/backticks and modules with double quotes; code blocks with @...@ or bird tracks >.

Use Bun for Shell Scripts

I published a post on using Bun for cross-platform shell scripts on Windows. Bun avoids shebang and WSL/Git-bash setup while giving a single runtime for ad-hoc commands and full scripts.

Single binary: bun build ./script.ts --compile --outfile script produces a native executable, so no shebang or interpreter is needed on Windows.
Bun Shell: Bun.$ builds shell commands from template literals (similar to zx). On Windows, Bun ships with MSYS for a consistent bash environment.
Extras: Bun.secrets for the OS keystore, built-in globs, YAML, ANSI. Fast startup (~5ms vs Node’s ~25ms for simple scripts) helps for small, frequent scripts.

Sources:

How I Estimate Work

Sean Goedecke’s post reframes estimation as a political and constraint-satisfaction problem rather than a pure “how long will this take?” question.

Context first: Gather political context before looking at code—pressure on the project, what kind of estimate the chain wants, whether this is a casual ask or a must-have.
Inversion: The job isn’t “break down work to get a duration.” It’s “find the set of software approaches that fit the timeline they already have in mind.”
If you don’t estimate: Someone less technical will estimate for you. Engaging with the process lets you steer which approaches are in scope.

Obsidian Links

What I Touched This Week 2026-02-01

me@iany.me (Ian Yang) — Sun, 01 Feb 2026 00:00:00 +0000

This journal is generated by AI

Haskell Type Classes: Functors, Applicatives, and Monoids

This week I dove deep into Haskell’s type class hierarchy, working through Learn You a Haskell and the CIS 194 course materials. The key insight is understanding how these abstractions compose to enable powerful, generic programming.- Functors are types that can be mapped over. The fmap function can be viewed as “lifting” a function: fmap :: (a -> b) -> (f a -> f b) transforms an ordinary function into one that works inside a functor context

The functor laws ensure predictable behavior: fmap id = id (identity preservation) and fmap (f . g) = fmap f . fmap g (composition preservation)
Applicatives extend functors by allowing wrapped functions to be applied to wrapped values using <*>. Lists as applicatives represent non-deterministic computations where [(+3),(*2)] <*> [1,2] produces all combinations
ZipList provides an alternative applicative instance for lists using pairwise application instead of all combinations
Monoids provide an identity element (mempty) and an associative binary operation (mappend). The foldMap function reveals why monoids matter: the identity handles empty structures and the associative operation combines values reliably
Use foldl' from Data.List instead of foldl to avoid building huge thunks; foldr is better when the folding function can short-circuit

Sources:

Using tmux for PowerShell in Windows Terminal

I published a blog post on getting tmux session persistence in Windows Terminal while keeping PowerShell as the default shell. The solution runs tmux through WSL but configures it to spawn pwsh.exe for new panes.

Create thin wrapper scripts (tmux.ps1, tmux.cmd) so tmux from Windows means wsl tmux
A helper script tmux-pwsh.ps1 creates or attaches to named sessions with pwsh.exe -nologo as the default command
The key trick: send set-option default-command via tmux -C attach because running wsl tmux set-option immediately after session creation has a race condition where the session isn’t ready
After setup, splitting panes and creating windows in that session will all start PowerShell in the Windows environment

Elite Performance Through Preparation

An insightful thread by Sandeep Palakodeti on what separates elite performers from amateurs. The core message: greatness is not about taking risks but eliminating variance through preparation.

When experts operate at their limit, they’re not “trying hard”—they’re executing scripts that have been debugged for decades through deliberate, high-fidelity repetition
Fear is the biological response to the unknown; when you’ve accounted for every variable, fear is replaced by focus
Elite performers aim below the edge of their ability because that’s where consistency lives
Every question gets answered upstream, every branch point gets a playbook—by the time the moment arrives, they’re executing state changes, not solving problems
“Don’t worship the risk. Worship the work that made the risk irrelevant.”

Obsidian Links

What I Touched This Week 2026-01-24

me@iany.me (Ian Yang) — Sat, 24 Jan 2026 00:00:00 +0000

This journal is generated by AI

Erlang State Machine Patterns in Rust

This week I created a presentation exploring how to implement Erlang OTP’s gen_statem patterns in Rust using Tokio. The core insight is that Erlang’s behavior pattern separates the engine (state machine framework) from the callback (state-specific logic), following the strategy pattern.

The fundamental state transition follows: State(S) × Event(E) → Actions(A), State(S')
Erlang’s “everything is an event” philosophy means state entry, timeouts, and internal messages are all unified as events
The enter event triggers when entering a new state, useful for running initialization logic without duplicating code across multiple transition paths
Postpone action defers events to a later state when we can’t process them yet
Timeout actions come in three flavors: event timeout (cleared on any event), state timeout (cleared on state change), and named timeout (manual clearing)
Inserted events enable preprocessing and state machine composition

The code examples progressively build from basic process simulation to full-featured state machines with all these capabilities.

BFT Consensus Protocol Comparisons

I studied the differences between PBFT, Tendermint, HotStuff, and HotStuff-2. These are all safety-preferring protocols where locked parties guard the safety of a potential commit. The key questions each protocol answers are:

What does the leader learn about system status at the start of a view?
How does the leader convince other parties about system status to get votes?

Among 2t+1 locks in a status response, up to t can be malicious, up to t can be honest but not locked on the committed value, but at least one honest party must be locked on the committed value. This honest party won’t vote for conflicting proposals, thus guarding commit safety.

HotStuff introduces an additional phase: “if some party locks, then ≥2t+1 parties know about this lock and hold a key corresponding to it.”

Sources:

What is the difference between PBFT, Tendermint, HotStuff, and HotStuff-2 by Kartik Nayak and Dahlia Malkhi
Provable Broadcast by Ittai Abraham and Alexander Spiegelman

CKB Virtual Transactions

I explored a design for implementing partial transactions in CKB through “Virtual Tx.” The approach mocks system calls so scripts access the virtual tx instead of the real current transaction.

Override syscalls in ckb-c-stdlib or ckb-std to redirect to virtual tx data
Anyone can be economically incentivized to match partial txs since fees can be provided
Use a special first input as the indicator that the tx is a vtx
The first input’s type script witness specifies how each vtx maps to tx components (inputs, outputs, etc.)
Inputs/outputs are handled exclusively, with mechanisms to tackle cell/header deps duplication

Obsidian Links

What I Touched This Week 2026-01-17

me@iany.me (Ian Yang) — Sat, 17 Jan 2026 00:00:00 +0000

This journal is generated by AI

Temporal Patterns and Bitemporality

This week I explored the concept of bitemporality and temporal patterns in data modeling. The key insight is that we need to track two dimensions of time: actual time (when something happened) and record time (when we learned about it). This becomes crucial when we need to answer questions like “what did we think the state was two months ago?” or “what did we know six months ago about something that happened earlier?”

Sources:

One for the Treble, Two for the Time by Lewis Daly
Temporal Patterns by Martin Fowler

Go Performance Optimization Techniques

I learned several advanced Go performance optimization techniques from VictoriaMetrics, a high-performance time-series database. The key strategies include using sync.Pool for object reuse to reduce GC pressure, implementing channel-based object pools for more controlled resource management, and using sharding to reduce lock contention by splitting large data structures into independent shards.

Use sync.Pool for object reuse to minimize garbage collection overhead
Channel-based object pools provide more control than sync.Pool
Sharding large data structures reduces lock contention
Localized worker pools with independent channels improve multi-core scalability
Buffered channels can serve as semaphores for rate limiting

Source: 从入门到极致：VictoriaMetrics 教你写出最高效的 Go 代码 by Tony Bai

JDK Selection Guidelines

I reviewed best practices for choosing a Java Development Kit (JDK) version and distribution. The primary recommendation is to use Adoptium Eclipse Temurin 21.

Source: Which Version of JDK Should I Use by Jochen Christ

Obsidian Links

What I Touched This Week 2026-01-10

me@iany.me (Ian Yang) — Sat, 10 Jan 2026 00:00:00 +0000

This journal is generated by AI

Learning C23: Going Behind the Curtain of Modern Systems

This week I dove deep into Paul J. Lucas’s book on learning C23, which provides a comprehensive tour of the latest C standard and why understanding systems programming at this level matters. With 133 highlights, this was clearly a major focus of my learning.

Modern C Features: C23 introduces many modern conveniences like bool, nullptr, constexpr, auto, typeof, and compound literals. The language is evolving while maintaining its core philosophy of being “close to the machine.”
East const Convention: A stylistic choice where const is placed to the right (east) of the type, making pointer declarations more readable when reading from right to left. This consistency helps with complex pointer declarations.
Type System Enhancements: New types like _BitInt for bit-precise integers, decimal floating types (_Decimal32, _Decimal64, _Decimal128), and complex number support show C’s continued evolution for specialized use cases.
Practical Systems Understanding: The book emphasizes that C was designed to work directly with machine details—understanding memory layout, alignment, and how data structures map to hardware is still valuable even when working in higher-level languages.

This connects to my broader interest in understanding how modern systems work under the hood, especially as I work with distributed systems and blockchain technology where performance and correctness matter deeply.

Time Management and Reflective Living

Arnold Bennett’s classic How to Live on 24 Hours a Day offers timeless wisdom about making the most of our daily time budget. The key insight is that we already have all the time there is—the challenge is how we use it.

The Inner Day: Bennett suggests dedicating 7.5 hours per week (about 90 minutes per evening) to cultivating your mind. This “inner day” should begin at 6 p.m. and end at 10 a.m., separate from your workday.
The Reflective Mood: What’s most lacking in modern life is the reflective mood—taking time to examine conduct against principles, to think deeply rather than just consume information. The solitude of the evening commute is perfect for this.
Slow, Deep Reading: When reading for cultivation, give at least 45 minutes to careful, fatiguing reflection on what you’re reading. Your pace will be slow, but that’s the point—the good stuff rises up to meet you in the extra time you give it.
Topic Reading with Limits: Choose a limited period, subject, or single author. Define the direction and scope of your efforts rather than reading aimlessly. Forget the goal; think only of the surrounding country, and you’ll find yourself in a lovely town on a hill.

This resonates with my experience that slowing down often yields better results than rushing, whether in reading, coding, or thinking through problems.

Formal Methods: Exploring Quint and TLA+

I’ve been exploring formal specification languages, particularly Quint, which provides a more accessible syntax for writing formal specifications compared to TLA+. This connects to my interest in distributed systems and ensuring correctness.

Quint’s Design Philosophy: Quint restricts the prime operator (') to assignments in the format <var>' = <expr>, preventing hard-to-grasp expressions while maintaining the power of temporal logic. The tooling reports errors if you misuse ' or forget to update variables in some branches.
State Machine Modeling: Actions named init and step define the state machine—init defines initial states, step defines transitions. This makes the model structure clear and checkable.
Pure Functions and Actions: Definitions prefixed with pure are functional—same input always produces same output. Actions use the prime operator to modify state. This separation helps reason about what changes state and what doesn’t.
Non-determinism: Quint supports non-deterministic definitions using any and oneOf, which can only be used inside actions before assignments. This is crucial for modeling systems with multiple possible behaviors.

The connection to TLA+ is clear—both are tools for specifying and verifying system behavior, but Quint’s more familiar syntax might lower the barrier to entry for formal methods. This is particularly relevant as I work on systems where correctness is critical.

Obsidian Links

What I Touched This Week 2026-01-03

me@iany.me (Ian Yang) — Sat, 03 Jan 2026 00:00:00 +0000

This journal is generated by AI

Training the Idea Muscle: Quantity Over Quality

This week I came across a fascinating article about training the idea muscle that perfectly captures a principle I’ve been trying to internalize: if you reject your own ideas, the part of the brain that generates them will simply stop producing.

Never Reject During Generation: The key insight is to generate ideas continuously without filtering them in the moment. You sort them out later. This is similar to the Creativity Faucet concept—you need to let the bad ideas flow out first before the good ones emerge.
Do It While Learning: “I don’t think I’ve ever done anything I’m not good enough to do because I get good at the thing while doing it.” This reframes the common fear of not being ready—you become ready by starting.
Fun as the Filter: Only work on things you think are fun. This is the real filter, not whether you’re “good enough” or whether the idea is “good enough” initially.
Ideas Require Action: Ideas are everywhere, but most people don’t act on them. The muscle being trained isn’t just idea generation—it’s the habit of execution.

This connects beautifully with The Motern Method, a book about an artist who released 23,000+ songs by embracing quantity and rejecting perfectionism.

Slowing Down to Go Deeper

David Cain’s article on default settings being too high offers a counterintuitive productivity insight: slowing down often yields better results than rushing.

Reading Aloud: Limiting yourself to mouth-speed rather than eye-speed prevents rushing through text, missing important details, and losing interest. If you’re enjoying something, why would you want to be done with it sooner?
The Vacuum Analogy: Passing a vacuum too quickly over carpet means you miss half the dirt. Slow down, and you can hear how much more grit gets picked up. The same applies to reading and eating—the good stuff (meaning in text, pleasure in food) rises up to meet you in the extra time you give it.
Quality Over Speed: This challenges the default assumption that faster is better. Sometimes our cultural “default settings” for speed are calibrated too high for actual comprehension and enjoyment.

This resonates with my experience using AI tools—the temptation is to go faster, but often the value comes from slowing down and engaging more deeply with the material.

Learning Tacit Knowledge: Copying Better

Cedric Chin’s piece on acquiring tacit knowledge from experts provides a practical framework for learning skills that can’t be easily articulated.

Four Key Elements: When observing experts, focus on their cues (what they notice first), expectancies (what they expect to happen next), goals (their priorities), and actions (courses of action that immediately come to mind).
Prototypes vs. Options: Experts rarely compare multiple options—they pick the first available option that fits their criteria because they’ve built up mental prototypes. If you find yourself doing option comparison in a situation where a colleague doesn’t, that’s a signal they have a prototype you lack.
Narrative Construction: Experts construct narratives or simulations to explain what they’re seeing, matching patterns against different prototypes. This is fundamentally different from following explicit rules.

This framework is particularly relevant for software engineering, where so much expertise is tacit—knowing when to refactor, which abstractions to choose, how to structure systems. These aren’t things you can learn from documentation alone.

Obsidian Links

What I Touched This Week 2025-12-27

me@iany.me (Ian Yang) — Sat, 27 Dec 2025 00:00:00 +0000

This journal is generated by AI

State Machines for Simplifying Complex Logic

This week I dove into using state machines as a tool for managing complex application logic. Dave Thomas’s approach in his book “Simplicity” resonated with me: state machines aren’t as complicated as people make them out to be, and they’re a great way of turning deeply nested code into nice linear chunks.

Data Over Code: The core insight is that data is easier to work with than code—it’s easier to reason about, manipulate, and change. You don’t need complex libraries or long-winded pattern-based approaches when you need a state machine; all you need is a lookup table.
State Transition Formula: The fundamental model is State(S) x Event(E) -> Actions(A), State(S'). This simple formula captures the essence of event-driven behavior in a declarative way.
Event Generation: Actions can return either new state values or generate new events. If an event is returned, the code immediately performs another transition—this allows for elegant chaining of state changes.
State Enter Calls: Erlang’s gen_statem has a powerful feature where the state callback is automatically called with special arguments whenever the state changes, making it easy to perform entry actions without cluttering transition logic.
Postponing Events: A clever pattern is the ability to postpone events—if an event arrives but shouldn’t be handled in the current state, you can defer it until a state change occurs when the event queue restarts from the oldest postponed event.

Sources:

Tokio and Async Rust Patterns

Continuing my study of async Rust, I worked through the Tokio tutorials and explored patterns for shared state and concurrent data structures.

Mutex Selection: As a rule of thumb, using a synchronous mutex from within asynchronous code is fine as long as contention remains low and the lock is not held across calls to .await. The Tokio mutex’s primary feature is that it can be held across an .await without issues, but if contention becomes a problem, the best fix is rarely to switch to the Tokio mutex.
Concurrent Hash Maps: For high-contention scenarios, there are several excellent crate options: dashmap provides a sharded hash map implementation, while leapfrog uses leapfrog probing, and flurry is a port of Java’s ConcurrentHashMap. I also discovered papaya, which is optimized for read-heavy workloads.
Async Trait Variants: The trait_variant and dynosaur crates help with async trait patterns—useful for creating both sync and async versions of traits without code duplication.
Testing with tokio-test: The tokio_test::io::Builder provides mock I/O for testing async code, making it easier to write deterministic tests for network protocols.

Source: Tokio Tutorial - Shared State

Clean Code: Maintenance as the Core of Software

I revisited Robert C. Martin’s “Clean Code” this week, and the framing around maintenance struck me differently in the AI era.

80% is Maintenance: In software, 80% or more of what we do is “maintenance”—the act of repair. Rather than the Western focus on producing good software, we should think more like home repairmen or auto mechanics: proactive maintenance rather than waiting for bugs to surface.
A Million Selfless Acts: Quality is the result of a million selfless acts of care—not just of any great method that descends from the heavens. These acts are simple but not simplistic, forming the fabric of greatness in any human endeavor.
Reading vs Writing Ratio: The ratio of time spent reading vs. writing code is well over 10:1. We are constantly reading old code as part of the effort to write new code, so making code easy to read actually makes it easier to write.
LeBlanc’s Law: “Later equals never.” We’ve all felt the relief of seeing our messy program work and deciding that a working mess is better than nothing, promising to clean it up later. This resonates especially with vibe-coded AI-generated solutions.
The Boy Scout Rule: Leave the campground cleaner than you found it. Small continuous improvements compound over time.
Clean Code Characteristics: Clean code reads like well-written prose, never obscures the designer’s intent, and is full of crisp abstractions and straightforward lines of control. It should make you smile the way a well-crafted music box or well-designed car would.

Source: Clean Code by Robert C. Martin

Obsidian Links

What I Touched This Week 2025-12-20

me@iany.me (Ian Yang) — Sat, 20 Dec 2025 00:00:00 +0000

This journal is generated by AI

The Ladder of Abstraction in System Design

Bret Victor’s “The Ladder of Abstraction” explores how to design interactive systems by moving between levels of abstraction. The core insight is that the most powerful way to gain insight into a system is by stepping up and down the ladder—abstracting over variables to see high-level patterns, then stepping down to concrete representations to understand the details.

Abstracting Over Time: Instead of watching a system evolve in real-time (which is limiting, like a film editor who can’t pause or rewind), we can abstract over time by turning time into a parameter. This creates a trajectory—a function that returns a point for any given time, showing the system’s behavior across all time values.
Stepping Up and Down: We step up to an abstraction by devising a representation that depicts the system across all values of a parameter. We step down by interactively selecting one particular value, allowing us to explore regions of interest quickly. This corresponds to partial application in functional programming.
Visual vs. Symbolic Abstractions: The human brain excels at pattern matching with visual patterns but struggles with logical inferences. Visual abstractions leverage our natural strengths, making it easier to see high-level patterns and tune out low-level clutter.
Metrics and Patterns: By choosing metrics—numbers that summarize system behavior in interesting ways—we can step up another level of abstraction. For example, plotting time to completion versus turning rate reveals patterns that aren’t visible in individual trajectories.
Starting Simple: Beginning with the simplest possible algorithm and thoroughly exploring it helps us understand why and how it’s terrible, providing the foundation for better solutions. The tools we build for simple cases continue to serve us throughout the design process.

Source: The Ladder of Abstraction

AI Investment Bubble and Infrastructure Economics

Howard Marks examines whether AI is experiencing a financial bubble, distinguishing between technological hype and actual market bubbles. His analysis reveals the complex economics of AI infrastructure investment and the risks of debt-financed expansion.

Bubbles vs. Technological Progress: Market bubbles aren’t caused directly by technological developments but by excessive optimism applied to those developments. However, Marks notes that “inflection bubbles” based on revolutionary developments can accelerate technological progress while still destroying wealth—they’re both collective delusions and expressions of collective vision.
The Compression Effect: If people remained patient and value-insistent, novel technologies would take decades to build out. The hysteria of bubbles compresses this process into a short period, with some money going to life-changing investments in winners but a lot being incinerated.
Circular Capital Flows: OpenAI receives billions from tech companies but also sends billions back to pay for computing power. Nvidia’s $100 billion investment in OpenAI flows back as the startup buys or leases Nvidia’s chips, creating circular capital flows that raise questions about actual value creation.
Debt-Financed Expansion: Major tech companies (Oracle, Meta, Alphabet) have issued 30-year bonds to finance AI investments. With close to half a trillion in expected spending next year but only $350bn collectively in the bank, heavy debt usage creates risks of overcapacity and depressed returns.
The Scale of Trillions: A trillion dollars is a dollar a second for 31,700 years—a scale that’s difficult to comprehend but represents the magnitude of AI infrastructure investment being discussed.

Source: Is It A Bubble

Becoming AI-Native in Daily Workflows

Jeff Su’s video provides practical strategies for integrating AI into daily work, moving beyond simple prompting to building sustainable AI-native workflows that anchor conversations, leverage swipe files, and strategically allocate tasks between AI and manual work.

Anchoring Important Conversations: If an AI conversation takes more than 10 minutes or produces something you’ll reference again, anchor it to your workspace immediately. This creates a searchable archive of valuable AI interactions and outputs.
AI Swipe Files: Create a dedicated folder for good examples—business proposals, code patterns, writing samples—that AI can reference. Instead of starting from scratch, you open your swipe folder to find examples that guide AI toward the quality and style you want. This acts as a curated reference library for AI.
Task Breakdown and Allocation: Before writing anything, break work into steps and microtasks. Then decide whether each microtask should be done manually or with AI, and specify the exact tool best suited for that task. For projects taking more than an hour, spend 5-10 minutes mapping steps and tagging which are AI or manual.
Battle-Tested Prompts: You don’t need a thousand random prompts—you need 10-15 battle-tested ones that you can use every day. Focus on quality and refinement rather than quantity.

Sources: Give Me 9 Minutes, I’ll Make You AI-Native

Obsidian Links

What I Touched This Week 2025-12-13

me@iany.me (Ian Yang) — Sat, 13 Dec 2025 00:00:00 +0000

This journal is generated by AI

This week I dove deep into Pieter Hintjens’ “Social Architecture,” a comprehensive guide to building sustainable open source communities. The book provides a framework for understanding how successful communities function, with direct relevance to my work on CKB Fiber and other open source projects.

The C4 Process: An evolution of the GitHub Fork + Pull Model that emphasizes problem-first thinking. All patches must start by identifying a clear problem before proposing solutions. This creates a culture where contributors focus on real needs rather than speculative features.
Optimistic Merging: Maintainers should merge patches rapidly, even if imperfect. This creates opportunities for mentoring—when a patch needs work, other contributors naturally step in to help, building relationships and improving code quality through collaboration rather than gatekeeping.
Free Entry and Non-Tribalism: Successful communities welcome competition and experimentation. If starting a competing project gets a negative emotional response, the group is too tribal. Healthy communities applaud new competitors as spaces for learning and innovation.
The 20 Principles: From strong mission and transparency to minimalism and sense of humor, Hintjens identifies key characteristics of thriving communities. Particularly resonant: “Perfection precludes participation”—releasing buggy, half-finished work provokes contributions more effectively than polished releases.
Economic Incentives: We’re economic animals, and architecture must provide economic incentive to invest. Whether it’s reputation, money, or skill development, contributors need clear value propositions. Think of architecture as a marketplace, not just an engineering design.

Source: Social Architecture

AI-Assisted Development and Learning

Multiple articles this week explored how to effectively use AI as a development and learning partner, moving beyond simple code generation to more sophisticated workflows.

Learning with AI: Scott Young emphasizes using AI for book recommendations and practice problem generation rather than summaries. AI tutoring works better than teaching because specific questions constrain answers more effectively. For repetitive learning tasks, building applications can be more consistent than repeated prompting.
Agent Design Challenges: Armin Ronacher highlights that differences between models are significant enough that you’ll likely need custom abstractions. Key insights include using static system prompts with dynamic messages for caching, and hiding execution failures from context by running potentially failing tasks in subagents until they succeed.
CLAUDE.md Best Practices: Kyle Mistele recommends keeping CLAUDE.md under 300 lines (ideally under 60), with task-specific instructions in separate markdown files. Most importantly: “Never send an LLM to do a linter’s job”—use deterministic tools whenever possible since LLMs are expensive and slow compared to traditional tooling.

Additionally, Ed sent me an email to introduce his app, Grasp, which I found impressively aligned with these best practices and strategies from the past two weeks’ articles.

Sources:

Git Workflow Improvements

I published a blog post about backing up ignored files using Git remote branches, solving a problem I’ve had for years. The solution uses Git’s low-level plumbing commands to store ignored files (like local configs, IDE settings, or personal scripts) in a separate remote branch without affecting the main branch or working directory.

The Problem: Files that need backup but shouldn’t be in main branch history—local development settings, IDE configurations, personal notes, or workflow-specific scripts.
The Solution: A git-store-file script that uses a temporary Git index to commit ignored files to a remote branch (default: origin/_store). This keeps everything in one repository while maintaining clear separation.
Technical Approach: Uses GIT_INDEX_FILE for isolated index manipulation, git read-tree to load branch state, git add -f for ignored files, and git commit-tree for direct commit creation—all without touching the working directory.

Source: ♯ Backup Ignored Files with Git Remote Branch

Obsidian Links

What I Touched This Week 2025-12-06

me@iany.me (Ian Yang) — Sat, 06 Dec 2025 00:00:00 +0000

This journal is generated by AI

Fuzzing Strategies from TigerBeetle

This week I dove deep into TigerBeetle’s fuzzing philosophy through several articles by Aleksey Kladov. The collection reveals a systematic approach to building testable systems from the ground up.

Design for Fuzzability First: You don’t build a system and then add a fuzzer—the process is almost reversed. Start by sketching minimal interfaces that yield themselves to efficient fuzzing. Minimize the interface by eliminating accidental dependencies and leaving only essential ones.
Data-Oriented Design: Apply data-oriented design principles—think in terms of input data, output data, and the fundamental data transformation the system implements. This makes the code more easily fuzzable.
Four Fuzzer Strategy: Use multiple fuzzing approaches: (1) positive space fuzzing with ideal lab environments to verify correctness, (2) negative space fuzzing calling all public methods in random order to break things, (3) boundary testing for valid vs. almost-valid-but-invalid codes, and (4) whole subsystem fuzzing.
Randomness in Tests: Don’t always use hard-coded seeds. Zig’s approach is best—provide std.testing.random_seed that’s different per run but generated outside the test process. Run tests twice: once with a hard-coded seed for regression testing, and once with a truly random seed for coverage.

Sources:

Lightning Network Mobile Nodes and Self-Custody

Stephen DeLorme’s article on Lightning self-custody and mobile nodes provided valuable insights into the future of Bitcoin payments, with direct relevance to my work on CKB Fiber.

Mobile Receiving Nodes: For receiving-only nodes, you don’t need routing, meaning you don’t need all that database storage. This was pioneered by projects like Breez, Phoenix, Mutiny wallet, Blixt, and newer versions of Zeus.
Offline Payments Problem: Even the sharpest performing mobile lightning wallets suffer from a lack of offline payments, which has severely tarnished the perception of Lightning. BIP-353 user names distributed via DNS and recent LDK PRs for async payments are addressing this.
Capital Efficiency: Splicing is a powerful tool for easing capital constraints for LSPs. The option_zero_reserve allows channel partners to choose not to use a channel reserve balance—great for UX, though it requires solving minimal capacity restrictions (relevant for CKB Fiber).
Graduated Wallet Model: A wallet that begins with a custodial service or trust-minimized technology, then graduates to a Lightning channel when the balance grows to a certain threshold. This helps LSPs avoid opening “non-productive” channels to users just experimenting with the app.
Dust Limit Considerations: Amounts below the dust limit (like a 21 sat Nostr zap) wouldn’t be claimable on-chain anyway, suggesting alternative approaches for micro-transactions.

Source: Lightning Self-Custody Works: Why Mobile Nodes Are the Future of Bitcoin

Think First, AI Second

Ines Lee’s article on using AI as a thinking partner rather than a solution generator resonated deeply with my own experience using AI tools.

Active vs. Passive AI Use: Active AI use means building understanding while collaborating with the model. Frame the problem yourself, make an initial pass, then use AI to challenge assumptions, uncover blind spots, and sharpen arguments. Studies show this approach maintains cognitive engagement even while using AI.
AI as Coach, Not Cheerleader: Shift AI from talking to you about your work (where it’s sycophantic) to talking to other editors about your work (where it’s professionally candid). You’re no longer the audience, so it drops the protective politeness.
Combat Illusion of Understanding: AI explains things in ways that are easy to follow, making us susceptible to the “illusion of understanding.” We overestimate what we’ve learned. Real comprehension emerges when forced to articulate thinking, because explaining reveals gaps we didn’t know existed.
Practical Prompts: Use prompts like “Ask exactly 5 high-leverage questions before proposing solutions,” “Act as an editor recommending whether to publish this piece,” “Analyze my reasoning and create an architecture of my thinking,” “Switch to devil’s advocate mode and dismantle my thesis,” and “Ask me to explain this as if teaching it to someone else.”

Source: Think First, AI Second

Obsidian Links

What I Touched This Week 2025-11-29

me@iany.me (Ian Yang) — Sat, 29 Nov 2025 00:00:00 +0000

This journal is generated by AI

Software Design Insights from TigerBeetle

This week I went deep into several articles from Alexey Kladov (matklad) and TigerBeetle’s engineering blog. The collection offers practical wisdom on building robust systems.

Code Review Workflow: Instead of reviewing diffs in a web UI, pull the branch locally, soft-reset to the base, then navigate through the diff using magit. Use the git staging area to mark files you’ve reviewed—treating the review process like authoring the code yourself.
Clockless Time Tracking: Rather than injecting a Clock dependency, push time into the system at fixed cadence via a tick method. For single-instant needs, use Call Site Dependency Injection by passing now: Instant directly to methods.
Write Last, Read First: When dealing with systems of record (source of truth) and systems of reference (derived data), write to the system of reference first, then write to the system of record last. Read in reverse order. This maintains application-level consistency.
Function Shape Matters: Functions should have an “inverted hourglass” shape—large implementations relative to their interfaces. Hourglass-shaped functions (small body, large interface) are a code smell. The 100-column limit exists so you can fit two files side-by-side on modern displays. Functions should fit on a screen (~60-70 lines).

Sources:

Self-Consistency Over Self-Discipline

An essay on achieving a good life without rigid self-discipline (“谈谈不自律的良好生活”) resonated with me this week. The author argues for balance over brute-force willpower.

Balanced Love: Drawing from Fromm’s The Art of Loving, healthy self-regard requires combining unconditional and conditional love. Pure unconditional love becomes indulgence; pure conditional love becomes self-attack.
Understanding Over Judgment: When you break a diet for your favorite ice cream, the productive response isn’t self-criticism—it’s understanding why you acted that way. Change requires awareness, care, creativity, and patience rather than pure constraint.
Goals as Direction: Goals shouldn’t be used to judge or lock down your future. A proper goal is merely a direction—like pointing at a distant peak and saying “I want to go there.” This supports Don’t Set a Goal For 2026 Until You Watch This.
Life’s Balance: Abstract learning (philosophy) without grounding becomes detached from life’s simple pleasures. All socializing without solitude leaves no room for reflection and creativity. Life needs all five flavors, both meat and vegetables.

Source: 谈谈不自律的良好生活

Effective Reading Strategies

A practical guide on retaining what you read offered some actionable techniques worth implementing.

Preview First: Spend 5-10 minutes per chapter skimming the table of contents, headings, introduction, and summary before diving into details. This builds a mental scaffold.
Question-Driven Reading: Before reading a section, convert the heading into a question (e.g., “What is X?”) and read to find the answer. This active approach improves engagement and retention.
Concise Personal Notes: Rather than transcribing passages verbatim, write brief paraphrases or bullet points in your own words. The act of reformulation strengthens memory.

Source: How to Remember Everything You Read

~iany/ Ai Generated

What I Touched This Week 2026-03-30

Convincing vs Persuading in Technical Work

Scale-First AI Thinking and Mental Models

Boring Tech, Better Practices, and Tooling Leverage

Obsidian Links

What I Touched This Week 2026-03-21

Software Maintenance and the Specification Problem

AI Agents and the Harness

Simplifying Life Through Lifestyle Design

Obsidian Links

What I Touched This Week 2026-02-07

Haskell: Typeclassopedia, IO, and Documentation

Use Bun for Shell Scripts

How I Estimate Work

Obsidian Links

What I Touched This Week 2026-02-01

Haskell Type Classes: Functors, Applicatives, and Monoids

Using tmux for PowerShell in Windows Terminal

Elite Performance Through Preparation

Obsidian Links

What I Touched This Week 2026-01-24

Erlang State Machine Patterns in Rust

BFT Consensus Protocol Comparisons

CKB Virtual Transactions

Obsidian Links

What I Touched This Week 2026-01-17

Temporal Patterns and Bitemporality

Go Performance Optimization Techniques

JDK Selection Guidelines

Obsidian Links

What I Touched This Week 2026-01-10

Learning C23: Going Behind the Curtain of Modern Systems

Time Management and Reflective Living

Formal Methods: Exploring Quint and TLA+

Obsidian Links

What I Touched This Week 2026-01-03

Training the Idea Muscle: Quantity Over Quality

Slowing Down to Go Deeper

Learning Tacit Knowledge: Copying Better

Obsidian Links

What I Touched This Week 2025-12-27

State Machines for Simplifying Complex Logic

Tokio and Async Rust Patterns

Clean Code: Maintenance as the Core of Software

Obsidian Links

What I Touched This Week 2025-12-20

The Ladder of Abstraction in System Design

AI Investment Bubble and Infrastructure Economics

Becoming AI-Native in Daily Workflows

Obsidian Links

What I Touched This Week 2025-12-13

Social Architecture and Open Source Community Building

AI-Assisted Development and Learning

Git Workflow Improvements

Obsidian Links

What I Touched This Week 2025-12-06

Fuzzing Strategies from TigerBeetle

Lightning Network Mobile Nodes and Self-Custody

Think First, AI Second

Obsidian Links

What I Touched This Week 2025-11-29

Software Design Insights from TigerBeetle

Self-Consistency Over Self-Discipline

Effective Reading Strategies

Obsidian Links