You might’ve already guessed what it is: stacked branches. But if you didn’t already know that, don’t worry, we’ll go over it shortly.

But first, let’s discuss the problem.

AI-generated code is hard to review

Pretty much everyone using AI has this problem at the moment; it’s moderately easy to generate code that is mostly coherent, mostly tackles the problem you’re solving, and in fact it’s so easy, we mostly get a little over-excited and do too much at once: this makes code hard to review.

This is creating stress on the reviewers, on several fronts. There’s just the plain apathy of staring a giant diff that probably does what the author says, even passes your test suites, but also probably contains some quirky/not-your-codebase’s-idiom things that you’d challenge if you were motivated.

There’s also the loss of knowledge; it’s just straight-up extremely difficult to read such large pieces of work and understand everything. Especially when you can’t totally trust that every line and comment comes from some deep fundamental understanding of the (human) author.

There’s many other problems; not all of which will be addressed by this idea; but the key idea here that we will go for is: less is better. It’s easier to review something when the amount of changes are small; and when you can focus on just thinking about “one thing”, while performing any specific review.

Standard techniques

There are many and ever-growing techniques to deal with this problem:

1. Just add more tests: Theory is, if it works then It Works. This can be risky or great, depending on your testing infrastructure. But we all know that tests don’t cover everything that it’s possible to express with code.

2. Just do less: Just have smaller PRs. This is hard, because it seems modern AI systems tend to be a little bit purposefully addictive/gamified: they’re often finding new things to do while doing a piece of work. It’s also at odds with most work pressures: deliver more better faster.

3. Group-reviews: Get everyone on a call (or in person?!), and talk through the code. This can be useful, but you can’t do it for everything. Also, it doesn’t work for some team members and thinking styles.

4. Author and merger responsibility: You can just make a declaration, that, say, if a (big) PR is found to introduce a bag big or some misunderstanding, you just fire the author the and merger. Or maybe something less drastic, like downvote them on their performance reviews. In any case, this one is punitive and pressure-based. It makes authors and reviewers more nervous; and doesn’t really empower them in any meaningful way. Ultimately, it will just slow you down, and upset people.

5. Stop caring, the market will decide for you: Does you product get better? Do things work? Are you getting more features? Then who is really to say what is “correct”? Isn’t the ultimate arbitrar of truth the users anyway? Shouldn’t we just get more things in front of them as fast as possible?

   Obviously, this framing is both correct and crazy. In theory it’s true that only visible functionality matters; but it’s also true that something can be visibly accurate but wildly off in ever-so-slightly different circumstances. We’re not yet at the point where it’s possible to operate this way. Maybe we’re approaching this with better-tested ecosystems and the combination of theorem provers in connection with code; but ultimately we’ll always need to review our stated intention, even in that promised land.

   So let’s just agree that, for the short term, we’re going to need some kind of human review.

6. Actually no, just let AI review it: Naturally, we can just have the AI perform it’s own review. Pragmatically, this can be very effective, certainly for catching missed things, bugs, security issues, etc. But I feel for gaining certainity that what you asked for is actually done correctly, we’re still going to want some oversight.

Let’s then see an old idea that can still be compatible with any of these approaches, if we so wished it.

An old idea: create stacked branches

I’m not inventing stacked branches here. Many many people love them, there’s jj, created in part to get more joy from them, and startups focused around the idea.

A stacked branch is conceptually simple:

• Think about the large bit of work you did,
• Break it into (coherent) chunks (each one perhaps passing CI alone),
• Create a branch per chunk,
• Have each branch depend on the prior one: 1 ← 2 ← 3 ← …
• Submit them as PRs in that order

Now, you have each coherent change readable by itself; they can be merged in order, and everything will be fine.

You can read more here.

The new workflow

Manually maintaining stacked branches is a little annoying. Yes you can use jj; but then you have to learn to use jj, convince everyone in your team to learn it, and still do manual busywork.

Alternatively, you can try and predict all the changes you’re likely to make, make individual branches and just keep switching around. This is of course extremely inconvenient and annoying.

But, happily, creating stacked branches from a single monolithic branch is fairly mechanical, boring, easy to describe, … What a great use-case for your AI tooling then!

So the new workflow is simply this:

1. Create a branch (some-performance-work),

2. Hack liberally,

3. Ask your AI something like:

   Can you reframe this work into a sequence of stacked PRs. Try and categorise all the changes into 4-5 chunks, and then make branches based on that. Please number the branches like some-performance-work-1.

4. Push all the branches and create the PRs.

5. Bask in the joy of simple reviewing

I’ve been experimenting with this a little, and it works quite well! Note that in my particular workflow, I wait until I’ve done the entire piece of work, and split it after the fact. Splitting it before requires a bit more jj busywork than I care to get into at the moment.

