<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 <em>adolescent</em>, 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. <em>War and Peace</em> is famously long and challenging, but I'm rarely <em>surprised</em> 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 <em>The Sorrows of Young Werther.</em> The book that makes me most curious in this regard is Balzac's <em>The Human Comedy</em>. 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>
<p>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.</p>
<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 <em>New York Times</em>.</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>
<p>Recommended.</p>

Reading notes: Cruciverbalism

<h2>The state of the site</h2>
<p>This site is now made with <a href="https://nextjs.org/">Next.js</a> and hosted on Netlify.</p>
<p>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:</p>
<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>
<p>So, this site isn't quite as hand-crafted as it used to be (or, at least, not quite as hand-crafted <em>by me</em>)--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>.</p>

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>
<p>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 <em>not</em> installing plugins. 
And only make a <code>.vimrc</code> when you really need to. 
Here's why:</p>
<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>
<p>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.</p></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>
<p>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:</p>
<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>
<p>Very similar patterns exist in Django and Flask. 
(Also in non-Python frameworks, but for concreteness I'll use only Python examples.)</p>
<p>Now: how do you <em>test</em> <code>get_hat_names</code>?</p>
<p>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:</p>
<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>
<p>There are at least four problems that arise in testing a function like this:</p>
<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>
<p>(Those problems are interrelated, but also multifaceted. 
You might say those are actually two problems or actually six. 
Never mind.)</p>
<p>Here's how I test these functions without creating an opaque wad of mocks and set-up functions.</p>
<h4>Step one: put persistence-related information behind an interface</h4>
<p>Create an interface that abstracts away the details of a particular database configuration:</p>
<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>
<p>This will help us a lot here. 
It will help us a lot <em>everywhere</em>, in fact: it's a powerful abstraction. 
(<em>Architecture Patterns with Python</em> is the best treatment I've read of the so-called "repository pattern.")</p>
<p>Then rewrite your decorated framework functions to depend not on a raw database connection but on an instance of the repository:</p>
<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>
<p>In our example, this would work like this:</p>
<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>
<p>The division of work above is common:</p>
<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>
<p>Now you have a helper function, <code>_show_hats</code>, that is perfectly testable:</p>
<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>
<p>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 <em>look</em> 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.</p></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 <em>more</em> 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>
<p>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.</p>
<p>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:</p>
<ol>
<li>Most or all of these dimensions have unbounded downside but fairly low ceilings, or</li>
<li>The best engineers really <em>are</em> vastly better than average ones, because they can be better along many high-impact axes--or at least a few.</li>
</ol>
<p>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.</p>
<p>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.</p></div>

</div>




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


A note on 10x engineering

<h2>Listening notes: Sold a Story</h2>
<p>I enjoyed and recommend the series, but not without qualification:</p>
<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 <em>credible</em> 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 <em>a priori</em> 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: <em>Get Ready</em></h1>
<ol>
<li>The book is about preparation, in the most practical and pragmatic sense. If you have <em>X</em> hours to spend, and your goal is to do the best possible job at <em>Y</em>, how should you spend your <em>X</em> 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 <em>The Art of Learning</em> in the relevant crowd. I would actually recommend <em>Get Ready</em> over <em>The Art of Learning</em> 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 <em>artists</em> get together they talk about where you can get cheap turpentine. This is the "cheap turpentine talk" of life.</li>
</ol>
<p>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.</p>


Listening notes: _Get Ready_

<h2>Reading notes: My Losing Season</h2>
<p>Here are two metrics for how much a book captures my imagination:</p>
<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>
<p><em>My Losing Season</em> 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.</p>
<p>If there is such a thing as a nonfiction <em>bildungsroman</em>, 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).</p>
<p>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 <em>season</em> 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 <em>then</em>, 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.</p>

Reading notes: My Losing Season

<h2>Viewquake: making meaning after the fact</h2>
<p>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:</p>
<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>
<p>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.)</p>

Viewquake: making meaning after the fact

