Reading Log

by Kurt Pan

They're a refuge from the GDPR cookie banners, the trashy ads, the email opt-ins, and the god-forsaken auto-play video.

A text-only webpage is clean. It's readable. It's fast and it's simple.

You've probably lost some engagement by keeping things so clean, but you're contributing to a simple, calm, and happier internet.

The fear that being the one who always initiates makes you weak. Think about it, when was the last time you were annoyed that someone reached out to check in? When did you ever think less of someone for being the one to text you? Never. Because connection isn't about scorekeeping. It's about courage.

The fence isn't there. It never was. It's just the memory of some childhood rejection, some social rule someone made up, some fear that caring more makes you matter less. Here's the truth: The person who reaches out first isn't the weak one.

Your breakthrough isn't on the other side of productivity or success or self-improvement. It's on the other side of that text you're not sending. That call you're not making. That “I miss you” stuck in your throat.

If software design is how you assemble lines of code, system design is how you assemble services. The primitives of software design are variables, functions, classes, and so on. The primitives of system design are app servers, databases, caches, queues, event buses, proxies, and so on.

Good system design is not about clever tricks, it’s about knowing how to use boring, well-tested components in the right place. I’m not a plumber, but I imagine good plumbing is similar: if you’re doing something too exciting, you’re probably going to end up with crap all over yourself.

The most elegant solution here is Haskell’s map words $ lines text

Here, your program is constructed left to right.

There’s a principle in design called progressive disclosure. The user should only be exposed to as much complexity as is neccessary to complete a task. Additionally, complexity should naturally surface itself as it is relevant to the user. You shouldn’t have to choose a font family and size before you start typing into Word, and options to change text wrapping around images should appear when you add an image.

Remember that LinkedIn is a website owned by Microsoft, trying to make money for Microsoft, based on time spent on the site. Nothing you post there is going to change your career. Doing work that matters might. Drawing attention to that might. Go for depth over frequency.

If writing online matters to you, you’re probably better off starting a blog and building things there. You’ll get less views and less engagement but there’s less temptation to post nonsense just for likes.

The average European household now spends close to €700 (£600) a year on three or more VOD subscriptions. People pay more and get less.

Piracy is back, just sailing under a different flag. Studios carve out fiefdoms, build walls and levy tolls for those who wish to visit. The result is artificial scarcity in a digital world that promised abundance. As the streaming landscape fractures into feudal territories, more viewers are turning to the high seas.

There are two reasons founders resist going out and recruiting users individually. One is a combination of shyness and laziness. They'd rather sit at home writing code than go out and talk to a bunch of strangers and probably be rejected by most of them. But for a startup to succeed, at least one founder (usually the CEO) will have to spend a lot of time on sales and marketing. The other reason founders ignore this path is that the absolute numbers seem so small at first. This can't be how the big, famous startups got started, they think. The mistake they make is to underestimate the power of compound growth.

Almost all startups are fragile initially. And that's one of the biggest things inexperienced founders and investors (and reporters and know-it-alls on forums) get wrong about them. They unconsciously judge larval startups by the standards of established ones. They're like someone looking at a newborn baby and concluding “there's no way this tiny creature could ever accomplish anything.”

The big danger is that you'll dismiss your startup yourself. I've seen it happen. I often have to encourage founders who don't see the full potential of what they're building.

I have never once seen a startup lured down a blind alley by trying too hard to make their initial users happy.

Sometimes the right unscalable trick is to focus on a deliberately narrow market. It's like keeping a fire contained at first to get it really hot before adding more logs.

Any startup that could be described as a marketplace usually has to start in a subset of the market, but this can work for other startups as well. It's always worth asking if there's a subset of the market in which you can get a critical mass of users quickly.

Some startups could be entirely manual at first. If you can find someone with a problem that needs solving and you can solve it manually, go ahead and do that for as long as you can, and then gradually automate the bottlenecks. It would be a little frightening to be solving users' problems in a way that wasn't yet automatic, but less frightening than the far more common case of having something automatic that doesn't yet solve anyone's problems.

But with GPT-assisted coding, I think we’re in an era where you can just stop after the first part. You can do something that doesn’t scale — and leave it that way. That might actually be the best version of it. I don’t feel the pressure anymore for every project to be “a business.” If it works for me — or a tiny circle of people I care about — that’s enough.

Some things work precisely because they’re small. See a need that matters to you. Build the smallest, simplest thing that solves it. Resist the urge to make it bigger. Enjoy it. Scaling used to be the point. Now, small can be the point. AI tools make it cheap to create software for an audience of one — and sometimes, that’s the best possible audience.

It’s the freedom to stop. To make something small, useful, and perfectly yours, and not feel obligated to grow it until it collapses under its own weight. In a world obsessed with scale, there’s a quiet satisfaction in leaving good enough alone.

A research statement describes your accomplishments and sketches your research plans.

Keep your audience in mind. What do they care about? What technical language do and don’t they understand?

What thread unites all the projects you’ve undertaken? Cast the key projects in the form of a story—a research program. What vision underlies the program?

Writing is rewriting, a saying goes.