Open questions and downsides

Here’s a dot-point list of open questions, downsides, and trivia to think about.

• GitHub’s UI is annoying for stacked PRs: They should thread them, like Gmail did back in the day. It would be so much nicer. There’s a world of improvements alternative source-control companies could make here that would make this all so much more pleasant.

• CI could be super annoying/wasteful/slow: Depending on what you do, you might accidentaly waste hours on rebuilds with this style. One should spend some time thinking about it. (Advertisement: Actually, I think this is an interesting open area of research, and if you’re struggling with it or want to talk more, reach out to me via Invariant.Club!)

• Atomic stacking: Perhaps you shouldn’t have the first one merge direct to main, you should instead target it to some xxx-stacked new branch, that’s based on main, but allows you to do some final re-orgs as you go. Otherwise, you tend to need to merge every step of a stacked branch set basically at the same time, because you want coherence and mostly these things are coherent only once everything is complete; i.e. if you merge steps 1-4 of a 5-step stack, do you actually need all those steps if you reject step 5? Targetting a new branch gives you some flexibility here. It also gives you a final clear PR history that shows before-and-after benefits; something you might not get depending on how you merge otherwise.

  Further, you might also want to protect your merged stack queue from being interrupted by some other unrelated merge to the main branch, that happens while you’re merging your stack.

• It’s easier post-fact: I personally find it hard to do this from the start. In fact one could argue, if I could do it from the start, I’d have separate PRs already!

• Maybe learn jj, or maybe don’t worry. It’s probably very useful to master jj if you want to get into this more. But don’t let not mastering it stop you from benefiting now.

• Probably some work could be done to make AI tooling a little more capable to manage a set of arguably-independent branches more coherently. I.e. normally it’s pretty easy to isolate independent hacking with git worktrees; but they’re 1-1 with branches; now that we’re potentially 1:many, it requires a little more care and attention.

Conclusion

In general, there’s a wide world to explore in this domain of AI-assisted work partitioning for efficient review and compilation. Looking forward to seeing more work in this area!

Updates

• August 2026 - GitHub recently announced UI support for stacked PRs

You may find yourself in the following situation:

• You have a new computer,
• It requires the some latest kernel features to work (perhaps for WiFi or something else),
• You want to install NixOS,
• And the latest ISO you download doesn’t work.

One potential reason for the failure could be that your new computer requires the latest linux kernelPackages in order to work; i.e. something like:

boot.kernelPackages = pkgs.linuxPackages_latest;

In your configuration.nix.

But, not to worry! You can follow the documentation to build your own ISO image; something like so (with flakes):

# flake.nix
{
  description = "Custom NixOS installation";
  inputs.nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
  outputs = { self, nixpkgs }:
  {
    nixosConfigurations = {
      iso = nixpkgs.lib.nixosSystem {
        system = "x86_64-linux";
        modules = [
          { nixpkgs.overlays = overlays; }
          ({ pkgs, modulesPath, ... }:
          {
            imports =
              let cd-drv = "installation-cd-graphical-calamares-gnome";
              in [ "${modulesPath}/installer/cd-dvd/${cd-drv}.nix" ];

            # Use the latest kernel packages!
            boot.kernelPackages = pkgs.linuxPackages_latest;
          })
        ];
      };
    };
  };
}

Run like:

nix build .#nixosConfigurations.iso.config.system.build.isoImage

Which will produce an iso file that you can mount something like:

sudo dd \
  bs=4M \
  conv=fsync \
  oflag=direct \
  status=progress \
  if=./result/iso/the-image-name.iso \
  of=/dev/sda

The most important fact here is that you select the calamares variant of the installation iso’s. Calamares is the graphical installer. (Note: If you wanted the minimal installer, you can actually download that from the nixos hydra instance directly: nixos.iso_minimal_new_kernel, but actually this will only get you one step further; which I will elaborate on momentarily.)

The trouble is that while this will be enough to get the installer to run, you will not be able to run the resulting installed NixOS! This is because Calamares writes the final configuration.nix of the new system, and it does not consider (wisely or otherwise) the system state of the installer image when it does so. ¹

So, the answer, naturally, is fork Calamares and change it the way we want! In fact, glancing at the relevant derivation we learn that it’s calamares-nixos-extensions that we need to fork.

If we just want to hack our way through, we just make some small changes to that code, and then adjust our flake file as follows:

