<h2>Reading notes: Emily Oster</h2>
Reactions to various of Prof. Oster's recent newsletters:
<ul>
<li>
<a href="https://www.parentdata.org/p/what-to-do-when-whats-best-is-impossible">Here</a> she argues that we need to do more thinking about, and be more accepting of, second-best outcomes. This seems obviously right, and parenting discourse is a locus of "anything that's not the best is unacceptable" thinking. I think there's another essential point here, though: advice about what's best is usually domain-relative. Your lawyer gives you legal advice: what's best from that perspective might not be best for your life overall. Similarly for everyone else giving advice. This comes up even within domains: what's best for your knee injury might not be best for your cardiovascular health. The reason we can't get the best outcome isn't so much because we're fallible (though we certainly are!), but because that best outcome is also a not-best outcome when viewed from other perspectives. The hard part is accessing and evaluating from the all-things-considered perspective. Almost nobody is incentivized to help you with that. Good luck.
</li>
<li>
<a href="https://www.parentdata.org/p/why-i-look-at-data-differently">Here</a> Oster gives us her take on econometrics. This is one of my favorite Oster posts ever, in part because it reminds us that there's no getting away from epistemology, even when formal methods can make us think that certain kinds of judgment are no longer necessary.
</li>
<li>
<a href="https://emilyoster.substack.com/p/q-and-a-smartphones-and-mental-health">Here</a> is a discussion of smartphones and mental health. The first-order point here is that everything Oster says about the paper itself seems to be correct and useful, and I'm glad she has her eye on it. The meta-level / "how to read Emily Oster" point is that <a href="https://technosapiens.substack.com/cp/122246027">the related article she praises as "excellent"</a> seems to exhibit some of the epistemic problems that The Zvi lays out <a href="https://thezvi.substack.com/p/the-kids-are-not-okay">here</a>. (The Zvi is indeed excellent on this and many other subjects, FWIW.) In general, if you read media that Emily Oster recommends because you think it will be excellent in the same way Oster's work is excellent, you will often be disappointed.
</li>
</ul>

Reading notes: Emily Oster

<h2>Reading notes: The Sorrows of Young Werther</h2>
<ol>
<li>I note with embarrassment that this is the first German novel I've ever finished. (If memory serves.)</li>
<li>Of every novel I've ever read, this might be the hardest to read as intended, or as its original audience would have read it. In 2023, Werther is hard to see sympathetically.</li>
<li>It's also hard not to read him as adolescent, in a way that's probably anachronistic. (Consider: "My days are as happy as those reserved by God for his elect; and, whatever be my fate hereafter, I can never say that I have not tasted joy,—the purest joy of life.") And thinking of Werther as adolescent is where I come closest to liking him.</li>
<li>My favorite passages are where the narrator gives general remarks about human nature. (Consider: "In this world one is seldom reduced to make a selection between two alternatives.") This is rarely what I like best in a good book.</li>
<li>These days I'm often thinking about which "classic" books are more and less often read relative to their fame. War and Peace is famously long and challenging, but I'm rarely surprised to discover that someone I know has read it. I can't remember the last time someone of my acquaintance talked about reading any Goethe, or specifically The Sorrows of Young Werther. The book that makes me most curious in this regard is Balzac's The Human Comedy. It's quite famous and quite influential--just read what Rodin said about him!--yet I cannot name a single person whom I'm confident has read it. (I read the first bit of it, and it was both wonderful and accessible.)</li>
</ol>

Reading notes: The Sorrows of Young Werther

<h2>Reading notes: Cruciverbalism</h2>
This feels like a book I would have checked out of the games section of the library as a 12-year-old (in 1995), in the best way. It is not available electronically. This sort of extremely opinionated book about a sport, game, or puzzle can often be very good.
<ol>
<li>The lists of crosswordese are useful enough, but the Wikipedia lists are better for serious students.</li>
<li>The anti-Eugene-Maleska rant (really, a throughline) is a highlight, and also a window into the history of the New York Times.</li>
<li>Now that I've read that editors look for clues that seem hard but are actually easy, it seems obvious. (And it enriches the solving experience to know that "fake-hard" clues exist and to guess which ones they are.)</li>
</ol>
Recommended.

Reading notes: Cruciverbalism

<h2>The state of the site</h2>
This site is now made with <a href="https://nextjs.org/">Next.js</a> and hosted on Netlify.
For over a year I used my <a href="notes-on-writing-a-static-site-generator.html">own hand-crafted SSG</a>. It was really nice. But:
<ol>
<li>I wanted to learn Next.js.</li>
<li>I love how fast the navigation is.</li>
<li>I still <a href="on-dependencies-in-small-projects.html">don't need many dependencies</a>, and I'm finding Next to be very well-behaved and stable.</li>
<li>A lot of the site infrastructure is the same (I just copied it over).</li>
</ol>
So, this site isn't quite as hand-crafted as it used to be (or, at least, not quite as hand-crafted by me)--but you ought to be able to click around a lot more easily. And I still think that taking on dependencies <a href="on-dependencies-in-small-projects.html">is overrated</a>.

The state of the site

<head><link rel='stylesheet' href='https://fonts.googleapis.com/css?family=Mukta'>
 <style>
 body {
 background-color: #D8D8D8;
 margin-top: 50px;
 font-family: "Mukta";
 font-size: large;
 max-width: 650px;
 margin-left: auto;
 margin-right: auto;
 }
 footer {
 max-width: 650px;
 margin-left: auto;
 margin-right: auto;
 }
 li {
 margin-top: 5px;
 }
 .markdown-output {
 max-width: 650px;
 margin-left: auto;
 margin-right: auto;
 }
 </style>
 <meta name='description' content='How not to learn software'>
<title>How not to learn software</title>
</head>
<div>

<div class='markdown-output'><h2>How not to learn software</h2>
I stand by <a href="on-learning-vim.html">this post</a> on learning Vim. 
Now I want to double down on the third point I made there: 
If you're new to Vim, default to not installing plugins. 
And only make a <code>.vimrc</code> when you really need to. 
Here's why:
<ol>
<li>What the plugin does is often doable in vanilla Vim.</li>
<li>If it's not, there's probably a reason vanilla Vim doesn't include it.</li>
<li>The time you spend worrying about the plugin is time you can't spend learning Vim itself.</li>
<li>Plugins are buggy.</li>
<li>Plugins can be hard to install and maintain.</li>
<li>To the extent you rely on plugins, your Vim skills are less portable. When you fire up Vim on whatever server you need to be working in, some of your muscle memory won't apply.</li>
</ol>
Eventually, you'll need to install a plugin (e.g., for Copilot) or persist a preference (e.g., about indentation). 
But your .vimrc and plugins are like any other code in that you'll pay a maintenance cost as long as you have them.</div>

</div>




<hr>
<a href='index.html'>Home page</a>

How not to learn software

<head><link rel='stylesheet' href='https://fonts.googleapis.com/css?family=Mukta'>
 <style>
 body {
 background-color: #D8D8D8;
 margin-top: 50px;
 font-family: "Mukta";
 font-size: large;
 max-width: 650px;
 margin-left: auto;
 margin-right: auto;
 }
 footer {
 max-width: 650px;
 margin-left: auto;
 margin-right: auto;
 }
 li {
 margin-top: 5px;
 }
 .markdown-output {
 max-width: 650px;
 margin-left: auto;
 margin-right: auto;
 }
 </style>
 <meta name='description' content='Testing decorated functions in Python web frameworks'>
<title>Testing decorated functions in Python web frameworks</title>
</head>
<div>

<div class='markdown-output'><h2>Testing decorated functions in Python web frameworks</h2>
The meaty parts of Web frameworks, the parts that determine what happens when you hit a certain URL, often have a similar structure.
Here's an example from Bottle, a Python framework:
<h5><code>hats.py</code></h5>
<pre><code>@app.route('/hats')
def get_hat_names():
 hat_names = db.connection.execute(&quot;SELECT name FROM hats&quot;).fetchall()
 return hat_template(hat_names = hat_names)