<h2>Reading notes: Super-Infinite</h2>
<p>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.</p>
<p>A few notes:</p>
<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 <em>sui generis</em>. 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>
<p>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.</p>
<p>(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.)</p>
<p>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.</p>
<p>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):</p>
<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>
<p>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:</p>
<ol>
<li>If carrots <em>A</em> and <em>B</em> are the same shape, but <em>A</em> is twice as long as <em>B</em>, 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>
<p>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.</p>

On trees and dimensionality

<h2>Reading notes: Crossroads</h2>
<ol>
<li><em>Crossroads</em> 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 <em>this</em> stuff isn't what ties the novel specifically to the '70s.)</li>
<li>The <em>manifestations</em> 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 <em>necessary</em> 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 <em>X</em> 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 <em>for us</em>, despite being less or differently politized <em>in the world of the book</em>. It's only <em>some</em> 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>
<p>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.)</p>
<p>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 <em>speak</em> 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 <em>today</em>.</p>
<p>Alternative ways to read this prediction, then, are (i) as a commentary on what <em>current</em> optimal use of Twitter looks like (a lot of deliberate user modification) and (ii) as a prediction that Twitter's AI will get <em>better</em>, not that it will change so fundamentally.</p>
<p>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:</p>
<ol>
<li>The changes Tyler imagines do not rest on improvements to <em>AI</em> 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>
<p>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.</p>
<p>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.</p>
<p>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.</p>

Notes on Tyler Cowen on relearning the Internet

<h2>Code correctly by conforming to the real world</h2>
<p>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.</p>
<p>We are modeling a soccer game and we have:</p>
<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>
<p>There are, broadly, a few ways to handle the mechanics of awarding a throw-in:</p>
<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>
<p>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!</p>
<p>In that post I argued for the last option. Here are two further notes about making this kind of decision:</p>
<h4>Study dependency problems as dependency problems</h4>
<p>First, notice that this is <em>a dependency problem</em>. 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 <em>are</em> import mechanics and ergonomics here, but those are manifestations of the fact that dependencies are being created. Worrying about dependencies <em>as dependencies</em> helps you resolve these other issues; trying to think about the issues independently of the fact that dependencies are involved leads to confusion.</p>
<p>What are some good heuristics for determining dependency directions?</p>
<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 <em>future</em> operations, and choose the direction that will be accommodate those changes most easily.</li>
<li>Try to anticipate possible future <em>modifications</em>, and choose the direction that will facilitate those.</li>
</ol>
<p>Here, by the way, are some <em>bad</em> but commonly used heuristics for making this choice:</p>
<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>
<p>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.</p>
<p>I find I make better decisions when I take the "because" in the previous paragraph very literally: bad decisions here are bad <em>because</em> 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.</p>
<p>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.</p>
<p>The second note about the soccer-events example is more controversial:</p>
<h4>Worry more about what the things you're modeling <em>really are</em></h4>
<p>The previous argument attempted to establish that many problems are not only correlated with but <em>caused by</em> 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 <em>really is</em> to be, among other things, an event broker. </p>
<p>What about the heuristics from before? Going in turn:</p>
<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 <em>X</em> persists even though some related <em>Y</em> changes, that's a good sign that <em>X</em> was more fundamental than <em>Y</em> 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 <em>possible</em> was baked into the interface.</li>
</ol>
<p>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 <em>Architecture Patterns with Python</em>, 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>.</p>
<p>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.</p>

Code correctly by conforming to the real world

<h2>Reading notes: The Remains of the Day</h2>
<p><em>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.</em></p>
<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 <em>Bright Lights, Big City</em>, 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 <em>your</em> values, and how much integrity do <em>you</em> 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 <em>Zen and the Art of Motorcycle Maintenance</em>), and the end seems to owe much to <em>The Great Gatsby</em>.</li>
</ol>
<p>Very highly recommended. An easy inclusion in the <a href="100-books.html">top 100</a>.</p>

Reading notes: The Remains of the Day