# flake.nix
{
  description = "Custom NixOS installation";
  inputs.nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
  outputs = { self, nixpkgs }:

  # Define an overlay to update the `calamares-nixos-extensions` used.
  let overlays = [
        (_: final: {
          calamares-nixos-extensions =
            # Update to use our fork
            final.calamares-nixos-extensions.overrideAttrs (_: _: {
              src = final.fetchFromGitHub {
                owner = "silky";
                repo = "calamares-nixos-extensions";
                rev = "latest-kernel";
                hash = "sha256-PEWH+YpmP4qD7IZJLcD9rYl+GEuHqbS/OQsaNUZYBMg=";
              };
            });
        })
      ];
  in
  {
    nixosConfigurations = {
      iso = nixpkgs.lib.nixosSystem {
        system = "x86_64-linux";
        modules = [
          { nixpkgs.overlays = overlays; }
          ({ pkgs, modulesPath, ... }:
          {
            imports =
              let cd-drv = "installation-cd-graphical-calamares-gnome";
              in [ "${modulesPath}/installer/cd-dvd/${cd-drv}.nix" ];

            # Use the latest kernel packages!
            boot.kernelPackages = pkgs.linuxPackages_latest;
          })
        ];
      };
    };
  };
}

And success! This results in an installer that will first of all even run, and second of all install a NixOS that will also run!

Update: Note that, in fact, as I was writing this blog-post, I noticed that the main repo already includes a better version of this fix, from a few days ago!² This is just more validation of one of my nix mantras: something isn’t working? Just wait a few days, probably it will be fixed!

Trivia: I had dreams of making this an option you could opt-into in the installer by editing the calamares script; but in fact this is more complicated than one might wish; you can get a sense for how annoying this is by looking at the patch required to allow someone to select “unfree” during the installation process.

As part of the interview process for a company I was recently rejected by, I wrote a blog post about HTMX and Haskell (and, JavaScript, but that was just a requirement :D).

I think the post is interesting in any case, so here it is :) The Haskell component is in the Bonus content. If you want to skip straight to the code, you can just go direct to the repo: htmx-servant-js-example.

Seamless and powerful handling of HTTP errors in HTMX

HTMX is a popular front-end JavaScript library that can be used to create simple dynamic UIs. But how robust is it? Is it ready for production use? And what are its features, anyway? Let’s explore it together by building an image conversion app.

Problem

You are building a dynamic UI and calling endpoints that will either fail or return some content to render. You want to handle both these cases with the simplest code possible.

A typical workflow somewhere in your code is to query the endpoint, check the status of what happened, and act accordingly:

fetch(url)
  .then( (result) => {
    if (result.ok) {
      // Everything is good!
    } else {
      // Something else ...
    }
})

It’s a bit of a hassle to write this logic all over the place. Can HTMX help us out here? How does it look for something non-trivial, and what are the caveats we should be aware of?

Solution

Let’s take the example of uploading an image and converting it from a PNG to a JPG.

Naturally, HTMX can do the happy-path, when there are no errors, easily. We define the form, with the HTMX attributes to define how the DOM changes based on the result:

<!-- index.html -->
<script src="https://unpkg.com/htmx.org@1.9.11"></script>
...
<body>
  <form
    hx-encoding="multipart/form-data"
    hx-post="/upload"
    hx-target="#result"
    hx-swap="innerHTML"
    >
    <input type="file" name="image" accept="image/png" />
    <button>Upload</button>
  </form>
  <div id="result"></div>
</bod>

On the server, at the /upload route, we return an HTML element:

// server.js endpoint definition
app.post("/upload", async function(req, resp) {
  // image conversion steps; new image in `newPath`.
  // ...
  // send the resulting path back as an "img" tag
  resp.send(`<img src="${newPath}" />`);
  });

Here’s what it looks like:

It’s interesting to note:

• It looks pretty smooth!
• We tell HTMX which element to update (via a CSS selector) with hx-target,
• We tell it how with hx-swap (it’s important that we use innerHTML so the main target element persists if we upload a different image),

These are some questions I’m asking myself at this point:

• What would happen if we didn’t return a HTML element from the response?
• What would happen if we didn’t return HTTP status 200?

We can actually already answer the first question, given what we know about innerHTML: whatever text is returned from our /upload route is directly set as the innerHTML, so we best make sure it’s valid HTML :)

For our second question, let’s just try it!

