I found it hard to believe Veritasium's claims about the 100 Prisoners Riddle, so I wrote a small experiment to confirm that the proposed solution did in fact improve the odds so drastically.

The video is available here:

And here's the code I wrote to verify the solution works as expected, including a short description of the problem:

The output of the code shows clearly that the strategy works as claimed:

➜  prisoner_riddle python3 prisoner.py
Naive strategy gave 0.0% chance of success
Looping strategy gave 31.313000000000002% chance of success
➜  prisoner_riddle

There's only about 4.2 billion IPv4 addresses. This seems like a lot, but if you've got a list of 2048 words, you'd only need three of them to cover all the IPv4 addresses in the world. Hence: What3Words, DNS Edition!

Find a What3Words for your domain...

I started by building a "translator", which lets you enter a real domain and see what the equivalent three-word triple would be:

$ ./what3words -t bede.io
balcony.scissors.hurt

Neat! It looks up the domain's IP address using Go's net.LookupIP function, then converts that IP into a trio of words.

IPv4 addresses are 32 bits long, so they're normally split into 4 bytes. But it's not called “what4words”. I used some bit-shifting to pick out the top 10 bits, then the middle 11 bits, and finally the last 11 bits:

ipNumber := binary.BigEndian.Uint32(fourByte)
firstIndex := ipNumber >> 22 & 0x7FF
secondIndex := ipNumber >> 11 & 0x7FF
thirdIndex := ipNumber & 0x7FF

Then I used each of those indexes to lookup a word in a big slice of 2048 words loaded from disk.

...and an IP for your What3Words!

I could build a command-line tool which translates back the other way. But turning a name into an IP address sounds like a job for DNS!

So, I built a mini DNS server. I looked around and the advice was almost always “don't build this yourself!” — always a sign that I'm about to learn some fun stuff.

This GitHub repository of a tiny DNS server was useful as a jumping-off point, as was this ServerFault answer describing some of the format, but to build this thing I ended up having to use the spec (RFC 1035) itself for reference. Honestly, it was pretty easy to follow — lovely ASCII diagrams like you see in the header of this page!

This does the inverse of the translator tool, but over DNS:

1. Read the query and extract the domain name pieces; then
2. Send back a correctly-formatted response

DNS Protocol Wrangling

A DNS request looks pretty much the same as a DNS response. There's a Headers section, a Question section, an Answer section, and a couple of others which I didn't bother handling for this simple demo.

It's a reasonably simple protocol, but there was still a lot of binary formatting to get right before any of these DNS requests would work. For example, this was the code to format the response header:

func getResponseHeaders(dataSlice []byte) []byte {
	// Set the query/response bit to RESPONSE.
	var QR byte = 0b1 << 7

	// Responding to a standard query only.
	var OPCode byte = 0b0 << 3

	// We're an authority on these triple-names.
	var AA byte = 0b1 << 2

	// We'll never truncate a message.
	var TC byte = 0b0 << 1

	// Recursion desired? (Copy from request.)
	var RD byte = dataSlice[3] & 0x2

	// We can't provide recursion.
	var RA byte = 0b0 << 7

	// Z must always be zeroes.
	var Z byte = 0x0

	// No error from us!
	var RCode byte = 0x0

	return []byte{
		// ID (2 bytes)
		dataSlice[0], dataSlice[1],

		// Flags (1 byte)
		QR | OPCode | AA | TC | RD,

		// More flags (1 byte)
		RA | Z | RCode,

		// Number of entries in the question section
		0, 0,

		// Number of resource records in the answer section
		0, 1,

		// Number of NS resource records in the answer section
		0, 0,

		// Number of resource records in the additional records section
		0, 0,
	}
}

I'm sure a real DNS (or Go!) expert would have a lot to say about this, but it's a working DNS server, which I've never built before!

The way it interacts with the network is using the lovely socket API provided by the Go standard library. We use socket.ReadFromUDP in a loop to get each new data, then go processDNSRequest to start up a goroutine and send a response back using socket.WriteToUDP.

