Watching discussions happening online, I see a frequent unfortunate tic I’ll call the Expert Asterisk. A beginner is asking for help, and experts are answering. Then in the spirit of completeness, an expert throws in a fact or detail far from the learner’s abilities or needs.

As an example, here was an interaction about git: a new learner was having trouble getting properly oriented. They were asking how branches relate to directories, and how to undo a change. They knew about git init but didn’t know how it related to changing projects.

newb: so every time I change project I simply do ‘git init’ on them?

expert1: ‘git init’ is for creating a new project.

expert2: you change your working directory, typically, when you change project

So far so good, but then:

expert2: or you specify the git repo directory with the -C switch, but it’s more typing to do, so hardly anyone does that unless there’s a very good reason

What!? Why mention this while explicitly pointing out no one does it? The newb just barely understands how git works at all. Why introduce obscure command-line options that “hardly anyone” uses?

I call this an asterisk because it feels like an esoteric footnote that only experts, academics, or completionists would need to know.

The expert is trying to be helpful. They are presenting all the options in the optimistic hope that the newb will be able to pick and choose among them.

Worse, sometimes multiple experts each offer their own asterisks, and the poor newb is intrigued and distracted by each one. The new learner doesn’t have a way to sift out which details might be important to them. Their original question gets lost in the spreading tangents.

It’s hard to help new learners: we can’t know where their gaps are. What misconceptions need to be unwound? Often we have only a glimpse of their context. Experts can miss when they use words slightly wrong, taking them at face value instead of seeing the misunderstanding that leads down the wrong path.

Notice in the exchange above, “change project” could mean switching among existing projects or starting a new project. We’re not sure which they meant. An expert will cycle among a number of active projects, but beginners will work on one until it is done, then switch to a new project, never returning to the previous one. Perhaps “every time I change project I do ‘git init’” was right for their situation.

The -C comment didn’t derail the session, but the effort of that comment could have instead been used to clarify the newb’s need.

I understand why experts add these asterisks to help sessions: they are useful for some people even if not for this beginner, and experts are interested (even fascinated) by all the intricate details. These discussion areas are not strictly for newb-help. They’re for general discussion among many people. There’s no rule against talking about advanced or rare options.

And it’s hard to know what will be useful, or what the newb really means, or what will resonate with them to help them find a solution. It’s all difficult.

But you should at least recognize who you are addressing and whether you are helping them. If you want to help the beginner, try to resist the impulse to add little-traveled tangents. Focus on the question at hand and try hard to understand the newb’s situation and mindset. Speak their language so they can hear you.

This is a lightning talk I did at PyCon US 2026: Silence is Golden. The overall message is to leave some quiet time so that reluctant speakers have a chance to participate. I start with a jokey disclaimer because I followed Simon Willison who gave an energetic, entertaining, and loud(!) speed-run through a year of progress in LLMs:

I do these talks and blog posts about how to better interact with people, but I hope they don’t come off as too preachy. I have to remind myself to keep these ideas top of mind. I am one of those people who speak easily that I describe in the lightning talk. I have to remember to hold back, to leave time and space for other people.

I had the idea for this lightning talk a few years ago at PyCon, while watching things going wrong. I was in a room with a few dozen people. The goal in the room was to hear from lots of people, but the leader of the discussion was a “speaks easily” kind of person, and I could see the dynamic of the room failing to make space for everyone.

I was really pleased to be able to extend the time-tested and well-known Pac-Man Rule from space to time. It made for an interesting hook, making the talk more interesting than just a scold.

It’s really hard to keep quiet. But it’s important sometimes.

I wrote a tiny language implementation: Calcium. It’s meant as a demonstration of how languages like Python are implemented. It has a tokenizer, a parser, an AST, a compiler, bytecodes, and an execution engine, all in about 300 lines of code.

I did it because I often see the question: isn’t Python interpreted? Why do people say it’s compiled? (BTW, I also answered this in an earlier blog post: Is Python interpreted or compiled? Yes.) It can be hard to explain that your Python program never becomes an explicit sequence of native CPU instructions, which is what people often think “compiled” means.

So I coded up Calcium to have on hand the next time it comes up. I think it will help to be able to show the execution engine code reading bytecodes and doing what they say.

It could also be an interesting starting point for people wanting to play with a language implementation. It has almost nothing, so there’s lots of simple things (comments?) to add.

I’ve had an idea rattling around to get more detail from coverage measurement. Can we measure the coverage in a function separately for each caller of the function?

Here’s why I want it: in Acidica, my toy BASIC interpreter, I had code to implement the built-in functions that looked something like this:

match func_name:

    case "LEN":
        if len(args) != 1:
            raise TypeError(f"Wrong arguments for LEN, got {len(args)}")
        return len(args[0])

    case "LEFT$":
        if len(args) != 2:
            raise TypeError(f"Wrong arguments for LEFT$, got {len(args)}")
        return args[0][:args[1]]

    # ... 19 other built-ins ...

I didn’t like the repeated code here: each different func_name has to check that it got its expected number of arguments and perhaps raise an error. So I refactored:

def expects(nargs: int, func_name: str, args: tuple) -> None:
    if len(args) != nargs:
        raise TypeError(f"Wrong arguments for {func_name}, got {len(args)}")

match func_name:
    case "LEN":
        expects(1, func_name, args)
        return len(args[0])

    case "LEFT$":
        expects(2, func_name, args)
        return args[0][:args[1]]

Nice. The code is tighter, easier to read, and common behavior is implemented in one place.

But the old code had an advantage: because each error condition had its own raise line, coverage measurement could tell me whether I had tested every func_name for the wrong number of arguments. With the error handling happening in a helper function, that information is lost. I’ll know that somefunc_name had a test for the wrong number of arguments, but not that all of them did.

Here’s where the new idea comes in. What if I could indicate that for the expects function, I want separate coverage data for each distinct calling site? Then I could see that every func_name had a test for both the wrong number of arguments and the right number of arguments. The simple branch inside expects would be measured separately for each caller.

I have a quick proof-of-concept. A decorator on expects does the work. Coverage.py already has dynamic contexts which are used for things like tracking which tests called which code. The decorator starts a new context named for the calling location, then restores the context when the function returns:

def coverage_per_caller(func):
    @functools.wraps(func)
    def _wrapper(*args, **kwargs):
        cov = coverage.Coverage.current()
        name = func.__name__
        caller = inspect.currentframe().f_back
        file = caller.f_code.co_filename
        lineno = caller.f_lineno
        prev_context = cov.switch_context(f"per_caller:{name}:{file}:{lineno}")
        try:
            ret = func(*args, **kwargs)
        finally:
            cov.switch_context(prev_context)
        return ret

    return _wrapper

I had to make one tiny (unreleased) change to coverage.py for this: switch_context used to return None, but now it returns the previous context so that we can nest them properly.

To my delight, this works! I can look at the HTML coverage report and see the caller contexts for the lines in expects. I can see that 20 callers ran the if line, but only 2 ran the raise, and the context names show the file and line number of the callers for each:

This isn’t the whole solution yet. Things to improve:

• I’d like to post-process these contexts to show which callers were missing lines inside expects. What I’m looking for is the same kind of “this line is missing” information that I got from the original inlined logic.
• These per-caller contexts overwrite the contexts we were already collecting (the test names). Ideally we’d have some kind of sub-context so that we could track both (or many) at once.
• It’s not great that I had to add a decorator to the source code. Driving this through the coverage configuration would keep these kinds of details out of the source.

But it’s a start, and gives me other ideas. I could use some aspect of the data passed into a function as the context name. In this example, we could have used func_name as the context instead of the caller’s location. Maybe you have ideas for other uses.

My latest fun project is a BASIC interpreter called Acidica. Classic BASIC is an old-school language first developed in 1964 that saw an explosion of implementations on microcomputers in the ‘70s and ‘80s. It’s much more primitive than the Visual Basic that you might be familiar with.

A simple BASIC program:

10 INPUT "What is your name"; U$
20 PRINT "Hello "; U$
30 INPUT "How many stars do you want"; N
40 S$ = ""
50 FOR I = 1 TO N
60 S$ = S$ + "*"
70 NEXT I
80 PRINT S$
90 INPUT "Do you want more stars"; A$
100 IF LEN(A$) = 0 THEN 90
110 A$ = LEFT$(A$, 1)
120 IF A$ = "Y" OR A$ = "y" THEN 30
130 PRINT "Goodbye ";U$
140 END

Run it, and you get this:

What is your name? Ned
Hello Ned
How many stars do you want? 10
**********
Do you want more stars? y
How many stars do you want? 20
********************
Do you want more stars? n
Goodbye Ned

The wide variety of BASIC flavors meant I first had to decide what to implement. I found Vintage BASIC and used its spec, both because it is concisely described, and because it has an implementation I could run to double-check behavior when I had questions. The site also has a collection of runnable games from Creative Computing magazine, which I remember fondly.

This was a perfect vacation-week project. It has no real-world consequences. It had some interesting problems to puzzle through. It was testable. It satisfied some nostalgia for my earlier computing days. It was bounded enough to be “done”.