</code></pre>
Very similar patterns exist in Django and Flask. 
(Also in non-Python frameworks, but for concreteness I'll use only Python examples.)
Now: how do you test <code>get_hat_names</code>?
The answer starts with the observation that things are not, in practice, as simple as the example above. 
Let's make the example slightly more realistic:
<h5><code>hats.py</code></h5>
<pre><code># You have some imports

# Somewhere you have a Django Router, a Flask object, or a Bottle command.

@app.route('/hats')
def show_hats(style: str = Form(...)): # In Django and other frameworks, there would be a `request` parameter here
 style_enum_value = Style[style].value # Style is an enum you're importing
 hat_names = db.connection.execute(&quot;SELECT name FROM hats WHERE style = {style_enum_value}&quot;).fetchall()
 sale_hat_names = db.connection.execute(&quot;SELECT hat_name FROM sales WHERE status = 'active'&quot;).fetchall()
 if not hat_names:
 return no_hats_template()
 sale_items = [hat_name for hat_name in hat_names if hat_name in sale_hat_names]
 return hat_template(hat_names = hat_names, sale_items = sale_items)
</code></pre>
There are at least four problems that arise in testing a function like this:
<ol>
<li>The function is more complicated than you'd want it to be for testing.</li>
<li>The function uses (closes over, if you prefer) items from the surrounding context These items often include routers, environment variables, and database connections.</li>
<li>You tend to need mocks: e.g., of database connections and of Django <code>Request</code> objects.</li>
<li>The function is decorated, and there's a lot of behavior happening in the wrapped function (but not the first-order <code>show_hats</code> function) that will interfere with your attempts to interact with it in tests.</li>
</ol>
(Those problems are interrelated, but also multifaceted. 
You might say those are actually two problems or actually six. 
Never mind.)
Here's how I test these functions without creating an opaque wad of mocks and set-up functions.
<h4>Step one: put persistence-related information behind an interface</h4>
Create an interface that abstracts away the details of a particular database configuration:
<h5><code>hat_repository.py</code></h5>
<pre><code>class HatRepository:
 @abstractmethod
 def get_hat_names(self, style_enum_value):
 raise NotImplementedError

 @abstractmethod
 def get_sale_hat_names(self, style_enum_value):
 raise NotImplementedError

class SQLHatRepository(HatRepository):
 def __init__(self, db_path):
 # Do your database setup
 pass

 def get_hat_names(self, style_enum_value):
 return db.connection.execute(&quot;SELECT name FROM hats WHERE style = {style_enum_value}&quot;).fetchall()

 def get_sale_hat_names(self, style_enum_value):
 return db.connection.execute(&quot;SELECT hat_name FROM sales WHERE status = 'active' AND style = {style_enum_value}&quot;).fetchall()
</code></pre>
This will help us a lot here. 
It will help us a lot everywhere, in fact: it's a powerful abstraction. 
(Architecture Patterns with Python is the best treatment I've read of the so-called "repository pattern.")
Then rewrite your decorated framework functions to depend not on a raw database connection but on an instance of the repository:
<h5><code>hats.py</code></h5>
<pre><code># You have some imports

# Somewhere you have a Django Router, a Flask object, or a Bottle command

repo = SQLHatRepository(&quot;db_path.db&quot;)

@app.route('/hats')
def show_hats(style: str = Form(...)): # In Django and other frameworks, there would be a `request` parameter here
 style_enum_value = Style[style].value
 hat_names = repo.get_hat_names(style_enum_value)
 sale_hat_names = repo.get_sale_hat_names(style_enum_value)
 if not hat_names:
 return no_hats_template()
 sale_items = [hat_name for hat_name in hat_names if hat_name in sale_hat_names]
 return hat_template(hat_names = hat_names, sale_items = sale_items)
</code></pre>
<h4>Step two: put all substantial logic in a helper function</h4>
In our example, this would work like this:
<h5><code>hat_helpers.py</code></h5>
<pre><code>def _show_hats(repo, style_enum_value):
 hat_names = repo.get_hat_names(style_enum_value)
 sale_hat_names = repo.get_sale_hat_names(style_enum_value)
 sale_items = [hat_name for hat_name in hat_names if hat_name in sale_hat_names]
 return (hat_names, sale_items)
</code></pre>
<h5><code>hats.py</code></h5>
<pre><code># You have some imports

# Somewhere you have a Django Router, a Flask object, or a Bottle command

from hat_helpers import _show_hats

repo = SQLHatRepository(&quot;db_path.db&quot;)

@app.route('/hats')
def show_hats(style: str = Form(...)): # In Django and other frameworks, there would be a `request` parameter here
 style_enum_value = Style[style].value
 hat_names, sale_items = _show_hats(repo, style_enum_value)
 if not hat_names:
 return no_hats_template()
 return hat_template(hat_names = hat_names, sale_items = sale_items)
</code></pre>
The division of work above is common:
<ol>
<li>The main decorated function parses inputs, which are often require transformation from what is passed in to the function. Most commonly, this is a matter of parsing strings or extracting fields from a request.</li>
<li>The main decorated function feeds values into templates.</li>
<li>The helper function does everything else.</li>
</ol>
<h4>Step three: test the helper function</h4>
Now you have a helper function, <code>_show_hats</code>, that is perfectly testable:
<ol>
<li>You can create a test-friendly subclass of <code>HatRepository</code>.</li>
<li>No mocks are required.</li>
<li>If the logic is complicated, you can (and should!) split it out and test those smaller functions separately.</li>
<li>You can import the helper without invoking side effects from your Web framework's router initialization, database connection, or anything else.</li>
</ol>
<h4>This looks like an anti-pattern, but it isn't</h4>
You might resist this solution: aren't these just "pass-through functions" of the sort John Osterhout <a href="reading-notes-a-philosophy-of-software-design.html">warns us about</a>? 
To have a function doing little more than passing arguments through is a well-known anti-pattern. 
What I'm recommending here, however, only look like pass-through functions. 
There's a lot of action happening in the decorator. 
To avoid pulling as much as possible out of these functions is to be deceived by syntax.</div>

</div>




<hr>
<a href='index.html'>Home page</a>

Testing decorated functions in Python web frameworks

<head><link rel='stylesheet' href='https://fonts.googleapis.com/css?family=Mukta'>
 <style>
 body {
 background-color: #D8D8D8;
 margin-top: 50px;
 font-family: "Mukta";
 font-size: large;
 max-width: 650px;
 margin-left: auto;
 margin-right: auto;
 }
 footer {
 max-width: 650px;
 margin-left: auto;
 margin-right: auto;
 }
 li {
 margin-top: 5px;
 }
 .markdown-output {
 max-width: 650px;
 margin-left: auto;
 margin-right: auto;
 }
 </style>
 <meta name='description' content='Notes on coding with ChatGPT'>
<title>Notes on coding with ChatGPT</title>
</head>
<div>

<div class='markdown-output'><h2>Notes on coding with ChatGPT</h2>
<ol>
<li>This is real.</li>
<li>There's a sort of endurance that coding with ChatGPT uniquely requires. You have to maintain the discipline to keep asking ChatGPT where appropriate; it's tempting to plow through a problem unassisted, especially when you've just asked ChatGPT for help a half-dozen times. You have to remember that ChatGPT is not getting tired or annoyed, and that you're not keeping ChatGPT from working on something more important. There's a certain social instinct that must be slightly repressed: entering into conversation of any sort prompts us to spin up various emotional capacities. Some of these are in fact good to maintain even when the interlocutor is ChatGPT, but many stop being worth the energy when it's not a human being on the other side.</li>
<li>The skill of dealing with code you didn't write, which has always been an important part of software engineering, is perhaps now even more important, given that you won't even have written a bunch of the code that you wrote.</li>
<li>There's a particular skill of remembering to double-check sources that are right perhaps 95% of the time. As I get better with ChatGPT, it has been harder to catch its mistakes, because its accuracy rate is sometimes so high that it comes to seem extremely convincing. (At Google there was an absolutely magical development tool that hot-swapped fixes into a development environment as you coded. It worked perhaps 99% of the time. I tended to lose hours chasing my tail when a 1% case hit.)</li>
<li>If you are coding with Copilot, don't be afraid to type "This is confusing because" and wait for the autocomplete.</li>
</ol></div>

</div>




<hr>
<a href='index.html'>Home page</a>

Notes on coding with ChatGPT

<head><link rel='stylesheet' href='https://fonts.googleapis.com/css?family=Mukta'>
 <style>
 body {
 background-color: #D8D8D8;
 margin-top: 50px;
 font-family: "Mukta";
 font-size: large;
 max-width: 650px;
 margin-left: auto;
 margin-right: auto;
 }
 footer {
 max-width: 650px;
 margin-left: auto;
 margin-right: auto;
 }
 li {
 margin-top: 5px;
 }
 .markdown-output {
 max-width: 650px;
 margin-left: auto;
 margin-right: auto;
 }
 </style>
 <meta name='description' content='A note on 10x engineering'>
<title>A note on 10x engineering</title>
</head>
<div>

<div class='markdown-output'><h2>A note on 10x engineering</h2>
Taylor <a href="https://taylor.town/-10x">argues that</a>, whereas "10x engineers may be mythical, -10x engineers exist." The form of argument is: it's pretty easy to waste ten engineers' worth of time and effort. He gives a long list of ways to do this.
It's a good argument, and it shows more than Taylor makes explicit. If he's right that there are so many dimensions of impact along which engineers can be much better and worse than each other, then I think you have to believe one of two things:
<ol>
<li>Most or all of these dimensions have unbounded downside but fairly low ceilings, or</li>
<li>The best engineers really are vastly better than average ones, because they can be better along many high-impact axes--or at least a few.</li>
</ol>
Moreover, Taylor barely discusses system design and architecture, and then only to discuss the costs of truly bad and sloppy planning. I'd also emphasize that the difference between mediocre and good system design is very large.
So: I don't know how sincere Taylor was when he said that 10x engineers are mythical, but it's very hard both to accept his argument for the existence of -10x engineers and to deny that 10x engineers exist.</div>

</div>




<hr>
<a href='index.html'>Home page</a>

A note on 10x engineering

<h2>Listening notes: Sold a Story</h2>
I enjoyed and recommend the series, but not without qualification:
<ol>
<li>It is way too long. The subject deserves a long treatment, but there is simply not enough information communicated per minute. Happily, the production is so good that it remains easy and pleasant to listen to despite this.</li>
<li>This has to be one of the most important issues in the country right now. Let's hope Emily Hanford is right that there is an awakening underway.</li>
<li>I am convinced that the science supports phonics instruction (and Hanford's views more broadly), but the listener would benefit from a thorough, reasonably complete overview of the research, early and at once. Instead, we get scattered descriptions of research and many claims (not immediately justified) that a certain view is right or wrong. Hanford is credible when she makes these claims, but it would be more rewarding and intelligible for the listener to get a good summary of the evidence up front.</li>
<li>I couldn't stop thinking about how a priori implausible cueing theories are. The series did not emphasize this, perhaps because appeals to intuition, to other domains (e.g., philosophy and linguistics) seem out-of-bounds; perhaps because it would be viewed as a cheap shot; and perhaps because other people don't have the same instincts I do. Nonetheless, I think a full epistemic treatment of this issue has to address the fact that phonics, as a theory of attaining literacy, makes a lot more sense than cueing.</li>
<li>The notes about privilege felt tacked-on and incomplete. I wasn't sure whether the claim was that rich people can afford to hire tutors, so are less sensitive to the quality of school instruction, or that cueing theories are a(nother?) manifestation of fashionable pseudoscience-as-science among American elites.</li>
</ol>

Listening notes: Sold a Story

<h1>Listening notes: Get Ready</h1>
<ol>
<li>The book is about preparation, in the most practical and pragmatic sense. If you have X hours to spend, and your goal is to do the best possible job at Y, how should you spend your X hours? The answer is probably not do do the most traditional, conventional sorts of practice. Buzzy has better answers.</li>
<li>This book should be as famous as The Art of Learning in the relevant crowd. I would actually recommend Get Ready over The Art of Learning for most people.</li>
<li>I was hearted to see echoes of <a href="https://www.natemeyvis.com/on-preparing-for-coding-interviews.html">my notes about preparing for coding interviews</a>.</li>
<li>Buzzy did a great job reading the audiobook. Unlike most, it's a pleasure to listen to.</li>
<li>The material is very general and not just for prospective Jeopardy! contestants. (This is very clear from the book itself, but not as clear from its marketing.)</li>
<li>Picasso (supposedly) said that whereas when art critics get together they talk high-mindedly about art concepts, when artists get together they talk about where you can get cheap turpentine. This is the "cheap turpentine talk" of life.</li>
</ol>
I value nuts-and-bolts / practical-advice-type books more than most people do (<a href="100-books.html">proof</a>), and this is the very best one I know of in its domain.

Listening notes: _Get Ready_

<h2>Reading notes: My Losing Season</h2>
Here are two metrics for how much a book captures my imagination:
<ol>
<li>How much do I think about it when I'm not reading it?</li>
<li>How eagerly do I abandon other leisure activities for it?</li>
</ol>
My Losing Season gets high marks on both of those. I thought about it all day. I looked for reasons to read just one more chapter. I broke my NYT crossword consecutive-days streak to read more of it.
If there is such a thing as a nonfiction bildungsroman, this is a remarkably successful one. Relatedly, it is one of the best books about masculinity I've ever read (though it is never presented as such).
The last portion of the book, to my ear, simply doesn't belong in it. It is a fine essay about reuniting with team members and a coach; I would have read it happily. But the end of Conroy's season is so powerful that these extra reminiscences are, by contrast, flat and even self-indulgent. I do want to know what middle-aged Conroy thinks about Vietnam; I didn't want to read about it then, when I cared so much about the world of the 22-year-old Conroy. This is an easy <a href="100-books.html">top-100</a> book for me and probably would have been in the top 25 or 50 had it ended sooner.

Reading notes: My Losing Season

<h2>Viewquake: making meaning after the fact</h2>
A couple years ago I started to reckon with the idea that, whereas some meanings of events are felt immediately, and some are intrinsic to those events, others are negotiable. Here's what set me on this line of thinking:
<ol>
<li><a href="https://twitter.com/MattGlassman312/status/1323493514169241602?s=20&amp;t=0RsNhicny7xi1dicm0b20Q">This Tweetstorm</a> by Matt Glassman about elections.</li>
<li><a href="https://gai.georgetown.edu/elections-matter/">This related Glassman article</a> about attempts to shape public meanings of elections.</li>
<li><a href="http://www.perseus.tufts.edu/hopper/text?doc=Perseus%3Atext%3A1999.01.0170%3Atext%3DApol.%3Asection%3D39e">Apology 39e and following</a>, when Socrates wants "to show you the meaning of this which has now happened to me."</li>
<li>Negotiation literature, especially <a href="https://www.amazon.com/Never-Split-Difference-Negotiating-Depended/dp/0062407805">Never Split The Difference</a>.</li>
</ol>
I have nothing profound to add to these here, but a lot of the world makes more sense when you see more behavior as negotiating over meaning. (And more events as mechanisms to force the negotiation over meaning.)

Viewquake: making meaning after the fact

<h2>Reading notes: Super-Infinite</h2>
Other reviews of this wonderful book summarize it well. You don't need to know or remember your John Donne to get a lot out of it. It's largely a portrait of London c. 1600, in all its glory and strangeness and brutality.
A few notes:
<ol>
<li>Rundell is fully convincing in arguing that the <a href="https://en.wikipedia.org/wiki/Commonplace_book">commonplace book</a> is an important way into understanding Donne. I'd say that the history of the commonplace book is generally underrated.</li>
<li>More generally, this is a good material history. Having a sense of the actual physical transmission (or not) of the various works vivifies them. In Donne's case this is unusually interesting. It takes a lot of work, at least for me, to overcome the impression high-school anthologies give of a well-defined, pristine corpus for every major author.</li>
<li>Biographers often speculate about human nature in asides, but for me this book is sui generis. The combination of detailed analysis of Donne, British and European history, and broader psychological discussions is striking and fresh.</li>
<li>Donne once wrote of something that it was "nature's great masterpiece" and "the only harmless great thing." What do you think he was talking about?</li>
<li>Here's a great few sentences: "But his poetry never describes her clothes, or her body. Donne's metaphors are vivid, wild, evocative, and potent, but they're strikingly unspecific. It never occurred to him to tell us if she was curved at the hip, or jutted at the collar bone, or was taller than him: presumably it was not what was important. The hunger, and the body itself, were what mattered."</li>
<li>And, finally, a great observation from Donne: "I throw myself down in my chamber, and I call in and invite God and his angels thither; and when they are there, I ignore God and his angels for the noise of a fly, for the rattling of a coach, for the whining of a door..."</li>
</ol>

Reading notes: Super-Infinite

<h4>On trees and dimensionality</h4>
Here's <a href="https://www.robertbeard.info/2022/03/21/subtree-matching.html">a crisp and thorough essay</a> from Robert Beard thinking through the problem of finding exact matches for a subtree in a larger tree. Unsurprisingly, you can help yourself by preprocessing the larger tree.
(I say "unsurprising" because there are so many graph algorithms that (i) are linear in the size of the graph, so not asymptotically more costly than simply reading the graph; (ii) straightforward to implement; and (iii) extremely informative. Tim Roughgarden calls these "<a href="https://theory.stanford.edu/~tim/won1samplefinal.pdf">for-free primitives</a>," which is a great way to think about them.)
The striking part (to me) of Robert's discussion is the value of preprocessing the large tree by labeling each node with its height (distance from the nearest leaf). Once you do that, you know that any node with height smaller than the height of the smaller tree cannot be the root of a match. So you can lop off the bottom of the tree from consideration.
Even if you're not worried about graph algorithms or interview questions, it's worth keeping in mind that most of a tree is near the bottom (if the tree is balanced or nearly so):
<ol>
<li>It's the key to seeing why <a href="https://stackoverflow.com/questions/9755721/how-can-building-a-heap-be-on-time-complexity">a heap can be constructed in linear time</a>;</li>
<li>It's why one or the other of breadth-first and depth-first search can be much better than the other, even though both take linear time (sometimes solutions are more likely to be found nearer to the start);</li>
<li>It's why searching a game tree just a little bit farther can take a whole lot longer;</li>
<li>And I'm pretty sure it helps explain why <a href="https://en.wikipedia.org/wiki/A*_search_algorithm">A* search</a> is so powerful in practice.</li>
</ol>
And from here it's a short step to more general facts about plane and solid geometry, which I use, on average, more than once a day in the kitchen:
<ol>
<li>If carrots A and B are the same shape, but A is twice as long as B, it will yield eight times as much food (as long as you peel carefully);</li>
<li>The cooking time of a meatball or roasted vegetable is extremely sensitive to how big the items are (so don't have much faith in listed cooking times, and if err on the side of making them small if you're in a hurry);</li>
<li>It's a big mistake to assume that every apple in the fridge is calorically equivalent.</li>
</ol>
See also the <a href="https://en.wikipedia.org/wiki/Curse_of_dimensionality">curse of dimensionality</a>. This all reminds me of how the Euclidean algorithm is often classified as "elementary," but roughly once a year I come to believe I've never properly understood it before.

On trees and dimensionality

<h2>Reading notes: Crossroads</h2>
<ol>
<li>Crossroads is set in the '70s, but is only lightly sprinkled with period references. Almost all the diction would fit into any of Franzen's worlds.</li>
<li>The characters largely sit around wondering whether they're good people; what their badness consists in, if they're bad; and how to find God. This is Franzen as an American Dostoevsky. (Certainly this stuff isn't what ties the novel specifically to the '70s.)</li>
<li>The manifestations of those topics, though--good, evil, self-doubt, God--involve: relevations about "social justice" (a phrase that appears three times) and the systematic mistreatment of women by men and of non-whites by whites.</li>
<li>Those issues are politicized in <a href="https://www.youtube.com/watch?v=uHCNXHzMRuc">the Callard sense</a>: "action and speech in that area must be interpreted against the backdrop of some standing debate." A 2022 reader could not read a book set in or around 2022 without immediately interpreting a remark like, e.g., "the Crossroads-encouraged inflation of emotional scrapes into ambulance-worthy traumas" in light of contemporary debates.</li>
<li>Here are two things that distinguish fiction from other forms of communication: First, there's a presumption that things happen for reasons. Those politicized subjects are presumably necessary in Franzen's project. Second, one's raw aesthetic reactions matter more than they do in other contexts. There are settings where we can say "I know this is politicized, but let's try to just talk about X here." A novel is usually not one of them.</li>
<li>But part of what produces that raw aesthetic reaction--that is, the reaction we have when we see a politicized topic and interpret it against the backdrop of a standing debate--is our understanding of the world in which the topic is being presented. So by setting the book in the '70s, Franzen opens up some of distance between those topics and our current debates.</li>
<li>Yet those topics remain thoroughly politicized for us, despite being less or differently politized in the world of the book. It's only some distance that gets opened up. How much distance that is depends on many things, surely including the reader.</li>
<li>The novel exhibits Franzen's full awareness that these issues are politicized and that some episodes in the book, in which characters do things that are presumptively OK in the world of the book, are only that way because the novel is set fifty years ago. In a climactic scene, someone says something like: "This is OK; it's the seventies." It's hard for the reader not to feel called upon at that moment to compare our world to the novel's.</li>
<li>I suspect it's wrong to read Franzen either as longing for a world where the old norms applied or as creating distance between our world and the novel's only to give us a perch from which to feel superior. For me, at least, there was room for a fresh and valuable look at various human depravities and struggles...</li>
<li>...including the struggles of religious faith, which are different for the characters (as opposed to us) because they're living in a more religious world.</li>
</ol>

Reading notes: Crossroads

<h2>Notes on Tyler Cowen on relearning the Internet</h2>
Tyler Cowen <a href="https://www.bloomberg.com/opinion/articles/2022-10-25/ai-will-require-you-to-relearn-how-to-use-the-internet">has a new column out</a> about "relearning how to use the Internet." As usual, the column is worth reading. Here are some reactions. (As always, I'm speaking only for myself.)
First, consider Tyler's description of a possible future Twitter: "Less than two years from now, maybe I will speak into a computer, outline my topics of interest, and somebody's version of AI will spit back to me a kind of Twitter remix, in a readable format and tailored to my needs." This is, structurally, very close to today's new-user flow at Twitter! You don't speak the topics, and some people don't find the result so readable, but I'd say that this description literally fits many people's interactions with Twitter today.
Alternative ways to read this prediction, then, are (i) as a commentary on what current optimal use of Twitter looks like (a lot of deliberate user modification) and (ii) as a prediction that Twitter's AI will get better, not that it will change so fundamentally.
Second, I worry that Tyler is sometimes characterizing non-AI obstacles as AI obstacles. Some of his speculations involve aggregating search results across services ("the current aggregators will themselves be aggregated and organized") and changing the user's experience with existing services ("you won't use Google, you will just ask your question to an AI and receive an answer"). Here I'd note that:
<ol>
<li>The changes Tyler imagines do not rest on improvements to AI as much as changes to UX;</li>
<li>Google, Amazon, and others are already working very hard to let you "just ask your question to [any number of devices] and receive an answer"--as a user, I think that in some cases these already work quite well;</li>
<li>One could imagine different or better results from combining current companies' responses to the same query, but combining these is more of a logistical and political project than an "AI" one;</li>
</ol>
More evidence for these is that many companies have already tried to build smart aggregation services on top of existing search and storage services. I am not an expert here, but I don't think that what has kept those new products from succeeding is that the meta-level AI wasn't good enough. Rather, the services resisted integration, the user experience wasn't good enough, or some single underlying component was so good that it rendered the others superfluous.
Relatedly, some of Tyler's speculations seem to have more to do with <a href="https://www.thediff.co/p/the-rise-of-single-result-search">single-result search products</a>, as Byrne Hobart wrote up recently (it's a free article). This feature, returning one result instead of many, characterizes some of Tyler's central examples: two of these are using Google Maps instead of typing a query for directions into the search box and getting answers from a voice-activated question-and-answer service. Better AI doubtless makes single-result interfaces more practical. Still, returning one result instead of many, and returning it in a particularly actionable form, is fundamentally a change in the interface as opposed to a replacement of something else with AI.
It's also worth considering the psychological barriers to using the sorts of services Tyler describes. Consider a Google search result that includes helpful notes about Google Drive documents, your email, and various other Google services. This is, in many ways, the sort of ur-level AI-driven experience Tyler imagines. It already exists! Many people find these results unsettling or confusing. Tyler seems implicitly to believe that people will accept these new AI-driven, aggregated services. I don't disagree, but I don't think it's obvious that they will. Here as elsewhere, the changes Tyler imagines are in some ways already here. In some cases they are not really AI changes at all, or at least the quality of the AI is not what is holding them back.

Notes on Tyler Cowen on relearning the Internet

<h2>Code correctly by conforming to the real world</h2>
I <a href="why-events.html">recently wrote about</a> why it makes sense to use events in many programming situations. There's more to say about the example and why events are correct there: the lesson applies more generally and will help you make good decisions about more than just event modeling.
We are modeling a soccer game and we have:
<ol>
<li>The basic apparatus of the game: the field, the ball, players, and teams.</li>
<li>An assistant referee, which in the primitive state of this hypothetical application is just a mechanism for determining whether the ball is out of bounds or not.</li>
<li>The notion of a throw-in when a ball is out of bounds.</li>
</ol>
There are, broadly, a few ways to handle the mechanics of awarding a throw-in:
<ol>
<li>The assistant referee, upon determining that the ball is out of bounds, examines the recent state of the game (which team touched the ball last) and instigates the throw-in (to the other team) directly.</li>
<li>Teams (or players) will attempt to take the throw-in, and the assistant referee will permit or deny this.</li>
<li>The assistant referee will perform an event. This event will be processed by some central entity (you can think of this as a <code>Referee</code> object or a more general message bus.</li>
</ol>
This sort of decision comes up all the time. And they're some of the most important decisions you make in programming. Important, common decisions are the best ones to study!
In that post I argued for the last option. Here are two further notes about making this kind of decision:
<h4>Study dependency problems as dependency problems</h4>
First, notice that this is a dependency problem. It can look like, and is often treated as, a purely mechanical problem about imports or an ergonomic problem about the convenience of methods you'll be implementing. There are import mechanics and ergonomics here, but those are manifestations of the fact that dependencies are being created. Worrying about dependencies as dependencies helps you resolve these other issues; trying to think about the issues independently of the fact that dependencies are involved leads to confusion.
What are some good heuristics for determining dependency directions?
<ol>
<li>Think about operations you need to do now, and choose the direction that will accommodate them most easily.</li>
<li>Try to anticipate possible future operations, and choose the direction that will be accommodate those changes most easily.</li>
<li>Try to anticipate possible future modifications, and choose the direction that will facilitate those.</li>
</ol>
Here, by the way, are some bad but commonly used heuristics for making this choice:
<ol>
<li>Think about the order data will flow through the system, and make the later objects depend on the earlier ones. (John Ousterhout <a href="reading-notes-a-philosophy-of-software-design.html">diagnoses "temporal bias" errors very well</a>.)</li>
<li>Think about your preferred database and choose the one that most intuitively fits it.</li>
</ol>
Here, the first two options are poor because they introduce inappropriate dependencies. The <code>AssistantReferee</code> object should not be rifling through game history, communicating with players, and doing whatever else would need doing if it were doing more than simply raising events. Nor should several players (or teams, or scorekeepers) have to issue separate requests to an assistant referee in order to determine what is happening. It might not sound as bad at first, but remember that not only the assistant referee but also the head referee, the head coach, and even the scoreboard or weather (is the game over? has thunder struck?) might change the result.
I find I make better decisions when I take the "because" in the previous paragraph very literally: bad decisions here are bad because they get the dependencies wrong. When you find yourself doing <a href="on-quadratic-complexity.html">unnecessary quadratic work</a>, debugging circular dependencies, or duplicating information because the alternative is too cumbersome, inappropriate dependencies are usually involved. Consider the case of quadratic work: this often happens because something is querying something else, and there are O(n) of each of those things. That, in turn, is often caused by information being stored with the latter thing instead of with the former thing. And that, in turn, is usually caused by a bad dependency.
Another hypothetical example in the spirit of something I've seen dozens of times: a library application is slow because every search requires a linear scan over all books, which in turn is because books are storing information about which users can check them out when. If the information were stored with the user or with some sort of neutral arbiter, this wouldn't be necessary.
The second note about the soccer-events example is more controversial:
<h4>Worry more about what the things you're modeling really are</h4>
The previous argument attempted to establish that many problems are not only correlated with but caused by dependency problems. These issues become clearer when you also recognize that dependency problems (and other problems) are caused by a bad match between your code and reality. That is, your bad dependency is a bad dependency because it fails to conform to the world. In the soccer example, when we introduce events, we conform more closely to reality: the job of the head referee really is to be, among other things, an event broker. 
What about the heuristics from before? Going in turn:
<ol>
<li>The operations you need to do now are very likely to be operations that have some real-world analogue. The more faithfully you model reality, the more elegantly you'll be able to implement those operations.</li>
<li>Same with the operations you don't need to support now but do need to support later.</li>
<li>And when things need to change more fundamentally in your code, it's often because something changed in the real world. The way things change in the real world are governed by their relationships in the real world. So, for example, if X persists even though some related Y changes, that's a good sign that X was more fundamental than Y and should have been modeled that way. Another common headache here is needing to do a large migration to, e.g., change a value from being treated as boolean to being treated as a member of a more robust enumeration. Almost always, the thing in the world that the value is representing never really had boolean structure. Rather, for contingent reasons there was no need to express more than two states for that value, and a bad assumption that only two states were possible was baked into the interface.</li>
</ol>
Each of those heuristics works because it keeps us in touch with reality. And this is where I find myself in deep agreement with the <a href="https://en.wikipedia.org/wiki/Domain-driven_design">domain-driven design</a> folks. I find the famous books in the tradition very difficult to read (except for Architecture Patterns with Python, which was a pleasure), and there tends to be a bit too much jargon and indoctrination there. But the core of DDD, as I understand it, is that you have to know which real-world domains you're working with, separate them cleanly, and model them correctly. This insight is valuable enough that it's worth wading through a lot of finger-wagging about <a href="https://en.wikipedia.org/wiki/Command–query_separation#Command_Query_Responsibility_Separation">CQRS</a>.
That is, each of those three heuristics (and pretty much any other reasonable heuristic you can think of) is a manifestation of a more fundamental principle. Your code will ultimately be accountable to the real world in some way, and that its success and failure will depend largely on how faithfully it models the world and how nimbly it adapts to changes in it.

Code correctly by conforming to the real world

<h2>Reading notes: The Remains of the Day</h2>
Very mild and general spoilers ahead. I have read no other reviews or commentary about the book, so you might find these notes either obvious or badly misguided.
<ol>
<li>The use of the second person is masterful. When commentators discuss second-person fiction, they tend to say that it's rare, give Jay McInerney a B or B+ for Bright Lights, Big City, and move on. Although much of this book is in the first person, the second-personal elements are significant and closely connected to the central aesthetic and moral moments of the novel.</li>
<li>The narrator who is gradually revealed as unreliable is a more familiar device. It is executed brilliantly and, again, intensifies the book's moral climaxes. We begin with the overwhelming sense of order and decency; this is gradually undermined; and eventually the reader must import skepticism into scenes with no overt signs of misbehavior or absurdity. This effect is powerful once it occurs.</li>
<li>Another way to read this book is as a challenge to the reader: how good are your values, and how much integrity do you have? (See the previous point.) The reader can often be thought to stand to the narrator as the narrator, a butler, stands to the head of the house he serves. This is a familiar device, but used to much more powerful effect than usual.</li>
<li>Some important influences here seem to include the tradition of the detective novel (is it true that "the butler did it"?) and some American traditions. It brings to mind various other meditative novels about car trips (I have a hard time not comparing it to Zen and the Art of Motorcycle Maintenance), and the end seems to owe much to The Great Gatsby.</li>
</ol>
Very highly recommended. An easy inclusion in the <a href="100-books.html">top 100</a>.

Reading notes: The Remains of the Day

<h2>Why events?</h2>
Many applications, including applications in tutorials, use events and coordinators. Students (and professionals!) often find these confusing. Here I'll try to motivate their use.
Imagine you're programming a simulation of a soccer game. You've got the basic structure of the game coded up (a field, a ball, the score, and so on). You also have:
<ol>
<li>a <code>Team</code> class;</li>
<li>an <code>AssistantReferee</code> class that determines whether the ball is out of bounds;</li>
<li>a <code>ThrowIn</code> class.</li>
</ol>
You don't need to worry about the specific choice of object here. For example, it doesn't much matter whether you have an <code>AssistantReferee</code> or the field itself determining whether a ball is out of bounds, or even whether the functions I'm going to describe are standalone functions or methods on objects you've defined. What's important to recognize is that you have some bits of code that are modeling causally interconnected events.
Now you need to write code to handle the situation when a ball goes out of bounds. A first pass might be something like:
<pre><code>class AssistantReferee:
 def is_ball_out(self, game_conditions):
 # logic goes here
 return some_boolean_value

 def handle_sideline_situation(self, game_conditions):
 if self.is_ball_out(game_conditions):
 team_to_award = game_conditions.team_that_did_not_touch_last()
 self.award(ThrowIn(team_to_award, location))
 else:
 self.maintain_good_posture()
</code></pre>
You can ignore most of the details there--though note that we already need all sorts of custom objects and that, as usual, even a very coarse-grained representation of reality requires quite a lot of care to model.
What's important is that:
<ol>
<li>This code does not use any explicit notion of an event or a coordinator;</li>
<li>This code is bad and will be extremely brittle and will soon become an unmaintainable, failing mess;</li>
<li>The ways in which it is bad arise precisely from our decision to model this situation without events and event coordination.</li>
</ol>
You're likeliest to notice things going wrong when you add some further bit of detail or functionality to your soccer game. For concreteness, let's say you want to model substitutions. There are times in a game when substitutions are allowed; throw-ins are one of them. We'll be tempted to simply add this to our previous code:
<pre><code>class AssistantReferee:
 def is_ball_out(self, game_conditions):
 # logic goes here
 return some_boolean_value

 def handle_sideline_situation(self, game_conditions):
 if self.is_ball_out(game_conditions):
 team_to_award = game_conditions.team_that_did_not_touch_last()
 check_for_pending_substitutions() # Are there players who are checked in and waiting?
 # Do whatever else needs to be done
 self.award(ThrowIn(team_to_award, location))
 else:
 self.maintain_good_posture()
</code></pre>
Now there are two big problems--or, really, one big problem that can be described in several ways:
<ol>
<li>Our <code>handle_sideline_situation</code> function is doing more things that it should be doing, and will soon become a huge unmaintainable mess;</li>
<li>Our <code>AssistantReferee</code> object is doing things that are not properly the job of an assistant referee.</li>
<li>The proper causal structure of the situation is being distorted in our code.</li>
</ol>
What is really happening in the game we're trying to model is:
<ol>
<li>Something has happened;</li>
<li>That thing causes other things;</li>
<li>And, in particular, it could cause several other things that might themselves have consequences. (When a substitution happens, the scorer needs to know about it and a number of remaining substitutions might need to be updated; this will go on and on.)</li>
</ol>
To represent this faithfully, we need to treat the ball going out of bounds as its own thing. Maybe an assistant referee will detect it; maybe video review will; maybe the referee will. Maybe it needs to cause one thing to happen; maybe several. Maybe those several things need to happen in a certain order; maybe not. (And some events require no downstream effects.)
These causal relationships inevitably change, a lot, over the life of a piece of software. Keeping track of them is not the <code>AssistantReferee</code>'s job. Note that in real-life soccer games, assistant referees do not, strictly speaking, award any throw-ins or make any rulings; they just send signals to referees. And referees are pretty good metaphors for coordinators: they receive events and know what those events need to be triggering. In your software as in real life, it would be a disaster to have all sorts of scorekeeping, game-management, and disciplinary judgements flowing through the assistant referee just because they happened to be the proximate agent to one part of one process.
Here I've just tried to convince you that events and event coordination are absolutely necessary. How exactly to implement them is tricky; I recommend Architecture Patterns with Python for a good overview of the subject. Good luck.

Why events?

<h2>Reading notes: Of Boys and Men</h2>
Recommended.
<ol>
<li>It is a book about men, but only a shortsighted reader would miss the lessons about (specifically) Black men, Black women, the middle and lower classes generally, and so on. I have long suspected that intersectionality and related concepts would be used by groups concerned with men's interests. This is the first sustained effort I've read in that direction (in book form, at least).</li>
<li>And this is, in its way, one of the most compelling discussions of income and wealth inequality I've seen. Many of Reeves' arguments can be seen as versions of: "The disproportionate money and power that flows to a small and mostly male group masks big problems with men, which are problems for everyone."</li>
<li>There are many and diverse citations. Evaluating them would be a major project. Reeves certainly presents a lot of reasonable-seeming evidence for his views, but might not always present the strongest evidence against those views.</li>
<li>One particularly interesting body of evidence Reeves collects is that various kinds of interventions help women more than they help men. This has <a href="https://conversableeconomist.com/2022/10/07/why-do-so-many-interventions-help-women-but-not-men/">drawn some blogosophere attention</a>. One explanation here is that non-male groups suffer discrimination that makes certain kinds of interventions particularly effective for them (again, I don't think one can read this book properly without thinking about how much we're doing wrong with respect to other groups). I hope more work is done to figure out how robust this phenomenon is and what its causes are.</li>
<li>Some of Reeves' policy proposals seem interesting: e.g., to work to get men into "HEAL" (health, education, administration, and literacy) jobs. Others seem like political and practical non-starters to such a degree that it's hard even to begin to contemplate their full impact: e.g., to fund an extra year of pre-K for (only) boys so that they can be redshirted. (This is to compensate for the features of male brain development that Reeves argues make boys less well suited to academic success if age is held constant.)</li>
<li>I expect a lot of low-quality commentary on this book. It's not that long, but <a href="on-actually-reading-the-book.html">most people won't read it</a>.</li>
</ol>

Reading notes: Of Boys and Men

<h2>The tweetstorm as a form</h2>
Tweetstorms give a loose, serial structure to their component tweets, but also leave those tweets largely independent both in the reader's experience and in the structure of reply chains. So they're not just a way to blast some information into public (however useful that function is); I think of them in the tradition of heroic couplets and ghazals. I'd rather read a pure list or a story on a blog or in a book, but semi-structured streams of information (like this) are great for tweetstorms.
My tweetstorms
Why I don't do poker software
The lost phenomenology of poker in 2006

The tweetstorm as a form

<h2>What is America's epic?</h2>
<a href="https://twitter.com/Isaiah545251391/status/1581434205376253954?s=20&amp;t=seLz9j0b1chgkAgcc43moRVWVUCtxoOtsD7kibi3GO4">The Twitter question du jour</a> is: What is America's epic? That is, what is to America what the Iliad is to Greece, Ulysses is to Ireland, and Don Quixote to Spain?
My first thought was Moby-Dick, which is a pretty common answer. But I'll take The Scarlet Letter instead:
<ol>
<li>It is accessible yet difficult, engaging, and deeply moral.</li>
<li>It's part of our explicit national consciousness in a way that Moby-Dick and most other contenders are not.</li>
<li>More people have actually read it than Moby-Dick and most other contenders. (Let me be clear that I also <a href="on-actually-reading-the-book.html">have not read more than 1/5 of</a> Moby-Dick, but I <a href="100-books.html">have read</a> many other classic American novels.)</li>
<li>It is, arguably, an origin story about American morals and values. (The frame of the novel is underrated.)</li>
<li>And it is a story about the transmission of values and character. A good epic should have at least one main character who is a child, right?</li>
</ol>
I'll put The Great Gatsby in second place:
<ol>
<li>There are explicit visions of American values and character traits. Think of the note about American physique and sports when Gatsby is leaning out of his fancy car or the note about how "Americans, while occasionally willing to be serfs, have always been obstinate about being peasantry."</li>
<li>It's still quite famous. Plenty of Americans have read it (though I strongly suspect that far fewer high schoolers read it these days).</li>
<li>It is built around a journey from the Midwest to the East and back.</li>
</ol>
I haven't seen anyone mention East of Eden yet, but I'd put it somewhere in the 5 or 10 best answers to this question.

What is America's epic?

<h2>Reading notes: There's No Such Thing as Bad Weather</h2>
I found this book valuable enough to finish. Valuable enough for me; it's hard to recommend it.
<ol>
<li>The central message of the book is that, along many dimentions, Sweden is different from, and preferable to, America. You don't have to believe this to benefit from the book, but there might be limits to how much of this you want to read.</li>
<li>The book cover promises "a Scandinavian mom's secrets," but there's less of that than simple reporting of what Scandinavia is like. If I had to choose a genre for this book, I'd pick autoethnography, not advice. The bulk of the book is description and interviews.</li>
<li>"Simple reporting" of parenting cultures I haven't experienced is, however, broadening and valuable. Bringing up Bebe is a favorite parenting book (and in my <a href="100-books.html">top 100</a>). I'd like to read more books like this.</li>
<li>There are many references to studies and books, but these are peppered in the text in an unsatisfying way. They're unlikely to convince you if you don't already like McGurk's point of view. (This is standard enough in pop-science and parenting books, but enough hours spent with writers who are better at this--Janet Lansbury, Jamie Glowacki, Emily Oster--will make you <a href="https://www.amazon.com/Expecting-Better-Conventional-Pregnancy-Wisdom/dp/B08SJDP2CW/">expect better</a>.) The discussions of sleep safety and of hygiene-related tradeoffs are two areas where a more rigorous and balanced scientific treatment would have been particularly valuable.</li>
<li>Some passages haunt me. I have spent many hours fussing over the details of baby food composition, environmental tradeoffs in diapering, and so on, but I would complete the prompt "I know exactly what I want for this child" very differently from McGurk:<blockquote>
I know exactly what I want for this child. Natural childbirth--check. Cloth diapers in gender-neutral diapers--check. Homemade, organic baby food--check.
</blockquote>
</li>
<li>A valuable complement to McGurk's view of Scandinavian parenting culture is volume six of Knausgaard. But that's also a tough thing to recommend or <a href="on-actually-reading-the-book.html">to expect someone to have read</a>.</li>
</ol>
So: I have my complaints, but I'm glad I finished this book. If nothing else, I'm more eager to take my kids outside in light rain.

Reading notes: There's No Such Thing as Bad Weather

<h2>What's happening with data scientists?</h2>
The <a href="https://www.thediff.co/p/snail-games-and-one-hit-wonders">most recent issue</a> [$] of The Diff discusses <a href="https://blog.interviewing.io/how-much-have-2022-layoffs-affected-engineers-vs-other-departments-we-dug-into-the-data-to-find-out/">this interviewing.io analysis</a> of recent layoffs.
One finding Byrne discusses is that data scientists are being laid off at surprisingly high rates (much higher than software engineers). Byrne suggests it is because staffing data science tends to be associated with expansion. Here are some other hypotheses:
<ol>
<li>At many companies, data science is used for exploratory or speculative ends. Stopping such projects can be less painful than stopping other projects--even if it's a mistake to do so. (And in some cases, stopping those projects puts more decisionmaking power with the people doing the layoffs.)</li>
<li>Anecdotal: some people who would have called themselves "data scientists" five years ago are now (maybe) calling themselves "ML engineers" or similar. It would be interesting to investigate whether and how the status and seniority of the "data scientist" title is changing. In the Stable Diffusion Era, I'd guess that people who work directly with ML models are even more eager to have "ML" or "AI" in their job titles.</li>
<li>Relatedly, some tasks in the traditional domain of data science are now being done in ways that look a lot more like software engineering (or the automatic behavior of software). This probably goes both ways, with data science capturing some other territory, but I'd guess that there's a net loss here. (This intersects with the point above about prestige.)</li>
<li>Computing power is more usable than ever (with better cloud services, M1 Macs, etc.). In my experience, this accelerates data science more than it does other kinds of software work. A lot of data scientists spend significant time waiting for calculations to finish.</li>
</ol>
Those are all hypotheses I'd want to investigate; they are certainly not firm beliefs.

What's happening with data scientists?

<h2>Code review reference</h2>
If you are reading this because I've linked you here: the relevant section contains a canonical version of some shorter code review comment, and I'd be grateful if you reviewed it. Otherwise: hello and welcome to a list of things I commonly say in code reviews. (Hat tip to Eric Breck, who maintains a magnificent document in this form.)
<h4>"Your near-synonymous variable names suggest that something is wrong."</h4>
If, in the same function / file / class / whatever, you have <code>size</code> and <code>object_size</code>, <code>error</code> and <code>mistake</code>, <code>dimension</code> and <code>dim</code>, or similar, one of these problems is probably happening:
<ol>
<li>Those two variables should be one. (Perhaps this is quick prototype code that hasn't been cleaned up yet.) The best fix is probably to collapse the two variables into one and adjust as appropriate.</li>
<li>One of those variables is misnamed. Often, this seems to result from an unwillingness to admit that something needs to be represented at all. Perhaps you think you should have cleaned up the raw input corresponding to X by now but for whatever reason can't, but you don't want to say <code>raw_input_for_X</code>. The best fix--honesty being the best policy in code as elsewhere--is to rename the variables to describe accurately what they represent. You might also need to file a ticket describing the work that would need to be done to make the embarrassing thing unnecessary. (It's OK!)</li>
<li>Those variables represent the same underlying thing in different contexts. (Perhaps this is a system that's grown larger than planned.) The best short-term fix is, again, to be more accurate about what the variables represent, even if it's embarrassing. In the longer term, planning in terms of <a href="https://martinfowler.com/bliki/BoundedContext.html">bounded contexts</a> might help.</li>
</ol>
<h4>"You're using a custom type or object here and keeping the definition in your head."</h4>
Lists, tuples, and arrays make it easy to pass around related bits of information. 
Be careful not to rely on the sequential structure of these objects in a way that is semantically opaque. 
This is a common source of unnecessary coupling between components and of structure living in a programmer's head that should be living in code.
So, if you need to pass around an event's time and place, representing this information as [<code>foo_time</code>, <code>foo_place</code>] and making every user retrieve the time with <code>foo_information[0]</code> and the place with <code>foo_information[1]</code> creates an unnecessary burden. 
Make an <code>EventCircumstances</code> or <code>EventStamp</code> object (using a struct, a Python dataclass, a Java @AutoValue class, or any other appropriate mechanism). If you really want to represent that data with a list, feel free to do so under the hood, so long as distant callers don't need to know that "<code>[0]</code>" is how you say "<code>.place</code>" in this context.
<h4>"This name is not semantically correct."</h4>
Prefer to name things according to what they <code>are</code>, rather than the circumstances of their use. If you have an object representing a pizza, and you order pizza only on Tuesdays, name it <code>pizza</code>, not <code>food_we_order_on_tuesday</code>. Some common manifestations of this error are:
<ol>
<li>Text fields. If the field is the serial number but is used by the header of the login screen, call it <code>serial_number</code>, not <code>login_screen_header_text</code>.</li>
<li>Exceptions. Exceptions are tricky, because you tend to want context (in a way that makes contextual information part of what the thing is), but still: If the exception arises from a failed widget validation, and that validation happens in your Jenkins CI, call it a <code>WidgetValidationException</code>, not a <code>JenkinsWidgetCheckException</code>.</li>
</ol>
<h4>"This layer of indirection is not permitting any useful abstraction."</h4>
Let's say you're representing a light bulb's brightness. Right now you're representing it as a single number of lumens. If you decide to represent that as a <code>Brightness</code> with a single field: sure, let's abstract away from a single primitive data type, for all the usual reasons, including extensibility.
Now let's say you have a <code>Lightbulb</code> object that has <code>LightbulbProperties</code> (the only one of which is the <code>Brightness</code>). Here I'd worry not only that <code>Lightbulb</code> and <code>LightbulbProperties</code> are too nearly synonymous (see above) but that the extra wrapper around this single number of lumens isn't helping.
And if the <code>Lightbulb</code> has <code>LightbulbProperties</code> that has a <code>LightbulbBrightnessProperties</code> that has a <code>Brightness</code>, you almost certainly have more indirection than actual abstraction. Remove at least one of these layers.
This issue commonly arises with central objects in a system, which programmers often feel (justifiedly) hesitant to create and modify directly. Jumping through the layers' definitions in an IDE can feel like watching someone put on latex glove after latex glove after latex glove in the hopes of not leaving a smudge on the vase they're about to handle. I respect the caution but would rather you be able to use your hands.
<h4>"I don't think this thing you're trying to formalize can be formalized."</h4>
See <a href="an-argument-from-jimmy-koppel.html">here</a>.

Code review reference

<h2>Notes on being the Day One chip leader</h2>
Some decades ago David Sklansky published an essay called "Why the First Day Chipleader at the WSOP Never Wins." 
It came to mind because Byrne Hobart wrote up <a href="https://mailchi.mp/verdadcap/persistence-of-growth?utm_source=substack&amp;utm_medium=email">this essay</a> about persistence. 
(It turns out the second quintile of EBITDA growth does better than the first quintile according to Verdad's research.)
It's a fun comparison: in some situations, and not just toy examples, the best performance is correlated with worse outcomes than merely very good performance. 
(Where else is this true?)
The essay is very old, by now, and does not apply directly to the modern game. 
Here are some updates:
<ol>
<li>The conclusion no longer holds: day one chipleaders do quite well. <a href="https://www.pokernews.com/news/2015/07/does-bagging-chip-lead-on-day-1-mean-success-22164.htm">Here</a> is a PokerNews analysis noting that both Joe Cada and Martin Jacobson won after chipleading Day 1. </li>
<li>But there is not quite such a thing as "the Day One chipleader" any more, because the Main Event is held with several starting flights (with surviving players combining later).</li>
<li>Good tournament strategy is probably more aggressive than Sklansky foresaw.</li>
<li>Or, at least, excellent players are studying and implementing aggressive strategies much more often and more effectively than they were when Sklansky wrote that essay.</li>
<li>The Main Event is much bigger, so that the returns to having a huge stack are higher than they were when the fields were smaller. (There are roughly 10x as many entrants as there were 20 years ago.) Or, at least, the value of having a huge stack and playing well thereafter is much higher.</li>
<li>And because the field is bigger, being at the top of Day One is a bigger accomplishment.</li>
<li>I've only briefly checked my memory here, but I think the blinds go up more slowly than they used to, which means that large pots (especially those at the end of the day in 2022 as compared to 2002) on day one on average involve more skill than they used to.</li>
<li>And there are far more good players than there used to be. This means both that one of them has a better chance of coming out on top and that weak players playing manically are much more likely to get picked off at some point, even on the first day. (The previous point is relevant here too.)</li>
</ol>
So, Sklansky's point is still worth thinking about, but no longer straightforwardly applicable to the actual Main Event.

Notes on being the Day One chip leader

<h2>Amplifying a point from Dan Gross</h2>
Dan Gross, during <a href="https://conversationswithtyler.com/episodes/talkingtalent/">Shruti Rajagopalan's excellent Talent interview</a>, made a point worth amplifying:
<blockquote>
GROSS: We’re certainly not saying that horsepower and IQ don’t matter. They certainly do, but there is a clearing bar at which point, for most roles, I think people tend to overvalue it and don’t realize the logarithmic nature of the curve and assume it’s linear. But I actually think, earlier than many people realize, you want to switch to caring about just how vigorous and how energetic that person is.
I think that might be because--I’d be curious if you’d agree that it’s because, for most tasks, doing gleans far more information than thinking.
TYLER COWEN: Exactly.
</blockquote>
The point mostly speaks for itself, but here are a few notes:
<ol>
<li>When I worked in machine learning every day, I found a close analogue of this to be very true. A slightly better architecture tended to matter much less than getting better data. Or, at least, once I hit on a reasonable model architecture, I tended to do much better by cleaning and gathering more data than by optimizing the architecture.</li>
<li>I was reminded of this by <a href="https://www.thediff.co/p/longreads-open-thread-629">yesterday's issue of Byrne Hobart's newsletter</a>, specifically the bit about forecasting: "The market message is 'don't forecast'!" Byrne gives what I think of as a variant of the Gross point: successful people need a good sense of what's going to happen, but spend a lot more time doing other stuff. (Or: "...spend a lot more time doing stuff.")</li>
<li>It's worth remembering that Gross is a startup investor, and startup investment notoriously involves the tricky balance of finding people who are (i) solid and smart, with a clear-headed and expert view of some domain, but also (ii) ahem, "optimistic" enough to be doing a startup. He more than most people needs to be thinking about the tradeoffs between different kinds of analytic and practical apititude.</li>
<li>Relatedly, there are kinds of discipline and hustle that are in many situations a good substitute for raw intelligence. Math competitions, programming interviews, and the like certainly reward studying. Reasoning under uncertainty benefits from discipline, and careful thinkers willing to do some research often do much better than top raw intellects. (This came to mind while I was writing up <a href="illustrative-epistemic-mistakes-people-made-with-the-j4-hand.html">this post about poker and epistemic mistakes</a>.)</li>
</ol>

Amplifying a point from Dan Gross

<h2>Illustrative epistemic mistakes people made with the J4 hand</h2>
The Robbi Jade Lew / J4 episode brought out some good analysis and much bad analysis. 
Many of the analytic mistakes were not about strategic or other specific evidential details, but structural errors in reasoning under uncertainty. 
Here is a partial list.
<ol>
<li>Ignoring base rates. (I discuss this more <a href="notes-on-the-garrett-adelstein---robbi-jade-lew-hand.html">here</a> and <a href="why-my-priors-about-cheating-at-poker-are-so-high.html">here</a>.)</li>
<li>Conflating unconditional and conditional probabilities. Many people on both sides said that some piece of evidence was very unlikely given some scenario--either that there was cheating or that there was not cheating. Often, these claims were perfectly true but ignored the fact that the evidence was also very unlikely under any scenario. What mattered was the likelihood ratio of the evidence, not simply its likelihood given some hypothesis or other.</li>
<li>Ignoring correlation. (See <a href="https://twitter.com/NateMeyvis/status/1578324019405025281?s=20&amp;t=aBEiMRcuNZCrbFtZTFO8Yw">here</a>.)</li>
<li>Ignoring the context. Expected behavior is simply different at very high stakes. I am not an expert about the nuances of high-stakes culture or the politics of getting into streamed games, but far too many people extrapolated from their own poker experience or what they see of the highest-stakes games they know a lot about. This caused people to reason poorly about, among other things, (i) the probability of a misread in a big pot, (ii) the likelihood that an honest player or a dishonest one would be given a 50% freeroll on a stake in a game, (iii) the likelihood that a weak amateur could win over two sessions against an uneven lineup including very top professionals, and (iv) the motivation to cheat. I was guilty of this in not thinking about (ii) as rigorously as I should have: although I initially thought the stake was suspicious, I mostly shrugged my shoulders and thought that very strange financial arrangements often happen in poker.</li>
<li>Ignoring history. This is closely related to ignoring base rates. It is irresponsible to claim that a cheater "would never" do something that is in fact what cheaters have been observed doing. As is so often the case, a bit of research is worth a lot of raw intelligence when you're trying to reason accurately.</li>
</ol>
There were also the usual emotional and political issues: getting stubborn, ignoring inconvenient evidence, disguising expressions of political affiliation as dispassionate analysis, and so on. But what is striking to me is the poor display of epistemic fundamentals even among people who seemed not to be suffering from those.

Illustrative epistemic mistakes people made with the J4 hand

<h2>Why my priors about cheating at poker are so high</h2>
I agree with much of the analysis of people who think that the evidence from the Robbi Jade Lew hand doesn't give strong reason to believe she was cheating. Most of my disagreement comes from the prior probability I assign to an unknown player cheating, which is higher than most.
Here are some reasons why I maintain such high priors:
<ol>
<li>There are plenty of well-publicized cheating cases.</li>
<li>The base rate of cheating in general (beyond poker) is quite high. (<a href="https://twitter.com/altluu/status/1576327068752965633?s=20&amp;t=Bj91FyOO_j5sgdRc-EalCg">Here</a> is a relevant Dan Luu Twitter thread.)</li>
<li>The infrastructure that keeps live poker safe has been eroding: for example, procedures that ensure dealers pitch the cards correctly are enforced much less rigorously than they were 10 to 20 years ago. (In many rooms they are entirely forgotten.) Whenever someone with expertise in live poker procedures came on Thinking Poker, I would ask about this, and none of them (that I can recall) disputed this view.</li>
<li>Many publicized cases of cheating were discovered because of greedy, shortsighted, or downright silly exploitation of the cheaters' edge. This suggests that more disciplined cheaters in analogous circumstances would not have been caught.</li>
<li>I have non-public knowledge of some incidents involving cheating and other very suspicious events. (And I was never the sort of prominent person who would have known lots of inside information.)</li>
<li>Poker players generally have an incentive to emphasize the cleanliness of the game.</li>
</ol>
Most poker games are clean. The layperson's view (if that layperson's view of poker derives from certain kinds of movies and stories) certainly overestimates how much cheating there is. I would hate for enthusiasts to think that they should not play the Bellagio 2-5 game for fear of being cheated.
I would like for more people to quantify their views here, understanding that a lot of estimation is involved. I have asked: what is the ratio of the probability that, in a given big pot in a high-stakes live cash game, a given player in it:
<ol>
<li>Will misread their despite rechecking their cards before making an all-in call.</li>
<li>Had planned to cheat in that pot and attempted to execute that plan.</li>
</ol>
I think that the first is not more than one order of magnitude more likely than the second. Misreads are common; misreads in big pots after rechecking one's cards are not. Cheating is uncommon, but (alas) not as uncommon as I'd like it to be.

Why my priors about cheating at poker are so high

<h2>Notes on the Garrett Adelstein - Robbi Jade Lew hand</h2>
<ol>
<li>I've been saying for over a decade that poker cheating is more prevalent than most poker players say it is. So my priors for claims of the form "Is X cheating here?" are higher than most people's.</li>
<li>Most of the not-cheating explanations of Lew's play don't address just how inconsistent with reasonable play Lew's hand is. There are many amateur archetypes: good amateur, try-harding amateur, legitimately good amateur, very casual amateur, drunk / drugged amateur, amateur hitting a breaking point against a perceived bully, and so on. Lew's turn play is not consistent with any of those. Different people play differently, and extremely unusual play is not proof of anything, but (again) it is often being mischaracterized.</li>
<li>Specifically, many commentators are missing the fact that Adelstein's shove was for over $100k, which was roughly twice the pot. Both as a matter of fact as as a matter of what various player types would think, this just makes it very unlikely that jack-high nothing would find a reason to call.</li>
<li>Relatedly, the fact that Lew was up over two previous streams is more important evidence than most analyses recognize. That is a very small sample, but it's a lot harder for bad players to put up those results than good ones. Suppose for simplicity that there are only two possibilities: Lew is a very competent amateur or a basically incompetent amateur. I'd guess that these results are about 2 to 4 times as likely for the former than the latter. If I were going to make a more serious study of this situation, I'd work to improve this estimate.</li>
<li>Less concretely, I am with Doug Polk in thinking that a lot of the footage of Lew's tanking looks like "fake tanking" or something more like stalling. (More than anything it reminds me of people stalling in tournaments.)</li>
<li>Again less concretely: the table talk and giving the money back seem more likely given scenarios where cheating is involved than given honest scenarios. I have literally never seen someone give money back in anything like this situation.</li>
<li>This reminds me of <a href="https://www.reddit.com/r/poker/comments/87w8oy/potripper_the_infamous_superuser/">POTRIPPER, the Absolute Poker superuser</a> who (if memory serves) has roughly similar-looking hands.</li>
</ol>
So, cheating appears to be likely given the evidence I know of and my priors. I'd be grateful for information about the situation I might not know or be misjudging.

Notes on the Garrett Adelstein - Robbi Jade Lew hand

<h2>2022 reading review</h2>
3/4 of the way through a wonderful year of reading, I've had time to think about the books again. 
In many cases I think my initial thoughts, either about the book itself or its likely long-term effects on me, were wrong.
Here are some new thoughts about various books. 
The most striking trend to me is that novels that I love when I read them fade from my intellectual view faster than I'd thought they would. (I didn't even bother revisiting The Three-Body Problem, and I haven't for a second thought about picking up either of the sequels, even though I enjoyed the book very much and think highly of it.)
<h4>The Nineties</h4>
I'd say I got this one very wrong when I first reviewed it. 
This is likely for two reasons: Chuck Klosterman is an excellent prose stylist and I love reading about the nineties. 
(Actually, being a nineties kid is one of the parts of my identity I hold most deeply, but enough about that for now.) 
But as I review the book, I think of it as a series of fun, smart GenX takes on the nineties, with too little attention to the mass culture of the decade. 
Klosterman doesn't mention the Macarena, the Backstreet Boys, the Kosovo War, or "MmmBOP."
When he mentions the fact that Cracked Rear View sold 21 million copies, he dismisses it (and related mega-hits) as "historical misdirection." 
What was really happening, Klosterman says, is that rock music was losing its "dominance... as an ideology." 
That's probably true. 
But a lot of culture and a lot of influence happened during that shift. 
It accounts for a lot of what the nineties were about and felt like. 
So, whatever this book's merits, it's not a sustained and successful treatment of what the decade was all about.
<h4>Lonesome Dove (<a href="reading-notes-lonesome-dove.html">initial review</a>)</h4>
I just finished this one a few weeks ago. 
I still believe it to be a great book. 
The epigram seems to me to get the themes right: its significance to me is as a treatment of freedom, law, choice, and the relationship between all of those.
It is remarkable how unfree many of the characters seem, and not just because they might die at any moment. 
Their choices often seem, if not forced upon them, not the product of anything we would recognize as personal deliberation.
The defining image of Lonesome Dove might be that of a human riding a horse, asleep on or tied to it. Perhaps they want to be there; perhaps they chose to be there (directly or indirectly, recently or long ago); perhaps not. Some combination of human, horse, and other natural forces will take them somewhere. They are quasi-free. They could really use some good institutions.
(That epigram: "All America lies at the end of the wilderness road, and our past is not a dead past, but still lives in us. 
Our forefathers had civilization inside themselves, the wild outside. We live in the civilization they created, but within us the wilderness still lingers. 
What they dreamed, we live, and what they lived, we dream.")
<h4>Crossroads</h4>
I think I overestimated this one, too. It's an admirable, meaningful novel, but for whatever reason it just hasn't stuck with me. 
An exception: the character of Russ Hildebrandt pops to mind often, and with him Franzen really hit a certain strain of semi-well-intentioned, pathetic psychology worth digging into.
I stand my my view that the book is a sort of exploration of ethical spaces that the contemporary political landscape doesn't permit and, simultaneously, a damning critique of ethical life (especially mainstream masculine ethical life) before it was modified by contemporary political awareness.
<h4>How to Change (<a href="reading-notes-how-to-change.html">initial review</a>)</h4>
I still think it's in the top tier of this kind of pop science / self-help book, but I'm struck by how little I retained. 
I'll say it's my failure, not the book's.
<h4>From Front Porch to Back Seat (<a href="reading-notes-from-front-porch-to-back-seat.html">initial review</a>)</h4>
I'll stand by my initial impressions here. 
I'd now add that I think I have a much more nuanced view about the sociology of monogamy and the economic roots and effects of "going out" as a mode of dating (one among many).
<h4>The End of Solitude (<a href="reading-notes-the-end-of-solitude.html">initial review</a>)</h4>
I read this only recently, but I don't want to revise anything I said, especially the praise. 
One idea from the book that's particularly stuck: that college coursework and other traditional infrastructure is a mere vestige, which few parties to those courses have much reason to care about, and onto which a certain kind of elite training is being "retrofitted."
<h4>Talent (<a href="reading-notes-talent.html">initial review</a>)</h4>
I'll stand by my initial impressions here, too. I still view this primarily as a book about cultivating and testing my own skills.
One broader point is that I think of Talent, Crossroads, and to some extent even The Nineties as books not just related to but about the systematic oppression of people who are not white men; if my quick tally is correct, over half of the books I've read that have been written in the last couple years fit this description. Culture is a powerful thing.

2022 reading review

<h2>Reading notes: The Baseball 100</h2>
This is my new favorite baseball book ever. (Literally.)
It's about the players. It's also sort of about the rankings, and sort of not. Posnanski mostly ignores methodological issues until ~90% of the way through the book. His explanations for the rankings, when they come, are steady and reasonable, but also involve a lot of shrugging his shoulders. This all reminds me of the economic/philosophical problem of interpersonal comparisons of utility: there's basically no way to do it right, but not doing it at all is also obviously not right. The Baseball 100 gets this balance basically right, even (or perhaps especially) when the ratings look most like a cop-out.
So, for example, Jackie Robinson is in 42nd place; he wore number 42. How much more can be said? By career MLB WAR, he's 103rd or so among position players. By other standards, he's an easy #1. The more I think about Posnanski's approach, the more I like it: Put him in the top half, write a beautiful and insightful portrait, make it clear you're honoring the number, and get on to #41. 
A major success of the book is keeping the reader's attention on the portraits. There's a lot here about family culture and some local culture, but not many sweeping claims about American culture (no "Wade Boggs was a product of the sixties"). Posnanski earns your interest and focus by making the people in the book pop, and he doesn't cash it out for a cheap or boring point about politics or culture. (Of how many recent books could that be said?)
Two themes run through the book: parental influence and the shame of baseball's segregated past. As for the former: Posnanski writes beautifully about childhood. As for the latter: what else can he do? In a book that's at all about rankings, not talking about segregation a lot would be like talking about 2020 college football without talking about COVID a lot.
If anything, I think Posnanski's "take the best guesses you can with all the evidence you have" approach should have taken him even farther. Charlie Gehringer really comes ahead of Martin Dihigo, Cristobal Torriente, and Turkey Stearnes?
This book made me think often of Chuck Klosterman's But What if We're Wrong?, which is the best treatment I've seen of the strangeness of cultural influence. Besides the top 100 themselves, there are anecdotes involving so many long-ago MVPs and statistical standouts. Many of those players' names ring loud bells in my head and, I'm pretty sure, others'. They've kept their portions of fame. Many others are absolute blanks to me. I have no real idea what accounts for this. Posnanski, like Klosterman, does a great job laying out mysteries of influence, not just in cases like Arky Vaughan (why is such a great player so obscure?) but also in cases like Roger Clemens: Why isn't it a bigger deal that he threw a bat at Mike Piazza in the World Series? How exactly will Clemens be remembered?
Posnanski's answers aren't always satisfying, but maybe there aren't answers to be found; maybe influence is just that deeply arbitrary. What's more important is that Posnanski has the ability to paint portraits so well and freshly that he's in a position to see those questions in the first place.

Reading notes: The Baseball 100

<h2>On stop-losses</h2>
Byrne Hobart has <a href="https://www.thediff.co/p/stop-losses-as-intellectual-honesty">a useful analysis</a> [$] of stop-losses today. It's as fun as it is useful.
Poker players have long used (and debated, and been proud about not using) stop-losses. How do Byrne's points look through the poker lens?
First, a big loss means that your leverage has changed. The (rough) poker translation of this is that your edge in a game relative to your bankroll has changed. This is strikingly absent from a lot of poker discussion. But a large loss is often at least 10% of a reasonable bankroll, and often a much bigger portion of the bankroll someone is actually using. Even if there's still a justification for playing the game, the decision relative to some smaller game often looks different.
Second, a big loss means that there's information you're missing, so persisting includes a tax on your finite attention. Sometimes this just isn't true in poker (if, e.g., your loss is due to simple bad beats). But this is more true than poker players think: game conditions when you're losing are often different than you took them to be. And even if they weren't, the fact of the loss itself changes them, because people play differently against opponents with losing images than with winning ones.
The way I've often thought about this is different still, but related to each of these. When you observe an extreme outlier, you should usually vastly reduce your credence in the model with respect to which the event counts as an outlier. In crude terms: suppose that you're 95% sure that some model of the situation is right. If you observe an event that is a four-sigma outlier according to the model but much less likely if the model is wrong, then (by Bayes' theorem) your model is almost certainly wrong. So if you were making commitments on the basis of that model, you should stop doing so.
In poker terms: if you're stuck that bad, it's much likelier than you thought that (i) you're on tilt, (ii) you're not as good as you think you are, (iii) you're not as good in that game as you think you are, (iv) you're getting cheated, or (v) something else is going on that you haven't even thought of.
About a decade ago, it happened pretty often that baseball teams were making comebacks (to win divisions or make playoffs) that the preferred models suggested were 100:1 (or much worse) underdogs. It was disappointing to me how many people accepted the conclusion that they were living in an age of miracles. They would have done better to reject the models.

On stop-losses

<h2>Reading notes: The End of Solitude</h2>
Read William Deresiewicz if you care about English prose, argument, higher education, politics vis-a-vis education, or anything else he happens to be writing about.
Misc. notes:
<ol>
<li>These really are essays. They cohere; they have arguments. It's a joy to read someone who is, fundamentally, not a take-generation machine or some other sort of content monster. I'd group him with <a href="on-reading-the-diff.html">Byrne Hobart</a> or Ian Mueller, whom Stephen Menn described as a "sporadic" <a href="https://www.philosophie.hu-berlin.de/de/lehrbereiche/antike/mitarbeiter/menn/ian-mueller.pdf">in the Diogenes Laertius sense</a>. Deresiewicz has his commitments and beliefs, but fundamentally he is an extremely active reader and intellect who synthesizes his intellectual life for the rest of us. Reading folks like this is one of the great intellectual joys in my life. It's heartening that there are (I think) more and more of them around these days.</li>
<li>The essays I'd read before (in most cases, roughly 10 years ago) feel very different here in 2022. Most obviously, COVID has given new urgency and relevance to questions of what solitude is, how to do it properly, and whether we can have too much of it. So many people have found themselves surprised by what it's like to be alone, physically or otherwise. The End of Solitude is, so far, the most important COVID book (both "book that came out during COVID" and "book about COVID-related subjects") I've read, for having the most to say about these issues. (In case you're curious, #2 on that list is <a href="reading-notes-the-last-days-of-roger-federer.html">The Last Days of Roger Federer</a>.) </li>
<li>Deresiewicz writes from anti-capitalist, anti-neoliberal commitments. I'd say that mainstream leftist politics (even those strains that get branded as "extremist") have moved pretty far away from Deresiewicz's views in the last decade--however much they use "capitalist" and "neoliberal" as slurs. Sustained critiques of capitalism and neoliberalism that don't rest on identity politics or certain other prominent political stances are less common than they used to be, and this is the best in recent memory. (Deresiewicz does, however, have some things to say about identity politics itself: across various essays, he critiques it as the consolidation and exercise of a certain strain of elite power. Like it or not, he has a lot of argument and evidence behind the view.)</li>
<li>I am in the position of, on the one hand, seeing Deresiewicz as a breath of fresh air and, on the other, reading page after page about how so many of my values, goals, and ideals are delusional and/or evil. If you are similarly situation but prefer not to read many dozens of pages about how misguided you are, may I recommend <a href="https://www.amazon.com/Jane-Austen-Education-Novels-Friendship-ebook/dp/B004IYIUQA">A Jane Austen Education</a>? What I actually recommend is reading it anyway, but one can't be scolded into a deep engagement with the best arguments against one's life structure and value system. That requires ethical development and the liberal arts--which brings us back to The End of Solitude.</li>
<li>There's a lot more than the headline topics in the book. Two unexpected joys were "Hunting the Whale," about the novel and recent books about the novel, and "A Jew in the Northwest," about being a Jew in the Pacific Northwest (including notes on Malamud and Leslie Fielder).</li>
<li>One metric I use to reflect on my reading is how much of my mental life a book takes up when I'm in the middle of a book but not at the moment reading it. The End of Solitude scores very high here.</li>
<li>As I write this, it's my <a href="2022-favorites.html">second-favorite book</a> of the year. I imagine Deresiewicz wincing at my tendency to rank what I read, but I'll <a href="on-ranking-things.html">stand by the habit</a>.</li>
</ol>
Finally, a few striking passages:
<blockquote>
Youth, now, is nothing more than a preliminary form of adulthood, and the quiet desperation of middle age has been imported backward into adolescence.
</blockquote>
And:
<blockquote>
Unlike the campus protesters of the 1960s, today’s student activists are not expressing countercultural views. They are expressing the exact views of the culture in which they find themselves (a reason that administrators tend to be so ready to accede to their demands).
</blockquote>
And:
<blockquote>
To put it another way, Portland does not seem to have any grown-ups. Sure, there are people in their forties and fifties and seventies, but there isn’t anyone who represents the past, and the weight of the past, like my old-timers and Italian grandmothers. There isn’t anything that represents the past.
</blockquote>
And:
<blockquote>
Elite mass culture hardly even anymore pretends to be interested in art—in art, that is, as opposed to entertainment, high art as opposed to kitsch. Art is too hard, too subtle, too complex, too time-consuming, altogether too recalcitrant. The professional would rather watch Netflix; the “cultural critic” would rather pontificate about the TikTok trend. Rosenberg didn’t think that kitsch was even worth bothering to attack. Now it rules the world.
</blockquote>
Highly, highly recommended.

Reading notes: The End of Solitude

<h2>Reading notes: Lonesome Dove</h2>
This is the best thing I've read in 2022, which is shaping up to be the best reading year of my adult life. Easy <a href="100-books.html">top 100</a> book: probably #25 or so, though I'm historically bad at predicting the staying power of a book I just read.
I have very little original to say about the book, except that it is more evidence about <a href="on-long-books.html">the value of long books</a>.
Very highly recommended.

Reading notes: Lonesome Dove

<h2>A Shapley example</h2>
I've <a href="why-dont-people-talk-about-the-shapley-value-more.html">been wondering lately</a> why we don't think about Shapley values more. 
The argument is, in brief, that whatever its flaws, it's the best algorithm we have for computing something of great interest: how to attribute the value generated by a whole to the parts of that whole.
Consider the "glove game": there is one left-handed glove and two right-handed gloves. 
A matched pair is worth one unit of value. 
How much does each glove contribute to that unit of value?
It <a href="https://en.wikipedia.org/wiki/Shapley_value#Glove_game">turns out</a> that the left-handed glove is assigned 2/3 of the unit and each right-handed glove 1/6. 
This is already pretty surprising to me: I might have guessed 1/2-1/4-1/4 instead.
Now let's generalize the situation: more right-handed gloves join the team, so that there is one left-handed glove and N right-handed gloves. 
Figuring out the Shapley values here is a nice elementary exercise. 
It turns out that the left-handed glove is assigned N/N+1 and each right-handed glove is assigned 1/(N * (N + 1)).
I would not have guessed this (at least not before I'd lived with Shapley values for a while). 
More concretely: if two more right-handed gloves show up, the single left-handed glove gets much more valuable: its Shapley value goes from 2/3 to 4/5.
And each of the right-handed gloves gets much less valuable: they each go from 1/6 to 1/20.
One more time: this isn't a claim that Shapley values are perfect. 
But the uniqueness claim is so strong. 
Interpreting the requirements of that uniqueness claim in this application: The null player assumption requires us to assign the other (non-glove) objects in the room should get assigned values of 0. 
The efficiency assumption requires us to make the values add up to 1. 
The symmetry assumption requires us to give the same value to each right-handed glove (and similarly for left-handed gloves, if we generalize the problem to add those).
For the linearity assumption, suppose we make a matching pair of gloves today and tomorrow, assigning one unit of value to each pair. 
The assumption requires us to give the same result if we consider these as two different value-creation events or one event that is spread out over two days. 
(We can't restribute value by playing metaphysical tricks in individuating those events.)
Those are very mild assumptions. And if you accept them, the Shapley assignment of values is unique.
A few lessons jump out at me here:
<ol>
<li>The left-handed glove's Shapley value gets bigger when more teammates show up.</li>
<li>Team size matters a lot. </li>
<li>Especially if you're doing highly interchangeable labor with those teammates.</li>
</ol>
Finally, a meta note: This reminds me so much of poker, where highly simplified "toy games" are used as intuition builders.
There's a real skill to using these toy games correctly. 
Most players never take them seriously. 
A few spend much too much time thinking about them. 
Finding the right balance here is an underrated cognitive skill.
(My former co-host <a href="https://twitter.com/thinkingpoker?lang=en">Andrew</a> is one of the best at this.)

A Shapley example

<h2>Why don't people talk about the Shapley value more?</h2>
Here's an argument that the Shapley value is underrated:
<ol>
<li>It's really important to figure out how to divide credit for the performance of a whole to the parts of that whole.</li>
<li>The Shapley value is, under pretty mild constraints, the uniquely best way to do that.</li>
<li>Those "mild constraints" <a href="https://en.wikipedia.org/wiki/Shapley_value#Properties]">really are pretty mild</a>.</li>
<li>Yet people barely talk about it.</li>
</ol>
I think that last assertion is pretty obvious, but in case you want evidence, <a href="https://marginalrevolution.com/?s=Shapley">here</a> is a Marginal Revolution search for "Shapley." Its few results are mostly coverage of a Nobel Prize and Shapley's death. There is no direct application of the Shapley value (the closest thing is some mentions of the <a href="https://en.wikipedia.org/wiki/Gale–Shapley_algorithm">Gale-Shapley algorithm</a>, again mostly in the form of Nobel coverage).
You might think that Shapley valuation is too much of an idealization to be useful. 
But I don't see how the Shapley value is worse in this regard than any number of other widely used and discussed tools from economics. 
In many respects it's better! 
(Again, because of the strength of the underlying uniqueness theorem.)
<a href="https://kpknudson.com/my-favorite-theorem/2018/12/12/episode-32-anil-venkatesh">Here</a> is an episode of My Favorite Theorem (a good podcast!) where Anil Venkatesh discusses the Shapley value and its many applications, including to the valuation of power-ups in video games.
There seems to be some use of the Shapley value in evaluating machine learning models (<a href="https://christophm.github.io/interpretable-ml-book/shapley.html">here</a> is a blog post I find useful; a YouTube search will also turn up results).
Why isn't there a lot more of this? Why can't you, e.g., evaluate results in baseball games by considering observed results (of pitches, games, or whatever) as results of coalitions, and trying to determine Shapley values correspondingly?
My view of baseball researchers is that they'll try to apply any quantitative technique to baseball. My view of Tyler Cowen is that he'll apply any useful model, certainly over many years of blogging and speaking. What is going on here? Am I missing some fatal flaw in the Shapley value?

Why don't people talk about the Shapley value more?

<h2>Reading notes: The Last Days of Roger Federer</h2>
<ol>
<li>Not my favorite book written during COVID--that's The Baseball 100--but my favorite COVID book (so far).</li>
<li>The central narrative decision here was to organize the book loosely. It's a lifetime of aesthetic-philosophical reflection, as it relates to various kinds of endings, organized in a meandering but satisfying way. The decision was a good one.</li>
<li>If this were a top-150 book for me (it narrowly misses, I think), I'd have to revise my <a href="books-i-like-more-than-other-people-do.html">books I like more than other people do list</a>: it would come in #3. It is not easy to come in lower than both Joyce and Franzen on Goodreads.</li>
<li>Nonetheless, I think this is an underrated book format. When people spend (most of) a lifetime building up human capital, I want them to share it. When I look back on good conversations, I rarely regret that they weren't more tightly focused. So too with this sort of semi-memoir.</li>
<li>A lot of writing about Nietzsche is inaccessible to me (or at least I don't want to access it). The reflections here, however, are useful and memorable--and fun.</li>
</ol>

Reading notes: The Last Days of Roger Federer

<h2>On accidentally starting a newsletter</h2>
This was written after I migrated to Ghost. That turned out to have its own problems; I now use <a href="notes-on-writing-a-static-site-generator.html">a static site generator I wrote myself</a>.
I've struggled with my online-writing toolchain. My ideal tools would:
<ol>
<li>Make writing and publishing new things easy;</li>
<li>Help me prevent data loss;</li>
<li>Make it possible to make natemeyvis.com more than a collection of writings.</li>
</ol>
I have tried WordPress, hand-rolling my own site, and many things in between. Long story short: I tried Ghost and it stuck.
In my hurry to make the default design palatable, though, I didn't notice that I left in a "subscribe" link. And people subscribed. Hello, and thanks! I'm grateful for the chance to write for all of you (and the whole Internet).
I plan to keep going here indefinitely, regardless of subscriber count. My views about this, I think, invert a common way of thinking about public writing.
People tend to say that if an Internet writing project peters out, it's (1) a failure of the project but (2) a consequence of normal, healthy life progress. Both of those seem wrong to me here. First, I don't think that the end of a writing project is intrinsically regrettable. (Most projects are supposed to end!) I worry that valuable work goes unpublished because we don't have better infrastructure (including social infrastructure) for projects longer than an article but shorter than a "forever blog."
But--and here I'm only talking about myself--I disagree with (2) also. Think of this site as the output of a funnel with various intellectual inputs. The funnel requires various kinds of intellectual effort; time spent refining and writing; and the desire to share the outputs.
Many intellectual experiences will not make it out of the funnel. Sometimes essays just don't come together; many thoughts are better left private; and even more thoughts are simply not worth sharing. Yet there is no part of that pipeline that I'd want to be temporary or optional (for me, that is)--the consumption, effort, synthesis, and sharing all seem clearly better to be doing than not doing.
So! I'm here to stay, if all goes well. Like <a href="https://www.stratechery.com">Ben Thompson</a>, I'm thinking about this as a Web site that derivatively has a newsletter, but I'm humbled by the thought of people reading this in any form. As always: if you aren't sure whether to email me, you <a href="mailto:natemeyvis.gmail.com">probably should</a>.

On accidentally starting a newsletter

<h2>Reading notes: The Three-Body Problem</h2>
<ol>
<li>It's pretty rare to feel compelled to go read the thing everyone was talking about 7 years ago. But I was, and it paid off.</li>
<li>This is my favorite science fiction novel ever. (Note that I am not a science fiction guy, and this still won't make the <a href="100-books.html">top 100</a>.)</li>
<li>There's almost no humor in the book (unless I'm just missing something, which could easily be the case, given how little I know about sci-fi and about Chinese literature).</li>
<li>Besides the overall "what the heck is going on" question, the narrative generally resolves one mystery while presenting another. This seems to owe something to the structure of video game narratives.</li>
<li>Of all the fiction I've read during my software carrer, this is the book with the most overlap in readership among my colleagues.</li>
<li>It's the most recommendable book I've read this year.</li>
</ol>

Reading notes: The Three-Body Problem

<h2>Listening notes: Test and Code 191</h2>
Eerily, <a href="https://testandcode.com/191">Test and Code 191</a> echoes some of <a href="notes-on-writing-a-static-site-generator.html">my thoughts on writing a static site generator</a>. 
It's entirely possible that they were recording the show as I was writing the post.
Test and Code is a real gem of the software podcast world. 
It's all steak and no sizzle. 
And I can prove <a href="my-information-diet.html">I thought so</a> even before I got the odd dose of flattery that is hearing one's slightly controversial beliefs affirmed on a respectable platform.
Episode 191 covered, among other things, the intersection of static site generation and testing.
My thoughts about writing the SSG powering this site grew out of <a href="15-notes-on-testing-software.html">my revised thoughts about testing</a>. 
I used to have an idealized view of testing: software breaks into atomic components; you should test all the atoms thoroughly; you should also test various relations among those atoms. 
I'm more pragmatic now. 
As I find things I need to be true of my code, I write tests for it. 
And when something breaks in my code, I write a test to check for that failure.
The latter I think of as "lazy testing," not in the psychological sense of "lazy" but as in "lazy evaluation," "lazy deletion," and the like. 
There are applications where finding and testing every edge case matters.
Often, though, a unit of testing time is better spent elsewhere.
A surprising benefit of this approach is that it keeps me focused on the question of how I can actually make sure the software works.
The surprising part is that we can lose focus on that question in the first place. 
But we can. 
It's all too easy to become a fanatic about testing in <a href="https://www.google.com/search?q=santayana+fanatic+redouble+efforts+source">the Santayana sense</a>, "redoubling your efforts when you have forgotten your aim."
Relatedly, Okken and Wisti make a point I think is underrated: learn coding by coding smoething that matters to you. 
If you are doing something you care about, it's easier not to forget your aim, and to avoid that sort of fanaticism. 
They even echo one of my examples: using Pytest to make sure links work. 
Wisti seems to be on the same journey that, for me, terminated in writing my own SSG. 
("Terminated" in the sense of "continuing indefinitely, but more pleasantly.")

Listening notes: Test and Code 191

<h2>My information diet</h2>
Last updated 2022-07-01.
This page exists because:
<ol>
<li>People ask me about it;</li>
<li>It's a way to keep myself honest;</li>
<li>It's an efficient way to give a sense of who I am.</li>
</ol>
<h4>Books</h4>
Roughly an hour a day. Currently:
1. Three Body Problem
1. The Last Days of Roger Federer
1. Pride and Prejudice (reread)
(Dipping in and out of roughly a dozen other books, each of which I'm an underdog to finish, but read fine this way.)
<h4>Newsletters</h4>
<ol>
<li>The Diff (Byrne Hobart), <a href="on-reading-the-diff.html">as often as possible</a></li>
<li>Money Stuff (Matt Levine), about half the time</li>
<li>Bits about Money (Patrick McKenzie), eventually</li>
<li>Stratechery, in podcast form (see below)</li>
<li>Parent Data (Emily Oster)</li>
<li>The Honest Broker (Ted Gioia)</li>
</ol>
<h4>Blogs</h4>
<ol>
<li>Dan Luu, every word, unless I don't have time to work through technical details</li>
<li>Erik Bernhardsson, everything that isn't a deep dive into something that would take a lot of time for me to get up to speed on</li>
<li>Marginal Revolution, in the manner of a daily newspaper</li>
</ol>
<h4>Podcasts</h4>
<ol>
<li>Conversations with Tyler, roughly 2/3 of the time</li>
<li>Accidental Tech Podcast, skipping around a lot</li>
<li>EconTalk, only occasionally (but the ceiling is very high)</li>
<li>Dithering, basically always</li>
<li>Stratechery, roughly 2/3 of the time (eventually)</li>
<li>Test &amp; Code in Python, very frequently</li>
<li>Under the Radar, almost always</li>
<li>Invest like the Best, when I hear a compelling recommendation for a specific episode</li>
<li>The Talk Show, occasionally</li>
<li>The Tim Ferriss Show, maybe 5% of the time (but the ceiling is high)</li>
<li>The Rabbit Hole, maybe 1/4 of the time</li>
<li>Mac Power Users, maybe 1/3 of the time</li>
<li>Hanselminutes, almost never but the ceiling is high and I love how consistent he is</li>
<li>Coding Blocks, only occasionally and skipping around a lot</li>
<li>Robot or Not, often</li>
</ol>
<h4>Social media</h4>
<ol>
<li>Twitter, almost entirely from a tightly curated list of ~25 people who respect the mental health of their readers (or, at least, whom I find informative and not gratuitously bothersome).</li>
<li>A little bit of Facebook</li>
</ol>
<h4>Newspapers</h4>
The Wall Street Journal, perhaps 15m / day
Various articles I'm linked to from Twitter

My information diet

<h2>Notes on writing a static site generator</h2>
<h3>Why write a static site generator?</h3>
<ol>
<li>Because <a href="https://www.natemeyvis.com/on-dependencies-in-small-projects">dependencies in small projects</a> are overrated.</li>
<li>For Marie Kondo reasons. It makes writing and maintaining my site pleasant and joyful. Other SSGs might be fine pieces of software, but they decidedly did not spark joy for me.</li>
</ol>
<h3>What have I learned?</h3>
<ol>
<li>Addressing some problem you actually have remains <a href="software-faq.html">a great way</a> to learn software.</li>
<li>Here's a testing philosophy: "Test the formal correctness of smaller parts of your code with suites of small tests. Test that these parts are interoperating correctly, and handling the right data, with other tools: smoke tests, dashboards, etc." You probably don't literally believe this, but a lot of us default to something like it. The SSG has, instructively, obliterated this view. Pytest is a wonderful tool for, e.g., ensuring that all my (relative) links work.</li>
<li>The SSG should be able to handle tens of millions of words or tens of thousands of posts. Not more, ever. (Alas.) The site might need to handle unpredictable and large scale, but its construction won't. Utterly divorcing "this is well-made software" from "this software can handle arbitrary scale" has been instructive. Remarkably few problems go away!</li>
<li>In many applications, separating the logical form of data from its persisted form is essential. Here, less so. I went down a wrong path of instinctively applying some patterns to accomplish that. It was an instructive failure, both psychologically ("why did I do that so reflexively?") and technically ("why don't I need this here?").</li>
<li>More generally: my other work is not at all like writing an SSG. Taking on a real project with a new structure has been eye-opening. I often see advice to stay sharp by learning new languages or new tools, usually with toy projects or tutorials. I find it much more illuminating to do diverse and real projects--usually, but not always, with the tools I know. The cognitive benefits of tackling a real problem are (for me, at least) much greater than those of exposure to a new tool. And I find it natural and pleasant to let technical needs in real projects drive me to learn a tool, rather than vice versa.</li>
</ol>
However many rough edges remain, the project is a success. I have a tool I can use and improve indefinitely. And it really hasn't taken that much longer than learning to use some existing SSG. I am struck by how many Web sites outgrow the software they're made from (or seem indefinitely and tragically constrained by that software). I'm pleased to eliminate that category of problems.

Notes on writing a static site generator

<h2>On estimating the value of GitHub Copilot</h2>
Forget, for a second, whether GitHub Copilot is sustainable or not, ethical or not, and so on. 
What's it worth? 
That is, supposing Copilot functions as advertised and is legal and ethical to use, how much does it help a programmer?
I suspect this value is overstated, both in general and (especially) among people who are excited about AI. 
That's because people are misunderstanding the value of autocomplete. 
More powerful, but less predictable, autocomplete is only a good tradeoff if the "more powerful" is way more powerful and the "less predictable" isn't too bad:
<ol>
<li>Most importantly: the way we generate value is by writing maintainable, intelligible code. The time savings of a great autocomplete are usually single-digit seconds. The time costs of having something that nobody ever properly understood in your code base are easily measured in the tens of hours. It doesn't even have to be a bug: it could be something needing changing in the ordinary course of development. This way of thinking is a crude simplification--there are more possible outcomes than these two. But when the bad outcomes are four orders of magnitude worse than the good outcomes are good, they better be very rare. Much rarer than Copilot's will be.</li>
<li>The time savings of autocomplete is less important than its ability to keep you in a flow state. Less predictable autocomplete is likelier to break your flow.</li>
<li>The cases where Copilot can offer the biggest savings--efficient generation of boilerplate code--are likely to be less relevant over time. Better frameworks and better development practices will (we may hope) remove more and more of these tasks. And if they don't, IDEs are likely to provide better support for boilerplate generation by traditional means. You might disagree with some of this; the broader point is that AI does not have as distinctive an edge in the case of snippet / boilerplate generation as it does in other applications.</li>
<li>The best users of Copilot are likely to be expert users of other autocomplete tools; this also diminishes the value Copilot provides.</li>
</ol>
Note that the above arguments do not apply to DALL-E or other exciting AI / ML tools, which have very different payoffs and risks, and which replace very different kinds of workflows. My argument is not that AI in general is too risky to use, but rather that Copilot is fighting excellent alternatives and tackling a problem with an unfavorable cost-benefit profile for AI.

On estimating the value of GitHub Copilot

<h2>On the death of new music</h2>
Ted Gioia's <a href="https://tedgioia.substack.com/p/is-old-music-killing-new-music">Is Old Music Killing New Music?</a> is wonderful. 
(And Ted Gioia is wonderful, and the newsletter is wonderful.) 
The best introduction to the piece is the introduction of the piece itself (it's just a click away!).
Its main explicandum (the "death" of new music) is a few facts: in 2021, we collectively listened to more old music and less new music than in 2020, not only in terms of share but in absolute terms.
Ted expertly analyzes the decline of new music. 
But I'm interested in the title question, which he doesn't really answer. 
In whatever sense new music is dying, is it old music that's killing it?
I'm tempted by this line of reasoning:
1. Music benefits a lot from being a focal experience (or at least from being really famous).
1. We have fewer focal experiences than we used to. It's harder for art to get really famous.
1. So you'd expect new music to get less popular.
1. But old things' focality doesn't go away (at least not quickly), and neither does the human desire to enjoy music that changes the world (or, at least, music that is A Big Thing).
1. So new music gets a bit less popular, and old music steps in to fill the void.
Meanwhile, the difficulty of making a big cultural impact with music changes how it is supplied (<a href="https://marginalrevolution.com/marginalrevolution/2022/01/a-simple-theory-of-culture.html">here</a> are some brief thoughts from Tyler Cowen on that subject).
There are, over time, fewer of us who lived through a certain kind of mass culture. 
It can feel gauche to say that one thing you want from music, at least sometimes, is the feeling that many millions of other people have also been moved by it. 
But a lot of us do want that. 
One often hears about "fragmentation," algorithmic pigeonholing, and so on: mass culture is turning to shards. 
In analyzing the precise shapes of the shards, we can miss the simple fact that the former whole is gone.

On the death of new music

<h2>On Excel, context, and talent</h2>
My post on <a href="https://www.econlib.org/no-one-cared-about-my-spreadsheets/">Bryan Caplan's model</a> drew a lot of feedback. 
Some expansions and clarifications:
What I most remember from <a href="https://conversationswithtyler.com/episodes/bryan-caplan/">Prof. Caplan's Conversation with Tyler</a> is what you might call either an interdisciplinary tendency or a willingness to consider a question itself as opposed to the question as discussed in a single literature. 
This raises my confidence that he will revisit his modeling methods--or at least that he, of all people, should.
You can think of a Caplan-style Excel model in at least two ways: a traditional academic artifact or a way of making claims about the best inferences to make from the data, all things considered.
If you take it to be the latter, your work will or should be judged against the state-of-the-art techniques in managing data. 
Do you get from data to results responsibly?
Are the computations doing what you think you're doing? 
Can you prove it? 
Are your data versioned and managed responsibly? 
Whether or not you were trained that way, that's the pond you're swimming in.
Aside: When I worked in bioinformatics, this kind of situation came up all the time. 
Someone would present a model and get asked some question like: 
Why didn't you use machine learning? 
Why use the 2011 data and not the 2014 data? How did you handle edge cases? 
What happens if you tweak the age cutoffs? 
And there were, broadly, two kinds of answers: (1) "Because that's how I made my model" / "Kindly go ask my grad students" and (2) something that shows that those questions really do concern them. 
(Imagine if Caplan's model needed to work on data that are eight orders of magnitude bigger.)
There are truly hard questions here about division of intellectual labor here. 
It's hard to imagine reading <a href="https://www.amazon.com/Shaping-Deduction-Greek-Mathematics-Cognitive/dp/0521541204">Reviel Netz</a> but with the quantitative work not done by Reviel Netz. 
There will be cases where the costs of communication and synchronization across people will mean that the best solution really is for the Caplan / Netz figure to use whatever tools they know.
Which is another argument for T-shaped competence. If there really is no good alternative to Caplan doing the model himself (though I think there is), then the value in turning <a href="https://twitter.com/detectiveenters/status/1494102721259057152">this</a> into something better is enormous. And the unit of energy Caplan spent researching the fourth-most-relevant academic discipline to his education research probably would have been better spent improving this side of things.
And this is also brutal evidence for <a href="on-the-scarcity-of-context.html">context being that which is scarce</a> (here this plays out very literally!). I'm not surprised at <a href="on-scarcity-and-regionality.html">the connection between T-shaped competence and context</a>.
An important lens on this episode is that of Bryan trying attract the best talent to his Case Against Education project. In some respects he succeeded, but on this quantitative side of things he (by his own lights) did not. (See my original post for more on the market for attention in this domain.) This helps me understand why Tyler Cowen is thinking so deeply about context while he's also thinking about cultivating and finding talent.
Keep in mind that part of Caplan's point is not just that nobody paid attention to his spreadsheets but that people did pay attention to his conclusions, and that the disparity is troubling. Surely he's right about that.
A constant lesson of the Internet age (and the pandemic era) is that it's hard to reason about, prepare for, and adjust to growth. A lot of human capital is stored in people--basically, all of us--who in some way need to do things differently if we want to optimize our intellectual output to the current world (and the future). Whatever the right solution here is, it certainly involves a lot of kindness and intellectual charity.

On Excel, context, and talent

<h2>On poker's comparative advantage</h2>
Jason Strasser gave [a great interview](https://www.youtube.com/watch?v=ObF6w8sNyJo) recently where he noted that poker players  think they outperform non-poker-players because they're fluent in calculating odds, but their comparative advantage is actually in having experienced painful losses.
This phenomenon is more general: I've never known a field where the general wisdom about where that field's intellectual edge is tracked reality. 
(The exception is maybe pure math, but I'm not qualified to judge.)
Outside the context of trading (what Jason was talking about), the comparative advantage of a training in poker is a bit broader. Here's how I see it. Note that this is not "what I learned from poker" but "what I think poker trains distinctively well":
<ol>
<li>How to lose, often painfully (Jason's answer).</li>
<li>How to see yourself fail and, ideally, learn from it (this is different from #1).</li>
<li>How not to conflate .1%, 1%, and 4% probabilities of things (and similarly for other probabilities).</li>
<li>How to synthesize different kinds of evidence ("there are eight clubs left in the deck, he called a three-bet before the flop, and he really doesn't want to miss his dinner reservation").</li>
<li>How to figure out where the value in a situation is really coming from (including how to avoid the <a href="https://en.wikipedia.org/wiki/Streetlight_effect">streetlight effect</a> of conflating importance with salience or quantifiability).</li>
</ol>

On poker's comparative advantage

<h2>On studying for your upcoming job: objections and replies</h2>
Here I collect objections that arose <a href="https://news.ycombinator.com/item?id=31856512">on Hacker News</a> in response to <a href="https://news.ycombinator.com/item?id=31856512">this short argument</a>. Thanks to everyone who replied.
Q1. "But of course studying a language is good!"
A1. Yes, it is. 
Mastering a language is wonderful, and being totally ignorant of the language you'll be using is bad. 
The question I was answering, however, is whether a given hour is more efficiently spent learning a language or a tool, supposing you want to use that hour to prepare for an upcoming job. 
For the reasons I lay out, and especially because it's very hard to predict which parts of a language will be used and how, studying tools is likely a better bet.
Q2. "Everyone should know [language X]."
A2. See A1. 
Also, here as elsewhere, you can't infer from "any programmer would benefit from knowing X" to "every programmer should learn X." 
The latter requires an argument that X is not just good but better than anything else a programmer should be doing with that time. 
Q3. "If you ask the hiring manager how to study the language, you'll be studying just what you need."
A3. Yes, this is better than just guessing.
But the hiring manager (i) might not know exactly how the language is used and (ii) often has strong incentives to oversell the quality of the existing code base.
The last time I tried this, Effective Java was recommended to me.
The Java I encountered was... not "Effective."
Q4. "This is just your experience."
A4. I should have been clearer about this. 
Although I've made this mistake many times, I'm not just writing about myself but about many other people I've seen do this. 
The impetus for writing this up was a person asking me what they should do to learn language X, having accepted a job offer to work in that language. 
So, this doesn't come out of rigorous research. 
But it's definitely not just me.
Q5. "But in Python, there is only one good way to do things."
A5. That's less true than people say, and less true than it used to be. 
(Just one example: whatever else you think of <a href="https://peps.python.org/pep-0622/">structural pattern matching</a>, it creates more ambiguity about which is the best tool when.)
More importantly, most code is not written "the good way."
Yes, be ambitious and aim to improve things.
But you will be working on the code base you have, which is probably not the code base in which everything is done properly.
Q6. "This doesn't apply to the very basics of a language."
A6. That's probably true, and I should have been clearer. 
Having some basic fluency in the languange will help.
(This is a great use of spaced repetition, by the way.)
But beyond "some basic fluency," the argument still applies.
Q7. "My team does use language X beautifully and idiomatically."
A7. Great! 
Good for you (sincerely). 
Q8. "But the use of a tool is as idiosyncratic and unpredictable as the use of a language."
A8. The premise is false. 
There are different ways to use various tools. 
But it's pretty hard to study Bazel or Splunk or Jenkins or whatever without learning things that will help you basically anywhere those tools are used. 
Databases are, arguably, an exception here. Those get used all sorts of ways.

On studying for your upcoming job: objections and replies

<h2>A common trap for people entering programming jobs</h2>
In my first programming job, I was given The C Programming Language and told to study it. So when I got my second programming job, I figured out what language I'd be coding in and started studying up.
This was a mistake. Supposing you want to study for a job before you start the job, language study is almost always the wrong place to put your hours:
<ol>
<li>If it's not a company-specific language, its range of use and ecosystem are probably so big that you can't know which parts of it will be used on the job.</li>
<li>And there will likely be specific libraries or tools that make using the language very different inside the company than outside of it.</li>
<li>There will often also be rules about which parts of the language you're allowed to use, and how. 
At my first BigCo job, I quickly realized that using C++ inside the company was more similar to using Java inside the company than it was to using C++ outside of the company.</li>
<li>With all respect: If you learn modern, beautiful, idiomatic use of some programming language, you're probably not going to see it on the job. 
It's good to know how the language is written under ideal conditions, but you'll still need to work with the code base you've got.</li>
</ol>
Meanwhile, there is a likely source of confusion you can often address in advance: tooling. Ask about what the team uses for:
<ol>
<li>Version control;</li>
<li>Testing;</li>
<li>Deployment / continuous integration;</li>
<li>Databases; and</li>
<li>Log management and search.</li>
<li>Metrics (thanks, <a href="https://news.ycombinator.com/reply?id=31858318&amp;goto=item%3Fid%3D31856512%2331858318">dukodk</a>!).</li>
</ol>
Sometimes these will be proprietary, and sometimes they will not exist. 
But often they will (exist and) be things you can read about and even practice with. 
I have always found this sort of thing much harder to pick up than a new language.
If you have only ever worked on small- to medium-sized projects and are about to join a company, consider reading Software Engineering at Google. 
Whether or not you're going to work at huge scale, and whether or not you like all the recommendations in the book, it's a wonderful menu of the problems that arise from any kind of real scale. 
Any chapter of that book would have been more valuable to me than all the C++ prep I did back in the day.
P.S.: This post is about what to do if you want to study for a job before you start it. I'm ignoring the question of whether such study is good, bad, appropriate, or whatever else.
P.P.S.: Follow-up <a href="on-studying-for-your-upcoming-job-objections-and-replies.html">here</a>.

A common trap for people entering programming jobs

<h2>Reading notes: A Widow For One Year</h2>
Revealed preference matters. Whatever I say about what I do and do not like and value, I have read four John Irving novels. That puts him #2 by novel count (I've read five of Jane Austen's) and almost certainly #1 by page count. And I don't regret reading any of those 700,000 or so words.
I am unlikely to say much that's new about the book. But:
<ol>
<li>Googling suggests that the connection between A Widow for One Year and The Great Gatsby is insufficiently appreciated (contemplating the stars in the orbit of Manhattan, carrying a torch for a really long time, etc.). It's a good question which presents the more optimistic picture of torch-carrying.</li>
<li>The author's interview that came with my edition was illuminating. This is partly for the notes about how he works (diligently, and spending huge amounts of time outlining the book before literally writing it) and for how he embraces his reputation as a sentimentalist. I was reminded of <a href="https://shows.cadence13.com/podcast/themomentwithbriankoppelman/episodes/e82c888f-0a34-40df-a419-db26b59f49d7">Josh Groban's interview with Brian Koppelman</a>, where he discussed the advantages of not being "cool" (or aspiring to coolness, at least) in a creative profession.</li>
<li>It's not quite a <Link href="/100-books.html">top-100</Link> book for me, but close (probably #120 or so as I write this). The other three Irving novels all still make the cut.</li>
<li>Irving seems to have gone from medium-famous to very obscure, but that could be a function of my intellectual context more than anything else. (Computer people are way less into long, sentimental American novels than the average reader.) I remember an Owen Meany question on Jeopardy! just a couple years ago.</li>
</ol>

Reading notes: A Widow For One Year

<h2>Python task manager from scratch, part 47: Tidying up the front end</h2>
Until now, I've been hacking together HTML and CSS by using Python string interpolation. The benefits of this approach are that it's very easy and it's also fundamentally true to the process of dynamically composing HTML and CSS. A CRUD app is, after all, largely a process of splicing and modifying text to send to a server. String interpolation and concatenation is a reasonable in-code manifestation of that.
Even so, it is an ugly, temporary hack, and in today's installment it gets fixed. Specifically, I've added:
(1) A proper HTML templating system, <a href="https://jinja.palletsprojects.com/en/3.1.x/">Jinja2</a>;
(2) A first HTML template, replicating the single Web page that has been made so far;
(3) Static-file functionality in <code>main.py</code> as per <a href="https://bottlepy.org/docs/dev/tutorial.html#static-files">the instructions</a> on Bottle's site;
(4) A <code>base.css</code> file replicating the styles that were being spliced into our page.
This is a good opportunity to practice good migration hygiene. My approach was:
(1) Copy the current <code>/&lt;env&gt;/add/</code> endpoint to a new, separate, identical one (<code>/&lt;env&gt;/add_jinja2/</code>);
(2) Create the new materials, modifying the latter endpoint as I went along;
(3) Continue until the two endpoints looked and behaved identically (or as identically as I could determine without automated testing);
(4) Delete the first endpoint;
(5) Rename the new endpoint to <code>/&lt;env&gt;/add/</code>.
Finally, remember to delete the old front-end code as soon as possible. Besides being ugly, it can cause confusion if it stays in the repository as "dead code," and it will always be available for reference in version control if we need to look at it.
Here's <a href="https://github.com/NateMeyvis/veery/commit/20bc3909beab4b90b6fc27e9bc7160f61b735f0f">the current commit</a> in <a href="https://github.com/NateMeyvis/veery">the <code>veery/</code> repository</a>.

Python task manager from scratch, part 47: Tidying up the front end

<h2>Python task manager from scratch, part 46: Getting handlers under test</h2>
Now that handlers are explicitly passed in an environment, we can create a test environment. It's surprisingly easy to go wrong with test environments. Here are some failure modes I've seen:
<ol>
<li>Not including enough or diverse enough test data.</li>
<li>Continuing to mock out functions when modifying the test environment would be cleaner, more reliable, and more readable.</li>
<li>Hiding test data behind layers of "convenience" functions for making test data. The idea motivating such functions is that test data often have tons of fields, most of which aren't being tested at any given time.</li>
</ol>
This last is the most interesting to me. First, I think it's underappreciated that an object with too many fields or properties is often ill-designed. Sometimes the domain really is that complicated, but often this is a sign that one code object is representing many logical or real-world objects. That's a problem. Often, homonymy seems to be behind this: the "delivery" as understood in an order-processing system is (arguably) not the same thing as, or at least not best represented as identical to, the "delivery" that is a box you might be monitoring with a smart camera on your doorstop.
Second, lots of helper functions seem to be motivated by a desire to reduce lines of code. Avoiding repetition is nice, but test code is supposed to be a bit repetitive, and readers don't mind scrolling a bit. More fundamentally, sometimes a bespoke set of test data really needs to be created, with a certain amount of variation in various fields. Stuffing all of that variation in as values of a dozen parameters of a <code>create_foo_test_data</code> function does not make things more readable.
Finally, I've occasionally seen towers of helper functions, like:
<ul>
<li><code>make_test_foo()</code></li>
<li><code>make_test_foo_with_variation_in_bar()</code></li>
<li><code>make_test_foo_with_only_some_variation_in_bar()</code></li>
<li><code>make_test_foo_with_new_value_of_enum()</code></li>
</ul>
The underlying issue seems to be that whatever helper function was useful at a given moment was checked in and made immortal. I find that a few text fixtures, along with ad hoc test data creation, serves me well. I don't mind reading test code that requires a bit of copying and pasting. (<a href="https://stackoverflow.com/questions/6453235/what-does-damp-not-dry-mean-when-talking-about-unit-tests">Here</a> is one discussion of the subject.)
Whether or not you like how I've done it, I've created a test environment, finally written some tests for those helpers, and fixed some bugs along the way.
Here's <a href="https://github.com/NateMeyvis/veery/commit/5d36815e640e2c0546407e6e16da84551e61afbf">the current commit</a> in <a href="https://github.com/NateMeyvis/veery">the <code>veery/</code> repository</a>.

Python task manager from scratch, part 46: Getting handlers under test

<h2>On type safety in natural language</h2>
Byrne Hobart has <a href="https://www.thediff.co/p/type-safe-internal-communications">a characteristically fun and insightful piece</a> [$] analogizing the "<a href="https://twitter.com/nipunmehra/status/1154590521345490945">four Amazon answers</a>" to types in programming.
Some reactions:
<ol>
<li>As <a href="on-talking-to-think-better.html">I've written</a>, many of us pay too little attention to military traditions and to radiotelephony conventions when we're thinking about clear, mind-improving communication. It's no coincidence Socrates obsessed over communicative "rules of the dance."</li>
<li>But the lesson I'd draw is a bit different: what's important is often getting communicators in the right roles, not improving the precision of a given response. I'm <a href="on-dependencies.html">tempted to believe that</a> the problem of dependency management is prior to, and harder than, the problem of improving accuracy and precision. (And that this is <a href="on-dependencies-in-small-projects.html">less sensitive to scale</a> that you might think.)</li>
<li>This makes sense, because types are only one way, and <a href="listening-notes-jason-strasser-on-the-risk-of-ruin-podcast.html">in practice often not a reliable one</a>, to achieve accuracy in software. Moreover, the kind of accuracy it gets you is often misunderstood, because it's very hard to make the guarantees of a type system extend to relevant, valuable guarantees <a href="an-argument-from-jimmy-koppel.html">at the logical level</a>.</li>
<li>So, while ambition and stronger typing might be correlated, I'd be more guarded than Byrne is when he says that "type-safe programs can be bigger, and the organizations that insist on them are implicitly more ambitious than the ones that don't." Programs that have good correctness checks can be bigger: stronger typing is one way to accomplish this, but only one. Good testing is another approach (I don't mean to imply that it's an orthogonal one). And I've seen strong typing prevent a code base from growing: complicated, ill-defined types can be so brittle that engineers either (i) leave the code in place, unable to change the types, or (ii) switch all those complicated types to <code>Any</code> (or some analogue of <code>Any</code>) when they need to change something.</li>
<li>I'm tempted to think of the Amazon approach less as a restriction on communication and more as a restriction on email. Certain questions can't be answered well, or at least felicitously, with one of the four answers ("do you think that John Doe will be back to full productivity soon?"). One way to think about this policy is as pressure to keep conversations off email that for legal reasons should not be conducted over email.</li>
<li>Further evidence for this is that many more companies than Amazon enforce similarly strong "typing" in other software (e.g., time estimates in JIRA). It's not clear how much this benefits them, especially if you try to control for other cultural factors.</li>
<li>Yet further evidence: big tech companies are famous for intellectual cross-pollination. Yet most non-Amazon FAANG employees (I'd bet) do not know about the "four email answers" policy, but many of them really hate and discourage email. I think this says something about what the policy's real effect and purpose is. (Is it four answers too many? Extending the typing analogy, perhaps "the best code is no code at all.")</li>
<li>People (I'm not implying Byrne is one of them) sometimes act as if the code-quality effects of strong typing are empirically proven. I do not think this belief can survive an honest encounter with <a href="https://danluu.com/empirical-pl/">Dan Luu's literature review</a>.</li>
</ol>

On type safety in natural language

<h2>Rubber duck text editing</h2>
I'm still using and loving Vim, and still believe that most advice about learning it <a href="on-learning-vim.html">doesn't work very well</a>.
A few new points of disagreement:
Too much emphasis is placed on speed. Vim is fast, and that's great, but users will feel enough pressure to go fast on their own. It's probably counterproductive to say or imply that hesitation is the sign of a weak user.
This is particularly true because it will push new users away from learning and toward trying to type the things they know faster. It's hard enough to communicate just how big and feature-rich it is.
Relatedly, but conversely, <code>vimtutor</code> (which I respect and like) and other beginners' tools should do more to make beginners at least aware of tools like the jump list, the change list, marks, and the quickfix list. They probably won't use all these tools very soon. (Probably most seasoned Vim users don't use all of them.) But they are great tools for giving people a sense of what Vim is all about and what it can do. So, instead of introducing a complicated and metaphysically dubious notion of a "grammar of Vim" or similar, which can leave learners feeling like they are missing the point if they don't intuitively grasp (e.g.) which commands take a count and which don't, we could just say things like: "There's this thing called the jump list; it lets you go back to the last location you jumped from, and the one before that, and so on, back and forth, as you wish."
I suspect that the deeper mistake here is assuming that users need to be fluent in the exact definition of X before showing them a feature involving X (so, that they need to know the definition of a jump, a change, or a motion before they can be shown tools that use these concepts). It's an intuitive thought, but I think it's wrong in this case. Probably nobody knows, for every service they use that supports undo functionality, the exact rules governing how actions are chunked into units for the purposes of that functionality. They still ought to know that undo exists.
The best mental adjustment I've made recently as a Vim user is, when I hesitate or get a little confused, to ask myself: "What do I want to do?" Whether or not I'm interested in Googling to learn a new Vim thing right then, just saying it to myself tends to lead me to a good answer. (Often it's something like: "Go back to that file I just had opened" or "put an asterisk in front of each of the next 8 lines.") It's like <a href="https://en.wikipedia.org/wiki/Rubber_duck_debugging">rubber duck debugging</a> but for editing text instead of coding.

Rubber duck text editing

<h2>On having philosophy in your life</h2>
<a href="https://twitter.com/AgnesCallard/status/1535598292427587584">Lots of people ask</a>: "I don’t want to go to grad school or become a professional philosopher, but I want more philosophy in my life. How can I get this?"
Here's how I think about this. Fundamental aspects of having philosophy in one's life include:
<ol>
<li>Recognizing philosophical questions when you encounter them;</li>
<li>Having some tools for addressing those questions;</li>
<li>Haivng some way to discuss and test what you think about them.</li>
</ol>
Taking these in turn:
First, how do you recognize philosophical questions? Life is full of them, but you'll be better off if you consume lots of high-quality stuff (any medium will do). When people ask me for philosophy recommendations, I more often want to encourage them to think about their intellectual consumption habits more broadly. (If you want lots of my opinions about this, just go to my home page and start reading; this site is full of them.)
The harder part is having the right receptive instincts. This is some combination of attention, energy, and a willingness not to fall back on broadly popular answers.
So, just last night I came across this passage:
<blockquote>
"What had befallen him was most unkind: the bewildering illusion that he was now in love with the daughter of the only woman he’d ever loved! But who can distinguish between falling in love and imagining falling in love? Even genuinely falling in love is an act of the imagination." (<a href="https://www.amazon.com/dp/B007Z2H3LU/">Source</a>.)
</blockquote>
This is, I think, a perfectly good example of having philosophical questions dropped on your intellectual doorstep:
<ol>
<li>What exactly is an act of the imagination?</li>
<li>Why would falling in love be one of those?</li>
<li>Why, exactly, would the fact that X is an act of the imagination make it difficult to distinguish between X and imagining-X?</li>
<li>What does any of this have to do with the fact that the object of the imagined love is the daughter of the object of the actual love?</li>
</ol>
<a href="https://www.natemeyvis.com/openmind.html">Here</a> is the output of my last attempt to organize a bunch of philosophical questions (around a theme, and under other constraints).
Second: how do you gain and refine tools for addressing philosophical questions? Lots of practice is essential. Having really good models is also important. I'll always recommend Platonic dialogues here, but also consider great art and following philosophers on Twitter.
The best way to improve your tools is also the last item on my initial list, which is to discuss and test your ideas (or the ideas you've encountered, whether or not you take yourself to have originated them). I don't have any surprising or witty advice to give about this, but note that you don't always need a single interlocutor and it doesn't need to have the surface appearance of a prototypical philosophical discussion. My maintaining this Web site is largely motivated by my wanting to test myself in generating and explaining ideas that are, broadly, philosophical. I get plenty of feedback, and I feel more pressure to be rigorous in public writing than I do in idle thoughts (which often seem interesting only until I get around to actually formulating them in a disciplined way).
Finally, a note about academic philosophy. I adore a lot of academic philosophy, but I think most people who try to keep philosophy in their lives weight their consumption too heavily toward academic outputs. Academic philosophers have wonderful outputs, but a lot of their best work isn't what makes it into writing. I think the norms of (academic) philosophical writing <a href="lawnmower.html">have gone badly wrong</a>.
There are plenty of great journal articles and books, but a good heuristic is to look for things that were commissioned but weren't as much at the mercy of peer reviewers. Introductions to anthologies and conference talks (check YouTube!) are often very good and have high philosophical value per word. (My favorite output of Terence Irwin is his "intellectual background" chapter in the <a href="https://www.cambridge.org/core/books/cambridge-companion-to-plato/14A54D47BE0B03A2220BAF130B4C8F94">Cambridge Companion to Plato</a>.)

On having philosophy in your life

<h2>Python task manager from scratch, part 45: Supporting environments</h2>
The main reason I went without testing event- and command-handling when I implemented them is that they operated only on the main repositories (defined in <code>main.py</code> and not redefined in any of the handling functions). This makes testing them awkward: either I'd have to <a href="https://docs.python.org/3/library/unittest.mock.html">mock out</a> those repositories or test on the main repositories. Neither is a good option.
As so often happens, the problem is in a sort of inappropriate coupling: those handlers should not be tied to the choice of repositories in <code>main.py</code>. In order to correct that, we need to build out some infrastructure that encodes the idea of there being different environments for things.
If you're not familiar with production vs. QA environments, the idea of test databases, or similar, now is a good time to Google around a bit for those.
For now our <code>Environment</code>s will be simple: just a bundle (dataclass) consisting of a <code>TaskRepository</code> and a <code>CoordinatorRepository</code>, both optional. (One reason to make them optional is that we might want to build out a test environment with just a <code>TaskRepository</code>, having no need in the context of certain tests for a <code>CoordinatorRepository</code>.)
This installment's work is to define that object, rewrite all the URLs to have the environment as a parameter, rewrite the various other functions (and tests downstream of these) to take in an environment as a parameter, and make sure the site still works.
Here's <a href="https://github.com/NateMeyvis/veery/commit/fee2dd14e24a7f27d045b2e308e89fa5e5e7b45f">the current commit</a> in <a href="https://github.com/NateMeyvis/veery">the <code>veery/</code> repository</a>.

Python task manager from scratch, part 45: Supporting environments

<h2>Python task manager from scratch, part 44: Implementing repeating tasks</h2>
After all of that preparatory work, finishing the first basic implementation of repeating tasks is straightforward. (See version history for a fun little bug I had to find and fix, though!)
Interestingly, despite all effort to stay disciplined and do things in the right order, I am still over my skis a bit. Task repetition is mostly untested, a bunch of event- / command-handling logic is now cluttering up <code>main.py</code>, Veery does not support the deletion of repeating tasks, and I haven't verified that event and command handling functions divide responsibilities properly.
It's normal to find yourself, quite suddenly, with a lot of infrastructure and cleanup work to do. What's essential is to actually do that kind of work and (especially) not to satisfy yourself with the mere appearance of stability. So, for example, I was briefly tempted to implement some complicated testing scheme, perhaps by mocking out the repositories in <code>main.py</code> or adding a repository parameter to the event handlers. It would have been replaced soon, however, after I implement the infrastructure to have separate environments (including a test environment).
Programmers also often feel the temptation to simply abandon testing and planning once things get a bit messy, whether that's because it forces them to confront ugly features of their code, it's less fun than playing with the new things they've just implemented, or it feels like a lost cause. Don't do that.
So, after this we'll do a series of cleanup and maintenance installments.
Here's <a href="https://github.com/NateMeyvis/veery/commit/86108f6c839711ec25898389de71a3f1090436ba">the current commit</a> in <a href="https://github.com/NateMeyvis/veery">the <code>veery/</code> repository</a>.

Python task manager from scratch, part 44: Implementing repeating tasks

<h2>Viewquake: interpreting obvious mistakes</h2>
In his poker manual Ace on the River, Barry Greenstein writes something like: When you see a successful player make an obvious mistake, do not dismiss them. Rather, start trying to learn more from them. It means that they must be compensating for the mistake--a mistake you know well enough to diagnose third-personally--by doing other things particularly well.
A few reflections:
<ol>
<li>In the poker context, this advice was a bit more relevant in an era when excellent training material was less available; scouting your opponents for implicit strategy advice was more important. This is a lot less true of poker now than it was when Barry was writing (almost 20 years ago!), but it's very true of software engineering.</li>
<li>Sometimes the person in question is directly compensating for the mistake (or seeming mistake) in a nonobvious way. The canonical poker example here is playing too loose preflop and making up for it in big-money decisions later in the hand. There are many less obvious examples involving passive play in order to entice weak players into the hand. It's more interesting, I think, when there's a real, all-things-considered mistake happening, but with offsetting skill in some other subdomain.</li>
<li>This advice shows up in a different way in Cowen and Gross's <a href="reading-notes-talent.html">Talent</a>, where they advise you to dwell on the "Groucho Marx" question of why a particular candidate is available to you. One of their conclusions is that an obvious defect somewhere allows for the possibility of extraordinary skill somewhere else (while remaining within the threshold of the talent you can actually get). There's also the story Ben Horowitz tells in The Hard Thing About Hard Things about how he was able to hire Mark Cranney because Cranney, despite being excellent at every strategic and organizational element of sales, did not "look the part" and so was passed over by other firms.</li>
<li>I found this so insightful in part because poker players are so eager to find fault in their opponents. This is both because finding and exploiting faults is exactly how you become a winning player and because the dominant psychology of the game simply involves a strong desire to believe yourself better than other players. Other domains are a lot less like this, but I'm reminded of the philosophy literature on <a href="https://plato.stanford.edu/entries/disagreement/#PeerDisa">disagreement</a>, which takes up questions like: "if I believe X and an epistemic peer believes not-X, must I change my belief in X?" So much of that discussion begins (or seems to me to begin) from a place of extreme desire to hang on to one's beliefs in the face of disagreement. Not to elide tricky questions of the structure of belief, but a lot of those papers felt like stories with desperately insecure protagonists. (Why not ask "what may I learn?" instead of "must I change?".)</li>
</ol>

Viewquake: interpreting obvious mistakes

<h2>Listening notes: The Pragmatic Programmer</h2>
The audiobook for The Pragmatic Programmer is everything that an audiobook, and especially everything that a technical audiobook, should be. I love to listen to stuff about software, but a lot of it doesn't suit the medium well. A lot of thought went into this: the narrator is excellent, some passages are read by the authors, and the code snippets are adapted to the audio format with good judgment.
Satisfyingly, this is not just an authorial but a programming success; the book itself is used as a case study in how to use text as a single source of truth, how to parallelize parallel problems, and how to do the reasonable thing even if it annoys your publisher.
It's easily the single best technical audiobook experience of my life.
The content is also excellent: this is a true revision of the original. It mixes "wisdom of the ancients" and "current expertise" far better than I expected it to. (Not all rereleased classics of programming literature hold up.)
I endorse most, by far, of what's in the book. Two quick points of disagreement:
<ol>
<li>Some of their recommended "descriptive names" (e.g., "buyer" for "user") seem dangerous to me. I'd rather maintain a focus on what the thing is rather than what it's doing right now in your code. My stock example here: if I'm writing a program to order pizza, and I currently order pizza on all and only Thursdays, I should still name the thing in my code <code>pizza</code>, not <code>thing_ordered_on_thursday</code> or <code>thursday_pizza</code>. In the <code>buyer</code>/<code>user</code> case, I fear that the code might change so that a <code>buyer</code> is also a shipping recipient, a notification recipient, or something else. Many problems are caused by names that are not descriptive enough, but many are also caused by things named according to accidents of their original context, not their real essences.[1]</li>
<li>The authors repeat fairly standard advice about using the power of Unix <a href="https://en.wikipedia.org/wiki/Pipeline_(Unix)">pipes</a> and generally about the power of viewing programs as extended transformations. I agree about the power of the paradigm, but I'm more skeptical about its limitations. Chaining together a ton of shell programs with pipes is almost impossible to test, and I think tests are valuable even in very small projects. Also, and relatedly, this usually requires intermediate values to be coerced into textual formats. That's often fine (or even desirable--see the chapter on "The Power of Plain Text"), but very often I'd rather have a program pass structured (and tested!) objects around. Finally, and at the risk of offending functional-programming acolytes, the paradigm of viewing all programs as transformations can be a Procrustean bed. But that's a longer argument.</li>
</ol>
[1] There's a counterargument here that roughly goes: if a thing takes on other roles, it will be in a different <a href="https://martinfowler.com/bliki/BoundedContext.html">bounded context</a>, so the other name will be for a legitimately different object in a different context, and the original (more specific--e.g., "buyer") name will after all have been apt. Perhaps such an argument is correct, but that's not the argument the authors give.

Listening notes: The Pragmatic Programmer

<h2>Python task manager from scratch, part 43: Preparing the way IV</h2>
In the spirit of building out the infrastructure before you add the functionality (see the previous installment), there are two new pieces of code here:
<ol>
<li>Adding a form field governing the interval between finishing one instance of a (certain kind of) repetitive task and having the next come due.</li>
<li>Parsing what we get from that field when the information is passed to the <code>proc_add_task()</code> function in <code>main.py</code>.</li>
<li>Actually routing task addition through the function that dispatches the <code>AddTask</code> command to its handler (<code>task_adder()</code>).</li>
</ol>
The Pytest tests still pass, and manual testing of the application shows that it still works--though if I try to add a task with a nonempty repetition interval, I hit the <code>NotImplementedError</code> and it fails. That's intended for now.
The application is getting to the size where, at least for me, I'd be getting lost if I hadn't kept things tidy enough. When I think about taking the next step, there's a part of me that thinks: "gee, I've got to figure out how to pass all that information between the coordinator, the task, the front end, and all the repositories." The prospect of loading all that into my short-term memory is intimidating. When I remember that I've got objects and repositories in place, a primitive but reasonable command dispatcher in place, and reasonable (not exhaustive!) test coverage, things seem a lot easier.
So, this is about where my projects would have started to fail, however many years ago. It <a href="on-quadratic-complexity.html">sneaks up on you</a>. We have reason to be much more optimistic here.
Here's <a href="https://github.com/NateMeyvis/veery/commit/fd209eaed09f5d5113163c3e056b844e23df3d77">the current commit</a> in <a href="https://github.com/NateMeyvis/veery">the <code>veery/</code> repository</a>.

Python task manager from scratch, part 43: Preparing the way IV

<h2>Python task manager from scratch, part 41: Setting up event handling</h2>
We are confronting the problem of how to coordinate tasks that have some special relationship, beginning with the case where completing a task kicks off a new task due some fixed interval after the completion. Doing that has prompted us to figure out how to properly implement a domain object that is not the <code>Task</code> but is closely related to it. And doing that has prompted us to implement some event-handling.
The newest set of changes implements rudimentary event-handling infrastructure without changing any behavior or indeed actually handling the case where a <code>KickoffCoordinator</code> is being created. So, those coordinators exist and can be persisted; events involving them exist; and we have some basic infrastructure to process those events. But that infrastructure will throw a <code>NotImplementedError</code> if we give it any event that actually exercises the new coordination functionality.
This is a common pattern in development:
<ol>
<li>Notice that something you want to implement requires some new infrastructure.</li>
<li>Find the smallest piece of that infrastructure that can be independently implemented.</li>
<li>Implement it without supporting the new feature.</li>
<li>Test it.</li>
<li>Make sure that the old behavior still works.</li>
<li>Start implementing the new behavior.</li>
</ol>
If you can get in the habit of separating infrastructure from functionality (the distinction isn't always sharp), you'll often find ways to factor your work into small, independently testable changes.
A few Veery-specific notes for the changes between the last installment and this one:
<ol>
<li>In the spirit of making small changes, there are a few commits covered in this installment. If you are following along by clicking through to the latest commit, you'll also want to look at its parent and grandparent.</li>
<li>I removed the <code>task_repository</code> parameter from the decorated functions in <code>main.py</code>. There's no mechanism for actually passing in such a repository, and it's better, for now, simply to define that repository at the top of the file and let all the functions beneath use it. The bad part of this solution is that functions are reaching outside their local <a href="https://realpython.com/python-scope-legb-rule/">scopes</a> when they call into repositories. I'll address this problem in a sturdier way when I get around to implementing several environments (for testing and production). Moreover, this problem always existed, because the default parameters to those functions were never being overridden, so this cleanup makes things no worse but more honest.</li>
<li>There was a circular import for a while among the <code>AddTask</code> event, which has a <code>coordinator</code> field typed as a <code>TaskCoordinator</code>, while the <code>TaskCoordinator</code> had a <code>proc_event()</code> method that checked for the <code>AddTask</code> subclass. I resolved this by removing the typing on the <code>coordinator</code> field. This is an insufficient solution, which removes a dependency at the code level but does not remove it at <a href="https://www.pathsensitive.com/2018/01/the-three-levels-of-software-why-code.html">the logical level</a>. Stay tuned for a better solution.</li>
<li>Eventually, we will not want to have all the event-routing and -handling in <code>main.py</code>. Because there is only one event so far, it doesn't clutter up that file too much. The practical danger to adding code in places where it won't ultimately live is not that deferring file creation and moving functions is a significant form of tech debt: that's easy. Rather, it's that you'll be tempted to mismanage dependencies, put some method on the wrong object, or similar. If you're keeping your changes small and thinking carefully, you'll do as well implementing first and splitting code into separate files later. That said, this is largely a matter of one's personal workflow and preference.</li>
</ol>
Here's <a href="https://github.com/NateMeyvis/veery/commit/bf64e12c52358cc52a64c0e9c0256ce826c92f31">the current commit</a> from <a href="https://github.com/NateMeyvis/veery">the <code>veery/</code> repository</a>.

Python task manager from scratch, part 41: Setting up event handling

<h2>Python task manager from scratch, part 42: Resolving a circular import</h2>
In the last installment I noted that I'd run into a circular-dependency problem and fixed it the wrong way, by removing a type annotation instead of addressing the actual circularity. The problem, again, is:
<ol>
<li>There is a command called <code>AddTask</code>. It has a field for a <code>TaskCoordinator</code>.</li>
<li>The only existing subclass of <code>TaskCoordinator</code>, <code>KickoffCoordinator</code>, generates commands, including <code>AddTask</code>, which it checks for explicitly.</li>
</ol>
What is the circular dependency here? There are <a href="https://www.natemeyvis.com/on-dependencies.html">at least two</a> good answers here:
<ol>
<li><code>commands.py</code> imports from <code>coordinator.py</code> and <code>coordinator.py</code> imports from <code>commands.py</code>.</li>
<li>What <code>AddTask</code> is depends on task coordinators: that's one of its fields. But coordinators depend on commands, because they need to know the commands that exist to implement the domain-specific logic required for processing them.</li>
</ol>
These dependencies are related but different. You can remove one without removing the other (as I did before the last installment). Do not settle for removing dependency problems at the code level but leaving problems at the logical level. Dependency problems of all sorts are signs of mistakes in structure, and those will always cause more and worse problems if you don't address them.
The problem I got myself into is of a fairly simple structure: A requires or uses B, and B requires or uses A. Here are some generic causes of that problem:
<ol>
<li>A and B should actually be one thing: they should be combined, or one of them should not exist at all. (Here: was I wrong to think that tasks and coordinators need to be distinguished?)</li>
<li>A should not depend on B. (Here: perhaps our command processor should just be like a woodchipper, not needing to know much about what it's fed. Some objects work like that.)</li>
<li>B should not depend on A. (Here: perhaps <code>AddTask</code> doesn't need to know what a <code>TaskCoordinator</code> is.)</li>
</ol>
The second of these is the easiest to eliminate. Our command processor needs to know what <code>AddTask</code> is. It's just not a woodchipper.
The first is also, I think, wrong. I thought <a href="python-task-manager-from-scratch-part-36-preparing-for-recurring-tasks.html">pretty hard</a> before adding the coordinator object.
That leaves the third--and, I think, revisiting my reasoning for adding a coordinator object shows why the third solution is right. What information should <code>AddTask</code> contain? Roughly, information about the task. Because coordinators and tasks should be different, it's too much information to add a whole <code>TaskCoordinator</code> as a field. Coordinators exist in part because all sorts of complicated domain-specific logic can go into scheduling tasks. A lot of it won't be relevant to the process of adding a task.
So, for example, I'd eventually like to implement coordinators that schedule new tasks based on when I have more time available and based on when I'll be doing other tasks. Certainly not all of this information, or the mechanisms to handle it, should be involved in the process of creating a new task, even if that task will be governed by that coordination logic.
If coordinators weren't intended to include other information, the first solution would probably be better: simply get rid of them and let tasks reschedule themselves.
It often happens, as it did here, that code concerns are really metaphysical concerns. I made this problem by losing track of which things needed to exist, and why.
So, I've implemented the last alternative. Here's <a href="https://github.com/NateMeyvis/veery/commit/84bf71af3e5848ff89a2fd7ae7ff11c0b77e78d1">the current commit</a> in <a href="https://github.com/NateMeyvis/veery">the <code>veery/</code> repository</a>.

Python task manager from scratch, part 42: Resolving a circular import

<h2>Python task manager from scratch, part 40: Persisting task coordinators</h2>
The job now is to fill out the persistence mechanisms relevant to <code>KickoffCoordinator</code>s. You've seen a lot of this before, when we've persisted <code>Task</code>s. A lot of the overall approach here is the same.
As you can see, I've made some changes to the initialization of <code>KickoffCoordinator</code> and to the object itself. Here's one problem I faced here and have faced before: When one domain object refers to another, how do you represent the dependency at the object level? Here: should we have <code>Task</code> be a field on <code>KickoffCoordinator</code>?
If we don't do this, and instead just store the task's UUID, our <code>KickoffCoordinator</code> domain object isn't as faithful to reality as we'd like it to be.
But if we do store the whole <code>Task</code> on the coordinator, how do we handle the persistence of that task?
<ol>
<li>We can persist the whole <code>Task</code> with the coordinator, but we're already persisting it in its own repository. We could store the information in two places, but that raises a ton of problems (besides the wasted space, we have to worry about keeping the different representations in sync, which is the stuff of thick textbooks).</li>
<li>Same as above, but we can only store the <code>Task</code> information with its coordinator and get rid of the other storage. But now we're coupling together both the actual persistence of those objects and the corresponding repositories. This is only appropriate if the objects are much more closely connected at the domain level thatn our coordinators and tasks are. (Think about how we'd store tasks that don't have corresponding coordinators; it could be done, but it would be a mess.)</li>
<li>We can persist just the UUID of the task on the coordinator, and every time we retrieve a coordinator we also retrieve the corresponding task from its repository and construct the <code>KickoffCoordinator</code> object. This is unwieldy and also couples together the functioning of the two repositories. (This is an important point: coupling and dependencies can occur even if the dependency isn't a matter of an explicit code import. If the actual functioning of a coordinator's repository depends on a task repository, or--worse--some specific task repository, our system is much less modular and harder to reason about than we want it to be.)</li>
<li>We can persist just the UUID of the task on the coordinator, only retrieving the whole <code>Task</code> when the situation demands it. Here, it's the responsibility of the user of the coordinator to summon up the whole task if that's necessary. It is not required to do so.</li>
<li>We can create "thin" and "think" coordinator objects, the former of which holds only the UUID of the corresponding task and the latter of which holds the whole thing.</li>
</ol>
I chose the second-to-last option, storing just the UUID and accepting a slightly impoverished <code>KickoffCoordinator</code> object. I think these situations are legitimately tricky to get right, but the more I think about it the more I'm happy with this one.
Whether I got this one right or wrong, the persistence and related testing is in place.
Here's <a href="https://github.com/NateMeyvis/veery/commit/ad1182ca6c851ab959837fac5f642e9ff4a11f10">the current commit</a> in <a href="https://github.com/NateMeyvis/veery">the <code>veery/</code> repository</a>.

Python task manager from scratch, part 40: Persisting task coordinators

<h2>Reading notes: Talent</h2>
Even more than usual, this is a set of reflections and not a comprehensive review. (Although I've made a point of not reading other reviews before writing mine, I imagine it's well- and thoroughly reviewed elsewhere.)
<ol>
<li>Like Tyler's books generally, this one is stylistically a little ragged--in good ways. It's pleasantly straightforward, and always reminding you that this is primarily a record of things Tyler wants to communicate and only secondarily a literary artifact. Good writing from academics often (not always!) has this feature: the reader is constantly, subtly reminded that the real project is accumulation of human capital in the writer, and that the articles and books are all downstream of that. In a book about talent, I find it to be a subtle, constant reminder of what the authors have done to cultivate their own talent.</li>
<li>Reading this book is strenuous and emotionally challenging--again, in a good way. How do I stack up? What could I be doing to cultivate talent better? It's a book about the assessment of talent and not, directly, its cultivation, but the two subjects are too closely linked for the active reader not to be considering both on every page. An important skill in reading this book properly is not letting your self-judgments and development plans distract you from the lessons about finding and cultivating talent.</li>
<li>The Groucho Marx effect is important: very often you need to be asking why the person wants your company. This is another way into seeing the value of being distinctive and focusing on comparative advantage as a writer. Suppose someone writes to me (I like it when this happens!) about a piece I wrote. Why were they reading, and why are they writing to, me instead of anyone else in the world? If you aren't doing something distinctive, the answer might not be flattering.</li>
<li>I've seen a lot of companies handle Groucho Marx reasoning badly specifically in software. The market for programmers is still very hot (yes, even now), and I have seen many American companies deal badly with the reality that just about anyone they can hire is someone who cannot get one of the X highest-tier programming jobs in America. This tends to be exacerbated by the facts that (i) the absolute compensation they are offering is still quite high and (ii) fully facing this reality tends not to reflect well on the interviewer, either. Hiring programmers is all about making necessary tradeoffs. There are certainly teams of "the X+1th-best-available" programmers working at very high levels and happily producing output as efficiently as teams from the most prestigious firms. But (I conjecture) this tends to be a story of managing, deploying, and retaining talent rather than finding eight programmers who all hate remote work and/or don't know that Google is hiring and prefer your firm to every other local firm.</li>
<li>Relatedly, for a lot of companies, I suspect that a big part of the search for software engineering talent is figuring out how to do things without using software engineers.</li>
<li>I don't remember any discussion of laws governing interviews in the book. I don't think the authors recommend anything illegal, but it's easy to imagine an HR department wincing at it. The gap between the Cowen/Gross picture of talent search and the reality of job interviews might have more to do with regulatory mindsets than they discuss (though I'm sure they're aware of this).</li>
<li>There are a lot of programming jobs where what the authors call a "multiplicative model" is probably correct. Consider (i) implementation accuracy, (ii) implementation efficiency, (iii) dependency management, (iv) persistence management, (v) debugging more straightforwardly logical errors, (vi) debugging data- and persistence-related errors, (vii) documentation, (viii) API construction, (ix) migration management, and (x) team communication. Many software jobs require at least 8 of these. Some require all 10. They're somewhat correlated, but less than many people think.</li>
<li>The discussion of cultivating talent is excellent, and something I spent the first half of the book itching to hear about. There's much more to say about this at the organizational level. Cowen and Gross discuss at some length (i) identifying talent generally, (ii) identifying talent that fits a specific need, and (iii) making organizational room for specific kinds of underappreciated talent. For human capital that grows exponentially, however (and that's the case the authors want you to shoot for), a lot of the person's ultimate output will reflect their growth after they join you. (Whether or not we're talking about hiring for a job or other kinds of talent search.) So there's a lot to be said about figuring out what kinds of talent you're best at nurturing.</li>
</ol>

Reading notes: Talent

<h2>Python task manager from scratch, part 39: Thinking about interfaces, again</h2>
Last things first this time. Between part 38 and this part the relevant changes are:
<ol>
<li>Moving the <code>Event</code> class and its subclass into a separate file;</li>
<li>Doing the same with <code>Command</code>;</li>
<li>Defining an interface for the repository corresponding to (what I called) a <code>KickoffCoordinator</code>.</li>
</ol>
There is no new functionality, but enough can go wrong between the last installment and this one that I want to provide a separate set of notes.
<ol>
<li>It's tempting to think about all the <code>Event</code>s and <code>Command</code>s you might ever need and define them now, both because it feels responsible and plan-ahead-y and because it can feel silly to define an empty class meant to be subclassed and then only provide one subclass. If there are some you know you'll need, go ahead. But it's easy to go wrong (and spend time inefficiently) if you guess in advance at what you'll need. Having <code>Event</code> and <code>Command</code> in place is more than enough planning. With this structure in place, we're not going to have a hard time adding any necessary items later. Further planning now therefore gains us no safety.</li>
<li>It might seem counterintuitive to distinguish between events and commands (in such a deep way) at all. The best discussion I know of this is in Architecture Patterns with Python, but Google tells me that there is also no lack of people opining on the Internet about how important it is.</li>
<li>We will need to persist <code>KickoffCoordinator</code>s somehow. (I'm not sold on the name: whatever it is in virtue of which my watering the plants means that I need to do it again after a while, that's what we're talking about.) It's tempting to create an extra field in the <code>task</code> SQL table and put that information there. I think this would be a serious mistake. The whole purpose of distinguishing between the coordinator and the task is that they're different things. That probably means they need different database tables to be persisted accurately. And adding several extra columns to the <code>task</code> table is a heavy cost in complexity.</li>
<li>At the same time, it's tempting to go wild and try to imagine in advance all the different coordination mechanisms we might need, defining an elaborate <code>coordinator</code> table correspondingly. I think this is a mistake, too. If other coordinators are way more complex, we can define other SQL database tables (or even persistence mechanisms that are not SQL database tables) for them. That can all be handled at the repository level. It's no problem to have a table structured just for (what I've called) <code>KickoffCoordinator</code>s.</li>
<li>And, as always, thinking about what interface the repository should present should come first. Perhaps persistence details will force you into modifying that interface (though this is necessary less than people tend to think), but at least start with the way you think things ought to be, independent of your actual futzing with persistence details.</li>
</ol>
Finally, the advanced mechanics of message-passing systems is a deep topic (easily enough to spend a career studying and specializing in). This, by contrast, is intended as enough infrastructure to allow us to build a clean system at modest scale (or perhaps just for personal use). I won't (at least for the next few hundred or so installments) be worried about:
<ol>
<li>Being robust against most or all concurrency issues;</li>
<li>Building enough abstraction to support many dozens of kinds of interrelated events with complicated interdependencies;</li>
<li>Handling millions of task updates per second.</li>
</ol>
Here's <a href="https://github.com/NateMeyvis/veery/commit/bd9f0f40e72e908ef122cdbecfac7a160be35d40">the current commit</a> in <a href="https://github.com/NateMeyvis/veery">the <code>veery/</code> repository</a>.

Python task manager from scratch, part 39: Thinking about interfaces, again

<h2>On viewquakes</h2>
A decade or so ago, it was briefly fashionable to think in terms of "<a href="https://www.reddit.com/r/slatestarcodex/comments/3st7e5/what_was_your_last_great_viewquake/">viewquakes</a>." These are "insights that dramatically change one's worldview, making one see the world in a new way." This fashion has passed. "Viewquake" appears to be a Robin Hanson coinage, and you know a Robin Hanson coinage is obscure if a Marginal Revolution search for it comes up empty, as "viewquake" and "viewquakes" do as I write this.
The phenomenon seems to me still to be under-appreciated and under-theorized. A lot of what I think is shaped by ideas that (i) I went a long time not believing or understanding, (ii) can be stated fairly succinctly, and (iii) now work as a high-frequency cognitive tool. They're a bit like favorite movie quotes in terms of salience and propensity to jump to mind (but more intellectually useful, at least on average).
A striking phenomenon of viewquakes is that they're non-transferable. Andrew and I would often ask guests on Thinking Poker about "aha!" moments or viewquake-like insights for them. Those insights seemed unremarkable, even from world-class players. More generally, how often have you been stunned by someone's "single key to life"?
My best theory for this starts with a Cowen-style emphasis on <a href="on-the-scarcity-of-context.html">scarcity and context</a>. A large, multi-dimensional understanding is required in order for a viewquake to register as a viewquake. (Here I'm tempted to disagree with Hanson and say that a viewquake often results from seeing the world in a new way, though it reinforces a different and often superior understanding.)
Here's <a href="viewquake-decisionmaking-is-overrated.html">a recent viewquake</a> of mine: "Decisionmaking is overrated (because having a stream of good options matters far more)." This resonated with me because of my background in poker (and transition into software); years of reading finance-themed newsletters and gaining a new vocabulary around options and a new understanding of variance; and because I was thinking hard about how to maximize my productivity. Such things, and many others, tend to come to mind along with that phrase. I expect a lot of readers found the sentence itself a bit underwhelming. I bet many have a longer-lasting and more intuitive grasp of the idea; perhaps others find its surface meaning uncontroversial and don't feel the impulse to see many other ideas in it; others might be left cold for different reasons.
So, I conjecture that viewquakes are non-transferable (as viewquakes) for roughly the same reasons that cultural and other expertise isn't transferable (that way). If you know more about this, please do <a href="mailto:natemeyvis@gmail.com">tell me</a>.

On viewquakes

<h2>Python task manager from scratch, part 37: Fixing our coordinator</h2>
I managed to do some constructive thinking last time, but messed up the implementation of KickoffCoordinator:
<ol>
<li>The coordinator should only track some subset of tasks; it somehow needs to know which tasks it's coordinating. (Maintaining this over time will not be trivial, but we'll worry about that later.)</li>
<li>Even if they're just in first-draft phase, our domain objects should not be depending on a repository. I passed a <code>TaskRepository</code> to <code>KickoffCoordinator</code> as an initialization parameter, because (I guess) I didn't know how else to actually enact what the coordinator needs to be doing: creating and adding tasks as appropriate.</li>
</ol>
So, we need to decouple what the coordinator is doing from what is processing the results of what the coordinator is doing. In other words, the coordinator's determining that a certain task needs to be added needs to be separate from the actual addition of the task (in some repository somewhere).
This is a complicated and controversial subject. Happily, first steps are somewhat less controversial and complicated. We'll turn the coordinator's output into a <code>Command</code> object and change <code>KickoffCoordinator.proc_event()</code> to emit those objects instead of directly modifying a repository. (My approach here is indebted to Architecture Patterns with Python, at least insofar as what I do is sensible.)
Soon: a proper message-processing system! So much writing about software either (i) does not involve a properly separated message-passing system or (ii) is concerned with operating such a system at large scale. It will be pleasant to construct a well-functioning system without worrying about Big Tech-level scale.
Here's <a href="https://github.com/NateMeyvis/veery/commit/3c0b95741fce68ed5b35d32627591c09d9a977fe">the current commit</a> in <a href="https://github.com/NateMeyvis/veery">the <code>veery/</code> repository</a>.

Python task manager from scratch, part 37: Fixing our coordinator

<h2>Python task manager from scratch, part 38: Add a license</h2>
Better late than never.
Here's <a href="https://choosealicense.com">choosealicense.com</a> from GitHub. Here's <a href="https://en.wikipedia.org/wiki/MIT_License">the Wikipedia entry</a> for the MIT license, which is also a reasonable starting point to learn about software licensing, if you're interested in it.
Here's <a href="https://github.com/NateMeyvis/veery/commit/2619374b78082e4f5a5d869eb1f1592b0d867534">the current commit</a> in <a href="https://github.com/NateMeyvis/veery">the <code>veery/</code> repository</a>.

Python task manager from scratch, part 38: Add a license

<h2>Viewquake: Decisionmaking is overrated</h2>
Patrick Collison <a href="https://tim.blog/2018/12/24/the-tim-ferriss-show-patrick-collison/">said this on the Tim Ferriss Show</a>. His justification is that having a stream of high-quality options matters much more, as does being able to correct mistakes and incorporate those new high-quality options quickly.
A similar idea arises in <a href="https://www.amazon.com/Talent-Identify-Energizers-Creatives-Winners/dp/1250275814">Talent</a>: Cowen and Gross emphasize that the way to make good hires is to have a stream of great candidates.
Other notes on the subject:
<ol>
<li>Back in my poker-forum days, savvy people liked to point out that the closest decisions mattered the least. (If the expected values of A and B are so close, you're not doing much better or worse by choosing the better one.)</li>
<li>Hiring (and other) decisions are very hard (see also the literature on NFL drafting that Cowen and Gross cite). The harder you think they are, the more you should emphasize cultivation over decisionmaking: good cultivation is more robust against human fallibility than decisionmaking is.</li>
<li>This is relevant to personal-management decisions, too. <a href="on-productivity.html">I've written that</a> that even if your best outputs are what really matter, it's better to try to (i) avoid zero-productivity "work" and (ii) cultivate lots of energy and lots of output. ("Trading down in the draft" for productivity.)</li>
<li>I'm struck by how many successful companies emphasize speed and quantity of output.</li>
</ol>

Viewquake: Decisionmaking is overrated

<h2>On (non-software) dependency management</h2>
The distinctive cognitive strengths of a discipline are usually not what its practitioners think they are--or so I've argued. If that's right, then we should discount the whole genre of "here's how being an X gives me the tools to give an excellent analysis of Y" articles.
So, caveat lector, because I'm about to discuss how being a software engineer is informing how I quit coffee.
[Edited to add: Turns out a lot of people find it easy to quit coffee. I am not one of those people. When I, e.g., accidentally made decaf instead of regular, I knew it by how sluggish and off I felt.]
First, it made me worry about dependencies a lot more. This mostly came through experience, but reading Dan Luu really <Link href="/on-dependencies-in-small-projects.html">crystallized my thoughts</Link> about it. There are well-known frames of these habits both as delightful, life-affirming rituals and as draining, costly habits. In <Link href="/on-dependencies.html">thinking-about-dependencies</Link> mode, the latter is more salient.
It also informed how I'm approaching this. The following ideas are salient:
<ol>
<li>When you have a dependency of X on Y, it's hard to know exactly which features of Y are being used by X, and how.</li>
<li>This gets more true as the system gets more complex.</li>
<li>And as documentation gets worse.</li>
<li>Migrations are easier and safer if you set up a mechanism to roll back to a pre-migration state if need be.</li>
<li>And it's best to go little by little.</li>
<li>It's particularly hard to make the first move.</li>
</ol>
So, here was my plan. (This is not medical advice. Please, please consult appropriate sources if you plan to address your dependence on stimulants / other substances.)
<ol>
<li>Estimate how much caffeine I was consuming per day.</li>
<li>Take caffeine (in pill form), starting at roughly 70% of the estimate (to minimize the chance of accidentally increasing my daily dosage).</li>
<li>At first, take the caffeine pills with mugs of hot lemon water.</li>
<li>Day by day, gradually decrease both the caffeine per day and the amount of caffeine taken in conjunction with hot beverages.</li>
<li>Put the coffee machine in the basement (to minimize psychological triggers), but don't give it away yet.</li>
</ol>
I'm at ~40% of my previous daily caffeine intake, with very little hot-beverage consumption.
Many people quit things in many ways; this has been remarkably painless.

On (non-software) dependency management

<h4>Python task manager from scratch, part 36: Preparing for recurring tasks</h4>
Here's a cluster of phenomena that I've never properly managed with productivity software:
<ol>
<li>Some of my tasks recur.</li>
<li>Completing one instance or part of a recurring task is independent of completing other parts of it.</li>
<li>Sometimes, but only sometimes, scheduling these instances depends on when the first ones are completed.</li>
<li>Sometimes, but only sometimes, these tasks should "pile up" if not completed.</li>
</ol>
Here are some examples:
<ol>
<li>I need to take out the trash every week. It is impermissible to do this before 5p Wednesday. It must be done before 8a Thursday. Perhaps 5 weeks a year, the schedule varies and the trash day is moved back by a day. It is metaphysically incoherent to be committed to two different "take out the trash" tasks at once. (I mean, to taking out our trash twice in parallel; in theory I could be covering the neighbors' while they're on vacation, or something.)</li>
<li>I take my vitamins every day. In some cases I should slightly adjust future doses if I miss a day, but for the most part it's like the trash: if I miss it, I miss it.</li>
<li>The plants need to be watered periodically. The time of the next watering depends not on any predefined schedule but on the last time the watering was completed.</li>
<li>I've occasionally set goals of reading X pages per day, where I do have to make it up on future days if I fall behind. (By the way, this worked fairly well, but it's not what I do now.)</li>
<li>There are some screws that need to be tightened: this is like the plants, where the next occurrence depends on the last completion date.</li>
<li>If I haven't talked to my mother in a while, I ought to call her.</li>
</ol>
And here are some reflections on those data:
<ol>
<li>Some feel like sequences of tasks (e.g., the trash) whereas others feel like temporally extended tasks with parts (e.g., plant maintenance).</li>
<li>Sometimes the completion of a task generates a new task and/or determines when a task ought to be done; sometimes not.</li>
<li>Sometimes I ought to do something only when some unusual circumstance (e.g., not having talked to my mother in a while) obtains.</li>
</ol>
And here are some meta-level reflections on thinking through a software problem:
<ol>
<li>However much the limitations of a system might constrain the implementation or manifestation of some object, do not let it constrain your understanding or description of the object. So, for example, Veery will probably never ingest a log of all my conversations with my mother, generating tasks automatically if it notices it's been a while (with "a while" depending on the season and other life features). It's still useful to say what the situation in my life actually is.</li>
<li>Try to describe the phenomena faithfully but, as much as possible, unencumbered by a metaphysical framework (or an elaborate framework of software domain objects). The descriptions are there to help you make such a framework! Here, for example, it's tempting to somehow distinguish between occurrences, tasks, projects, and more right from the start. Eventually we'll need to do that, but when you're in this sort of capture/research stage, it's best to describe things neutrally where that's possible. Sometimes, the hard part is that the whole reason you're doing the project is that you think all the other software is using the wrong model for something and yours is better. If so, great--just make sure that your model is growing out of how things really are. Avoid the temptation to describe everything in terms of some limited technical vocabulary.</li>
<li>There are two basic warnings one often hears: First, if you do too much planning up front, you're going to have to rewrite a lot of those plans as new requirements and lessons come up. Second, if you do too little planning up front, you're liable to go in the wrong direction ("weeks of coding can save hours of planning"). Striking a balance between these is context-dependent. As a one-person team happy to let Veery evolve more organically, I can afford to skip some of the planning I'd do if I were on a team building specific inventory-management software. But that doesn't mean I don't need to plan at all.</li>
</ol>
The reflections above make these (tentative) conclusions seem relevant and useful:
<ol>
<li>Veery will not do everything. There is some "manage everything" software (DevonTHINK, JIRA, arguably Reminders as integrated in MacOS, arguably Slack for extreme power users). This is not that.</li>
<li>I am not (yet) interested in attempting to convert anyone else in my life to Veery. This is software for a single person, for now at least.</li>
<li>I use Apple hardware and am basically happy with Reminders for alerts and reminders. It's the nuts-and-bolts to-do-list stuff I want to be cleaner and snappier.</li>
</ol>
In light of all that, I'll take on a workstream of implementing recurring tasks, both those that are like the trash (where the tasks come on a schedule) and those that are more like the plants (where completing one task kicks off another).
I could implement both of these by modifying <code>Task</code> as implemented: make some system for generating new tasks when old ones finish and cancelling ones that are too far past a deadline. So, the trash <code>Task</code> could cancel itself at 2p on the day of trash collection (whether or not I did it), and this could kick off a process of scheduling the next week's trash task. (That task probably shouldn't show up on my list until 5p the day before trash collection, but let's deal with that separately.) Meanwhile, the plant-watering task could generate a new task, using different logic, (only) upon its successful completion. (That task should probably get more urgent over time after its due date, but let's deal with that separately.)
This scheme would work, for now, but I think it's dangerous--it's a sort of solution that is very common and also a disastrous mistake. What's wrong with this?
<ol>
<li>It elides an important real-world difference between the trash and the plants tasks. Again, one seems to be a set of tasks that happen to be on a schedule whereas the other seems to be a bunch of tasks that are unified in being parts of some higher-level task (keeping a plant healthy).</li>
<li>It jams a bunch of logic into the central domain object. Sometimes that's unavoidable, but having over-complicated domain objects is one of the main failure modes of real-world software. (When the domain and persistence layers are not cleanly separated, this gets even worse.) This mistake is <Link href="/on-quadratic-complexity.html">quadratically</Link> bad: the extra methods and logic on the domain object interfere with each other proportionally to their number. It only gets worse from there: misplaced functionality is almost always more complicated.</li>
</ol>
So, what will I actually do?
<ol>
<li>Notice that I already have the tools for trash-like and vitamin-taking-like tasks: any number of mechanisms can invoke the <code>add_task()</code> method, including built-in scheduling infrastructure like <a href="https://en.wikipedia.org/wiki/Cron"><code>cron</code></a>. An appropriate way to analyze these cases, for now, is: "I already have <code>Task</code>s, and these situations involve a lot of tasks that occur on a schedule. So the fundamentally missing thing here is the scheduling part, and the scheduling part only. Veery is not itself scheduling software; it's more appropriate for it to integrate with scheduling software. So I'm not going to build out any new domain objects here; the next step is to integrate existing infrastructure with <code>cron</code> or similar."</li>
<li>Notice that plant maintenance and similar are not like that. In this case there's a higher-level task or project or goal that coordinates the lower-level "water this plant today" sorts of tasks. Veery's job is to represent those higher-level items, whatever they are.</li>
<li>I don't know yet exactly what those higher-level items are. But what do they need to do? They need to coordinate the scheduling of lower-level tasks, sometimes generating them not just because it's a certain time but because of facts about the task/project/goal.</li>
</ol>
A reasonable pragmatic approach again involves interfaces. My plan is:
<ol>
<li>Define an interface: TaskCoordinator. Anything that's in the business of coordinating tasks can implement it.</li>
<li>Define an object implementing the behavior we described for the plant and vitamin cases. That object will implement the TaskCoordinator interface (in Python, this is a matter of subclassing an abstract class).</li>
<li>Figure out the appropriate relationship between a given water-this-plant-today <code>Task</code> object and the keep-the-plants-watered coordinating object. This might be tricky.</li>
</ol>
My first steps to enact that plan are to define an Event object (with a subclass representing task-completion events), the coordinator interface, and an implementer of that interface. First drafts of those objects and their tests (and some formatting tweaks) now exist.
Here's <a href="https://github.com/NateMeyvis/veery/commit/50e0079be450ed20dc2fe8210c4a629b4e0f1cc4">the current commit</a> in <a href="https://github.com/NateMeyvis/veery">the <code>veery/</code> repository</a>.

Python task manager from scratch, part 36: Preparing for recurring tasks

<h2>The 100 books nearest to my heart</h2>
Not the 100 books I recommend the most, but the ones that changed my life the most or spark the most joy in me.
<h4>The very top</h4>
<ol>
<li>Pride and Prejudice</li>
<li>The Great Gatsby</li>
<li>Crime and Punishment</li>
<li>Love in the Time of Cholera</li>
</ol>
<h4>Big American novels</h4>
<ol>
<li>All the Pretty Horses</li>
<li>My Ántonia</li>
<li>Lonesome Dove</li>
<li>The Scarlet Letter</li>
<li>East of Eden</li>
<li>The Crossing</li>
<li>A Prayer for Owen Meany</li>
<li>Crossroads</li>
<li>The Grapes of Wrath</li>
<li>Suttree</li>
<li>The Cider House Rules</li>
<li>Freedom</li>
<li>The Corrections</li>
<li>The World According to Garp</li>
</ol>
<h4>Big non-American novels</h4>
<ol>
<li>My Struggle, Book VI</li>
<li>My Struggle, Book I</li>
<li>My Struggle, Book II</li>
<li>My Struggle, Book III</li>
<li>The Sea, The Sea</li>
</ol>
<h4>Other novels</h4>
<ol>
<li>Midnight's Children</li>
<li>Mrs. Dalloway</li>
<li>The Remains of the Day</li>
<li>A Portrait of the Artist as a Young Man</li>
<li>The Ground Beneath Her Feet</li>
</ol>
<h4>Childhood / adolescence / formative</h4>
<ol>
<li>Baseball By the Rules</li>
<li>Friday Night Lights</li>
<li>Gödel, Escher, Bach</li>
<li>Zen and the Art of Motorcycle Maintenance</li>
<li>1984</li>
</ol>
<h4>Turns out most of my favorite philosophy isn't in book form</h4>
<ol>
<li>The Discovery of Things</li>
<li>Philosophical Explanations</li>
<li>Meditations on First Philosophy</li>
</ol>
<h4>Self-help</h4>
<ol>
<li>Getting Things Done</li>
<li>The Artist's Way</li>
<li>The Art of Learning</li>
<li>Never Split the Difference</li>
</ol>
<h4>Sports and games</h4>
<ol>
<li>The Breaks of the Game</li>
<li>The Biggest Game in Town</li>
<li>My Losing Season</li>
<li>What I Think About When I Think About Running</li>
<li>The Inner Game of Tennis</li>
</ol>
<h4>Computers</h4>
<ol>
<li>Working Effectively with Legacy Code</li>
<li>Refactoring</li>
<li>Effective Debugging</li>
<li>Designing Data-Intensive Applications</li>
<li>Programming Pearls</li>
<li>Fluent Python</li>
<li>Architecture Patterns with Python</li>
</ol>
<h4>I went through a phase</h4>
<ol>
<li>Infinite Jest</li>
<li>A Supposedly Fun Thing I'll Never Do Again</li>
<li>The Pale King</li>
<li>Brief Interviews with Hideous Men</li>
</ol>
<h4>A lot of what I know about thinking came from poker</h4>
<ol>
<li>Ace on the River</li>
<li>Hold'em Poker for Advanced Players</li>
<li>Seven-Card Stud for Advanced Players</li>
<li>High-Low Split Poker for Advanced Players</li>
<li>Super/System 2</li>
<li>Elements of Poker</li>
</ol>
<h4>Parenting books are way underrated</h4>
<ol>
<li>Precious Little Sleep</li>
<li>Expecting Better</li>
<li>No Bad Kids</li>
<li>Oh, Crap!</li>
<li>Bringing Up Bébé</li>
<li>Cribsheet</li>
<li>The Family Firm</li>
</ol>
<h4>Economics</h4>
<ol>
<li>Average is Over</li>
<li>The Great Stagnation</li>
<li>The Complacent Class</li>
</ol>
<h4>Baseball!</h4>
<ol>
<li>The Baseball 100</li>
<li>I was Right on Time</li>
<li>Bottom of the 33rd</li>
<li>The New Bill James Historical Baseball Abstract</li>
<li>Summer of '49</li>
</ol>
<h4>Business</h4>
<ol>
<li>Talent</li>
<li>The Hard Thing About Hard Things</li>
</ol>
<h4>Catch-all (nonfiction)</h4>
<ol>
<li>A Moveable Feast</li>
<li>The Autobiography of Frederick Douglass</li>
<li>Walden</li>
<li>Thinking, Fast and Slow</li>
<li>A Swim in a Pond in the Rain</li>
<li>Abe</li>
<li>But What If We're Wrong?</li>
<li>Bad Blood</li>
<li>Battle Cry of Freedom</li>
<li>Adam's Task</li>
<li>RN: The Memoirs of Richard Nixon</li>
<li>The Autobiography of Benjamin Franklin</li>
<li>The Apprentice: My Life in the Kitchen</li>
<li>Self-Portrait in Black and White</li>
</ol>
<h4>Catch-all (fiction)</h4>
<ol>
<li>The Dog</li>
<li>Play It as It Lays</li>
<li>The Great Fire</li>
<li>Straight Man</li>
<li>The Power and the Glory</li>
<li>Their Eyes were Watching God</li>
<li>The Tim Tebow CFL Chronicles</li>
</ol>

The 100 books nearest to my heart

<h2>12 rules for living</h2>
This is my contribution to the "write down twelve rules for life" game as brilliantly played by, among others, <a href="https://marginalrevolution.com/marginalrevolution/2018/01/tyler-cowens-12-rules-life.html">Tyler Cowen</a> and <a href="https://twitter.com/AgnesCallard/status/1503108298349838336?s=20&amp;t=wqblwUxYEam_eSMxJd65nQ">Agnes Callard</a>. (Update 2022-02-09: <a href="https://lisielilli.medium.com/12-rules-for-life-df3593099c3f">Lisie Lillianfeld's</a> is great.)
<ol>
<li>Whenever possible, ask: "should I do this same thing again and again?" Getting compound returns is great. Getting diminishing returns is bad. Doing more and more of the same thing tends to get you one or the other, and figuring out which situation you’re in is often very tricky. Work at it.</li>
<li>Write every day.</li>
<li>Minimize the time you spend thinking about food. Have default meals, think twice before spending a lot of time cooking, and so on. Food is great, but the other stuff I can do with that time and energy is even better. And when it comes time to cook or dine with friends, it’s that much more enjoyable. (OK, maybe you really like food. In that case, is there something else you can cut ~80% of the time investment out of?)</li>
<li>Whenever possible, ask: "Does the Coase Theorem apply here?"</li>
<li>Just try to get a lot of high-quality stuff into your brain. Try to understand it, of course, but don’t worry too much about that, because getting whatever you can out of something really great is usually better than a fuller experience of something mediocre. So, for example, listen to a lot of great music even if you don’t understand music very well.</li>
<li>Whenever possible, ask if the causal order of things is other than it appears to be. (Really try to do this. If I don’t ask myself such questions several times a day, it’s probably because I’m being sloppy.)</li>
<li>Read a lot. Worry a lot about the quality of what you read, but not so much that it paralyzes you. Reread a lot (see (1), (5), and (8)).</li>
<li>Divide your attention so that you get a little bit of exposure to a lot of things and very deep knowledge of a few things. (See (1).)</li>
<li>Find some people whose thinking you appreciate, enjoy, and easily ingest. Consume everything they put out, several times if necessary, and think about it carefully. (See (1).)</li>
<li>When you’re thinking about a belief someone else holds, ask whether it’s a "coherence belief," believed because it flows naturally from other commitments, or a "portfolio belief," believed because it somehow balances out other commitments (e.g., in being more politically palatable). This is often the key to really understanding what is being expressed and what the relevant commitments are. Relatedly: Get relatively much parenting advice from books and experts and relatively little from other parents.</li>
<li>Have a lot of daily habits and maintain good to-do lists. Relatedly: for any length of time, have a productive default activity available for that length of time.</li>
<li>About common behaviors, ask: "Is this mere orthodoxy, some sort of <a href="https://wiki.lesswrong.com/wiki/Chesterton%27s_Fence">Chesterton’s fence</a>, both, or neither?" It’s really important and really hard to figure out whether you have good reason to do what everyone else is doing. And these decisions come up all the time.</li>
</ol>

12 rules for living

<h2>15 notes on testing software</h2>
<ol>
<li>If there is a One True Way to test software, we can't know what it is until we know a One True Way to design software.</li>
<li>But we don't know such a One True Way.</li>
<li>So, for now, it's more productive to think about empirical, surface-level claims about testing. (That's why this list is not an essay.)</li>
<li>Most of the world's production software is not tested.</li>
<li>The difference between "tested at all" and "not tested at all" is much bigger than the difference between "tested really well" and "tested at all."</li>
<li>Whereas the main practical difficulty in software is getting people to write software well, the main practical difficulty in software testing is getting people to write tests at all.</li>
<li>So beware of instituting any policy that could be willfully misinterpreted in a way that will cause fewer tests to be written.</li>
<li>And beware of responding to having poor test coverage by thinking about how ideal tests look instead of the motivational causes of proper tests' not getting written.</li>
<li>Bug-report templates with too many required fields discourage people from reporting bugs and distract them from communicating what's most relevant. </li>
<li>So optimize your bug reporting to <a href="on-task-management.html">make capture easy</a>.</li>
<li>If you're picking an aspect of discipline to develop, choose "actually goes and writes the test when something fails, even in development" over "writes beautiful and comprehensive tests for whatever thing I'm actually writing tests for."</li>
<li>Pytest is great.</li>
<li>When there's a performance problem with tests, most of the problem usually comes from just a few tests (or a single technique for setting up a fixture).</li>
<li>So a little profiling can go a long way.</li>
<li>And "I don't want to slow down the test suite" is not a good reason not to write that extra test.</li>
</ol>

15 notes on testing software

<h2>2022 favorites to date</h2>
Last updated 2022-12-05
This is stuff I consumed in 2022, not necessarily stuff released in 2022.
<h4>Books</h4>
<ol>
<li>Mrs. Dalloway, Virginia Woolf</li>
<li><a href="reading-notes-the-remains-of-the-day.html">The Remains of the Day</a>, Kazuo Ishiguro</li>
<li><a href="reading-notes-lonesome-dove.html">Lonesome Dove</a>, Larry McMurtry</li>
<li><a href="reading-notes-the-end-of-solitude.html">The End of Solitude</a>, William Deresiewicz</li>
<li><a href="reading-notes-talent.html">Talent</a>, Tyler Cowen and Daniel Gross</li>
<li><a href="reading-notes-how-to-change.html">How to Change</a>, Katy Milkman</li>
<li>The Fifties, David Halberstam</li>
<li><a href="reading-notes-crossroads.html">Crossroads</a>, Jonathan Franzen</li>
<li><a href="reading-notes-from-front-porch-to-back-seat.html">From Front Porch to Back Seat</a>, Beth Bailey</li>
<li><a href="reading-notes-a-widow-for-one-year.html">A Widow for One Year</a>, John Irving</li>
<li><a href="reading-notes-the-last-days-of-roger-federer.html">The Last Days of Roger Federer</a>, Geoff Dyer</li>
<li><a href="reading-notes-of-boys-and-men.html">Of Boys and Men</a>, Richard Reeves</li>
<li><a href="reading-notes-super-infinite.html">Super-Infinite</a>: The Transformations of John Donne, Katherine Rundell</li>
<li><a href="reading-notes-the-three-body-problem.html">The Three-Body Problem</a>, Cixin Liu</li>
<li>The Nineties, Chuck Klosterman</li>
<li>The Tim Tebow CFL Chronicles, Jon Bois</li>
<li><a href="reading-notes-the-score-takes-care-of-itself.html">The Score Takes Care of Itself</a>, Bill Walsh et al.</li>
</ol>
<h4>Audiobooks</h4>
<ol>
<li><a href="https://www.amazon.com/Pragmatic-Programmer-Anniversary-Journey-Mastery-dp-B0833FBNHV/dp/B0833FBNHV/">The Pragmatic Programmer</a>, Thomas &amp; Hunt (narr. Katarina)</li>
<li>Software Engineering at Google, C. Titus Winters et al.</li>
<li>A Way With Words II: Approaches to Literature, Michael D.C. Drout</li>
</ol>
<h4>Podcast / YouTube episodes</h4>
<ol>
<li><a href="https://www.youtube.com/watch?v=PwlONu13GoQ">UChicago Aims of Education 2022</a>, Agnes Callard</li>
<li><a href="https://www.youtube.com/watch?v=NmEVwJ_lJ1A">Two products that cannot be equal</a>, Timothy Gowers</li>
<li><a href="https://www.youtube.com/watch?v=VfFn4NqQr_U">How to score 10 runs in the first inning and lose</a></li>
<li><a href="https://www.econtalk.org/roland-fryer-on-educational-reform/">Roland Fryer on Educational Reform</a>, EconTalk</li>
<li>Doug Polk Podcast: Poker Pro to Full-Time Trading (with Jason Strasser)</li>
<li>Reconcilable Differences #179: I Believe in the System... Kind Of</li>
<li>The Morning Shakeout: Kate Grace</li>
<li>Causality 16: Tenerife</li>
<li><a href="https://www.wtfpod.com/podcast/remembering-michael-k-williams">Remembering Michael K. Williams</a>, WTF with Marc Maron</li>
<li>Indie Hackers (various episodes)</li>
<li><a href="https://stratechery.com/2022/an-interview-with-daniel-gross-and-nat-friedman-about-the-democratization-of-ai/">An Interview With Daniel Gross and Nat Friedman About the Democratization of AI</a>, Stratechery</li>
<li>Solving Wordle using Information Theory, 3Blue1Brown</li>
<li>Sebastian Mallaby on Venture Capital (Conversations with Tyler E143)</li>
<li>Lecture 3: Robert Frost (Modern Poetry, Langdon Hammer)</li>
<li>Living in an Internet Age (Meditations with Zohar S1E1)</li>
<li>Tips to be a better problem solver, 3Blue1Brown</li>
<li>Reconcilable Differences #173: The Chicken Project</li>
<li>'See Me After Class,' with Jason Snell (The Talk Show E337)</li>
<li>The Moment with Brian Koppelman: Gillian Jacobs</li>
<li>Minimum Viable Continuous Delivery, Coding Blocks</li>
<li>The Tim Ferriss Show: Mark Zuckerberg</li>
<li>Under the Radar #241: Farewell, Feed Wrangler</li>
<li>The Tim Ferriss Show: Cal Newport</li>
</ol>
<h4>Blog posts / articles</h4>
<ol>
<li><a href="https://thepointmag.com/examined-life/art-is-for-seeing-evil/">Art is for Seeing Evil</a>, Agnes Callard</li>
<li><a href="https://marginalrevolution.com/marginalrevolution/2022/01/a-simple-theory-of-culture.html">A Simple Theory of Culture</a>, Marginal Revolution</li>
<li><a href="https://danluu.com/cocktail-ideas/">Cocktail party ideas</a>, Dan Luu</li>
<li><a href="https://salmagundi.skidmore.edu/articles/434-on-not-drinking-the-kool-aid">On Not Drinking the Kool-Aid</a>, William Deresiewicz</li>
<li><a href="https://salmagundi.skidmore.edu/articles/379-on-the-bobos">On the Bobos</a>, William Deresiewicz</li>
<li><a href="https://thezvi.substack.com/p/covid-63022-vaccine-update-update">Covid 6/30/22: Vaccine Update Update</a>, Zvi Mowshowitz</li>
<li><a href="https://kvetch.substack.com/p/why-did-comedy-die">Why did Comedy Die?</a>, Misha Saul</li>
<li><a href="https://marginalrevolution.com/marginalrevolution/2022/02/context-is-that-which-is-scarce-2.html">Context is that which is scarce</a>, Marginal Revolution</li>
<li><a href="https://milan.cvitkovic.net/writing/things_youre_allowed_to_do/">Things You're Allowed To Do</a>, Milan Cvitkovic</li>
<li><a href="https://siddhesh.substack.com/p/culture-shock">Culture Shock</a>, Obvious Bicycle</li>
<li><a href="https://stratechery.com/2022/digital-advertising-in-2022/">Digital Advertising in 2022</a>, Stratechery</li>
<li><a href="https://www.theatlantic.com/ideas/archive/2022/01/old-music-killing-new-music/621339/">Is Old Music Killing New Music?</a>, Ted Gioia</li>
<li><a href="https://stratechery.com/2022/data-and-definitions/">Data and Definitions</a>, Stratechery</li>
<li><a href="https://www.daemonology.net/blog/2020-09-20-On-the-use-of-a-life.html">On the use of a life</a>, Colin Percival</li>
<li><a href="https://tedgioia.substack.com/p/academic-publishing-and-the-death">Academic Publishing and the Death Instinct</a>, Ted Gioia</li>
<li><a href="https://siddhesh.substack.com/p/every-us-state">Impressions of Every US State</a>, Obvious Bicycle</li>
<li><a href="https://guzey.com/things/software/anki/">Instilling Novel Thought Patterns and Making Your Long-Term Memory Accountable with Anki</a>, Alexey Guzey</li>
</ol>
<h4>Operas about Richard Nixon</h4>
<ol>
<li>Nixon in China, John Adams</li>
</ol>

2022 favorites to date

<h2>A quick argument for naming all software prototypes after birds</h2>
<ol>
<li>Software ought to have a memorable name.</li>
<li>It's good if software has a name that accurately describes what it does, but it's bad if it inaccurately describes what it does, and the magnitude of the badness of the mis-description is usually much larger than the benefit of an apt description.</li>
<li>It's hard to predict how software will evolve.</li>
<li>So a basic expected value calculation, in light of (2) and (3), suggests that software should not be given a descriptive name from the start.</li>
<li>And it's best not to spend too much time thinking about a prototype's name.</li>
<li>There are lots of birds, with names that are memorable but not descriptive, and it's easy to find long lists of bird genera.</li>
</ol>
It's my <code>["foo", "bar", "baz", ...]</code> of software naming. And note that you can pick a name that evokes the idea of what you intend the software to be, without limiting it.

A quick argument for naming all software prototypes after birds

<h2>An argument from Jimmy Koppel</h2>
Jimmy Koppel has, in various places (see <a href="https://www.natemeyvis.com/software-design/">here</a>), advanced pieces of an argument that is significant enough to deserve an independent reference.
Let an interface be a specification of what a given bit of software does (and not, e.g., some abstract class appearing in code).
<h4>Premises</h4>
<ol>
<li>There is a many-to-many relationship between implementations and interfaces.</li>
<li>What the code really is and really does is determined (at least in part) by its interface. In Koppel-ese, code has <a href="https://www.pathsensitive.com/2018/01/the-three-levels-of-software-why-code.html">a logical level</a>.</li>
</ol>
<h4>Conclusions</h4>
<ol>
<li>Specifying the behavior of an implementation cannot (entirely) specify what the code really is.</li>
<li>Guaranteeing (e.g., through testing) a set of implementation behaviors cannot guarantee that the code is correct.</li>
<li>The provable guarantees of the formalization (e.g., through a type system) of an implementation of an object do not ipso facto extend to what the implementation represents. The <a href="https://www.pathsensitive.com/2018/01/the-design-of-software-is-thing-apart.html">stock Koppel example</a> helps here: suppose you have an object that returns True iff some internal internal field is at least 65. All the formalism in the world won't distinguish between its being an ASCII alphanumeric-character checker and its being a retirement-age checker, and therefore won't verify that it is a correct implementation of (either) an ASCII character checker or a retirement age checker.</li>
</ol>
<h4>Occasionally useful alternative formulation</h4>
All you can test about an implementation is a current, actual set of behaviors. But current, actual sets of behaviors implement many interfaces, in general, because interfaces also include counterfactual behavior (most commonly, behavior under future changes).
And counterfactual difference matters, because code needs to be maintained and should also be semantically correct.
So constraining, verifying, and testing implementations in general fails to constrain, verify, and test it as an implementation of the interface.
Thanks to <a href="https://www.robertbeard.info">Robert Beard</a> for helping me clarify this. As always, all mistakes and infelicities are entirely mine.

An argument from Jimmy Koppel

<h2>Books I like more than other people do</h2>
If you take my 150 favorite books and sort them by Goodreads score, lowest to highest, here's what you get:
<ol>
<li>The Dog, Joseph O'Neill (3.15 / 5 on Goodreads)</li>
<li>The Great Fire, Shirley Hazzard (3.45)</li>
<li>A Portrait of the Artist as a Young Man, James Joyce (3.62)</li>
<li>The Biggest Game in Town, Al Alvarez (3.71)</li>
<li>Freedom, Jonathan Franzen (3.76)</li>
<li>Walden, Henry David Thoreau (3.77)</li>
<li>My Ántonia, Willa Cather (3.81)</li>
<li>Play it As it Lays, Joan Didion (3.88)</li>
</ol>
(Goodreads scores as of late summer 2021.)
Again, these are not listed in order of my preference: they were eligible only in virtue of meeting the top-100 criterion. 
If it's important to figure out your intellectual comparative advantage, exercises like this might be more valuable than they seem. It looks like I value sincerity more than the average reader. (But the simpler explanation might be that I like a lot of the books that people resent having been assigned.)
Nate Silver <a href="https://conversationswithtyler.com/episodes/nate-silver/">once noted that</a>:
<blockquote>
like, every book on Amazon, in the long run, gravitates toward having four stars. A lot of 9/11 conspiracy books are rated pretty well on Amazon, because only the conspiracists bother to read them.
Whereas, Othello or Macbeth or something, everyone reads, a lot of kids have to read it for homework when they don’t want to, necessarily, so they’ll leave a bad review there, potentially.
</blockquote>
This gives a good conjecture for why the classics are on this list. And it's easy enough to see why a lot of people would hate The Dog. The most confusing entry here is The Great Fire. I remember reading lukewarm reviews, but I'd never have thought it would score lower than Joyce (often assigned, unfamiliar style) and Franzen (obvious).

Books I like more than other people do

<h2>How I got into programming</h2>
<h3>My story</h3>
In the early 2010s I was a gradate student in philosophy. I read about <a href="https://projecteuler.net/">Project Euler</a> somewhere and realized that programming was (i) interesting enough to try and (ii) would cost $0 given that I already owned a computer. Project Euler was itself fun, and (more enduringly) I fell in love with Python.
A college friend was working for a bioinformatics startup needing a documentation writer. Needing to choose between (i) leaving Boston for a TAship in Ithaca, NY or (ii) making money some other way, I chose (ii) and got the documentation job. Everyone involved was eager for me to spend some of my time learning the details of algorithms relevant to bioinformatics, so it was a good environment to learn to code.
(There's a familiar story among programmers: "In my course work I was led to believe that programming was all about learning algorithms and data structures. When I started my career I immediately found myself using only basic algorithms; the hard part was learning tools and systems." I had something like that experience, but delayed: my first job thoroughly reinforced the impression that fancy algorithms were absolutely central to industrial work in programming.)
Startups tend to be flexible places, and I took on a lot of jobs within that company, including first-order work as a programmer. Eventually I went out on my own as a consultant, then took a job at Google, then did various other things. But that's of much less interest to most people who ask me about this. The most relevant aspects of this story are:
<ol>
<li>I learned from MOOCs, books, and experimentation.</li>
<li>I started on a lark.</li>
<li>It was a bit less than a year between starting my independent part-time studies and having some sort of job in software.</li>
<li>It was about six months after that that I was in some sense working as a programmer.</li>
<li>I got my first job by (i) being willing to work at a startup and (ii) having a very good personal connection at one.</li>
<li>And my first job was "programming-adjacent."</li>
</ol>
<h3>Postscript</h3>
That is, I said, my story. It's true and it's what I said in all sincerity, for years, to people who asked. It's incomplete, though. I was in high school from 1997 to 2001. Some friends of mine were into computers; there were a couple computer classes available; and I carried around a programmable TI-83 calculator all day.
I can't say how much programming I did then, but it must have been a lot: I remember spending hours programming, e.g., a simple version of craps. And I wrote a units-conversion program. The latter was my first experience releasing and versioning software: I chased down the one person who self-identified as a user of it and asked to borrow his calculator so that I could attach it to mine with a cable and give him a version of the program with a bugfix.
It is easy to recall many memories of myself being totally engrossed in programming. I omitted from the narrative above because I omitted it from my narrative then: I was a math guy, trivia geek, runner, and so on. (Or so I thought.) I never so much as considered a CS class as an undergrad and never talked about myself as a programming enthusiast.
So, I spent a bit over a decade paying no attention to programming. And the most relevant facts here are that:
<ol>
<li>If you asked me about my programming background, and I told you it all started in my grad school years, I wasn't quite getting it right;</li>
<li>But I wasn't lying; I had really just not allowed that part of my youth to enter my self-concept.</li>
<li>The more accurate version of that first point above is: I learned from MOOCS, books, and experimentation, where "experimentation" includes a lot of fumbling around with TI-83 programming and BASIC in the Clinton administration.</li>
<li>The human capacity for self-deception is enormous.</li>
</ol>

How I got into programming

<h2>Nate Meyvis</h2>
<h3>About me</h3>
I work in software. 
I'm <a href="https://twitter.com/NateMeyvis">on Twitter</a>. 
My academic background is in math (undergrad) and ancient Greek philosophy (<a href="https://philpapers.org/rec/MEYKSA">beyond</a>). 
If you're not sure whether you should email me, you <a href="mailto:nate@natemeyvis.com">probably should</a>.
<a href="programming.html">Here</a> are various writings about programming, broadly construed.
<a href="reading-notes.html">Here</a> is a list of books I've written up in some form.
<a href="most-recent.html">Here</a> are my most recent posts.
If you're looking for a specific post, <a href="alphabetical.html">here</a> are all of them, ordered alphabetically by title.
<h3>Software</h3>
<ul>
<li>I like to think about <a href="software-design.html">software design</a>.</li>
<li><a href="an-argument-from-jimmy-koppel.html">This argument</a> is underrated.</li>
<li>Here's <a href="software-faq.html">a FAQ about learning software</a>.</li>
</ul>
<h3>Some posts people have liked</h3>
<ul>
<li><a href="on-actually-reading-the-book.html">On Actually Reading the Book</a></li>
<li><a href="on-conversations-with-tyler.html">On Conversations with Tyler</a></li>
<li><a href="on-the-scarcity-of-context.html">On the Scarcity of Context</a></li>
</ul>
<h3>Spaced repetition and Anki</h3>
<ul>
<li><a href="on-using-anki.html">Here</a> is how and why I use spaced repetition.</li>
<li><a href="on-using-anki-again.html">Here</a> are notes on spaced repetition and personal dependency management.</li>
<li><a href="on-ankis-database.html">Here</a> are notes on Anki's data model and database structure.</li>
<li><a href="on-self-experimentation-in-spaced-repetition.html">Here</a> are notes on scheduling algorithms and self-experimentation.</li>
</ul>
<h3>Philosophy and academia</h3>
<ul>
<li>I <a href="lawnmower.html">disagree with</a> some influential guidelines for writing philosophy.</li>
<li>I help academics <a href="nonac.html">find non-academic jobs</a>.</li>
<li>I taught <a href="openmind.html">a course at Boston College</a> (fall 2021).</li>
</ul>
<h3>Other stuff</h3>
<ul>
<li>I co-hosted <a href="http://www.thinkingpoker.net/">a poker podcast</a> for 8 years. <a href="podcasting-faq.html">Here</a> is a FAQ.</li>
<li>People ask me about parenting (whether or not they should do so!). <a href="parenting.html">Here's</a> what I tell them.</li>
</ul>
<h3>About me, again</h3>
<ul>
<li>I did the <a href="12-rules.html">12 Rules for Living</a> game.</li>
<li>I like <a href="ranking.html">to rank things</a>.</li>
<li>I'm thinking about <a href="on-viewquakes.html">viewquakes</a> these days.</li>
</ul>

Nate Meyvis

<h2>The Lawnmower Essay and the Problems of Philosophy</h2>
Jim Pryor’s "Guidelines on Writing a Philosophy Paper" is the most influential course handout I know of in contemporary academic philosophy. The magnitude of its influence is not easily measured. But my first- and second-hand observation; the essay’s many glowing reviews; and the linked page’s excellent SEO combine to suggest that it has a status not unlike that of Plato’s Apology in many quarters: it has been received as a sort of holy text or perfect enunciation of principle. I suspect, however, that it is also like the Apology in that professional philosophers spend more time telling undergrads to read it than they do studying its details. Here I’ll examine some of those details and conclude that the professional obsession with "Guidelines" is unhealthy, or at least reflects something unhealthy about the discipline.
"Guidelines" is doing a few things at once: it sets out some of Dr. Pryor’s course policies; it gives advice about the mechanics of writing; and it describes successful pieces of writing in his class. Another way of saying that last thing is: "Guidelines" describes a particular subgenre of a literary form. I’m going to call that form, the one Pryor is requiring the reader to use in completing course assignments, the Lawnmower Essay.
The Lawnmower Essay has never been described more famously or cleverly than in "Guidelines," but don’t conclude that it’s Pryor- or NYU-specific. It is even more ubiquitous in analytic philosophy classrooms than the five-paragraph essay is in high-school English classes. It is a variant of the argumentative essay in which clarity, explicitness, and exposure of logical structure are dialed as high as possible. Indeed, they are dialed so high that practitioners often ignore, miss, or renounce the Lawnmower Essay’s connection to the literary form of the essay. (Pryor never once uses the word "essay" in the document.)
I mentioned before that the Lawnmower Essay demands clarity, explicitness, and exposure of logical structure; here’s how meeting those demands can play out. In ordinary life you might write me a note: "Beans need to soak overnight before they’re within an hour’s cooking of being edible, so you should soak those beans." If I’m a fair reader and a competent cook, I’ll understand what you said, but note that you’ve suppressed some premises in this note to me. You implied, but did not say, that we plan to eat those beans tomorrow and are in a position to cook them today. You made some questions about the beans in question--e.g., that they’re not lentils (which cook up just fine without soaking); that they’re not canned (in which case they’re already relevantly "soaked," though good luck defining that term with Myhrvoldian precision); that you have no reason to believe they’ll resist soaking (by having too much wax, say); that by "cook" you don’t mean "pressure-cook" or some other method powerful enough to render pre-soaking unnecessary; and so on. (How long is "overnight," anyway? Do we need to make sure they’re submerged, or can we just let them float in a pot of water?)
Contemporary analytic philosophers tend to be addressing questions like "How much of my income must I give to charity?" and "What exactly does the name ‘Banquo’ refer to?," not "Should I soak these beans tonight?." But the process above--expand, clarify, refine, expand, clarify, refine, on and on--is what the Lawnmower Essay is about. Not all of what it’s about: you might also present examples that are intended to convince the reader to accept one premise rather than another; you might argue that certain premises are inconsistent; and so on. Those operations are natural extensions of the fundamental work of exposing the logical structure of an argument, and are continuous with it. Our little bean soup inference, after all this work is done, would be likely to occupy 1000 or 2000 words: that’s impractical for a note left on the kitchen table, but it’s much more thorough.
That sort of work is what Pryor, and many other modern philosophy instructors, are looking for in a philosophy classroom. Such work is what philosophy, as they teach it, is. What would seem pedantic or obnoxious or unhelpful in the case of bean stew--though I do tend to want a bit more intellectual rigor in the recipes I read--is much more helpful in the subjects academic philosophy deals with. And again, helpful or not, in Dr. Pryor’s class it is mandatory. You haven’t done your work, according to "Guidelines," until: you are arguing from premises that any interlocutor would agree to; you have not missed the opportunity to clarify what might need clarifying; you have given examples where examples would help; and you have laid out in plain black ink every premise and inference you need to make your argument airtight. Hence my calling it a "Lawnmower Essay:" you can’t miss a spot, it won’t turn out right unless you go in perfect order, and attempts at elegant flourish figure to get you nothing but blemishes. If you’re not going slow, or if an observer would have any trouble figuring out what you’re doing, you’re not doing it right.
That's not disparagement. I am a Lawnmower Essayist. I’m proud of the semesters I spent grading Lawnmower Essays and of the intellectual muscles I developed writing my own. The form develops the epistemic virtues of rigor and straightforwardness. Its strictness makes you develop new skills: when you can’t use elision, metaphor, or most of your vocabulary, you develop new capacities of expression. I’m grateful to have written so many Lawnmower Essays, just as I’m grateful that forms of "to be" were forbidden in my ninth-grade English assignments and that my undergrad poetry workshop put us through all the ordinary paces and then some (we did scansion, we wrote sonnets and sonnets and more sonnets, we wrote villanelles and sestinas, and then we were presented with new and tougher rules). Our public discourse would be healthier and more honest if we replaced some shrieking op-eds with Lawnmower Essays. It’s not just that doing the chores is good for you; there really are lawns out there that need mowing.
But, again, "Guidelines" is not just a record of Dr. Pryor’s course policies. It is also a statement of what it is to do philosophy. Sometimes Pryor speaks of "this course," of his teaching assistants, and of what’s done "here," but more often he simply talks about what philosophy is and what we must do to meet its norms. And the document would not be so widely reproduced, distributed, assigned, and adored if it were not taken as a description of philosophy itself.
In its first role, that of recording course policy, I have no fundamental beef with "Guidelines," and not just because it’s not my place to tell Dr. Pryor how to run his courses. It’s because, again, mowing lawns is good for you, and the Lawnmower Essay is a perfectly good form to constrain students with, at least sometimes. I do have some non-fundamental beefs here, though; I’ll mention two.
First, Pryor says that we should "start from common assumptions [your audience would] agree to," and we later learn that this audience should be imagined as maximally hostile. But is this really possible? Isn’t it more accurate to say that we should make our premises as plausible as possible, and fully explicit? I think this is just loose phrasing on Pryor’s part, especially since his examples of model writing tend to involve premises being made explicit rather than completely obvious truths being enunciated. It’s an unfortunate slip, however, because there is such a great difference between "start from something your opponent must agree with" and "start from a reasonable place while making it fully clear that’s where you’re starting from." It’s the difference between starting at the edge of the lawn and starting at the edge of the world.
Second, because Pryor is telling the reader to adhere not just to the formal and rhetorical strictures of the essay but to those of the Lawnmower Essay, an element of his FAQ--"Can you write your paper as a dialogue or story?"--comes off as a bit disingenuous. (The answer is, unsurprisingly, a polite "no.") By presenting dialogues and stories as the relevant alternatives to the form he’s laying out, he implies that the form in question is The Essay, not The Lawnmower Essay, to which the most relevant alternatives are not dialogues and stories, but other kinds of essays.[1] There plainly are many other such kinds: the essay is the form of Montaigne and Emerson and on and on, but an Emersonian essay will not satisfy Dr. Pryor’s TA, who is expecting a Lawnmower Essay. It would be more honest, or at least more informative, to openly acknowledge that the document describes a subgenre, which certain kinds of professional philosophers employ disproportionately (though not at all exclusively), and that Dr. Pryor expects his prompts to be answered in that subgenre--not with a dialogue or story, but also not with any other kind of essay.
Again, though, "Guidelines" is a very fine course handout, and these are small complaints with it in that capacity. They point the way, however, to far more serious complaints with it in the other roles in which it is routinely deployed: the professional manifesto and/or general guide to written argumentation. Here we need to recall that Dr. Pryor recommends that the Lawnmower Essayist imagine and write toward a reader who is "lazy, stupid, and mean." Quickly glossed: so lazy that you need to explain everything you say, because he won’t bother to look up or recall anything; so stupid that he needs taking by the hand, inch by logical inch; and so mean that you must relentlessly disambiguate terms he might otherwise maliciously misconstrue, anticipate and parry even unpromising/sophistical objections, and otherwise cover your rhetorical behind from every direction.
Note I said "write toward," not "write for." You can’t--nobody can--truly write for a reader who so deeply lacks the epistemic virtues necessary for proper reading. We continue to teach reading at the university level because there is, beyond the mechanics of literacy we teach in elementary school, a receptivity to good writing that requires those epistemic virtues. (Educated people sometimes speak of "where they learned to read." They aren’t talking about preschool, and they also aren’t speaking loosely, though they are using a specific sense of the verb.) The audience Pryor has us imagine isn’t an audience of readers at all, and you can’t write for someone who’s not a reader any more than you can feed a doll. The best we can do is write at them, as boxers work on punching bags or children serve tea to stuffed animals.
Here the philosopher might object: those other essayists have goals other than arguing for the truth of propositions and the correctness of explanations. So I’m wrong to have implied that the Lawnmower Essay is merely one form among many, suitable if one’s mission is as narrowly truth- / explanation-correctness-directed as the contemporary analytic philosopher’s. Making everything explicit and disambiguating wherever possible just are the intellectual work of clarifying claims and arguments (or so the objection would go); those other kinds of essays use methods that are strictly worse for the purposes of philosophical argument.
This objection doesn’t work. First, it relies on an controversial definition of philosophy; we (not just the objector and I, but very many of us, very much of the time) notoriously disagree about what philosophy is. Moreover, none of the candidate definitions carves out something the pursuit of which Lawnmower Essays are uniquely suited for. So, for example, if you think that philosophy is just about arguing for truths, or about arguing for truths about less-empirical things: don’t mathematicians do that too? Why, then, don’t mathematicians use (analogues of) the Lawnmower Essay, except in problem sets?[2]
I think that’s enough to be done with the objection, but if you aren’t convinced yet, note that the objection admits of other refutations, too. One set of such refutations begins with the observation that the Lawnmower Essay can be very good for defending oneself rhetorically while still being very poor for communicating truths and correct explanations. Because we write essays (and sonnets, and epics, and ghazals, and jingles, and grocery lists) in order to communicate, essays--even of the most rabidly truth-seeking sort--are thus governed by norms of communication other than the maximization of self-defense. When we put things in logical order, we risk taking them out of rhetorical or epistemic order. If we keep them in rhetorical/epistemic order, and so pass up the chance to put them in logical order, we risk a wagging finger from a lazy, stupid, and/or mean reader. What should we do? If we are students of Dr. Pryor’s, and acting in that capacity, we should avoid the wagging finger and restore logical order just for the sake of logical order: for the practice of doing it, for proving we know what it is, and for proving that what we’re saying suits it well. If we’re acting as writers, though, we should write for actual readers and choose the best rhetorical order. The finger-wagging audience is terroristic and not to be negotiated with. Even if we do give in, they’ll just ask for more.
Finally, the very norms of the Lawnmower Essay that usually lead us away from epistemic sin sometimes lead us into it. Consider, for example, the device of disambiguation: if we use a technical or possibly unfamiliar term, we are told to say exactly what we mean by it, as early as possible in the essay. But what if the term is something like "consciousness" or "reason" or "rule," where the relevant paraphrase might be more confusing than the term itself? Even worse, what if all available paraphrases distort the term so badly that we end up discussing something neither we nor or readers have any intuitive grasp of or reason to care about? There are regions of lawn so gerrymandered that mowing them accomplishes nothing. The skilled philosopher will not make errors like these, but the best way to avoid them is often to abandon the Lawnmower Essay.
Time and human attention are finite and precious. When we spend them by writing, we must remember that there are, at least potentially, readers out there waiting to spend, in turn, their finite, precious reserves on our work. We owe it to them to use the best tool for the job--the best communicative tool for the job. Sometimes that’s the Lawnmower Essay; often it’s not. Choose wisely.
[1] Maybe this isn’t fair. As we’ve already noted, Pryor never uses the word "essay" in the document. Perhaps he thinks of The Philosophy Paper as an entirely different form, or as a kind of argument so pure it shouldn’t be thought of as having any relationship to any literary form. But I don’t think Pryor has this in mind, because (i) it would render his FAQ even more disingenuous / odd and (ii) I can’t charitably assume that Dr. Pryor believes that philosophical essays are not really essays.
[2] A quick aside. You will sometimes hear philosophers claim that philosophical explanation is like mathematical explanation, with similar norms and techniques. <a href="https://twitter.com/NateMeyvis/status/1332469115446030341">Do not believe this</a> (and certainly do not take this as permission to submit philosophy papers that obey the argumentative and stylistic norms of mathematical proofs). When you hear this, the speaker is almost always best understood as asserting one of two other claims. Either: (A) that philosophers write the way the speaker imagines mathematicians write, which in turn means: that philosophers write the way philosophers write. To the speaker’s credit, this claim is true. Or: (B) that philosophy classroom exercises (by which they mean Lawnmower Essays) are conducted the way mathematics exercises (e.g., problem sets) are. This is not tautologically true, nor is it perfectly accurate, but it’s accurate enough.

The Lawnmower Essay and the Problems of Philosophy

<h2>Listening notes: Jason Strasser on the Risk of Ruin podcast</h2>
Jason <a href="https://www.buzzsprout.com/1267901/10676159-the-character-building-side-effect-of-losing?t=0">was on the Risk of Ruin podcast</a> recently. He was characteristically thought-provoking and eloquent. So, for example, he notes that a lot of practical poker knowledge--or, at least, his practical poker knowledge--consisted in being able to describe situations to himself in real time and have a game plan for those situations. There's an art to carving up the space of possibilities in a way that's both real enough to be useful and coarse-grained enough to be intelligible. This is an underrated facet of poker thinking and also useful across disciplines.
Mostly, though, I was struck by a software parallel to something Jason said about risk.
Jason notes that risk profile by itself is meaningless, in the sense that (e.g.) the fact that a strategy wins X times for every Y times it loses says nothing about whether it is good for you to use that strategy. That is primarily because it offers no guarantee that the strategy has any edge in the first place. (It does you no good to win a lot if the losses, when they occur, are too large.)
This reminds me of excitement in software around type systems, formal verification, and elaborate testing principles. All of those have their place; all provide guarantees of desirable formal properties, given the existence of certain background relationships between what they are verifying and the real world; all are silent on the question of whether those background relationships actually hold. So, in software, you might have some type system and static verification system that guarantees that a system will behave "correctly," in the sense of provably transforming certain inputs in certain ways.
That's a great guarantee to have, but only if the right correspondence holds between the code you're verifying and the world. One reason--obvious, but very important--for this is that provably well-behaved code often does not accomplish any real-world result <a href="https://xkcd.com/1312/">anyone cares to bring about</a>. A less obvious reason has to do with what Jimmy Koppel calls <a href="https://www.natemeyvis.com/an-argument-from-jimmy-koppel/">the three levels of software</a>:
Providing some guarantee about some implementation of something says, in general, rather little about whether a software system can correctly represent something over time. Exactly how and why this disconnect happens is a tricky metaphysical question. But that the disconnect happens is indisputable. You can see this in a lot of codebases that use strong typing, various kinds of formal verification, or similar: the most common and obvious symptom is that all sorts of things are annotated as <code>Any</code> (or some analogoue of <code>Any</code> in the system at hand). This is usually because the system had to be modified to handle cases that the carefully constructed types could not faithfully represent. And that is usually because those types were not correctly representing anything at all. If you are designing a wicker cabinet shipping system, all the formal verification in the world will not help you if the objects in your code do not properly represent a wicker cabinet, a shipping container, or whatever else.
A further analogy between Jason's comments and the software phenomena I've described is psychological. An "attractive risk-reward profile" (on the trading side) or heavy-duty formalism (in software) often provides a sense of entitlement. This causes people to attribute failures either to bad luck or an unfair system. They're really not so different, the gambler whose martingale strategy failed him and the software engineer lamenting that his beautiful type system was vitiated by the "surprising" new requirement that it be able to express the fact that not all wicker is made of bamboo or rattan.
Of course, I love testing and use way more type annotations than most programmers who do what I do. (And Jason loves not going broke every time a trade goes wrong.) There are just a lot of ways to misuse these tools. The human capacity for error and self-delusion is always there, and it's almost never a mistake to worry about it a bit more.

Listening notes: Jason Strasser on the Risk of Ruin podcast

<h2>Listening notes: Kate Grace on The Morning Shakeout</h2>
I listen to maybe two episodes of The Morning Shakeout per year, but they're always great. Distance runners are, unsurprisingly, good at maintaining conversational pace and energy for an hour. Mario Fraioli does his homework but knows when to shut up; he's a sneaky-great interviewer.
I wasn't familiar with <a href="https://www.instagram.com/fastkate/?hl=en">Kate Grace</a>, but turns out she's <a href="https://en.wikipedia.org/wiki/Kate_Grace">good at running</a> and extremely insightful. <a href="https://themorningshakeout.com/podcast-episode-189-with-kate-grace/">Here's the link</a>. Some of many striking elements:
<ol>
<li>She advocates practicing dealing with doubts and other psychological aspects of running. For her, this is better achieved by explicitly working through (e.g.) frustration and self-criticism while practicing running than by treating mental preparation as a separate activity.</li>
<li>Her worst doubts come roughly 1/3 of the way through a set or workout. In my own (very, very different!) workout regimen I've noticed the same thing, and a lot of what I practice is simply not indulging the part of my brain that calculates how many more repetitions I have, compares my fatigue to the fatigue I remember from analogous portions of other workouts, etc. One big mental breakthrough I had when I was training as a runner was simply to realize that I persistently confused the "things are harder because I'm running uphill" feeling with the "my body is not performing well right now and I might not be able to finish this run" feeling.</li>
<li>For mental preparation, she aims for a kind of level confidence, not "hype" (which she thinks of as overrated).</li>
<li>She recommends that an elite athlete choose where to live in part by how convenient the location is to a major airport.</li>
<li>How much of what we know about the career trajectory of an athlete is mere convention or a relic from when we didn't know as much about training and longevity? Maybe a lot. Grace is (i) specializing in the 800m and (ii) running really, really fast well past the age when it's traditional to do either; she speculates that we don't know as much as we thought we did about what athletes can do at various life stages.</li>
<li>She advocates for combining a willingness to make big decisions with (i) an ability to adjust later and (ii) less fear about whether the decision is optimal. This reminds me of Patrick Collison's belief that <a href="https://tim.blog/2018/12/24/the-tim-ferriss-show-patrick-collison/">decisionmaking is overrated</a>:<blockquote>
I actually think that decision-making is probably a little bit overrated as a question or an area of study in that – investors, obviously, this is their job, right? And that’s all they can do in some sense, invest or not. [...]
But it’s not usually that. And I think that the question I would encourage people to think more about is, “How do I get to make better decisions?” as in, “How do I make sure the decisions I’m confronted with end up being better?” It’s not like, “How should I choose between option A and B,” but, “How do I make sure that both options A and B are as good as possible, and there’s also a C, D, and E, and that those options are great too?”
</blockquote>
</li>
</ol>

Listening notes: Kate Grace on The Morning Shakeout

<h2>Listening notes: Russ Roberts and Tyler Cowen on reading</h2>
A form of confidence I would like to impart more generally is the willingness to say what you think is worth saying, without embedding it in a larger or more detailed context. <a href="podcasting-faq.html">Potentially great podcasts die</a> because their hosts choose formats that are too constraining. I suspect many people think that "I'm going to talk about food with reference to the geography of current events every week" justifies itself in a way that "Let's talk about food for a while" does not. But almost any project that could be started under the first description could be started better under the second. (And if it's a podcast, "I'm going to talk for a while every week, and I happen to know a lot about food" is probably better yet.)
Happily, Russ Roberts and Tyler Cowen do not lack the confidence necessary to simply get on a call and <a href="https://www.econtalk.org/tyler-cowen-on-reading/">talk about reading for a while</a>. Some notes from the show:
<ol>
<li>Tyler's admonition to read more is important. I view it as an instance of a general fact about productivity: avoiding zero output is harder than is generally acknowledged and is a great way to increase productivity generally. This is counterintuitive, because a lot of us are focused on maximizing the value we get for our time. But in a domain where (i) it's easy to get zero return and (ii) it's very hard to predict where the very highest intellectual returns will come, you can often maximize your expected return by ensuring you're doing something. (You can think of it as power-law investing for your mind.)</li>
<li>I'd say rereading is better than Tyler thinks it is. This is probably related to <a href="on-reading-canonical-literature.html">a broader disagreement</a>, which could simply be a difference in temperament or life stage.</li>
<li>Related to (1) and also to confidence: it's healthy to admit that there are great books that just don't work for you. The best response by far in this situation is to put the book down and read something else. This is hard, because the book's fans are often right that it contains something special you won't get anywhere else. But: (i) many books are like that (more than you can read in a lifetime), so you're only sacrificing this special element, not your ability to consume uniquely special things in general; and (ii) trying to shame yourself into appreciating something tends to work about as well as trying to shame someone else into appreciating something. Just keep reading (something else).</li>
<li>Relatedly: an underrated way to grow intellectually is by learning more about your profession, or some other thing you care deeply about. Russ Roberts and Tyler Cowen don't mention this here; each of them is by now explicitly a sort of professional student of everything. But think back to Tyler's claim that <a href="https://marginalrevolution.com/marginalrevolution/2017/12/understand-modern-india.html">a great way to understand modern India is to study textiles</a>. I think he's right, but that it's less to do with textiles and more to do with the way in which focused study of any meaty topic will teach you a lot, and broadly. A lot of us have talked to strikingly well-informed people who got that way by knowing some craft and adding layers of related knowledge to it. And this gets to a point Tyler does make in this episode (and has often made over the last few years): if what you really care about is welding, don't feel bad about reading the hundredth book about welding! Reading deeply on a subject gets you super-linear returns (or <a href="on-distributing-reading-time.html">so I think</a>).</li>
</ol>

Listening notes: Russ Roberts and Tyler Cowen on reading

<h2>New site design</h2>
About a month ago:
<ol>
<li>I was coming to realize how dangerous dependencies are...</li>
<li>...even or perhaps especially <a href="on-dependencies-in-small-projects.html">in small projects</a>.</li>
<li>I wanted to be writing English prose in Vim, not a Web editor.</li>
<li>I wanted my effort, other things equal, to be gaining me capital (human, intellectual, or otherwise).</li>
</ol>
So I started writing a static site generator:
<ol>
<li>It's not that much harder to make your own SSG than to learn an existing one.</li>
<li>And I can make (or at least work toward) the SSG I want. (A common criticism of projects like this is that existing projects are always going to be better than what you hand-roll. Perhaps they're better by some independent metric, but most of their features are not useful to me, and often there are a few things I want to do that require a lot of painful customization.)</li>
<li>As I started out, I learned that making an SSG is very different from making the sorts of things I usually make. It's been useful for separating what is true about software generally from what is true about the sorts of software projects I've been consumed with thus far in my career.</li>
<li>I've been struck by how many software or software-adjacent people I know have custom Web sites.</li>
</ol>
There will be rough edges for a while. Please excuse them. And <a href="mailto: natemeyvis@gmail.com">let me know</a> if you have thoughts or bug reports.

New site design

<h2>How academics can find non-academic work</h2>
This document began its life as an email to philosophy grad students looking for non-academic work. It might be useful to you even if you are not a philosophy grad student, especially if you are looking for work in the tech industry. All feedback is welcome.
<h3>My background / credentials for giving this sort of advice</h3>
I have spent roughly a decade in and around the non-academic job market. I have done recruitment and interviewing at every company that’s employed me and for years I was responsible for recruiting and hiring at a genomics startup. It was my job not only to manage our hiring process but to study non-academic hiring processes more generally. Moreover, we recruited, interviewed, and hired many academics--mostly biologists, but also philosophers, linguists, and other humanities types. I have also looked for jobs several times and have had countless conversations with industry folks who were looking to hire people.
More concretely, I’ve conducted roughly 300 interviews. More than half of these were of candidates with Ph.D.s, and of those, many were people who one might describe as “transitioning from academia” (as opposed to folks for whom there was a well-defined Ph.D.-to-industry path, and who might never have intended to stay in academia). Roughly 1/4 of those were humanities Ph.D.s, and roughly 1/3 of those were philosophy Ph.D.s.
So: I’ve spent a whole lot of time thinking about these issues, though my experiences are necessarily limited. The job market is a very big place; everyone’s experience is limited. I know more about the software side of things and am still closely in touch with the startup world. There are many other sides of many other things, where the advice below might not apply so well.
<h3>Finding jobs to apply to</h3>
My colleagues have often wondered how they could find a job in circumstances where they didn’t at all know what they were looking for. <a href="http://www.perseus.tufts.edu/hopper/text?doc=plat.+meno+80d">This is a reasonable concern</a>. We can factor the problem into two parts: learning about job-types and learning how to find specific opportunities.
Here are some kinds of jobs that exist (mostly unknown to me ten years ago):
* Technical documentation writers
* Marketing writers
* Product managers (and entry-level jobs in product departments)
* Operations managers, recruiting managers, HR folks of various kinds
* Software testers (see below for more on software)
* Librarians / archivists
* Consultants
* “Directors of Happiness”
* “Business Operations Specialist” (what appears to be an advanced administrative job title at IBM)
<h3>How to find specific jobs (also a good way to discover more job-types)</h3>
<ul>
<li>Pick names of companies out of a hat. Go to their Web sites. Click on “Careers.”</li>
<li>Every month <a href="https://news.ycombinator.com/">Hacker News</a>, a start-up / technology link aggregator and discussion board, has a “Who’s Hiring?” thread. (A <a href="https://www.google.com/search?client=safari&amp;rls=en&amp;q=who%27s+hiring+site%3Anews.ycombinator.com&amp;ie=UTF-8&amp;oe=UTF-8">site-restricted Google search</a> ought to turn up recent threads.) Many of these jobs are for coders or other folks with software experience, but plenty are not.</li>
<li>Ask around (I know it’s obvious, but many people don’t do this enough).</li>
</ul>
<h3>Miscellaneous notes</h3>
You are likely to have a “non-traditional” background for many of the jobs to which you will be applying. You might lack a background as an editor but be seeking an editorship, for example. Do not despair if you do not meet every desideratum listed on a job ad. Whereas academic job listings often include lists of qualifications that preferred candidates will far exceed, non-academic job listings often contain “wish lists” in the guise of hard requirements. (These generate amusing stories — e.g., about job ads requiring N years of experience in a computer language that did not exist N years ago.) If you think you might be able to do the job, and if the application requirements aren’t onerous, give it a shot. (Update 2022-02-09: deleted a happily obsolete joke about Interfolio.)
You might, of course, really be less qualified than the competition for that editorship (or writing job, or coding job, or…). It is therefore also useful to consider how to compensate in such situations. One strategy is to apply to startup companies. Such companies are often willing to take on less traditional candidates, for at least two reasons. First, they often offer somewhat lower salaries and less job security than more established companies (they generally can’t afford above-market or sometimes even at-market compensation, and there’s often no guarantee they’ll still be in business in a couple years). As a result, they often have to be willing to accept candidates who are by some traditional metrics less qualified. Second, they often need to get a small staff to handle the whole set of tasks for a company, so they need to find generalists. This sometimes leads to a desire to trade deep experience in a field for general intelligence and aptitude (and a good attitude about taking out one’s own trash, tolerating uncertainty, and so on).
<h3>Preparing job applications</h3>
Application materials vary widely, but here are some suggestions:
<ul>
<li>Attempt to strike a balance between emphasizing the virtues of an academic background and your non-academic preparation, your eagerness for the role at hand, etc. Nobody (or at least very few people) will blame you from expressing positive views about many subjects, even when that might appear to reveal inconsistent preferences. (For example, don’t worry about being enthusiastic about the chance to take on short-term projects that offer fast feedback even if you have previously talked about the immense value in taking on a years-long project undertaken in the pursuit of academic rigor and not an immediate market test.)</li>
<li>Do not assume that the reader of your materials will appreciate the importance of your dissertation subject or of philosophical inquiry more generally. Again, the goal is to take appropriate pride in your work without making too many assumptions about the reader’s sense of its value or its reflection on you. In most cases, a brief expression of genuine interest in a job will matter much more than a strained claim that one’s work is relevant to the job. (People who read these materials often spend many, many hours a week reading such materials. They read a lot of strained claims that X is relevant to Y. Even if they are not as smart as you are, they have very keen noses for this sort of thing.)</li>
<li>Your materials might be evaluated by software. Do not fail to use keywords (“editor,” “Portuguese,” “Ruby”) that truly describe your qualifications and that the software might be looking for.</li>
</ul>
<h3>Interviewing</h3>
There are more interviews and more kinds of interviews than can be usefully surveyed here. Some miscellaneous notes:
There is likely to be some sort of performance aspect to an interview (sample editing work; whiteboard coding; hypothetical discussions of conflict resolution; etc.). If you are rusty at some mechanical aspect of a domain, it is useful to prepare for an interview as one might brush up for a standardized test.
You might face implicit or explicit suggestions that being a grad student is problematically different from being a [whatever you are applying to be]. Of course, these situations need to be navigated in light of their variable particular features, but it might be useful to think through some ways in which being a grad student and writing a dissertation is apt preparation for corporate work. Here are three:
<ul>
<li>The most common desideratum I have read from companies looking to hire remote workers is a candidate’s experience in working remotely or independently. Having written a dissertation would (in many contexts) go a long way toward convincing a prospective employer that you’re not going to watch YouTube all day.</li>
<li>More generally, grad students have the chance to prove that they do things and get results. Many employers are looking for people who can reliably get the project finished instead of working only on the easy parts and saving the hard parts for later (forever), fretting about feedback too much to show results to peers or supervisors, etc. Do not forget your teaching experience when you are looking for examples of situations in which you have reliably produced acceptable work on time.</li>
<li>The ability to cope with setbacks and failure is often something an interviewer is looking for; most of us have academic experiences of this sort to talk about.</li>
<li>Note for philosophers: It’s not easy to talk about one’s research to a non-philosophical audience. Some interviewers will be interested in your work; others will be rather hostile to the whole enterprise of academic philosophy, and especially to anything that may appear to be a merely verbal dispute. (A prominent person in biotechnology once told me about the philosopher he knew who has the stupidity and audacity to work on vagueness [“it’s just obvious it is a non-problem”].) You might just have to wing it, be honest, and hope for the best. That said, try to emphasize ways in which the problem can seem compelling to those without philosophical training; be accurate without making your interlocutor feel attacked or not heard; try to give your interviewer something to hold on to (you probably have a five-second summary of your work for the academic job market; try to produce some quick summaries that will be accessible to laypeople). Also, many people who do not like philosophy do like “fun facts.”</li>
</ul>
Many people who might be interviewing you spend lots and lots of hours interviewing people. Their jobs are not always fun. If you can make your conversation more pleasant than the next person’s, you’ll have helped yourself — and brightened that person’s day.
Here and elsewhere, do not assume that your reader or interlocutor is lazy, stupid, or mean (despite <a href="lawnmower.html">what you might have been trained into</a>), unless you have hard evidence that some particular person really is one of those. People generally do not wish to spend their professional lives in the company of people who make such assumptions about them. And spending too much space and time protecting yourself against vicious readers’ misreadings will prevent you from displaying the most important aspects of your background and candidacy. Interviewers will want to know whether you can function in a team and whether you will take a positive, constructive approach to your work. It may therefore be useful to keep in mind the improv maxim: begin replies, even to silly or ill-formed prompts, with “yes, and…” (At the very least, consider using “and” whenever you are tempted to reply with “but.”)
Err on the side of accuracy, of course, but note that the sorts of folks who end up staffing HR departments often overvalue (less-than-fully-articulated versions of) the virtues of straightforwardness, clarity, and confidence. Qualifying your claims may be interpreted as a lack of confidence or as an excess of belligerence. As always, assessing one’s interlocutor is valuable.
Your interviewer is unlikely to know what a premium academic philosophers place on rigor and the close connections that philosophy has with technical disciplines. It might be important to correct such false impressions (gently!). If, say, your work in epistemology has led you to study representation theorems, you’ll often do well to mention those theorems.
Do a little bit of homework. Google is your friend. A good way to differentiate yourself from others is to show that you really care about the job (this is quite a contrast from the academic job market!). Don’t appear desperate, but do appear interested. Ideally you can signal your interest in a way that can’t be faked (perhaps by reading a white paper that the company has published).
If they ask you if you have questions for them, reply honestly, and also consider asking about the job itself. (“What’s the day-to-day like? To whom does the position report? How will my success be judged?”)
<h3>A few miscellaneous notes</h3>
Writing is a superpower. Many of us underestimate the effectiveness (both in general and for one’s reputation) of memos, follow-up emails, blog posts, contributions to internal documentation, and so on. Use your superpowers.
It’s generally OK to send a friendly note asking about the status of your application. Things sometimes go slowly or fall through the cracks. If you are polite and if your requests are reasonable, you probably won’t hurt your chances by making such inquiries.
Hiring decisions are often made by committee. What might sound like an informal guarantee that you will get an offer might only be an expression of one person’s enthusiasm (or a misguided attempt to be encouraging).
If you receive a job offer, do not be afraid to negotiate (politely and professionally). The norms here vary greatly from context to context, but in many situations one is expected to haggle a bit. Seek advice from a domain expert if you are in this situation. If the job is in software, <a href="https://www.kalzumeus.com/2012/01/23/salary-negotiation/">read this</a>. (If you think I might know something about the domain in question, feel free to email me.)
Good luck.

How academics can find non-academic work

<h2>Notes on a Bryan Cantrill talk</h2>
So! Bryan Cantrill (who, it turns out, <a href="https://en.wikipedia.org/wiki/Bryan_Cantrill">has a Wikipedia page</a>) gave <a href="https://www.youtube.com/watch?v=30jNsCVLpAE">a talk</a> at GOTO 2017. It deserves to be seen more than a five-year-old conference talk figures to be. Some notes:
<ol>
<li>For Cantrill, debugging is the process of asking questions of a system (and not, primarily, attempting to fix a system). This reminds me of Michael Feathers' view of testing as primarily about describing what a program does (and not, primarily, of enforcing its correctness).</li>
<li>Therefore, debuggability is the propensity of a system to have questions asked of it. I think about this in Socratic terms. When you're doing intellectual work, you of course need to have ideas to talk about. But you also need to be in the right condition to pose and answer questions in light of those ideas. That system of questioning is the more fundamental thing. (In grade school I was taught that The Scientific Method requires one to formluate hypotheses strictly before looking at data. This view seems totally archaic.)</li>
<li>Relatedly: suppose X is causing an incident in a distributed system. Given that, you'd like to have an alert for X. It does not follow that you should have tons of alerts all over the place! Humans are not very good at inferring from alerts to causes in the first place, and this ability degrades quickly with the number of alerts to process (<a href="https://www.youtube.com/watch?v=gO8N3L_aERg">video link</a>). eThis is not quite how Cantrill puts the point.)</li>
<li>We can learn about distributed systems incidents by looking to history, and not just the history of computer distributed systems. (Cantrill has a useful discussion of <a href="https://en.wikipedia.org/wiki/Three_Mile_Island_accident">Three Mile Island</a>.)</li>
</ol>
Some people react to intellectual challenges by reciting everything they know; others are great interlocutors. Whom would you rather be working with in an emergency?

Notes on a Bryan Cantrill talk

<h2>On actually reading the book</h2>
First, two conjectures:
<ol>
<li>Basically nobody has read Knausgaard's My Struggle all the way through. My evidence: (i) it's really long; (ii) there's about 1000 pages in the middle that most people, including the author, think is substantially weaker than the rest; (iii) most commentary, even from people who talk as if they've read the whole thing, focuses on the first book or two; (iv) there is some absolutely mind-blowing, wonderful, hair-raising stuff in the sixth book. More concretely: I've heard a bunch of people describe My Struggle as provocative, but the evidence they give tends to come from the first 100-500 pages of the series, even though book VI gives, e.g., an argument that the ethos of modern Western day cares comes, psychoculturally, right out of Nazi values. And people claim that the series is structurally innovative, but again, the evidence for this usually comes from the beginning of the series. I've never heard someone mention that there's a c. 100-page analysis of a Paul Celan poem right in the middle of Book VI. The best explanation of all this is that people simply never got to (or even near) Book VI.</li>
<li>Basically nobody has read The Mathematics of Poker all the way through. My evidence: (i) it's long; (ii) much of it is difficult; (iii) most commentary, even from people who talk as if they've read the whole thing, focuses on the overall approach or the beginning. So, for example, the poker world is full enough of people who like to poke fun at and/or find amusing details in poker books, but I've never heard anyone other than me mention that near the end of Mathematics of Poker there's a page or two where every lowercase s is italicized (so that you read things like "this issue"). And here's <a href="https://statmodeling.stat.columbia.edu/2014/08/25/poker-math-showdown/">a blog post from 2014</a> in which a respectable person claims that the whole risk of ruin analysis is completely flawed. Whether or not the claim is right or wrong, the issue is (I think!) pretty serious, at least as a matter of clear communication. Again, the best explanation of why all this happens only in a few comment threads from 8 years after the book's publication date is that basically nobody ever made it to, much less seriously worked through, that part of the book.</li>
</ol>
This all reminds me of:
First, <a href="https://fs.blog/the-buffett-formula/">Warren Buffett's famous claim</a> that you should simply read a lot of relevant material because "knowledge builds up, like compound interest."
Second, a claim from <a href="https://twitter.com/benskuhn/status/1419281153983500290">this wonderful tweetstorm</a> about gaps in results from number theory:
<blockquote>
Apparently it's frequently the most famous people who discover these gaps. Roommate said it was surprising the degree to which a lot of what famous people do is actually what everyone is "supposed to do," e.g. deeply understanding techniques, checking things for yourself...
</blockquote>
And third, Byrne Hobart noting that that claim "<a href="https://twitter.com/ByrneHobart/status/1419406713007001608?s=20">generalizes across other fields</a>." I can affirm it's true in philosophy, poker, and software.
People often ask what they can do to generate original contributions or comparative advantages. Usually they vastly overestimate how common it is to have gone through the basic intellectual background in a field. If you've actually read the book (actually checked the proof, actually implemented the algorithm), you're probably way ahead of the field. Much expertise is simply doing this over and over.
Addendum 2022-10-05: <a href="https://www-cs-faculty.stanford.edu/~knuth/news.html">This note from Donald Knuth</a> suggests that he thinks that "nobody has been sufficiently motivated to check the finer points out carefully as yet." From context it seems to me that "check out the finer points" means "actually work through properly."

On actually reading the book

<h2>On Anki's database</h2>
I am a daily spaced repetition user (I describe how and why <a href="on-using-anki.html">here</a> and <a href="on-using-anki-again.html">here</a>). I've been working with my Anki data lately, which has meant exposing and manipulating the <a href="https://www.sqlite.org/index.html">Sqlite</a> database underlying the program. (I'm grateful to the <a href="https://github.com/ankidroid/Anki-Android/wiki/Database-Structure">Ankidroid project</a> and <a href="https://www.reddit.com/r/Anki/">r/anki</a> for having documented so much about the .apkg format and the database itself.)
The database structure is fairly typical of data management in long-running projects. And, typically, some of its design looks rough to fresh eyes. When fresh eyes see rough parts of a software project, <a href="https://danluu.com/wat/">it's important to write about it promptly</a>, and the Anki community is large and dedicated enough that it seems worth doing that writing in public. So here's what I think could be better.
By the way, <a href="https://www.itsinks.in">It Sinks In</a> is an attempt to address some of these issues with a user-friendly, cloud-based approach.
<h4>Caveats</h4>
<ol>
<li>Anki is, I think, maintained by a very small team. Some of the notes about the intelligibility of the schema matter less if there aren't many people who need to work with the database every day. You can think of the relevant notes as things that are merely suboptimal now and would be more damaging if the Anki project were to grow.</li>
<li>The underlying database is, I think, not (or at least not primarily) intended for direct manipulation by program users. So there's a sense in which it doesn't matter very much how intelligible I think the data management is. That said, insofar as it affects the accuracy or performance of the software, it certainly matters. And given that people turn over parts of their minds to Anki, it's especially urgent to document these things.</li>
<li>Anki is great and all this comes from a place of love.</li>
</ol>
<h4>Principles behind these notes</h4>
You can think of this as a data-oriented extension of my code review reference; this is all stuff I find myself saying a lot. Seeing so many of these issues crop up in Anki's database was one impetus for making a case study of it.
<ol>
<li>Try to name columns (or tables, or documents, or whatever) according to what the thing is. Not its domain, not what you want it some day to be, and not even its intended use, but what it is.</li>
<li>Unless you have a very good reason to denormalize your data, represent a given piece of information at most once in your database.</li>
<li>Unless you really need to optimize something, make a given column represent only one piece of information. (You know those surveys where you rank things on a 1-7 scale, but "4" also means "not applicable"? Do better than that.)</li>
<li>All else equal (and sometimes even if not), use consistent conventions (e.g., for naming, for delimiters, and for <a href="https://en.wikipedia.org/wiki/Universally_unique_identifier">UUIDs</a>).</li>
</ol>
<h4>Notes</h4>
<ol>
<li>In the <code>cards</code> and <code>notes</code> tables, the <code>id</code> (primary key) field is the number of milliseconds since the epoch when it was created. There are good reasons not to have semantically meaningful information in the <code>id</code> field: in this case, it is entirely possible for several <code>cards</code> to be created at the same millisecond. (The foreseen use case is that of a single human creating cards manually, but what if the system scales to many users with many cards? What if cron jobs that go off at midnight generate new cards? What if cards are created from timestamps that only have second-, hour-, or day-level resolution?)</li>
<li>In the <code>cards</code> table, the <code>type</code> and <code>queue</code> columns duplicate information and both express what I'd be tempted to call a "learning status" (whether the card is new, is being reviewed, is buried, and so on). The database would be cleaner with these collapsed into a single column with a better name.</li>
<li>In the <code>cards</code> table, several columns have integers representing times or durations for which the units are different depending on some other feature of the card. For example, the <code>due</code> column is an integer representing either a number of days or a number of seconds, depending on the card status. I could imagine a case for splitting this out into separate columns. It's also worth considering not explicitly storing the data at all, because it's a function of other data (and the learning algorithm). Because most decks are not huge, it could probably could be calculated on demand (or, if it really needs to be precomputed, cached elsewhere).</li>
<li>The <code>cards</code> table has a <code>reps</code> column indicating its number of repetitions. This duplicates information from the <code>revlog</code> table. One could imagine a situation where information needs to be denormalized in this way, but (i) this system is clearly not designed for the sort of scale that would require that (see other notes) and (ii) if so, it would probably be better to keep "source of truth" <code>cards</code> data in a separate table and generate separate denormalized views or tables. Similar comments apply to the <code>lapses</code> column.</li>
<li>The <code>flags</code> field is only significant mod 8: mod-8 values correspond to various colors of flags or no such flag. This rules out the possibility either of a card's having several flags set or of there being more than 8 flag-states. Moreover, coders accustomed to "flags" fields will likely anticipate a system where bits of a binary representation correspond to flags' being set. Given that this is an integer field in either case, little would be lost and much gained by adopting a more standard system for representing flag values.</li>
<li>There is a <code>graves</code> table representing cards, notes, and decks that have been deleted. This is awkward. First, it combines heterogeneous data (data that are different not only in representing different categories of items but also in actually being stored in separate tables in this database when learning circumstances are different). Second, it amounts to moving data from one table to another in the case of a status change; it is usually better to simply make such a change like that in existing status fields. (I often find that solutions like this are attempted compromises by programmers who are pretty sure, but not completely sure, that data should be deleted. It is almost always better to settle that question once and for all--by literally deleting it, by leaving it, or by sending it off to some archive or backup--than to attempt this kind of compromise.)</li>
<li>The relationship between <code>notes</code> and tags is represented by a text column on <code>notes</code> with a list of tag names, both separated by spaces and with spaces at the end (in order to support <code>LIKE "%tag%"</code> queries, according to the Ankidroid documentation linked above). This is an error-prone way to represent a many-to-many relationship. I'm not an SQLite expert, but I'd imagine it's inefficient, too. More fundamentally, tags are clearly domain objects that should be properly represented (and probably need their own table). Whenever I've tried to keep track of objects like this ad hoc as strings--and I've tried this many times!--I've regretted it. (Do as I say, not as my past self has done.)</li>
<li><code>flds</code> (representing a many-to-many relationship between <code>notes</code> and fields) is represented similarly to <code>tags</code>, but separated by <code>0x1f</code>. The comments above apply, and there's an extra bit of potential confusion because the delimiter is different here. An aside: in this case, using <code>flds</code> instead of <code>fields</code> appears to be abbreviation for abbreviation's sake, and nothing more. But I often find that abbreviations like this, especially when nearby objects are not abbreviated, correspond to misalignments between the abbreviated word and the data object. So, for example, <code>tmstp</code> might abbreviate "timestamp" but actually mean something closer to "a timestamp but not really." When you read code, get in the habit of asking whether abbreviated names are subconscious (or conscious) expressions of the fact that the name isn't quite right.</li>
<li>The <code>csum</code> ("checksum") field on <code>notes</code> is (apparently) intended for uniqueness checks. (It's not clear that this is literally a checksum; see point (8).) This function would be better served by using built-in mechanisms for creating unique <code>id</code>s. (More generally, database software is pretty good at primary key management and generation. Programming is hard enough; leave this sort of thing to the software.)</li>
<li>In the <code>revlog</code> table, the <code>time</code> field represents a duration, is capped at 60s, and is represented in milliseconds. It's usually best not to throw away information. (Are you so sure you won't ever care about the difference between 65 and 75 seconds?) Moreover, this is not a time but a duration and should be so named. And it would probably be best simply to store the beginning and end timestamps of the review and let the calculations be done downstream: this is a subtle form of storing several pieces of information together.</li>
</ol>

On Anki's database

<h2>On Bryan Caplan's spreadsheets</h2>
Bryan Caplan <a href="https://www.econlib.org/no-one-cared-about-my-spreadsheets/">is complaining that</a> nobody looked at the spreadsheets on which he based The Case for Education. Tyler Cowen comments <a href="https://marginalrevolution.com/marginalrevolution/2022/02/no-one-cared-about-bryans-spreadsheets.html">here</a>.
I also did not look through Prof. Caplan's spreadsheets, and I'm probably one of the likeliest people in the world to have done it. I'm a computer programmer, quantitatively trained, and I care a lot about the subject.
So why didn't I read through the spreadsheets? Yes, I'm going to repeat some of the Excel complaints (see <a href="https://www.econlib.org/archives/2014/06/embarrass_me_no.html">the comments</a>), but with more context.
It's almost impossible to take someone seriously who says that they care so much about the accuracy of their results when they're calculating this intricately in Excel. If you really care about maintaining a complicated set of data relationships, you write readable, testable code somewhere.
Put another way: when you care enough that something like this is right, you test it with computers, not just people.
I know Bryan is aware of this complaint. He says:
<blockquote>
P.S. Using Excel does not count as “demonstrable error.” It’s my comparative advantage.
</blockquote>
Comparative advantage at what? There are literally hundreds of thousands of people who are better than this at maintaining quantitative infrastructure with computers, so I don't think he's saying "I have a comparative advantage at maintaining quantitative infrastructure with computers, and this is how I do it." He might be implying that there's some aspect of this reasoning that is better done with Excel than with other tools, and that he is uniquely trained to do it--but I can't think of what that would be.
(By the way, I spent more of 2020-1 looking at work in Excel than I would have preferred to, and I suspect Bryan's Excel skills do not stack up as well as he thinks they do. But, happily, I am not really in a position to judge.)
A few further points:
When you say "I have put tons of effort into ensuring the accuracy of this Excel sheet," knowledgable people will not infer that your work is less likely to contain errors. They will assume that you are <a href="on-quadratic-complexity.html">fighting quadratic growth</a> and losing.
Compare: "I have spent X hours fixing my car myself this year. I have asked many neighbors to look at the car. I've issued an open invitation to the Internet also, allowing any respondent into my garage."
For large X:
1. Do you think that car is safe? Would you ride in it?
1. How much do you think that person really cares about car safety?
1. Are you surprised that more people did not respond to the open invitation?
1. Would you expect those who did respond to be the very best mechanics?
Crucially, how do your answers change as X goes from "large" to "very large"? I conclude that Bryan is not giving evidence for what he thinks he's giving evidence for when he talks about how much effort (of a certain sort) went into his spreadsheets.
Finally, remember that the attention of people who can best assess Bryan's work is very scarce. (Surely Bryan knows what this labor market is like?) A lot of them care very much about Bryan's work and conclusions, but the world is full of interesting data and programs to look at and make. To spend scarce time giving a professional look at these spreadsheets, I'd have to care not just more but so much more about this than about any project in the world that uses more modern tools. Elsewhere, I could use my attention at least an order of magnitude more efficiently.
Like Bryan, I conclude with regret about state of the art in professionalized quantitative social science, but I'm much more optimistic than he seems to be about the future of quantitative work more generally. (The ironies of Prof. Caplan, in this context, citing his professional training to justify his methods, are too obvious to elaborate on--but they are amusing nonetheless.)

On Bryan Caplan's spreadsheets

<h2>On capturing thoughts</h2>
What's the most efficient way to get ideas from your head into some sort of storage? (Hat tip to <a href="https://twitter.com/ben_reesor">Ben Reesor</a> for the question.)
I'm a contrarian here, at least with respect to the productivity community. First, I advocate for domain-specific capture. If you're an expert with some software like Drafts, Notes, or Roam and have a good system for getting anything in there, great. But I do better putting tasks into Reminders, facts into DevonTHINK, messages directly into a messaging client, and so on. And I don't know anyone for whom a general-purpose capture system has worked better than a piecemeal system.
There's a line of thought according to which we should resist piecemeal capture systems, with two claims at its core:
<ol>
<li>You should be able to coordinate (put into a graph structure, search over, or whatever) all your notes in a single system;</li>
<li>You should be able to capture arbitrary thoughts quickly, not just ones you can already classify as tasks, memories, or whatever.</li>
</ol>
The first of these just seems false to me. Having a single digital system that reflects as much as possible of your mind, life, and history is, for some, an appealing ideal. But why expect that tasks, memories, goals, and everything else should comprise a single software system? They don't feel, behave, or manifest themselves similarly in our embodied lives, so why should they do so in our software lives? More practically, domain-specific tools are so wonderful these days that I'm more eager to bet on the future of a piecemeal system than a fully integrated one.
I'm more contrarian still with respect to the premise behind the question, though: Why think that it's good to capture the marginal thought? I've recently gone through a bunch of my old notes and journal entries. They're terrible.
Empirically, my note-taking is most valuable when it's tied to some long-standing line of thought or established project. This is all the more reason to keep a quick-capture system piecemeal. At least for me, the dream of being able to record arbitrary thoughts quickly is not worth pursuing: The more I've pushed myself toward a general-purpose capture system, the more I've encouraged myself to capture--and perhaps distract myself with--my worst ideas.
There are surely people who have much better random thoughts than I do. If you're one of them, good luck. But remember that reducing friction in the general case often increases it in specialized cases (e.g., as you need to move tasks from a general-purpose system into a task manager). Don't set a goal of reducing that friction without at least trying to assess the tradeoffs involved.

On capturing thoughts

<h2>On checklists, again</h2>
A while ago <a href="https://www.natemeyvis.com/writing/on-linear-scans/">I wrote that</a> checklists are (i) underrated and (ii) underrated by people who might be expected to rate them highly.
One further note, which perhaps states the obvious: I suspect part of the resistance here is the tension between the rigidity and algorithmic nature of a checklist and the often very different nature of the thing the checklist is about. This blinds us to the possibility of using a checklist and tempts us to reject any such list on the ground that it must be missing something. It's not easy to reply to oneself: "Yes, it's surely missing something, but hopefully not too much.")
When you learn calculus and get to integration, it's standard to hear in the first lecture that although differentiation can be done algorithmically--with few caveats, if you learn a fixed set of techniques, you can calculate any derivative you'll see--integration cannot be done that way. In general it requires some insight. A while later, you're likely to hear that if it's tricky enough, you should really just try integrating by parts.
Anyway, here's a list I find useful:
<h3>What's going on when people are persistently behaving in a way I can't figure out</h3>
<ol>
<li>They're signaling something.</li>
<li>There's a feeling I don't understand, or a connection I don't understand between the behavior and some feeling.</li>
<li>Taxes.</li>
<li>The obvious alternative is less good than I think it is.</li>
<li>The Coase theorem applies (am I conflating the formal locus of power with the practical balance of incentives?).</li>
</ol>

On checklists, again

<h2>On Conversations with Tyler</h2>
Here's my stab at the guide Tyler and his producer mentioned near the end of the <a href="https://conversationswithtyler.com/episodes/conversations-with-tyler-2021-retrospective/">2021 retrospective show</a>. The goal is to give the uninitiated listener essential context. (They mentioned a 10-point guide, but I only need 8.)
<ol>
<li>These are not debates. Tyler will make his point and move on. He will let the interviewee do the same. Nor are they wrestling matches: one neither needs to pin down the opponent for some length of time nor see a scoreboard get incremented. (So, just because Tyler doesn't mark the occasion specifically, don't think he doesn't take himself to have just decisively refuted an entire Nobel Prize-winning body of research.)</li>
<li>Why talk as in (1)? One reason is efficiency. Never forget that this is part of <a href="https://www.mercatus.org/bridge/commentary/my-personal-moonshot">Tyler's moonshot project</a>, one core of which is for him to process as much information as he can. Always think of Tyler trying to maximize his own intellectual progress per minute.</li>
<li>Again, why talk as in (1)? Think of Tyler as committed to the view that things have explanations (perhaps several) and as a realist about explanations. In particular, sometimes explanations are, in fact, simple--which is not to say "easy." Here I think of the way (the philosopher) David Lewis often seemed to believe things based on very short lines of argument (e.g., <a href="https://www.csus.edu/indiv/m/merlinos/paradoxes%20of%20time%20travel.pdf">here</a>), or the way Reid Hoffman <a href="https://hbr.org/2015/03/reid-hoffmans-two-rules-for-strategy-decisions">values simplicity in decisionmaking</a>. (This is one way Tyler is working in philosophical traditions; see below.)</li>
<li>If you are a realist and a pluralist about explanation, you ought to care how these explanations coexist. And Tyler does. So, e.g., he <a href="https://conversationswithtyler.com/episodes/robin-hanson/">presses Robin Hanson</a> on levels of explanation. And for guests with thrilling empirical results (e.g., <a href="https://conversationswithtyler.com/episodes/raj-chetty/">Raj Chetty</a>), he tends to ask "but what's the causal mechanism here?" Such questions are deeply unfashionable in some circles these days, and it's striking how much his guests vary in the quality of their answers here.</li>
<li>I view Tyler as working in a Socratic/Platonic tradition. (Explanations exist; they're domain-relative; their domain-relativity does not undermine their reality; the real natures of things are very hard to understand, usually too hard for a single human mind; etc.) More generally, whether or not he resembles an academic philosopher, and whether or not you want to think of his work as philosophy, think of him <a href="https://www.amazon.com/dp/B07G9DFC8W/ref=dp-kindle-redirect?_encoding=UTF8&amp;btkr=1">thinking of his work as philosophy</a>.</li>
<li>If you still don't understand why Tyler is asking something, think about comparative advantage. He views his guests as having uniquely benefited from some lifelong course of study (see (2) above) and attempts to extract as much insight as possible from the intellectual tools they've uniquely developed.</li>
<li>And if you still don't understand, think about cultural background. Tyler thinks that things tend to have earlier roots than is generally recognized: that includes individual people's intellectual output. He's not asking about someone's childhood to be polite or to humanize the guest: he probably suspects that their work on cancer research (or whatever) truly grows out of their being a cultural product of Topeka (or wherever).</li>
<li>Some, but only some, teachers-on-the-Internet (1) remember that you have pause and rewind buttons and (2) take you to know how to use them. Tyler is one of them.</li>
</ol>

On Conversations with Tyler

<h2>On coordinating intrapersonal skill levels</h2>
A while ago I wrote that software is different from poker in that it's more often correct to get some mileage out of worse-performing versions of yourself (it's often best to quit a poker game when you're not playing well, but there's productive work you can do as a fuzzy programmer). 
Judging from my correspondence, many people disagree with this. A few thoughts:
<ol>
<li>
There's a distinctive skill to making progress when you're on your B- or C-game, programming-wise. This is a great time to write tests, clean up some of the easy / annoying TODOs, write scripts to do checks on data, and so on. And if some code is impenetrable when I'm tired, that's a good sign it's not clear enough simpliciter. It's probably the wrong time to design an interface or do really hard architectural work, but there's a lot that can get done.
</li>
<li>
Small commits are a good idea generally. I rely on them even more when I know I'm not at peak performance.
</li>
<li>
Recently Dan Luu <a href="https://twitter.com/danluu/status/1524068642538672130">has offered some similar thoughts</a>. They're characteristically excellent. (And I hope he feels well soon.)
</li>
<li>
The value of learning tooling is often described in terms of raising peak performancer. Its benefits in raising mediocre performance might be understated. Writing tests confidently, rolling back changes, and so on--if you do these competently enough to do them when you're on your B-game--help a ton.
</li>
</ol>

On coordinating intrapersonal skill levels

<h2>On dependencies in small projects</h2>
Dan Luu <a href="https://twitter.com/danluu/status/1434282810622291970">Tweeted</a>:
<blockquote>
The places where I most regret taking a dependency are often very low effort projects (like the SSG for my blog), where the complexity of the dependency wasn't worth it.
</blockquote>
I've chewed on this for three days. It feels like a <a href="https://www.reddit.com/r/slatestarcodex/comments/3st7e5/what_was_your_last_great_viewquake/">viewquake</a>. Some reflections:
<ol>
<li>The survivor bias in the sample of "here's a thing I hacked together on a weekend" is obvious but easy to overlook.</li>
<li>Also obvious but easy to underestimate: there are strong social norms encouraging people to exaggerate (i) how fast they've shipped small projects and (ii) how well those projects work.</li>
<li>A lot of small projects, certainly including those that rely on a dependency the way a personal site relies on a static site generator, do not survive. I have lots of first- and third-personal evidence here.</li>
<li>Most dependencies that are maintained well enough to avoid crippling bugs also add features regularly. Over time, and often despite maintainers' best efforts, this can make basic "plug and play" usage harder.</li>
<li>Small projects, not just in software, are harder to pull off than they seem. So here's another way to frame the point I take Dan to be making: Let's say a project seems small. You do it without taking on a dependency, and it's basically a success, but it took more effort than it seemed it should. So we have extra effort to account for, and at least two possible causes: (i) the actual intrinsic difficulty of the project and (ii) the fact that you didn't get a boost from the dependency. Because we underestimate (i), it's natural to overestimate (ii).</li>
</ol>

On dependencies in small projects

<h2>On dependencies</h2>
If I could give four words of instruction to an unknown intermediate-level programmer, I'd probably go with "think about dependencies more."
It's remarkably hard to keep track of what exactly you're thinking about when you're thinking about dependencies. There are at least three candidates:
<ol>
<li>There are dependencies at the file/package/module (depending on the system you're working in) level. When your compiler (or interpreter, or whatever) complains about a circular dependency, this is the kind of dependency you start reasoning about.</li>
<li>There are dependencies of objects on objects. So, when you read Architecture Patterns in Python and you read that your domain entities should be depended on and not depend on anything else, it's this kind of relation you're thinking about. But these discussions often occur at the code level, and there is also a logical level, so that:</li>
<li>There are dependencies of objects on objects at the logical level. So, for example, when you make a foreign key reference in a Django model <a href="https://docs.djangoproject.com/en/4.0/ref/models/fields/">with a string instead of the Model itself</a>, you avoid a dependency at the code level but retain it at <a href="an-argument-from-jimmy-koppel.html">the logical level</a>.</li>
</ol>
There are a few immediate lessons here:
<ol>
<li>It's easy to take yourself to be thinking about one kind of dependency and actually be thinking about another.</li>
<li>If you're making a dependency graph, be sure not to graph different kinds of relationships at the same time or unwittingly make the same box refer to, e.g., both a module and a logical object.</li>
<li>Devices that remove one sort of dependency might leave another sort of dependency, and the remaining dependency might be dangerous.</li>
</ol>

On dependencies

<h2>On distributing reading time</h2>
Suppose you've read 90% of Alice's output, 50% of Bob's, and 0% of Charlie's. You have an hour available for reading: whom should you read?
Other things equal, I'd argue for: Alice, then Charlie, then Bob. That is: choose a T-shaped consumption strategy. I think it's broadly accepted that broad sampling in reading is a good idea: the controversial part is advocating for reading the 100th hour of Alice instead of the 30th hour of Bob. For one thing, you have less fresh material from Alice to choose from (other things equal).
But I find myself more and more confident in the T-shaped strategy. Some arguments:
<ol>
<li>It feels to me like I get outsized value from the thinkers I read the most.</li>
<li>One of my favorite questions to ask impressive thinkers is: "Who is the most obscure person whose output you read all of?" I've never posed this question without getting a good answer. That is, impressive thinkers are pursuing the "consume everything from at least some people" strategy, and I should mimic that strategy.</li>
<li>There is a valuable reward, governed by a threshold, to reading enough of someone's output: you get a mental model of how they think. (Patrick McKenzie put it that way in <a href="https://www.thinkingpoker.net/2020/12/episode-341-patrick-mckenzie/">this interview</a>.) Moreover, it pays to invest in those models even after you cross the threshold, because that improves the model.</li>
<li>The Internet improves the value from both the top and the tail of the T more than it does the middle. There's more and better content to sample broadly from, while the best thinkers are becoming absolute intellectual powerhouses (in part by using the Internet to consume and reply to objections to their work). This is obviously speculative, but I'm very confident in it.</li>
<li>The best thinkers are not only improving the quality of their thought but also finding more and more channels to distribute their output. It's striking to me how often I see footnotes from a generation ago that say things like: "Professor X always said this and argued for it brilliantly, but she never published on it in any form;" I suspect that happens less now. (There's a lot of analysis about how the newsletter renaissance is changing flows of money. That's interesting and important, but I'd love to read more about how it's improving the intellectual outputs of the people best suited to it.)</li>
<li>Many of <a href="on-long-books.html">the arguments for long books</a> also apply to large bodies of work.</li>
<li>Rereading is underrated, so it's a mistake in the first place to view what you've already read as an exhausted resource. And the returns to rereading the best thinkers (best for you) are much higher.</li>
<li>Reading output from a favorite thinker tends to have both a high ceiling and a high floor, and (for me, at least) these increase my motivation to do the reading in the first place. So I'm more likely to read more if I'm reading Alice than if I'm reading Bob, and shifting the marginal time to reading from whatever else I'd be doing is probably valuable.</li>
</ol>
Nozick famously said of <a href="https://en.wikipedia.org/wiki/Newcomb%27s_paradox">Newcomb's Paradox</a> that almost everyone agrees that the answer is obvious, but they disagree about what the answer is. I suspect this issue is similar.

On distributing reading time

<h2>On editing text</h2>
Here I assemble a bunch of things I believe, and find myself repeating, about text editors.
<ul>
<li>Learning how to use your tools well is one of the two or three most underrated skills in software.</li>
<li>It's also one of the most underrated skills in computer usage (and by extension modern life).</li>
<li>It's very hard to learn from authority here, because (i) tool fitness is idiosyncratic, (ii) feelings get involved, and (iii) knowledge of an ecosystem is hard-earned but short-lived and often more local than one appreciates. (In this respect, advice about software tools is a lot like parenting advice.)</li>
<li>More specifically: many people will say that you are not A Real Programmer or A Real Writer until you know [some tool]. That is not true.</li>
<li>You can achieve large productivity gains from improving your use of a text editor.</li>
<li>But be kind to yourself. Learn in a <a href="https://www.natemeyvis.com/writing/backward-compatible-improvements/">backward-compatible</a> way. Do not shame yourself for, e.g., using a mouse even after you get a taste of the power of keyboard shortcuts.</li>
<li>I think PyCharm is great. I used it for a long time and will probably go back to it during coding sessions when I'm likely to need advanced refactoring support.</li>
<li>But I'm loving Vim these days for nuts-and-bolts coding--it's so fast.</li>
<li>And although PyCharm, like other modern IDEs, is a wonderful language-specific coding tool, I fear I was using it as a mediocre operating system.</li>
<li>E.g.: tab-completion doesn't work for me in its terminal. I've looked through some forums. Do I really want the burden of knowing stuff about the PyCharm terminal? Enough of my brain is consumed with knowledge about terminals. Once I chose not to use the integrated terminal, some fraction of PyCharm's functionality was not relevant to me. Similar things happened with the debugger, version control integration, and so on.</li>
<li>That said, I do not intend to maintain an extensive .vimrc. The extensibility of Vim is a sneaky weakness: it tempts you to bind your knowledge of a very secure, long-lasting tool to a bundle of ephemeral, indifferently tested ones. (You know that bit in "Sailing to Byzantium" where the narrator notes that his soul is "sick with desire / And fastened to a dying animal"?)</li>
<li>I'm increasingly convinced that the trick to choosing the right development environment is (i) not allowing learning about it to suck up too much of your time but (ii) giving yourself permission to learn progressively more about it without frustration. For a long time learning things about PyCharm felt like time well spent and learning about Vim felt like time spent badly. Now it's the opposite.</li>
</ul>

On editing text

<h2>On improving data-adjacent code</h2>
Here's the most stimulating bit of feedback from <a href="on-ankis-database.html">the post about Anki's database</a>:
<blockquote>
My impression is most databases are designed fairly haphazardly, and while tables may have fields added, the entity relationship diagram stays pretty static. My rationale is as follows: (1) A database schema requires quite a bit of thought and up-front design, which we're loathe to do in this agile world; (2) Schema migrations are hard and scary, so we avoid doing them.
</blockquote>
--<a href="https://news.ycombinator.com/item?id=30439645">LAC-Tech</a> on Hacker News (lightly edited)
So: we get into the habit of defining structures on the assumption we can change them easily, but when databases are involved we can't change them so easily. This is an underrated problem; it's both technical and cultural. Here's how I try to mitigate it:
<ol>
<li>Think about persistence from the beginning, but delay actually persisting things until later. Use in-memory / mock versions of your persistence layer until you've had a chance to learn more about your objects.</li>
<li>Have ready sources of test data, usually flat files but sometimes functions that make mock data. Maintain functions that transform that test data into your current object representations, so that you don't have to change the underlying test data every time you change your object representation. (It's usually a lot easier, both mechanically and psychologically, to change those functions than the underlying data.)</li>
<li>Make the in-memory / mock versions of your persistence layer obey the same interface as your database-facing code will. This means that other parts of your code base should not need to know or care about persistence details. (The Domain-Driven Design folks are good at this.)</li>
<li>Make utilities that test, for anything implementing the interface described in (3), whether the data conforms to the current schema. Dashboards are your friend: it's usually not hard to calculate and display lightweight analytics. Having a ready way to display a human-readable view of data samples is often invaluable. </li>
<li>Add tests that feed the data from (2) through whatever CRUD functions you're building, retrieve that data through the interface described in (3), and test the data with the utilities in (4).</li>
</ol>
Different projects are different enough that these steps look different whenever you implement them. A common flow, however, is to have some utility function loop through <code>test/data/test_widgets.csv</code>, create a bunch of Widget objects, create a new widget persister and apply the current schema to it, pass the Widget objects into <code>widget_persister.add_widget()</code>, call <code>widget_persister.get_all_widgets()</code>, and run some tests on the result.
After I sketch out a design, I often build out parts of it roughly the way I'd implement a sand castle: by starting to put sand wherever I want there eventually to be castle. (It's not too hard to touch things up along the way, and the best way to know what to fix is to have built something that shows me what's wrong.) Persistence-facing parts work differently: it's the part of the sand castle where you have to leave the upside-down bucket in place of the tower for a while and just built around it.
This can be tricky, but it has clear benefits: it forces you to focus, for a while at least, on the interface the persistence layer will obey more than its implementation. Most of us <a href="software-design.html">don't think about interfaces enough</a>, so this makes for great practice.

On improving data-adjacent code

<h2>On learning Vim</h2>
<a href="on-editing-text.html">I use Vim</a>. I like Vim. But for all that's written about learning Vim, most of it is not useful.
<h3>Suggestions on learning Vim</h3>
<ol>
<li>Do not put painful restrictions on yourself or shame yourself for using the mouse. Learn enough to get going, and when you find yourself trying to do a certain thing over and over, look up how to do it. (I think Yehuda Katz <a href="https://yehudakatz.com/2010/07/29/everyone-who-tried-to-convince-me-to-use-vim-was-wrong/">got this basically right</a>.)</li>
<li><code>vimtutor</code> is great for learning enough to get going.</li>
<li>Installing a bunch of plugins is often a trap. This is especially true at the beginning, when it's more likely that the thing you're trying to accomplish is doable with vanilla Vim. Dependencies are terrible, <a href="on-dependencies-in-small-projects.html">even or perhaps especially in contexts like this</a>. Avoid them.</li>
<li>Vim is huge. It has more features than you think it has. Its speed and lack of a persistent menu add to this illusion. This means, among other things, that different users grow into using different subsets of the features, and come to find them fundamental. So: ignore most claims about which features of Vim are the fundamental ones.</li>
<li>Vim doesn't have a persistent menu, but its <code>:help</code> documentation is wonderful.</li>
</ol>
<h3>A note on human progress</h3>
Much of the best stuff in computing comes out of small communities characterized by strongly held core beliefs, cultures of learning, and strong adherence to principle. Many could be described as "cult-adjacent." (The domain-driven design community has always struck me this way.) It's tricky to use artifacts from these communities, whether they be pieces of software or mental models, effectively. This is not the only case where the thing is worth learning but the dominant explanations for how and why to learn it are likely to mislead.