Testing it locally

Using dig or nslookup we can see it's sending back a well-formatted response for our DNS query!

$ sudo ./what3words -s
Listening on port 53...
Transaction ID: 0x20FC
Flags: 0x0120
Questions: 1
Name: balcony.scissors.hurt
Responding with IP: 35.176.67.126

$ dig @localhost balcony.scissors.hurt

; <<>> DiG 9.10.6 <<>> @localhost balcony.scissors.hurt
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8444
;; flags: qr aa; QUERY: 0, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; ANSWER SECTION:
balcony.scissors.hurt.	0	IN	A	35.176.67.126

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Apr 12 18:38:10 BST 2022
;; MSG SIZE  rcvd: 49

Silly MacOS Redundancy

I had a bunch of trouble getting this to work correctly with MacOS. It turns out that while dig and nslookup are absolutely fine with the response as-is, most tools on MacOS (i.e. the ones that use mDNSResponder, like ping, curl, Safari, etc.) require you to send back the Question part of the DNS query! Otherwise, they fail with some ambiguous errors.

This was a surprise to me, since it seems like redundant information — after all, the “ID” should tell any DNS client what the server is responding to.

After adding this chunk of code...

// For some reason, we need to send the Question section back...
reqQuestion := []byte{}
reqQuestion = append(reqQuestion, domainSliceToBytes(name)...)
// A Record, IN Type.
reqQuestion = append(reqQuestion, 0, 1, 0, 1)
res = append(res, reqQuestion...)

...and adding 127.0.0.1 at the top of my DNS servers (not recommended!)...

...it connects to my server as expected:

It's managed to connect to my Caddy server, which has this directive to serve a different response for anything asking for the hostname balcony.scissors.hurt:

http://balcony.scissors.hurt:80 {
  file_server {
    root website/balcony
  }
}

The full code for my mini-DNS-server is on GitHub. Now to convince everyone else to use it...

I've been looking at the performance of my website and decided to cache some of my assets, like fonts and CSS files. To have them cached for as long as possible, and prevent "cache misses" when no data has changed, I knew I wanted to set a Cache-Control: Max-Age header with a veeeeeeery long timeout.

However, this makes things difficult when I want to change some of the CSS. How do I tell people's browsers that their cache is invalid, and they should load the new styles?

Hashing & Build Tools

The way that many modern frontend build tools do this is by adding a mini hash to the filename. For example, style.css becomes style-c81ac3.css. This small hash isn't cryptographically secure or anything, but it doesn't need to be for the use case. It's so likely it's nearly guaranteed that your changes will result in a different hash (1/16,777,216 chance of failure).