I gave all my Apple wealth away because wealth and power are not what I live for. I have a lot of fun and happiness. I funded a lot of important museums and arts groups in San Jose, the city of my birth, and they named a street after me for being good. I now speak publicly and have risen to the top. I have no idea how much I have but after speaking for 20 years it might be $10M plus a couple of homes. I never look for any type of tax dodge. I earn money from my labor and pay something like 55% combined tax on it. I am the happiest person ever. Life to me was never about accomplishment, but about Happiness, which is Smiles minus Frowns. I developed these philosophies when I was 18-20 years old and I never sold out.

LLMs get endlessly confused: they assume the code they wrote actually works; when test fail, they are left guessing as to whether to fix the code or the tests; and when it gets frustrating, they just delete the whole lot and start over.

Software engineers test their work as they go. When tests fail, they can check in with their mental model to decide whether to fix the code or the tests, or just to gather more data before making a decision. When they get frustrated, they can reach for help by talking things through. And although sometimes they do delete it all and start over, they do so with a clearer understanding of the problem.

Partly because Framework has gone with the AMD Ryzen AI Max 395+, which is technically a laptop CPU.

It's a solid 40% faster than the M4 Max and 50% faster than the M4 Pro!

Turns out the best productivity system is the one you actually use.

Simple beats sophisticated every time.

I want some of you to read my article then ask me to speak at your conferences. Many folks rely on ad impressions to support the high-quality content they’re putting out for free.

I don’t write these posts for VC-funded LLMs to come along and gobble up and produce some shitty facsimile, or summarise what I’m saying with none of the nuance or context on someone else's website.

Supporting a technology being developed only if it's open source. Open source improves equality of access. Open source improves equality of access to being a producer. Open source improves verifiability. Open source removes opportunities for vendor lock-in.

The biggest reason why is that I am generally skeptical that, especially in the modern world, trustworthy gatekeepers truly exist.

The value of openness is (i) ensuring that it's more democratized (eg. usable by many countries instead of just one), and (ii) increasing the accessibility of information, so people can more effectively form their own judgements of whether or not what is being done is effective and safe.

Most fundamentally, I see open source as the strongest possible Schelling point for how technology can be done with less risk of concentrating wealth and power and asymmetric information.

The third option – focusing less on rate of progress, and more on style of progress, and using a norm of expecting open source as an easily legible lever to push things in a better direction – is an underrated approach.

When this libertarian hears about this proposal for an efficient and robust, but unfree, society, they are making a realization that, actually, efficiency and robustness are analogous to material in chess: an important part of winning the game, but not the only part.

Cryptocurrency enthusiasts will often say that they want to improve global finance accessibility, create trustworthy property rights, and solve all kinds of social problems with blockchains. But if you show them a way to solve the same problem without any blockchain at all, they always seem a little too enthusiastic to come up with reasons why your plan would break, perhaps because it's “too centralized” or it “doesn't have enough incentives”.

I would argue that this is basically the failure mode that we need to watch out for: elevating something to being an end-in-itself when it isn't, in a way that ends up greatly harming the underlying goals.

Principles as a tool for coordination.

Principles, not ideology. The subtle difference between these two terms is that principles tend to be limiting, whereas ideology tends to be totalizing. That is, principles give you some set of things to do or not do, but then stop there, whereas there is no limit to how far you can follow an ideology.

My favorite period of history is the 30- to 40-year span between the end of the 19th century and the early innings of the 20th century. It was an era of incredible change.

Great history books remind us that while history never repeats itself, its themes never stop rhyming, and we would all do well to listen with open ears.

Critics and novelists considered technological speed to be a vice, and they warned that our lust for celerity might turn into literal lust; that cars and bicycles would beckon us into carnal sin.

Neurasthenia seemed to disproportionately affect white-collar workers, who were “overwhelmed” by their labor. “Overwork was a common theme in patients’ histories.”

What we call Modernism today was in most cases a reaction to modernity. It was an effort to excavate something ancient and honest about humanity in an age obsessed with and overrun by novelty.

Weber wrote that modern capitalism evolved from religious doctrines that fit our nature, while Freud argued that human nature is unfit for a modern world that distorts and represses our basic urges.

They want some trustworthy authority to change the way they think until they become perfect, and then to assign them to their role in the grand plan to save humanity. They’re disappointed to discover a community made of mere mortals, with no brain tricks you can’t get from Statistics 101 and a good CBT workbook, whose approach to world problems involves a lot fewer grand plans and a lot more muddling through.

Paradoxically, the desire to ignore the experts can make rationalists more vulnerable to a charismatic leader.

Try to do things where there is some external gauge of whether you’re succeeding at them or not. Similarly, try to test your beliefs against reality.

Maintain multiple social groups. Ideally, have several friends who aren’t rationalists.

Keep your work, housing, and therapy separate.

Give it a lot of input. The more input you give it, the better its output is.

It's surprisingly good at UI design given that it's mainly a text model.

claude -p "Read the SPEC.md file and implement it"

I tell it to keep things simple, stay away from frameworks, and just write raw SQL. In the broken version, I let it do whatever it wants.

A key is writing a clear spec ahead of time, which provides context to the agent as it works in the codebase. Having a document for the agent that outlines the project’s structure and how to run e.g. builds and linters is helpful. Asking the agent to perform a code review on its own work is surprisingly fruitful. Finally, I have a personal “global” agent guide describing best practices for agents to follow, specifying things like problem-solving approach, use of TDD, etc.

Enter your email to subscribe to updates.