Write with your ears instead of eyes, Programming is not about code, Why Palantir only has one title for all engineers

Weekly I/O #102: Write with Ears not Eyes, Programming as Theory Building, Only One Title for Engineers, Growth Imperative, Love and Work

Jun 08, 2025

This week's edition of the newsletter is free to everyone! But if you'd like full access to more posts like this and all the Weekly I/O archives, consider subscribing!

Hi friends,

I listened again to Acquired's Meta episode and read Morris Chang (founder of TSMC) autobiography this week. Oh boy, they really show resilience. Highly recommend!

I'm also thinking of sharing a list of assorted links every week of what I found worth reading/listening to. Let me know if you are interested!

Input

Here's a list of what I learned this week.

1. C. S. Lewis writing advice: Turn off the Radio. Always write with the ear, not the eye. You should hear every sentence you write as if it were being read aloud or spoken.

Book: Letters of C. S. Lewis

Here's what C. S. Lewis advised about writing in 1959:

It is very hard to give any general advice about writing. Here’s my attempt.
Turn off the Radio.
Read all the good books you can, and avoid nearly all magazines.
Always write (and read) with the ear, not the eye. You should hear every sentence you write as if it was being read aloud or spoken. If it does not sound nice, try again.
Write about what really interests you, whether it is real things or imaginary things, and nothing else. (Notice this means that if you are interested only in writing you will never be a writer, because you will have nothing to write about. . . .)
Take great pains to be clear. Remember that though you start by knowing what you mean, the reader doesn’t, and a single ill-chosen word may lead him to a total misunderstanding. In a story it is terribly easy just to forget that you have not told the reader something that he wants to know—the whole picture is so clear in your own mind that you forget that it isn’t the same in his.
When you give up a bit of work don’t (unless it is hopelessly bad) throw it away. Put it in a drawer. It may come in useful later. Much of my best work, or what I think my best, is the re-writing of things begun and abandoned years earlier.
Don’t use a typewriter. The noise will destroy your sense of rhythm, which still needs years of training.
Be sure you know the meaning (or meanings) of every word you use.

I found his "Turn off the Radio", and "Write (and read) with the ear" advice very intriguing. That might explain why I prefer listening to the same few music albums when doing my creative writing.

"Be sure you know the meaning (or meanings) of every word you use." also resonates with one of my writing rules: Don't use words I cannot pronounce.

2. Programming is not about writing code but about building a theory as a comprehensive mental map of how the pieces fit and why they matter. A program dies when the original team processing the theory leaves because new developers cannot construct that theory from code and artifacts.

Paper: Peter Naur, Programming as Theory Building

Why do some software projects thrive over time while others collapse under their own weight?

Peter Naur states that the fundamental nature of programming is not the creation of source code or documentation, but rather the construction and maintenance of an evolving "theory of the program" shared within the minds of the people working on it.

This theory is a mental map constructed through fixing bugs, developing features, and debating design tradeoffs. Developers learn how the pieces fit and why they matter so they can use this theory to predict how the software behaves, solve new problems, and make reasonable modifications.

The code and other artifacts are merely written representations of this theory. They are secondary products and are inherently "lossy". Therefore, the complete theory cannot be rebuilt solely from these artifacts.

This explains why software projects collapse. A program dies when the team possessing its theory is dissolved. While the software might continue to run, its death becomes inevitable when modifications or extensions are needed. A new team lacking the original theory will eventually cause changes that diverge from the original intent. To extend a program's life, new developers must build their own theory by working closely with existing developers.

To save "dead" programs, it might be more effective to discard all existing codes and solve the problem from scratch, rather than attempting a difficult, frustrating, and time-consuming effort to rebuild a theory for an existing, potentially obscure program text.

Seeing programming as theory building resembles how Deutsch and Popper think knowledge is from guesses we invented as theories and the process of turning mental construct into code resembles how writing is the process of encoding a web of ideas into a string of words using a tree of phrases.

The concept of the lifecycle of software projects also reminds me of Ted Chiang's novella The Lifecycle of Software Objects, which I've briefly noted here.

3. When titles become goals, workers chase labels rather than mission success. Palantir uses a single title for all engineers to keep focus on outcomes instead of promotions.

Article: Reflections on Palantir

Goodhart's Law states that "when a measure becomes a target, it ceases to be a good measure". This happened in big companies, where promotions meant launching shiny new products with your name on them, even if the products confused users.

The metric is launching new things, not user value. So people steer their efforts to win the metric. Because the badge of Product Lead mattered more than product quality, titles became trophies that caused a company to drift from its mission.

Palantir tried a simple fix. Apart from the CEO and a handful of directors, everyone was called a forward deployed engineer. No senior, principal or vice president badges to chase.

Need someone to lead a critical project? The role belonged to whoever earned trust through results. If you slip in performance, someone else could step in. The absence of ladders made politics less rewarding. If you wanted recognition you had to ship good code or solve a hard client problem.

The policy was not perfect. People still sought influence by bonding with leaders. However, the flat hierarchy made it hard to rest on status. You always had to earn your place in the company and earn the right to work on what you were working on.

Roles remained fluid, and the absence of titles became a quiet guardrail nudging efforts toward merit and away from mimetic status envy.

4. Growth imperative in modern economies is a hidden rule that forces everyone to chase bigger output or face decline otherwise. Competition, innovation, and social expectations turn growth from a choice into a necessity, across governments, firms, households, and even at the individual level.

Paper: Growth imperatives: Substantiating a contested concept

Why do even successful companies feel restless? If a successful mid-sized phone maker skips the next big upgrade, its competitors will take its customers, and its workers will start to leave. The company must pour earnings back into research and bigger factories just to stay in place.

Growth imperative is a fundamental principle embedded in modern capitalist economies, describing the systematic necessity for continuous economic growth.

The phone maker example demonstrates the growth imperative at the firm level. At the micro level, households feel a similar pressure. A worker must buy a laptop and better internet to keep a job that demands remote meetings. Falling behind on these efficiency purchases can risk unemployment or social exclusion.

At the macro level, governments must chase more output new industries, and ever-faster innovation to protect employment and social stability because, each year, rising labor productivity means the same tasks need fewer people. Without matching economic growth, jobs vanish and tax revenue drops, straining welfare budgets.

Across all three levels, the same pattern appears: survive by expanding resource use and capital or face existential costs.

Potential solutions to the growth imperative include degrowth, although I have yet to see a clear implementation path."

Some people also apply the growth imperative at the personal level. Bill Bain, founder of one of the most prestigious consulting firms in the world Bain & Company, introduced Morris Chang to the Experience Curve concept at Boston Consulting Group (BCG).

When leaving BCG in 1973, resigning as vice president to found Bain & Company, Bain was asked by Morris Chang why he wanted to leave. Bain replied: "We all have a growth imperative".

5. "Love and work, work and love, that's all there is." — Sigmund Freud

Quote.

You can categorize things as either love or work. All there in life is love and work, and nothing else.

Recap

Try answering these five simple questions to review and reinforce what you've learned:

Thanks for reading!

One small favor: please share which input you found the most helpful or intriguing! Just comment on Substack with a number!