Frontend build tools also typically use templates for the tags (e.g. href="{{ STYLE }}" or swap out references to real files (e.g. href="style.css"). I don't want to do either of those, because they mean maintaining two sets of files: the "templates" and the "built files".

Introducing a modern build tool takes time, and I'm not managing a large client-side rendered JavaScript app — this is a simple personal page. I don't want to introduce Jekyll or Gatsby, since they have far more features and dependencies than I need.

Simple is Best!

In the end, the perfect solution ended up being a bash script. Changing styles while serving the site locally works immediately as expected, as I can configure my browser to ignore the cache. When my changes are done, I run this bash script which does two things for each CSS file I have;

1. Calculates a hash of the file's contents, and rename that file to use the hash
2. Search for the old filename in HTML and replace with the new filename

The minihash command I've used to calculate file hashes lives in my ~/.scripts directory on my PATH:

#!/bin/bash
shasum $1 | cut -d' ' -f1 | cut -c -8

It outputs an 8-character hash of a file (trimmed down from a full sha256 hash!).

Important disclaimer: If I were writing this for an important production site I'd have a LOT more safeguards in place, and might not even use any form of this method, likely preferring the template/build approach. Using a regex to replace details in HTML is fine, provided you know exactly what the HTML contains. For my personal site, it's enough to check everything's still working and rollback in git if not!

Here's the final script:

One thig I'm still trying to work out is how to make this bash script portable between MacOS and Linux. Currently I've used the -i argument to run Sed in-place, but I understand that's not in the POSIX standards. Any tips welcome!

I wanted to make a specific bit of UI to help me roll some dice, and it turned out quite interesting.

My requirements are:

• Roll some standard D&D dice!
• Make it as quick as possible — keyboard shortcuts preferred over mouse clicks
• Be forgiving about the input, and allow correcting mistakes, or cancelling a roll

I've been using Improved Initiative, which has a shortcut for pressing d to roll some dice. It's quite good, and I'm undecided whether it's worth switching tabs, but I think my version is a lot quicker.

Unconventionally, I'm using the r key as a sort of modifier. You hold the r key to roll dice, and then you type the numbers you want. For example, r 2 4 would roll two d4s, aka four-sided dice. Try clicking in this iframe and rolling some dice.

This continues my trend of writing in quite a TDD style for my side projects. I don't love TDD for UI work, but here I'd identified a pure function to test: given a growing list of user inputs, what should the computed dice roll be?

I started this project using Deno, a lovely TypeScript runtime and growing competitor to Node. Deno includes a test suite, so I didn't have to configure Jest or anything.

My tests look like this (shown: about a third of them):

I wanted some nice shortcuts in there, like being able to type 00 for a d100, omitting the 1. But shortcuts do lead to more complex code, so the testing was important to make sure I hadn't broken anything.

I then built a fairly simple UI in React, using the Pantone Colour of the Year (of course). One interesting part about the UI was a new hook I wrote:

Generally, this UI was very reactive to keystrokes, which was somewhat tricky to manage in a declarative way. The useEffect pattern can sometimes lead to uselessly destroying and re-creating global event listeners, something I was keen to avoid. I used the useRefState hook for a boolean variable to track whether the UI was in the "rolling" state or not. This meant that the UI could reactively update, but the change was immediately and synchronously available for the keyDown/keyUp callback functions, and those callback functions could be maintained without concerns about stale state.

A future enhancement would be to roll combinations of dice, like 2d8 + 4d4. This goes along with the other missing feature, which is adding constant numbers to the dice rolls. Honestly though, that's not a feature I've ever loved — mental maths is part of the fun of D&D (possibly one of the nerdiest sentences ever, but I'm owning it). And this UI is quick enough to just roll the dice in succession without worrying about combos. Still, that might be the next challenge for me!

I'm having my first game with it tonight, so it'll be battle-tested very soon!

TLDR: “Dates are broken; use Luxon and subsequently Temporal; test timezones in your unit tests if you can!”.

Part 1 — Picking A Picker

Long ago, we’d started off by ruling out any date pickers tied up in an existing design system — great for some, but hard to style to fit our braaaaaand. Typescript support was desirable, but not a must-have. Really, it just needed to let a user pick dates in a non-frustrating way. That ruled out any library which didn’t use a dropdown for years — clicking back month-by-month to 1972 isn’t the most fun way to spend a half-hour, trust me.

We ended up settling on React Datepicker because it wasn’t too hard to style, and “date library agnostic”. Turns out, this meant the component would deal exclusively in JS Date objects.

If you haven’t dealt much with dates and times, feel free to back out now — I won’t judge you. It’s the sort of thing that you should just be able to leave to other people. Annoyingly, in this case, that’s not entirely possible.

So look, not to get all fancy about it, but we have users in a few different countries. With different timezones. Some of those users occasionally need to pick some dates. We try to accommodate our users in order to get paid — you know how it is.

So when Jean-Luc opens up our date picker in his apartment in sunny Hamburg, he sees a simple date picker that lets him choose three things:

• The year;
• The month; and
• The day.

It seems so simple. So pure. And if Hacker0x01 had simply chosen to return this year, month and day, then they wouldn’t have roughly a trillion issues that look like this:

The trouble is, clearly someone over there was a big fan of Using The Platform. Instead of making their own Date structure with these three properties — or just returning a string — they’ve chosen to return a native JS Date.

Part 2 — Dates: They're Bad!

Here’s the issue: JS isn’t magic. A Date object isn’t something which mysteriously “does the right thing” on a bunch of systems. It’s a pretty thin wrapper around a Unix timestamp.

A Unix timestamp is measured in seconds since midnight, Jan 1st, 1970 (UTC). Actually, that’s not quite true — UTC didn’t exist until 1972, so there’s a bunch of weird stuff where you actually have to calculate it from 1972 and then add a constant number of seconds on top. And even then, guess what? Sometimes the Unix timestamp repeats itself with leap seconds. Try and find out what precise second the timestamp “915148800” refers to, if you’re interested. Spoiler alert: there’s two of them!

But anyway, it’s way too easy to get lost in the Forest Of All Knowledge with this stuff. Why do we care about leap seconds and monotonicity all of a sudden? We’re just building a date picker, for crying out loud!

The real problem is, we’ve gone from a simple [year, month, day] representation of data to a much higher-resolution one. In GCSE Physics, we were taught about the difference between “accuracy” and “precision”. Here, we’re just pretending we’ve got more precision than we really have, a bit like rating a restaurant 5.0000000 stars. The user hasn’t indicated anything about what hour, minute or second they’re interested in. We’re just — wrongly — using the Date container because it has a relevant name. Unfortunately, the underlying Unix timestamp implementation has very little to do with dates as our users understand them.

Part 3 — Uh Oh, It Actually Breaks Things

Our problem isn’t just hypothetical, though. In our case, we’re building financial software (boo, hiss). So Jean-Luc is actually interested in some data from 2/3/2014 to 2/3/2016*. In our database, we have a bunch of entries with dates attached, and we want to send him all the entries within that range.

When Jean-Luc chooses a date using Hacker0x01’s date picker, he's just choosing a year/month/day — a date in the conventional, human sense. But as soon as it's converted to a JS Date, it's given a lot of extra data:

Suddenly, our date looks more like a super-precise timestamp, down to the second. It also looks like it contains information about Jean-Luc's timezone — Central European Standard Time, or CEST for short.

It sort of does, as well — if you call .getTimezoneOffset() on this date, it'll happily tell you that the current offset is “-60”: if you take the timestamp as-shown, and subtract sixty minutes, then you'll get the timestamp as it would be in the UTC zone. (Slightly confusing, given that it's written as GMT+1 in the format, but sure.)

Here's what happens if you call .toISOString() on this date:

Bizarrely, it applies the timezone offset, and then renders the timestamp to the ISO format, with an offset of zero — marked by the trailing Z. (source)

This is also what happens if you use JSON.stringify on a Date object — the toISOString method gets called, with exactly the same result. (source)

On the server side, we’ll parse this date using... well, anything, really. Regardless of whether we use new Date(...) here, or something third-party, the damage is already done. Any reasonable parser will see that timestamp, and when asked “what date is that timestamp referencing?”, will give the answer 2014-03-01. The first of March, not the second. Sure, it's a bit late at night... but it's the first of March nonetheless.

Part 4: Can We Just, Like, Not

This is baffling. We've taken a built-in Date object, as provided by a third-party library, and serialised it using the default method, to a format which should support timezone offsets. We then parsed it using the default method on our server, which correctly supports timezone offsets. And somehow, we've ended up with a completely different day!

(Parsing dates can also be problematic, as Jacob Jedryszek points out here, although not relevant in this specific case.)

Now, maybe we're tempted to write dirty hacks on the server to get this working. Ooh, maybe we can just find the closest midnight instead of using the current day. Nope — timezone offsets can be more than 12 hours, so this will reliably be wrong for folks in some parts of NZ, Samoa, Tonga, and Kiribati. (source)

At this point, we've gained precision (added a lot of zeroes) and lost accuracy (we're not even talking about the same day any more).

Poor Jean-Luc. All he wanted to do was pick a date. And poor us, to be honest — we did what we'd always been told to do with dates (and displaying maps, and optimising code, and cryptography, etc.): we didn't roll our own code; we relied on the platform, and some popular third-party code with good test coverage. In short, we took the path of least resistance. And it's totally wrong.

Part 5: Alright, Now Get To The Point

For dates — and I'll die on this hill — the correct data structure is a tuple: [year, month, day]. We can add any other features around weekdays or adding intervals or ranges or whatever using a collection of helper functions. The popular date-fns library almost gets this — they've got a fantastic idea of using a simple builtin type, and providing a bunch of useful functions which act on that builtin type. But the problem, of course, is that the builtin type is rubbish.

I'm now very much convinced that a library very similar to date-fns should exist, but that acts on ISO date strings ('YYYY-MM-DD') or date-tuples [year, month, day] instead of native Date objects, or anything third-party like Moment/Luxon. Maybe for time stuff there could be a library which acts on full ISO timestamps, but I see that as a separate problem-space entirely — calendar dates shouldn't rely on timestamp weirdness!

That all being said, I'm not going to build one, because it'll immediately become obsolete as soon as the Temporal API becomes a reality. Check out the PlainDate spec — it's just what a calendar date-picker should deal in!

Anyway, I believe the correct option to make this work right now, in the absence of a reasonable builtin Date type, is some combination of these:

1. Immediately use the getDay, getMonth and getYear methods to get a [year, month, day] tuple to pass around and format yourself.
2. Optionally, realise that getYear actually returns the number 114 for this, and discover that you instead have to use getFullYear. Ideally, this should be done only after the code reaches production, in order to tell as many users as possible that their stock market data begins just 14 years after the first appearance of the wheelbarrow in China.**
3. Add loads of test cases which mock the system's timezone and time — eurgh, fine, we should probably do this. But it sounds really hard.
4. Use Luxon, which at least does include the current system's timezone by default in its formatted ISO strings, and provides a nice method called toISODate which only returns the actual date bits of the DateTime. Both methods output the date as chosen by the user, in their own timezone — you can choose to keep the timezone info or get rid of it when serialising, but there's no nasty surprises either way.

We're using #4 (and, aspirationally, #3) in our app — Luxon's many methods for adding/subtracting weeks, months and years are too useful to give up. We'll try and make sure that we're using toISODate where possible to introduce as little false precision as possible — serialised calendar dates should look like YYYY-MM-DD, nothing more.

And maybe we'll be the first to open-source a date-picker which uses the Temporal API. Who knows?

*I'm using the European date format here, day/month/year. It doesn't hugely matter though, the format is less important here than the underlying representation.

**I should clarify, this didn't happen to us. At least, not yet.

Since graduating last year, my CS has got a bit rusty – working full-time, there's not much time to learn much dense theory. But there's always time to play a quick board game. Mancala is an ancient game with really simple rules which I've been playing since I was a kid.

The board looks like thisꜛ: twelve small pots and one big pot on each side. To start with, each small pot is filled with three* marbles.

*Although the rules are simple, there are hundreds of variations: from the number of marbles each player starts with, to the rules for capturing, it seems like nobody can agree on the “real” rules. Anyway, I've always found this variant to be fun and challenging!

Each player controls the six small pots closest to them. On their turn, a player can choose one of their (non-empty) pots, and distribute the marbles in the pot anti-clockwise, one at a time.

For example, moving pot #5:

If your last marble falls into an empty pot on your side, and the opposite pot has marbles in it, you capture those marbles – clear out both pots and put them in your store to the right.

And one last rule – if your last marble falls into your store, you get another turn!

A Quick Primer on Game AI

While playing Mancala with myself in lockdown is fun for a little while, it's much more fun to have an opponent.

In university we learned about a game AI technique called MiniMax (and its less fashionable younger sibling, MaxiMin). Today, I'll be using MaxiMin to try and maximise the minimum possible score achievable by every move.

For example, let's imagine a simple two-player game where we both have two choices – A or B – and the game has a running score every turn.

Let's say that we're playing this game, and the current score is zero. By choosing A, I  know the score will become +1 in my favour; by choosing B I know it'll be +4 in my favour. Both options are great, but option B seems like the smartest one!

That's looking only 1 move ahead – it's what we might call a "greedy" strategy; taking the highest total score we possibly can each turn.

This is a half-decent strategy, and it's how most people start learning to play games like Mancala! In a lot of situations, though, humans can beat it by thinking a couple of moves ahead.

For example, let's look a couple of moves into the future.

If we're playing Green, it's the "greedy" choice to pick option B straight away. But then, regrettably... it's Blue's turn. Blue is trying to minimise our score. So Blue could choose B, but why would they do us any favours? If they're playing well, they'll chose A, and we'll end up on a score of -3 after two moves.

This is the core idea of MaxiMin – assume your opponent is playing perfectly, and maximise the score you're guaranteed to get. In this case, you can pick option A and guarantee that you'll have a score of at least -1. Not great, but not as bad as if you'd picked B!

Applying AI to Mancala

The great thing about Mancala is that there's at most 6 choices you have at any time. So you can relatively easily look 7 or 8 moves into the future without much computation time at all – it's under a couple of million configurations, which V8 crunches through in no time!

The only minor complication to just plugging a Mancala game into MaxiMin is when you can repeat a turn – but that's not too hard to account for in code.

The algorithm evaluates each move recursively. On the first player's turns, it picks the best moves for the first player; on the second player's turns, it picks the best moves for the second player. By doing this, it works out the optimal strategy to play against a completely rational opponent.

The base case of this recursive evaluation is to calculate the "final score" of the board – counting the marbles in both players' pots, combined with their stores, and taking the difference between the two. This base case is reached either when the depth limit is exceeded, or when no more moves are possible.

I've included this code below. The updateBoard function, which immutably creates a new board from the current board and a player/move, also returns a nextPlayer value. By passing down this, as well as the player whose score we're maximising, into the recursive call, we don't need to worry if the moves don't strictly alternate. At every level, we know whether to pick the move with the highest or lowest score!

Here's the full code to the game, including logic for calculating the next board states, captures and so on – it's a bit rough, but it gets the job done. I even did a few unit tests – which is honestly more than I expected of myself for a fun little side-project...

https://gist.github.com/bedekelly/5f1d566df8368a8f08fec4acaec13aab

What we've all been waiting for...

So, we've built this AI– how does it do in real games? Well, anecdotally, it's scary good: I'm not too bad at the game, but it kicks my butt almost every time. Playing the best game I can, and using the opening I'm most familiar with, it beat me 23-13!

If you're interested to see how my Mancala-bot plays when it can see 8 moves in the future, try dragging the slider below to see me get owned in real-time:

Thanks for getting this far – you're a trooper! If you've enjoyed this, or you think you can beat my Mancala AI, come follow me on Twitter (@bedekelly) – I generally post small coding projects I've been working on like this or this, and always include a link to the source code. Hopefully you'll see something you like!

I'm super excited about Svelte! Compiling JS instead of doing virtual-DOM diffing is loads faster and opens up some amazing possibilities – once you get past the slightly weird syntax, that is.

A great test for whether I understand the basics of a framework is writing a Knob/Dial component. It should work the same as in most music software these days – drag up, and it rotates clockwise, increasing the value; drag down, and the inverse happens.

This is a good test because it has three "representations" of a value:

1. The actual value, maybe something like a volume from -12dB to +24dB;
2. The pixel offset of the user's cursor from their initial click location; and
3. The amount of rotation applied to the knob itself.

Keeping these three values in-sync is an interesting problem. Dragging the cursor changes the pixel offset, which should affect both the rotation of the dial and the value reported by the knob component.

But not only that: the knob should also be "settable" from outside. In React-land, we think of this as a "controlled component" – if, say, the volume is being automated from elsewhere, it should be possible to control the knob (and its underlying values) without using the cursor. (In the gif above I've simulated this with a "set to 50%" button.)

I've found this is a great way to dig into whether I fully understand how data should flow in any given framework. For example, what's the "source of truth" of the three values: the pixel offset, the rotation, or the underlying value?

Almost always, it's a better idea to use the underlying value as the source of truth. But there's a few issues which occasionally crop up with this approach:

1. The underlying value isn't actually accessible synchronously – e.g. all you have is a set() method, and a get() method which returns a Promise!
2. The underlying value can't be changed many times a second – maybe it's a parameter in a physics calculation happening in a web worker;
3. The underlying value isn't linear – for example, it makes sense to increase amplitude logarithmically for a perceieved linear increase in volume.

Ideally, the Knob component should be built in such a way that these details don't matter at all. Integrating/extending this component to handle such cases is a good exercise in decoupling the UI and the inner workings of an application.

Here's my code for the animated example above – it's using Svelte's 2-way data binding, and anecdotally it seems a lot more performant than the React alternative – I think this is a case where the lack of virtual DOM diffing really shines!

https://svelte.dev/repl/e76f28b965334d37a792ed1f2ecb67b1?version=3.29.4

And the code is copied here, if the Svelte online REPL doesn't work for you:

Enjoy!

Imagine waking up one day and being told:

“Every second you’re awake, you can spend £50.”

What would you spend it on?

If you’re like me, your first thought would be food. That’s a seriously fancy order delivered to your door – a full meal for you and a partner. But maybe the first order wasn’t quite up to scratch, so you try somewhere else: a dessert place this time. (Hey, you can afford a personal trainer now!)

Many people would start paying off their bills. Five seconds more, and this month’s electricity, gas, water, phone and internet bills (plus TV license!) are all paid in full (£250).

A big grocery shop to fill the cupboards (£100), and another couple of seconds elapse. Booking a day trip to the nearest spa to celebrate (£200, 4s); thirteen seconds in total have passed.

Go ahead and get a bottle of wine in. Waiting just five seconds gets some premium booze (£250). And bring some friends round – a couple more seconds and all their taxi fares are covered.

Let’s set our sights a bit higher. On average, people in the UK have £15,400 in debt. That’s a genuinely huge amount of money that causes people untold amounts of stress. Perhaps we’ll have to wait overnight for that to be paid off? No, actually– it’ll take a little over 5 minutes.

Debt-free and well-fed, with great company for the evening, and full cupboards: we’ve spent under five and a half minutes so far.

To make it up to six minutes, we can pay our £1k rent for the month (20 seconds); all our travel costs for the month (£230 for a monthly zones 1-5 travelcard, or 5 seconds); another big shop (£100, 2 seconds); and spend the remaining 9 seconds (£450) on a whole new wardrobe.

Short-term needs (and some desires) fulfilled – after just 6 minutes – a lot of people start thinking about the medium term. Waiting another minute covers the next year of travel (£2400, 48s, rounded up for £600 extra out-of-London). Another four minutes, and the next year’s rent (£12k, 4m) is paid. After another minute, all bills for the next year (£200x12=£2400) are sorted too. Fourteen minutes after waking up, you can safely afford food for the whole year.

At this point, your quality of life is roughly the same – but you don’t have to worry about food, rent, bills or travel costs any more for the next year. If the money stopped flowing now, you’d still be able to quit your job and spend your time with friends, working on personal projects, creating art and learning. In real terms, you’ve been given £42,000, or a fairly high big-city salary after tax, all in the first 14 minutes.

A car is often the next big purchase people consider making. Especially outside of London, it can help immensely with employability and care of relatives, as well as just freedom to explore. Spending £30k for a new car will get you a nice Audi or Mini, and you’ll only have to wait 10 more minutes for it.

So why not wait a little longer? Waiting an hour and a quarter, you could bag a brand-new Lamborghini – the 2020 Huracán Evo Spyder. And I’d be lying if I said I knew anything about what justifies its $290k price tag.

But this is a huge purchase for someone who lives in a pretty modest flat. Waiting 6 more hours (with bated breath), you can outright buy this luxury London apartment for £1m:

Or if you decided to move outside London, this sprawling countryside mansion for nearly the same amount (and you’d have £50k left over for a third car, too):

It’s been a hell of a day. If you woke up at 8:00am, you’d have been debt-free and comfortable by 8:06am; and fully paid-up for the next year’s expenses by 8:14am.

By 8:24am, you’d have a brand new car.

By 9:39am, you’d have a 2020 supercar which would turn heads anywhere in the world. (Let's call it 10:00 – just to get all the comfy extras.)

And by four in the afternoon, you’d have signed the deeds on a countryside mansion, or a luxury London penthouse – your choice. (If you waited till 10 in the evening, you could comfortably have both.)

Let’s say you were more charitably inclined, though. Instead of going for the second house, you could choose to fund a charity.

GiveWell recommends the Malaria Consortium’s “seasonal malaria chemoprevention” programme, and has verified that it’s capable of absorbing up to $66MM in funds. It estimates that the cost of covering one person for four months of its treatment programme is roughly £5.36 – that’d be nine people every second, with your newfound wealth.

Putting just a couple of hours into this programme could effectively protect sixty-seven THOUSAND people from malaria. That’s a huge number to comprehend, but in West Ham’s new stadium it’d look like this:

(plus a big crowd of a few thousand waiting outside!)

It’s 7:00pm, and you’ve already saved the lives of countless tens of thousands of people you’ve never met. It’s easy to feel like you’ve done more than enough – after all, you didn’t have to give anything to charity.

We’ve been making some fairly large purchases, so it’s worth remembering just how fast the money is flowing in. In the sixty seconds from 7:00 to 7:01, you could buy:

• Another fancy meal for two, delivered to your door;
• Each current-generation games console (PS4, Switch, and Xbox One);
• A night out in a posh London cocktail bar;
• A Deluxe King room at the Savoy hotel;
• £200 in premium skincare products;

and still have nearly £100 left over to idly rip up as you start to wonder how you’re going to spend the rest of the cash. All in the space of a single minute.

From then until the end of the night, you’d accumulate £897k – enough for this ten-cabin mahogany sailing ship.

Over the course of the day, it’s become clear that you have no reasonable way of spending the money you’ve been given. Your quality of life has been irrevocably changed: food, bills, and other incidental costs are now meaninglessly small amounts of money for you. It’s likely that you’ll have stopped thinking about money in units any smaller than £3000, which you accumulate in exactly 60 seconds. You’ll consider employing people just to advise you on how to spend your money, or to manage the cars and properties you’ll likely never spend much time with.

In total, you’ve been given £2.88 million for your first day.

The richest man in the world as of 15/11/19 is Bill Gates, with $110B (or around £85 billion). Widely acclaimed for his philanthropy, Gates’ fortune has nevertheless grown by £16B since last year, even taking into account his charitable donations.

For Gates, the thought experiment above is a reality – not just for one day, but for every day of the rest of his life. Even if his net worth never grew again, he could spend this amount of money every day – new stadiums full of people saved from malaria, new sports cars, new exotic homes – without seeing a dent.

In fact, if this spending went on for eighty years, he’d still comfortably be a billionaire.

The argument against higher taxes on the ultra-wealthy often goes that people have worked hard for what they have; that they’re just reaping the rewards of waking up early and “hustling” for decades. This argument relies on a lack of understanding of the true scale of billions of pounds, and insults the genuine working class who can often barely afford to pay their rent after long shifts in hazardous conditions.

While there are faintly more credible economic arguments regarding “job creation”, it seems clear that the supposed ”incentive” is too great – that simply having wealth on such a vast scale is an immoral act. Even despite Gates’ charitable contributions, his personal net worth increased by $19B over the last year: enough for another eighteen years of the unimaginable spending detailed above.

Whatever the case, it’s worth remembering this rule of thumb: each billion pounds is nearly a full year of new supercars, mansions, boats, and more – every single day. If that isn’t worth redistributing, I’m not sure what is.