<h2>Why events?</h2>
<p>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.</p>
<p>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:</p>
<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>
<p>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.</p>
<p>Now you need to write code to handle the situation when a ball goes out of bounds. A first pass might be something like:</p>
<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>
<p>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.</p>
<p>What's important is that:</p>
<ol>
<li>This code does <em>not</em> 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 <em>precisely from</em> our decision to model this situation without events and event coordination.</li>
</ol>
<p>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:</p>
<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>
<p>Now there are two big problems--or, really, one big problem that can be described in several ways:</p>
<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>
<p>What is really happening in the game we're trying to model is:</p>
<ol>
<li>Something has happened;</li>
<li>That thing causes other things;</li>
<li>And, in particular, it could cause <em>several</em> other things that might <em>themselves</em> 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>
<p>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 <em>no</em> downstream effects.)</p>
<p>These causal relationships inevitably change, a lot, over the life of a piece of software. Keeping track of them is <em>not</em> 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.</p>
<p>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 <em>Architecture Patterns with Python</em> for a good overview of the subject. Good luck.</p>

Why events?

<h2>Reading notes: Of Boys and Men</h2>
<p>Recommended.</p>
<ol>
<li>It is a book about men, but only a shortsighted reader would miss the lessons about (specifically) Black men, Black <em>women</em>, 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 <em>with men</em>, which are problems <em>for everyone</em>."</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 <em>against</em> 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 <em>other</em> 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>
<p>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.</p>
<p>My tweetstorms</p>
<p>Why I don't do poker software
The lost phenomenology of poker in 2006</p>

The tweetstorm as a form

<h2>What is America's epic?</h2>
<p><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 <em>Iliad</em> is to Greece, <em>Ulysses</em> is to Ireland, and <em>Don Quixote</em> to Spain?</p>
<p>My first thought was <em>Moby-Dick</em>, which is a pretty common answer. But I'll take <em>The Scarlet Letter</em> instead:</p>
<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 <em>Moby-Dick</em> and most other contenders are not.</li>
<li>More people have actually read it than <em>Moby-Dick</em> 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> <em>Moby-Dick</em>, 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 <em>transmission</em> of values and character. A good epic should have at least one main character who is a child, right?</li>
</ol>
<p>I'll put <em>The Great Gatsby</em> in second place:</p>
<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>
<p>I haven't seen anyone mention <em>East of Eden</em> yet, but I'd put it somewhere in the 5 or 10 best answers to this question.</p>

What is America's epic?

<h2>Reading notes: There's No Such Thing as Bad Weather</h2>
<p>I found this book valuable enough to finish. Valuable enough <em>for me</em>; it's hard to <em>recommend</em> it.</p>
<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. <em>Bringing up Bebe</em> 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>
<p>I know exactly what I want for this child. Natural childbirth--check. Cloth diapers in gender-neutral diapers--check. Homemade, organic baby food--check.</p>
</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>
<p>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.</p>

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

<h2>What's happening with data scientists?</h2>
<p>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.</p>
<p>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:</p>
<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>
<p>Those are all hypotheses I'd want to investigate; they are certainly not firm beliefs.</p>

What's happening with data scientists?

<h2>Code review reference</h2>
<p>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.)</p>
<h4>"Your near-synonymous variable names suggest that something is wrong."</h4>
<p>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:</p>
<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 <em>X</em> 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>
<p>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.</p>
<p>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.</p>
<h4>"This name is not semantically correct."</h4>
<p>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:</p>
<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>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<h4>"I don't think this thing you're trying to formalize can be formalized."</h4>
<p>See <a href="an-argument-from-jimmy-koppel.html">here</a>.</p>

Code review reference

<h2>Notes on being the Day One chip leader</h2>
<p>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 <em>second</em> quintile of EBITDA growth does better than the first quintile according to Verdad's research.)</p>
<p>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?)</p>
<p>The essay is very old, by now, and does not apply directly to the modern game. 
Here are some updates:</p>
<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 "<em>the</em> 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 <em>and playing well thereafter</em> 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>
<p>So, Sklansky's point is still worth thinking about, but no longer straightforwardly applicable to the actual Main Event.</p>