// update server.js to just through an error:
app.post("/upload", async function(req, resp) {
  return resp.status(500).send(`Sorry, no thanks.`);
}

Then:

We can see that nothing gets rendered, and we see the errors in the console.

With what we’ve seen so far, we would be justified in assuming that the text Sorry, no thanks might have come through to the <div id="result"> element, but in fact if the response is a HTTP error code HTMX doesn’t perform subsequent steps (typically a good idea when something has gone wrong!)

Luckily, there is an extension: response-targets that we can use to get the behaviour we are after. Phew! We can make the following modifications to our index.html page:

<!-- index.html -->
<script src="https://unpkg.com/htmx.org@1.9.11"></script>
<script src="https://unpkg.com/htmx.org@1.9.11/dist/ext/response-targets.js"></script>
...

<body hx-ext="response-targets">
  <form
    hx-encoding="multipart/form-data"
    hx-post="/upload"
    hx-target="#result"
    hx-target-error="#result"
    hx-swap="innerHTML"
    >
    <input type="file" name="image" accept="image/png" />
    <button>
      Upload
    </button>
  </form>
  <div id="result"></div>
</body>

What did we do?

• We added a dependency on dist/ext/response-targets.js
• We added `hx-ext=“response-targets” to the parent of the elements we want to use it on (read more about hx-ext; I forgot this initially and was wondering why it didn’t work!)
• We used the catch-all hx-target-error to send all errors to the id="result" element, just for simplicity (you can target specific error codes if you wish).

Here’s how it looks now:

Success! We see the error rendered in the page! And in the case that we don’t hit an error, we will still render the image directly as well. That’s exactly what we wanted! :)

Discussion

It’s pretty nice to use HTMX to handle HTTP errors from your API: use response-targets to pick up specific errors, or all of them, and render the contents directly in the page!

A small detail that I came across along the way is the difference between outerHTML and innerHTML and what you might consider repeated behaviour while preserving the most “meaningful” structure for your HTMX documents.

The scenario is this: Imagine you want to repeatedly convert images; then you need to make sure that the HTML element of hx-target persists; with innerHTML it always will, but with outerHTML it will be replaced. The advantage of outerHTML is it’s a bit more “meaningful” to replace an <img> tag with another <img> tag; and likewise. But, ultimately, it’s up to you to pick the style you prefer.

Bonus content: The server is now in Haskell

HTMX is, after all, a front-end technology, so we can continue to use it if we have our server in a different language.

It turns out Haskell will let us express one interesting requirement of using HTMX: our routes should return HTML, not, say, JSON, or plain text.

In the Servant ecosystem, you would having something like the following¹ to define the /upload endpoint:

-- Main.hs
data Routes mode = Routes
  { upload :: mode :- "upload" :> MultipartForm Mem (MultipartData Mem) :> Post '[HTML] Html
  , ...
  }

And then something like this 👇 (with a few details left out) to do what the JavaScript server.js was doing before: read exactly one image from the form, throw an error if not, and otherwise take the image, convert it to a JPG, and return the new path as an <img ... /> tag:

-- Main.hs
uploadAndConvert :: MultipartData Mem -> Handler Html
uploadAndConvert form = do
  newPath <- case (files form) of
    [] -> oops "No files uploaded!"
    f : [] -> liftIO $ do
      let jpg = ...
          newPath = ...
      BIO.writeFile newPath jpg
      pure newPath
    ...
  pure $ [shamlet| <img src=#{newPath} /> |]
    where
      oops m = throwError $ err500 { errBody = m }

It is a requirement of the type system to make sure that this particular endpoint returns HTML! It’s then a small exercise to ensure that any error content comes through with the appropriate HTML wrapping :) Happy Haskelling!

We are all familiar with the standard kanban/agile board settings:

• Backlog: Things we’re ignoring for now
• Todo: Stuff we’ve got to do this “sprint”
• In progress: Stuff we’re working on now
• Done
• Blocked

There are many variants on these names, but they’ve remained pretty standard over all the organisations I’ve worked in.

I myself now prefer a buddhist-inspired variant; namely:

• Background (was: backlog): Items floating in the expanse of consciousness.
• Awareness (was: todo): Items present in the mind.
• Sparking joy (was: in progress): Items presently being enjoyed directly.
• Thank you (was done): Items that have passed their time with us, for now.
• Impermanence (was blocked): Items temporarily on hold.

It at least lets me feel more relaxed about almost every column :)

Background

I can’t remember when I first stumbled across SciRate.

I’d had a fascination with scientific papers for many years, well before actually attending university (as a mature-age student) and starting to learn more formally. I would store them in a variety of ways, print them out and hang them up in my house; send them to myself on a mailing list that I created just for that purpose, or a public subreddit where I would post the papers I wanted to read, so I wouldn’t forget about them. Evidently, the “bookmarking” feature in the browser wasn’t one I found particularly useful.

Eventually, I discovered JabRef, which I used for several years. I stored all the papers that I was interested in (at the time, quantum computing), and learned all about bibliography management. I even stored all the PDFs, and the metadata from the JabRef system, in git, horribly offending bitbuckets storage limits by having a repository ~10GB in size (I think it doesn’t clone successfully anymore; it’s been several years since I tried.)

After some time I became tired with JabRef, and built my own (very very terrible) reference management program: super-reference.

Eventually, I discovered SciRate. I think the version I found was called “SciRate 2”. It was in the hands of Bill Rosgen. I got incredibly excited and signed up immediately. Because the code was open-source (I actually can’t remember, but I think it might’ve been a personally-hosted git repository somewhere), I added possibly one of my first “impactful” changes: MathJax support! This was neat; now we could see rendered math while reading abstracts and titles! I think arXiv.org only added this feature a few years ago.

But, aside from this very minor hacking on the code, I immediately started finding SciRate actually useful! I could browse it every day; see which papers would pop up, and track papers I was interested in. Fairly quickly, it became a very addictive habit for me. I began to learn the time of day that it would update, and made sure I would scour the website shortly after to browse the “freshest” papers.

I did this for several years (actually, I only stopped recently, maybe a few months ago). I read many papers (but not every one that I would “scite”); made several nice connections, and even used my personal SciRate data to teach my first deep learning workshops. SciRate stuck with me as my interests varied from quantum computing, theoretical physics, black holes, philosophy, AI, deep learning, computer vision, generative art, category theory, astrophysics, and the stranger maths papers. For a while my favourite thing was discovering the “best paper title” of the week.

The most memorable moment was when, many years later (after the scirate3 re-write), I met people who “knew” me from SciRate, only because they had seen that I would “scite” a lot of papers (in fact, someone told me that they didn’t think I was a real person; only a scite-making bot.) To date, I’ve amassed more than one hundred thousand “scites”. And yes, most of this was done by clicking manually; but in the last year or two I’ve used a custom program I wrote: the scirate-cli.

In any case, by a very strange coincidence, during my Masters program I happened to learn that SciRate was undergoing a re-write, amazingly by a company based in Melbourne (where I lived); just down the road from my university! I happened to have a conversation with the founder of that company, Ben Toner, relating to my masters project, but it was a curious connection.

That re-write ended up going, in my view, quite well. But I think, at some point, it stopped being funded, and fell on the shoulders of mispy. Mispy funded SciRate for a while, out of their own pocket, until I decided to take it over from them.

That was, now, 5 years ago.

All I’ve really been doing in the mean time is keeping things afloat. Upgrading the various packages as is required; managing the server, and the occasional bugfixes.

The only interesting thing I did, in recent times, was to add a “jobs” feature to SciRate. This was actually moderately successful, but in the end it was more effort for me to maintain than it was worth, so I disabled it.

Current

SciRate needs a new maintainer. I’ve decided that, personally, my focus has to shift elsewhere. You can read about that in the Addendum below.

Here’s what you’ll need to do:

1. Take ownership of the scirate repository,
2. Update the codebase occasionally, maintain deployments, fix the occasional bug,
3. Manage the error emails that come in,
4. Restart the server when it dies,
5. ???
6. Extend it in interesting ways!

The last one is actually quite important! SciRate has lacked any real new features for a very long time; but there’s certainly some interesting things that could be done! Notable among them could be:

• Support for “reading groups”,
• A recommendation engine,
• …?

The world is (somewhat) your oyster. Clearly there are some rules on how we’d like SciRate to develop; after all, there is a solid and growing user base, who have some expectation on how it will operate.

In any case, if you’re interested in getting involved, reach out to Aram and myself by sending us an email:

• noonsilk@gmail.com
• aram@mit.edu

We’d love to hear from you.

Addendum

The central reason I’ve decided to stop spending time on SciRate is because of the climate emergency. I’ve been reading a lot of books and it’s become increasingly important to me to spend my energy learning more and doing more (or less!) in this space. If you’re interested in this too, then please reach out; I’d love to chat!

You were born, cried, learned, made friends, and talked to no-one.

You have survived off the land; launched a startup (the best one), managed thousands of people, and never been able to get a job, no matter what your resume says or how you change your name.

You have travelled; and you have lived alone, isolated, and cold.

You have been the best and succeeded all your life.

You have failed; only, just missed out, and never tried again.

You made people happy; shown them the best time, given them everything, and hurt them, taken it all for yourself, and killed them.

You have died after every breath, and before your first.

You have already accomplished everything.

What do you want to do next?

A classic Australian movie: A nightmare chase through hell in a never-ending, unrequited daisy chain of desire… .

What is time? How do we measure a life? How many things did you get done today? What are you working on tomorrow!? Can you come hang out on Sunday!!?

Recently, and also always, I’ve been thinking about how to manage a list of todos. During an internal knowledge-sharing session at work I was prompted to reflect on all the different schemes I’ve tried:

• Random pieces of paper
• Notepad
• Windows sticky notes
• Tiddlywiki
• Mediawiki
• Jira
• phpBB and other misc BBS software
• Vim
• Vim quickfix window
• A terrible custom python script
• Vimwiki
• Text files
• Org-Mode (I gave up almost immediately)
• Emails to myself
• A private mailing list I made up
• Pomodoro
• Github issues
• Trello
• Notion
• Asana
• Readme files
• Taskwarrior
• Bullet journal (for <4 minutes)
• Physical notebooks
• Fancy notebooks
• Cheap notebooks
• Physical ‘kanban’ cards
• A whiteboard
• My head
• Nothing
• Random pieces of paper

Right now I’m back to a whiteboard (by luck I happen to have one behind me where I work), and ‘todo’ notes in code + github issues.

My friend Ruth told me something that perhaps is very obvious but was also surprisingly calming to me: You’ll die with items on your todo list. So don’t worry about it!

I think there’s a few ways to think about this:

1. The optimisic view: Amazing that I am lucky enough to have things I intend to do and look forward to!
2. The pessimistic view: Sad that I had goals that I was never able to achieve!
3. The Buddhist view: Your big mistake is having desires at all!

I want to live around option (3) and (1) at the moment, but of course option (2) is a very very strong driving force; and often necessary (for example, at work!); the only time I was brave enough to enact option (3) at a work setting was when I ran my own business!

Another interesting thing that came up as part of the work discussion was that in some ways what you want to do depends on your mood. No doubt! So … maybe mood can be a parameter?!

I think, secretly, for the rest of my life, I will believe that there is a True answer out there; an ultimate organisation scheme; the Four-Fold path to Life Efficiency: Right Editing, Right Organisation, Right Workflow and Right History.

But I also think that I should never think about this again. But on the other hand, I was inspired at the talk today; so I might give task-warrior another go.

But, you didn’t come here for that! Maybe you came here for advice? So, here it is (it’s not even my advice! Gala claims it’s her idea which is probably true):

If you can, don’t even write the thing down; just do it immediately, or, alternatively, convince yourself you don’t need to think about it now.

Maybe it’s part of my personality, but this works surprisingly well for me. Especially if it’s something that I’m working on with someone else; instead of delaying my part, I can just try and make as much progress as I can immediately, and send it back to the other person! Another way of saying this: I can offset storing my todo list to you!

I find this idea to be quite operaitonal; I often find myself using this rule to do something sooner rather than later.

Here’s one thing I know about myself: I can’t be trusted with lists. I get a bit obsessed with organising them. So I’m trying to avoid them these days.

Continuing the tradition started in 2018, continued in 2019 over on the Braneshop blog, I was reminded I haven’t posted the books I read in 2020 yet.

So, here we are:

How Long ’til Black Future Month? by Jemisin, N.K.

As a big fan of N.K. Jemisin I just wanted to read more of what she’d written. This is good for that; it’s a really nice dip-in to the worlds she has created and leaves you wanting more!

Gravity’s Century: From Einstein’s Eclipse to Images of Black Holes by Cowen, Ron

Pretty good. This was a nice history of black holes and an introduction to some of the pressing issues presently.

The Cloudspotter’s Guide by Pretor-Pinney, Gavin

I picked this up after starting (but not finishing) The Wavewatcher’s Companion, which I found to be hilarious. This book was not as funny, but was still pretty good. Gavin has a very nice way of appreciating the world.

Altruism: The Power of Compassion to Change Yourself and the World by Ricard, Matthieu

I really quite enjoyed this book, and infact wrote a longer review over on the Between Books website.

Girl, Woman, Other by Evaristo, Bernardine

A nice collection of stories featuring different women and how their lives intersect. I think it’s quite nice to get so many stories from the everyday lives of women; especially for me, for whom it’s a bit unknown territory.

The White Album by Didion, Joan

The first Joan Didion book I’ve read. She’s very famous of course; and I don’t know. It was good to read; but was it objectionably good? Maybe. It’s at least nice to know a bit about her life and how she writes. I’ll probably read more.

Mullumbimby by Lucashenko, Melissa

I quite enjoyed this story. It’s also the first time I’ve read a modern fictional Australian indigenous-centered story. Will be on the look out for more books of this kind! Came up as part of the OC House bookclub, I think.

Down Girl: The Logic of Misogyny by Manne, Kate

This book is amazing. I found it to be written in a bit of an academic-y style; so it can be a bit dense, but it does an amazing job of framing what misogyny is and how it is present in all aspects of society.

Unfree Speech: The Threat to Global Democracy and Why We Must Act, Now by Wong, Joshua

This is a nice short history of free speech and how China is taking over Hong Kong. It was interesting to read about how they attempted to make some large changes to their democracy through grass-roots organisation. In some ways quite inspiring, but also a reality check that it isn’t easy to defeat power. Worth a read.

A Month in Siena by Matar, Hisham

This was just a nice simple book about someone getting amongst life in a new town. In many ways I think this kind of experience is how many people wish their holidays to go: meeting some nice stranger, integrating into the community, and just appreciating the joy of life.

The Weil Conjectures: On Math and the Pursuit of the Unknown by Olsson, Karen

I can’t remember much about this book at this point; I think I enjoyed it.

The Worst Journey in the World by Cherry-Garrard, Apsley

I read the next two books back-to-back. This one was strange. It’s written from the English perspective; it’s quite racist at times. I wouldn’t recommend reading it, unless you really want to compare perspectives on the journeys of Scott and Amundsen.

The Last Place on Earth: Scott and Amundsen’s Race to the South Pole by Huntford, Roland

This was a really interesting read. It was so fascinating to compare how Amundsen approached the journey compared to Scott. According to this book, Scott was woefully underprepared and arrogant, and Amundsen spent many many years training and learning the right skills from different indigenous groups in order to survive.

If you want to learn about the race to the south pole; this book is definitely better than the above.

Food Rules: An Eater’s Manual by Pollan, Michael

More of a blog post than a book; but still, nice to keep next to you somewhere when you want to remember if it’s okay to eat chocolate everyday (probably not) or have a wine with dinner (probably fine).

Men Explain Things to Me by Solnit, Rebecca

Hilarious. This is a collection of stories; some funnier than others, but overall great.

The Shadow of the Sun by Kapuściński, Ryszard

I enjoyed this as a nice way to get a bit of, albeit an outsiders, insight into how different people live in some of the poorer parts of Africa.

Capital and Ideology by Piketty, Thomas

I really enjoyed this book, and wrote about it more over on Between Books - Capital and Ideology

Capital in the Twenty-First Century by Piketty, Thomas

This one I also enjoyed; I don’t think you really need to read it first before Ideology, but I opted to do so. Reading this really inspired a love and interest of economics, and Piketty seems to do an amazing job of exploring these topics in an approachable way.

Affluence Without Abundance: The Disappearing World of the Bushmen by Suzman, James

This book wasn’t bad; it’s an exploration of life with a marginalised tribe referred to as the Bushmen. It doesn’t totally take the expected view that the simple life is better; but it does discuss how politics and the community encroaches on this tribe, and how they live life.

A Woman in the Polar Night by Ritter, Christiane

I think this is a classic book; it’s a little strange, but it does show one persons journey into the Arctic and how she learned to love it. It didn’t exactly inspire me to go and life there, but I do admire her approach!

Touching the Void: The True Story of One Man’s Miraculous Survival by Simpson, Joe

This is amazing. I read this assuming a particular fact about the story (I won’t spoil it by telling you), but it turned out that my mind was blown by what actually happened. I’ll probably read it again!

Into Thin Air: A Personal Account of the Mount Everest Disaster by Krakauer, Jon

I bought this I think after the one above; desperate for more books about climbing. This is also an amazing story; I think if anything it made me feel certain that I’ll never attempt to climb Everest.

The Case of the Honjin Murder by Yokomizo, Seishi

I just happened across this one in the bookshop and thought I’d give it a go. I can’t say it was the best; it was quite sexist. The story was probably pretty good, if you could ignore that; but I couldn’t.

Tall Man: The Death of Doomadgee by Hooper, Chloe

This was a good read but super aggravating. It’s really unsettling to learn how terrible some of the policing is; and the subsequent investigations that yielded no useful outcome. Eye-opening for me in terms of how bad racism is in Australia.

Mountains of the Mind: A History of a Fascination by Macfarlane, Robert

Pretty good. I went through a phase of reading about mountain climbing. This was a nice little overview of how people justify climbing. Good for an introduction to other things to read.

The City We Became (Great Cities, #1) by Jemisin, N.K.

For how much I loved her other books; I have to say I found this one a bit disappointing. I think by normal sci-fi standards, it’s certainly excellent, and I’ll definitely read the rest of the series; but if you’re looking for something as amazing as her other books, you might not find it here.

Annapurna: A Woman’s Place by Blum, Arlene

I really enjoyed this one. It was interesting to compare this to other climbing books written by men, which almost never feature much uncertainty or collaborative leadership.

Underland: A Deep Time Journey by Macfarlane, Robert

This is just super cool. We are taken on a journey through lots of different underground worlds. Certainly makes you want to do this kind of exploring.

The Eastern Curlew by Saddler, Harry

I read this after meeting the author at a party! I felt so cool; I’d never met an author in real life before. Inspired by that meeting, I picked it up. It’s really a nice story about following the migratory path of a bird, and thinking about how their ecosystem is being impacted. Would definitely recommend!

Her Body and Other Parties by Machado, Carmen Maria

Not bad. Probably not my favourite style of book, but if you like weird kind of magical fiction with a message, probably quite good.

My Sister, the Serial Killer by Braithwaite, Oyinkan

I quite enjoyed this one; it was a very quick read; so I’m looking forward to more by this author!

In Praise of Shadows by Tanizaki, Jun’ichirō

Pretty good. Very very short; but a thoughtful analysis of how light impacts space. I think it’s a classic of the architecture world.

Barbarian Days: A Surfing Life by Finnegan, William

I really really enjoyed this one. Very nicely written, you feel like you’re living the life alongside the author. It’s nice to read about someone who follows their passion so directly.

Why I’m No Longer Talking to White People About Race by Eddo-Lodge, Reni

I picked this up as soon as I arrived in the UK, to gain an understanding for how people here think about race issues. Pretty good reading.

Kon-Tiki by Heyerdahl, Thor

This was a funny one. A classic kind of adventure story, from real life, I have to say I enjoyed it.

Mad, Bad & Dangerous to Know: The Autobiography by Fiennes, Ranulph

I found this one also kind of funny. I suppose this guy is very famous in the UK, but I’d not heard of him really. It’s funny to read about how he thinks of endurance, and his claim that “anyone” can be like him; in terms of running 7 marathons at the age of 70 across 7 countries; or something along those lines. Didn’t exactly encourage me to do the same, but did give me some food for thought about willpower and energy.

See What You Made Me Do: Power, Control and Domestic Violence by Hill, Jess

This is a very hard book to read, emotionally. It contains some exceptionally difficult stories. Definitely recommended reading, but if you want a more academic treatment see the earlier book by Kate Manne.

Becoming Bodhisattvas by Chödrön, Pema

Easily the best book I read last year. Of course it’s a buddhist view on how to live life; but I found it very practical and thoughtful. I’ve read it again during some difficult times, and found it very uplifting.

So, I’m very excited to share that we’re moving overseas! We’re headed to Cambridge in the UK at the end of this month.

I’m very lucky to be starting work with a very cool quantum computing company: Riverlane.

Leaving Melbourne

It’s going to be interesting leaving Melbourne. I’ve lived here all my life basically, and I’ve found a really nice group of friends. I’m going to miss everyone.

I owe a big thanks to everyone that’s helped me in my career and life over the years here. I won’t list all of you, but thanks :) I wouldn’t be where I am if I hadn’t had your help and support. ❤️ 💖

In particular the meetup community has been a great place for me and somewhere I was able to forge some really strong friendships. Specifically, I’ve had a great time at the Melbourne Maths and Science Meetup, the Haskell Meetup, back in the day I loved MXUG, and of course I have to thank my friend David Kemp for being the only consistent attendee of the Quantum Lunch, started way back in the day! I’ll also miss hanging out with the cool people who’ve come to events I’ve helped organise, such as compose conference and post-prediction conference. I love Melbourne for the really nice connection you get between different communities, and it’s been some of my favourite times meeting people from outside my standard little bubble.

I also have to thank my friend Charles Hill from Melbourne University, who taught me so much about quantum computing, is an amazing researcher and very kind and generous person.

Thanks also to the other people in the tech community here that have supported me and helped me first move into new jobs and learn interesting and fun things. I’ve been very lucky.

Of course, thanks again to all the people that helped out with Braneshop whom I’ve already mentioned over there.

Cambridge

We’re totally new to Cambridge, so if you’ve got suggestions/connections I’d love to hear about it! Definitely keen to meet some people and get into the community over there.

Reach out if you like!

I’ve benefited a lot from emailing random people and just asking questions, so please feel free to reach out to me if you think I can help with anything!

Inspired by this recent paper - Towards decolonising computational sciences - I thought it might be a nice idea to write down a list of privileges that I can identify I have. I’ll probably update this list as I think of them.

My list:

• White, Male, Cisgendered: I don’t often feel out of place.
• Healthy: Nothing has prevented me from finding work.
• Able-bodied: Getting around is easy.
• Somewhat extroverted: Able to engage and network somewhat easily when I want to.
• No dependants: Freedom to move around and spend time as I wish.
• Financial stability from a young age: Able to take (moderate) risks.
• Supportive parent: I know I’ll have a place to go.
• Supportive partner: Financial/emotional support to experiment.
• Live close to the city: Access to events, convenience.
• Good mental health: I’m able to focus when I want; am most of the time moderately calm.
• Language: I speak English natively.
• Exposed to tech from a young age: I had a computer in the house since I was young, and was able to learn programming on my own as a result.
• Well-educated: I went to a private school, and was eventually able to attend good universities and get access to experts and knowledge in this way.

These things have helped me get jobs in the past. Some of them are traits that you can improve, as well as baseline things thare are out of my control to some degree (i.e. mental health; certainly it can be improved, but certainly it’s not all my doing.)

I also found this: Privilege Checklist from this Social Justice Training program, that is a very good starting point for building a comprehensive list. This feels like a great exercise for teams to get together and think about.

What’s your list?