In those ways, it’s very similar to a vacation project of mine from four years ago: Stilted, an implementation of PostScript.

Acidica is not useful for writing new programs, only because BASIC itself is so difficult. There is no scoping beyond single-line functions, variables names can be as long as you want but only the first two letters and first digit are significant. Keywords are recognized anywhere, so FACTOR can’t be variable name because it has TO in the middle. The only control structures are FOR, IF, and GOTO. It’s something of a testament to human persistence that programs like three-dimensional tic-tac-toe can be written in it.

As a side project, I could choose my development style: no real type checking (partly because BASIC’s values would be awkward to squeeze into static typing), and very few docstrings. There are lots of tests, but only integration tests: every test is a BASIC program to run, with a check for the correct output and/or the expected error.

To be honest, the “only integration tests” approach was kind of a pain, but I stuck with it and resisted the temptation to add unit tests along the way.

Another choice I made: no AI. I like writing programs. I get a deeper sense of the thing I am building when I have my fingers in the clay. Since there was no deadline, or even any reason to ever finish the project, I could take my time and not be rushed.

But I like the result. I enjoyed the time I spent working on it. I liked being able to stop and devote pure thinking time while doing other things when I got to the next hurdle. The next steps here might be to use this project as a test bed for some development ideas. Or maybe add a BASIC-to-Python transpiler. Or maybe it’s done.

My mother is 86, and she is declining. Things that used to be easy for her now seem completely foreign. She was a programmer, writing software before I could read, so it is very strange to see her like this.

She no longer uses a computer. If I mention some photos I found online, she asks if there’s any way she can see them, as if she has never used the internet. This is a new reality for me, but is easier than a year or two ago when she still tried to be constantly online. As things got more confusing for her, she struggled and complained “the computer is haunted.” Now she doesn’t have the computer as a source of friction, but also not as a center of activity.

In many ways, she is following a similar path to her own mother, my Grandma O. Like her, my mom is accepting the changes in her relationship to the world. She is able to laugh at it a bit. But it will still be difficult, especially because we know it is a progression that is not going to get better and will very likely get worse.

The new her is very different from the original her. She was not timid. She came out as gay in the mid ‘70s and ran a feminist bookstore. She worked as a programmer. She got a PhD in computational linguistics just because she was interested in the topic. These were the things I was used to hearing about from her. She never lacked for enthusiasms, projects and accomplishments.

She was always energetic and feisty, ready to engage in debate. This picture does a good job capturing the spirit of many of our interactions in the past:

Now she is mild and somewhat resigned. She says things like, “I don’t think much anymore.” I know there are other ways this could go. Some people get very angry as their abilities fade. In that sense, this is a good trajectory, but I am still sad to see her shrink.

Last week we had a family gathering at my sister’s house, the usual location for these big events. My mom has been there many times. But now she didn’t recognize it. I sat with my mom and sister over lunch. They were discussing the dining room we were in. It wasn’t familiar to my mom. She wasn’t upset about it, just looked around and said, “no, I don’t remember this.”

My mom was enjoying her salad, but eating it with her hands. I pointed to the fork on her plate and asked, “You don’t like the fork?” She looked at it as if it was some unimportant detail of the tablecloth, and kept eating with her hands. She wasn’t bothered, just calmly proceeded in her way.

At the end of the party, my mom and her wife Fumiko were getting ready to go. Fumiko had scheduled a ride-share car, so we went out to the street to wait for it. We brought out a chair for my mom to sit. The time for the car came and went, but no car arrived. There were five of us out there: me, my sister and brother, my mother and Fumiko. My brother and Fumiko were trying to figure out where the car was. They were looking through the app for information. They re-read the email confirming the scheduled ride. Should we keep waiting? We could request a new ride. Would we be charged for the missed scheduled ride? It was a whole thing, lots of discussion and questions.

In the middle of this, without warning, my mom tried unsteadily to get up from her chair. Two of us quickly intercepted her. The uneven pavement seemed particularly treacherous for her. We supported her arms to keep her steady.

“Mom, where are you trying to go?”

“I want a place of certainty. This place seems very uncertain.”

She was right: out there on the sidewalk we were all uncertain. But I have to wonder if she was also talking about her larger experience in a world that is less and less understandable for her.

In the back of my mind, I wonder what my own future holds. But that is decades away, and my mother’s situation is now. I don’t know what her next steps down will be like. She has already changed a great deal in the last year.

I think we would all like a place of certainty. I know I would, but I also know I am not going to get it soon.