These behind-the-sketch posts are for paid subscribers interested in learning about the process — the weekly sketches remain free as always.

As Norwegians say: Det finnes ikke dårlig vær, bare dårlig klær, which loosely translates as, “There’s no such thing as bad weather, only bad clothes.”

Read more

Hello!

One of my favourite quotes this week. Paid subscribers can see me struggle with drawing inverted at the bottom.

Wishing your chances to come this week,

Jono

Subscribe now

Abraham Lincoln stands among the most admired US presidents. Apart from his deeds and what he stood for, from what I’ve read, he also appears kind and wise.

As a model for behaviour, Dale Carnegie points out Lincoln’s humble and kind approach several times in his awkwardly titled book, How to Win Friends and Influence People.

Apart from highlighting the value of a sharp axe to cut down trees efficiently*, my favourite words from Lincoln are:

This quote, or at least sentiment, was also a favourite of the legendary American basketball coach John Wooden. He would use it to help players stay focused on training even when they weren’t playing. If a player isn’t ready when the chance comes, they may not get another anytime soon.

Lincoln’s simple statement echoes some of my other favourite advice, that is surprisingly hard to follow, in:

• “The time to fix the roof is when the sun is shining,”

• the Chinese proverb to “Dig the well before you are thirsty,” and

• Louis Pasteur’s wise words, “Chance favours the prepared mind.”

My experience has taught me that I can’t predict my future. I also don’t know what chance meeting will lead to my next opportunity, or what bit of work will turn out to be the one that I’m most grateful for later.

I take from Lincoln’s quote:

• Work hard.

• Do my best.

• Stay humble.

• Prepare if I can.

• Look out for opportunities.

• Don’t rush it. Be patient.

• Don’t be too hard on myself if things come slowly or not at all.

The universe doesn’t owe me anything. But if I study and get ready, if something does come my way, I’ll hopefully be able to make the most of it. Or at least I’ll try to.

What do you take from it?

Related Ideas to Study and Get Ready

Also see:

• Sharpen the saw

• Everything is aiming

• The Pomodoro Technique and the importance of breaks

• Hitched to everything else in the universe

• To scale, first do things that don’t scale

• Replicate then innovate

• The upward spiral

• And above all, never give up

• Unknown unknowns

Notes on the quote

As with most old quotes, it seems to exist in myriad slightly different forms. I like the one here, but I’ve also seen it as:

• I will prepare and someday my chance will come.

• I will study and prepare myself, and someday my chance will come.

• I will study and get ready and someday my chance will come.

• I will study and get ready and maybe my chance will come.

• I will prepare and some day my chance will come.

According to Wikiquote, this quote was cited in
“Steps Upward in Personality: What Kind of Person Do I Want to Be?” (1931) by Laura Haddock, though I have failed to get hold of the original. Lincoln died in 1865, so I guess the precise words he used may be lost to time in any case. If you know of a reliable source, please let me know.

*Another famous quote from Lincoln: “Give me six hours to chop down a tree and I will spend the first four sharpening the axe.”

Curious about the drawing process? Here you can see my many mistakes, and redos on the way to something where I had to tell myself to stop.

Read more

Listen on Spotify · Apple podcasts · YouTube · Online

Well, we thought, if this 78th(!) episode doesn’t make this podcast an overnight success, nothing will 🥁

I really enjoyed the most recent episode of the podcast talking about this quote from one of the lesser-known Twitter cofounders, Biz Stone. It hit home well enough for me to sketch it.

I read Biz Stone’s impressive story in his book Things a Little Bird Told Me.

Now is also a good time to try the podcast, as we turned all the ads off not too long ago. If you have a listen, I hope you enjoy it, too.

With co-host Tom Pellereau an entrepreneur, and me having spent 13 of the last 15 years at startups I have a few sketches about entrepreneurship. Here are a few of my favourites.

Subscribe now

• Optimism bias

• Starting a company

• To scale, first do things that don’t scale

• Altruism and ambition

• When there’s a gold rush, sell shovels

• Vitamins and painkillers

• The Golden Circle

Hello,

Last year I gave a talk on Sketchplanations at the Sketch Your Mind Conference that was also visually recorded by Oliver Caviglioli. If you’re interested in a bit of the backstory of Sketchplanations and some of the lessons I’ve learned along the way you might enjoy it (1hr, fair warning =).

Zsolt Viczián the organiser made a hilarious and so impressive soundtrack for the session (using Suno) that keeps getting stuck in my head. A Sketchplanations song no less:

This week a sketch on an important feature of our oceans and a couple of brilliant short videos to watch.

Have a great week,

Jono

Subscribe now

Perhaps, like me, you’ve tried diving down towards the bottom of a lake and noticed how after the first few metres, the water quickly drops in temperature. It has been a personal joy to test this in mountain lakes. Even just a few metres down, the water can be much colder than at the surface. This temperature gradient is a thermocline.

In the ocean, the thermocline is the zone below the surface mixed layer where water temperature decreases rapidly with depth. Because cooler water is denser than warmer water, the deeper water is typically denser than the warmer surface water.

The thermocline tends to have a greater temperature difference in tropical and temperate latitudes, and in the summer, when the surface layer is heated more. In the polar regions, thermoclines are much weaker.

Thermocline comes from thermo-, for temperature or heat, and -cline for slope, lean or bend—along with incline (bend towards), decline (turn aside), recline and others.

Thermoclines and Ocean Layers

Changes in temperature, salinity, and density lead to layers in the oceans. Ocean layering has important and far-reaching effects. Deep water may be doing something quite different from water at the surface. And areas where density causes water to rise or sink help drive ocean currents. In some cases, cold water at the bottom may be travelling in one direction, while surface water driven by winds may be travelling in the other direction.

NASA Goddard created a beautiful visualisation of ocean currents at different layers that’s well worth a 5-minute watch.

The three main ocean layers are the surface layer, sometimes known as the mixed layer, the thermocline, and the deep ocean.

• The surface layer gets heated by the sun. Mixing by winds and waves distributes the heat.

• Underneath, the thermocline is where temperature changes significantly with depth. The thermocline usually begins tens of metres below the surface and can extend to around 1000 m.

• In the deep ocean, at the bottom, temperature and salinity tend to change little. Most of the oceans’ water is down here.

And sea ice, being less dense than water, floats on the surface.

Haloclines and Pycnoclines

Also affecting ocean layering is salinity—how salty the water is. Salty water, as well as colder water, is denser than fresh water and so will tend to sink beneath it.

Ever since the incredible “underwater lake” in BBC’s Planet Earth, I’ve been meaning to sketch a halocline, the change in density when fresh and salt water meet.

Fresh water entering the North Atlantic from Greenland’s ice sheets reduces the density of surface waters. This may, in turn, weaken the sinking that helps drive major ocean circulation patterns.

A pycnocline is a density gradient, often caused by changes in both temperature (thermocline) and salinity (halocline).

Related Ideas to Thermocline

Also see:

• Know your poles — polar bears or penguins?

• Why ice doesn’t sink

• Topography and bathymetry

• Mirage — light bends as it passes through air at different densities

• Moon pool

• Latitude or longitude

• Buoyancy — how mega ships float

• Parallax — different layers moving at different speeds

Once, when swimming across the stunning Lake Sils in the Engadin Valley in Switzerland, an upwelling of ice-cold water from the bottom of the lake took my breath away. Just when I had decided that I couldn’t swim further, I arrived out the other side of the cold water back into the, relatively, warmer surface water. I thanked my lucky stars.

Thermocline can refer both to a temperature gradient in water and to the specific ocean layer where that gradient is strongest. I’ve tried to discuss both here, not just the layer.

I created this sketch for a series on oceanography with the brilliant team at the American Meteorological Society.

Hello! A fun geography-related sketch this week. This is a real thing.

And this week had a lighthearted podcast episode—Rule number 1 of indoor games: play until something gets broken.

Have a great week!

Jono

Subscribe now

What do you get if you have a lake on an island with an island on it? A recursive island.

Visual recursion happens when something contains a smaller version of itself—a pattern within a pattern or a scene within a scene.

A recursive island is a geographical version of this: an island, within a lake, which itself is within an island. Kind of like a nested island, or perhaps an island squared.

But it needn’t stop there. In the Philippines, on the large island of Luzon, is Lake Taal, which fills an old volcanic caldera. Lake Taal has an island called Volcano Island. On Volcano Island is a small crater lake. Inside the small crater lake is a small island called Vulcan Point.

Therefore, Vulcan Point is:

1. an island in a lake
   Vulcan Point, within Taal Volcano’s crater lake

2. on an island in a lake
   Volcano island in Taal Lake

3. on an island
   within Luzon in the Philippines

We can think of these as orders. An island in the ocean is the first order. An island on a lake on that island would be second-order. An island in that lake would be third order. That makes Vulcan Point one of the few third-order islands in the world.

Canada, with its vast archipelagos and watery lowlands, seems to have an abundance of higher-order islands. You can zoom in and out to explore some on Google Maps.

Stream Order

Thinking of islands within islands as “orders” is similar to the Strahler stream order used to classify rivers.

A single new stream straight from the source is first order. When two first-order streams meet, they form a second-order stream. Larger rivers accumulate higher orders as more streams combine. This can continue all the way up to the mighty Amazon, a 12th-order river.

Related Ideas to Recursive Islands

Stream order was my first attempt at creating a gif to explain something, and honestly, it didn’t work great. Too slow! (be patient if you’re looking at it)

Also see:

• The Droste Effect

• Volcanic Explosivity Index

• The Coastline Paradox

• The three tallest mountains

• Heat islands are a very different type of island

• Point Nemo, the furthest you can be from an island

• Double-landlocked countries

• Isochrones, kind of like travel time islands

• Red volcano, grey volcano

Wikipedia has a table listing islands in lakes on islands in lakes on islands...

I learned that the traditional definition of an island is land surrounded by water that is not a continent. By that definition, Madagascar and New Zealand count as islands, while Australia doesn’t.

HT to my cousin for first sharing recursive islands with me many years ago.

If you made it this far, here’s a timelapse of sketching this. I tried two different options when drafting, several different highlights that I ended up leaving out and just generally fiddled around rather a lot:

Hello!

Brendan Leonard, who creates the brilliant , asked me what my 5 favourite creative works were. Completely bungling my intro aside, it’s a brilliant question. Why not ask yourself, friends and family the same? You can listen, and find out what I went for, here (or on YouTube):

Semi-Rad

My Favorite Things Episode 13: Jono Hey

The concept for the My Favorite Things podcast is simple: Each guest compiles a list of five books, movies, music, art, and other creative works that have helped shape their lives. My guest for Episode 12 is Jono Hey, designer, writer, illustrator, creator of…

Listen now

a month ago · 3 likes · 1 comment · Brendan Leonard

I like paradoxes. This week’s sketch is a famous robotics paradox.

Have a great week,

Jono

Subscribe now

About Moravec’s Paradox

In his 1988 book Mind Children, Austrian robotics researcher Hans Moravec, wrote:

“…as the number of demonstrations has mounted, it has become clear that it is comparatively easy to make computers exhibit adult-level performance in solving problems such as intelligence tests or playing checkers, and difficult or impossible to give them the skills of a one-year-old when it comes to perception or mobility.”

This surprising pattern became known as Moravec’s Paradox, the idea that machines often do well at things people find hard, and do poorly at what is easy for us.

As classic examples:

• We consider chess grandmasters to be among the most intelligent people on the planet, yet computers eventually triumphed over them.

• * A young child can (in principle) place raspberries gently on a plate, stack glasses in a dishwasher, read a friend’s emotions, crawl up some stairs, or play with a dog, and yet our machines still find this hard.

It sounds rather reasonable.

That Google Maps can, in seconds, provide me with an optimised walking route between places hundreds of miles apart is a source of consistent amazement for me. Yet it’s challenging for a self-driving car to understand if a traffic official is gesturing for it to slow down, something I find effortless.

Yet some of the traditional examples of Moravec’s paradox now feel dated. As Hans said, “Unfortunately for humanlike robots, computers are at their worst trying to do the things most natural to humans, such as seeing, hearing, manipulating objects, learning languages, and commonsense reasoning.” Machines have now made great strides in most of these.

Princeton Computer Science Professor , thinks Moravec’s Paradox is neither useful nor true.

Yet UC Berkeley Robotics Professor Ken Goldberg cautions that robotics still faces a “100,000 year data gap.” He explains that the extraordinary capabilities of models that produced the AI capabilities we all know are created from the internet-scale amount of image and text data we already had available. He calculated that it would take a person 100,000 years to read or view all the data that we had ready to feed into our AI models.

In contrast, we have comparatively little data ready to use for applying similar techniques to, say, robot dexterity. He advocates an approach where we make robots that are functional enough to be useful, and use these for data collection to improve, much as Waymo have been doing with self-driving cars for over 15 years.

What do you think?

Related Ideas to Moravec’s Paradox

Also see:

• The Automation Paradox: the better the machines get, the more we struggle when they fail

• Fauxtomation: claims of automation for work actually done by people

• Cognitive offloading: delegating our thinking

• Jevon’s Paradox: Fuel efficiency gains tend to increase, not decrease fuel use

• Chaos monkey

• Looking under the Lamppost

• More paradoxes

Ken Goldberg’s view on robotics at UC Berkeley News, Aug 2025

And ICMYI, insightful chat about leadership and life with submarine captain David Marquet:

Sketchplanations

Nuclear Submarine Captain David Marquet on: Push Authority to Information

“Live a big, interesting life. Think, share your thoughts. We need a world like that. We don’t need a world with a bunch of bobbleheads doing what they’re told by so-called experts…

Read more

a month ago · 41 likes · 6 comments · Jono Hey

Made it this far? Here’s a timelapse of creating this sketch for paid subscribers:

Read more

“Live a big, interesting life. Think, share your thoughts. We need a world like that. We don’t need a world with a bunch of bobbleheads doing what they’re told by so-called experts.”
— Former nuclear submarine captain, David Marquet

I was thrilled to have nuclear submarine captain and student of leadership, David Marquet, join us on the podcast for last week’s episode.

We discussed one of my favourite leadership ideas: don’t just push information to authority, push authority to information.

🎧 Listen to the episode: Spotify · Apple · YouTube · website

True to expectation, David was wise, funny and brought his incredible experience to share.

Some things we covered:

• Why leadership is closer to a practice—like learning a language or learning to swim—than a concept

• Why it still has echoes of the Industrial Revolution and the fundamental shift from Leader-Follower to Leader-Leader

• Why giving your people decision-making authority is one of the best things you can do as a leader

• How the simple step of distancing yourself from the situation helps lead to better decisions

• A bobblehead image that I’ll never forget

• A simple way to encourage yourself to invite feedback

• How to be somewhere else, be some other time, and be someone else when coaching yourself.

• The top submarine films—as rated by a submarine captain =)

I’ve read two of David’s three books:

Turn the Ship Around!

An account of his experiences transforming the submarine USS Santa Fe from the lowest-performing to the best. Not only do you get to hear about what it’s like to run a nuclear submarine, but you get to learn the changes and mistakes David made as he instilled a new leadership ethos. What’s more, the improvements lasted for years after he left the ship.

Distancing: How Great Leaders Reframe to Make Better Decisions

I recently read his latest book, Distancing, which covers simple strategies for making better decisions by distancing yourself from the situation—be somewhere else, be some other time, or be someone else.

He’s also written Leadership is Language

David joined in person for the podcast, which was a treat. I’ve got to admit I felt a little intimidated meeting a submarine captain =)

I had so many questions that I didn’t get to ask, alas, including about the submarine shower.

I hope you enjoy listening and learning from him.

Subscribe now

About the sketch

I first came across David’s ideas watching a talk he gave many years ago.

He shared many simple ideas and anecdotes that I tried to apply in my own leadership. Top among those was this idea of not having leaders be the bottleneck of authority and making decisions, but instead giving authority to the people who already have the information.

I learned more about how to apply this in Turn the Ship Around! You can’t just give away Control as a leader without also establishing Competence and Clarity.

Control — Shift authority to the people closest to the work

by establishing

Competence — technical mastery, training, understanding the wider system

Clarity — understanding purpose and intent

If you try to push all authority to information without competence and clarity you will trip up, as David shares through the missteps shared in his book.

I liked the symmetry of the simple principle and tried to capture it in a sketch. The bosses, who tell you what to do, vs leaders who inspire and guide what you do is my unendorsed addition.

The pleasing symmetry btw is chiasmus (which we also covered in the podcast episode with Mark Forsyth).

This sketch was the first principle of three that I included in my essay on leadership in the Big Think.

I like this sketch because I think it gets the simplicity of structure and economy of words just about right. There are a few sketches that I regularly refer back to when planning new ones. The simplicity of structure in this sketch is one of those. Of course, much of that is down to the simplicity and clarity of David’s principle.

Some other popular leadership sketches to explore:

You can find all of these on the Sketchplanations site

Hello,

Well, the last few topics have been more serious than usual and what with everything else here’s something lighter.

1. I have three new tracks out on streaming services (Spotify, Apple, YouTube Music) and now on Bandcamp, too: I Belong and 2 versions of The Space Between. They’re rather peaceful, I think. More about these later.

2. What with the Artemis II excellence, I shared some moon sketches this week: moon sketches on Instagram

3. Maybe you, like me, heard that there are no words that rhyme with orange or chimney. From time to time, I’ve wondered at this. For orange, I got as far as lozenge, which I don’t think is bad, but beyond that, it’s not clear to me what works. Eminem put me straight.

Wishing you a great week,

Jono

Subscribe now

In a short segment on the 60 mins show, Eminem said,

“People say that the word orange doesn’t rhyme with anything, and that kind of pisses me off because I can think of a lot of things that rhyme with orange.”

“If you’re taking the word at face value and you just say orange, nothing is going to rhyme with it exactly. If you enunciate it and you make it more than one syllable, or-range, you could say:

I put my orange, four-inch door hinge in storage and ate porridge with George.”

I love that the general incompetence at rhyming kind of pisses him off.

It’s all in how you say it. So, if you need practice (or convincing) before relating this to anyone else, I recommend watching the 2-minute clip yourself.

With how easy he makes it I figured I should try with chimney. I got this far:

Climbing the chim-ney, in the city, I scraped my flimsy, right knee, when I saw a big bee, getting all filthy, and making me dizzy.

Hmm. Eminem is impressive. Got any good rhymes for chimney?

Related Ideas to Rhyme with Orange

Also see:

• The rhyme as reason effect

• Ablaut reduplication (flip-flop, not flop-flip)

• Chiasmus — Fail to prepare, prepare to fail

• Pleonasm — An unexpected surprise

• Ordering adjectives — a great green dragon, not a green great one

• Collective nouns — a shush of librarians

• Everyone’s a geek about something

• And related to oranges somewhat: Mandarins, clementines, satsumas, tangerines??

PS if you haven’t listened to it, you might enjoy the podcast episode we did with Mark Forsyth on all things language like these: Ordering adjectives with Mark Forsyth

Hello!

Today’s email is a little longer than usual—though I like it and it has pictures. Feel free to just stay for the sketch as always.

Jono

The McNamara Fallacy is a belief in easy-to-measure quantitative metrics at the expense of ignoring hard-to-measure qualitative factors.

Robert McNamara was president of Ford Motor Company and later the Secretary of Defense for the USA during much of the war in Vietnam. He was highly intelligent and excelled at dealing with data and using it to inform strategy.

Coined by social scientist Daniel Yankelovich, the McNamara Fallacy, also called the Quantitative Fallacy, involves:

• Prioritising easier-to-measure quantitative metrics and

• Disregarding hard-to-measure qualitative metrics as unimportant

The fallacy can progress as follows:

1. Measure what can be measured

2. Disregard what we can’t measure

3. Assume what cannot be measured is not important

4. Conclude that what can’t be measured doesn’t exist

In the words of Yankelovich:

“The fallacy is: If you’re confronted by a complex problem that is full of intangibles, you decide to measure only those aspects of the problem that lend themselves to easy quantification, either because you find other aspects difficult to measure or because you assume that they can’t be very important or don’t even exist.” …

“It is a short, fatal step from the statement, ‘There are many intangibles and imponderables that we can’t put on our computers,’ to the statement, ‘Let’s measure what we can and forget about the intangibles.’”

Yankelovich cites working with Ford during McNamara’s time and sharing research that included both quantitative and qualitative factors. As the research was assessed, the qualitative data on the meanings people gave to small cars were discarded, and the less significant quantitative and demographic data were retained.

Examples of the McNamara Fallacy

I first learned about the fallacy from a reader’s article about one of the easiest to measure aspects of a bike: its weight. All things being equal, we’d probably prefer a lighter bike, but other aspects like maintenance, reliability, and handling are important yet harder to measure, report on and compare. As a result, weight often comes to the fore at the expense of the others.

Other examples might include:

• Perhaps your hiring time is down, but how is the fit of the people you’re bringing in?

• Maybe more people are visiting your website, but they aren’t the right people for your service.

• We can calculate a country’s GDP, but GDP doesn’t account for human labour without a monetary transaction—like a home-cooked meal—and vital work done by nature, like filtering water, sequestering carbon, or lifting spirits.

• If food in a can gives you all the nutrients you need, what are you missing by skipping family meals?

A commonly cited example of the McNamara Fallacy is the US military’s approach to measuring progress in the Vietnam War.

The McNamara Fallacy and the Vietnam War

As the US Secretary of Defense from 1961–1968, McNamara employed similar techniques to those he had used successfully in business contexts to assess the progress of the war in Vietnam.

If wars were won by inflicting damage on the enemy, then metrics measuring the damage inflicted should be decent proxies. In particular, assessing body count evolved to be the primary measure of progress.

Reliance on purely quantitative metrics had significant shortcomings. In this context, enemy body count was more easily quantified than their morale, political support, or resolve to defend. Because of the interest in this measure, many officers believed that it was also often inflated (see Goodhart’s Law and Campbell’s Law below).

Measuring the tons of explosives dropped is easier than measuring the reduction in capabilities they caused. Knowing the number of troops you have is easier to measure than the abilities of those troops.

According to the numbers, the U.S. was winning the war, yet it failed to overcome the resistance of North Vietnam.

Related Ideas to The McNamara Fallacy

An over-reliance on quantitative metrics quickly leads to several other related problems to deal with:

Goodhart’s Law: When a measure becomes a target, it ceases to be a good measure.

For example, assessing the progress of war on the numbers of enemy dead may lead to increased killing to inflate numbers. Or pinning a bonus on review ratings may lead to fake reviews.

Campbell’s Law: The more a metric counts for real decisions, the greater the pressure for corruption, and the more it distorts the situation it’s intended to measure.

For example, if reducing crime rates matters for law enforcement jobs, it creates an incentive to under-report cases or downgrade crimes.

The Streetlight Effect: Looking where it’s easiest to look, rather than where it matters. Also known as the drunkard’s search or looking under the lamppost, the Streetlight Effect is named after the economists’ joke of a person scrabbling on the ground for their car keys under a street light. When asked where they lost them, the person says they dropped them “over there,” but the light’s much better over here.

For example, optimising an existing product because it is known and does well, rather than working on an uncertain new product.

You Get What you Measure: The instrument you use to measure affects what you see.

“For example, in school it is easy to measure training and hard to measure education, and hence you tend to see on final exams an emphasis on the training part and a great neglect of the education part.”—Richard Hamming

The Cobra Effect: When an implemented policy backfires causing the opposite of the intended outcome. Named after a British attempt to reduce cobras in Delhi by introducing a bounty on dead cobras. Seeing the lucrative bounty, people started farming cobras thereby increasing their numbers.

For example, the Streisand Effect is a well-documented case of a cobra effect when Barbara Streisand tried to suppress images of the coast that included her house. The attention drawn to her attempts to suppress the images brought thousands of people to look at them who otherwise would never have considered it.

And all of these are examples of the broader Law of Unintended Consequences, which comes from trying to regulate a complex system with a simple system.

If the ideas above aren’t enough, you might also see:

• In theory, practice is the same as theory, but not in practice

• All models are wrong but some are useful (from last week)

• Reliability vs validity: You can hit the target but miss the point.

• Analytics maturity

• What gets measured gets better

• The map is not the territory (no sketch!)

For a super discussion on the measurement of all sorts of things, including acute (being run over by a bus) and chronic risks (smoking), I recommend the fun podcast episode: Microlives & The Art of Uncertainty with Sir David Spiegelhalter

The article about bike weight is: The McNamara Fallacy and Bikes by Peter Verdone

Daniel Yankelovich, who named the McNamara Fallacy, stressed no disrespect to “one of our most distinguished citizens,” Robert McNamara, “a brilliant and dedicated man who brings a vital intensity to bear on his work.”

Some of the complexities of the war and McNamara are covered in the Academy Award-winning documentary The Fog of War, which makes fascinating and, at times, uncomfortable viewing.

Hello!

Sticking on the model theme from last week, here’s a sketch I started a year ago.

Wishing you a great week ahead,

Jono

PS

I have a new track releasing from today: “I Belong”. Look out for it on Spotify, Apple or others.

One of my favourite statisticians’ quotes is British statistician George Box’s point that:

His point, as I understand it, is simply that any model is inherently a simplification and approximation of reality. It will never capture reality in its entirety.

This applies to your formula of expected revenue and expenses that you drag down cells in a spreadsheet. And it applies to our largest, immensely complex, weather and climate models with millions of individual variables and data points. They can never be complete. And while we should keep this in mind for the limitations of all our models, forecasts, predictions and explanations, it doesn’t stop them from, many times, being useful.

While you can, and many people do, argue with the premise of models being “wrong,” I like the quote because it reminds me to be humble and duly sceptical of any models I read about or put together. While their accuracy varies enormously, they are all fallible.

It also reminds me that any model has a purpose—emphasising some features of reality and ignoring others.

On Maps

While a map is not a model in the statistical sense that George Box likely had in mind when he uttered the phrase, I find that maps are a great example of selective focus.

In the sketch, you can see the messy complexity of the world, the traditional map where buildings and roads become marks on paper, and the simplification of a bus route’s sequential stops.

Other times, maps may focus on:

• Human geography: streets, buildings, shops

• Tourist attractions

• Relief, elevation and geographic features

• Water courses and watersheds

• Traffic and travel times

• Political boundaries

And any number of other things. They are all models representing some aspects more accurately at the expense of others. As the saying goes, “The map is not the territory.”

Other Examples

Some other examples of simplified, yet still useful models.

• Weather: imagine trying to condense all the complexities of a day’s weather in the UK into a single icon. Not so easy. And yet, it can still help you decide if you should bring an umbrella or postpone a sailing trip.

• The Mercator projection: Useful for sailors. Massively distorted at high latitudes.

• Naismith’s Rule: for estimating walking time in the mountains based on distance and elevation

• An orthographic drawing of a house or product: may highlight relevant features for construction—wiring, plumbing, structural integrity—while ignoring textures, colours, imperfections or cost.

• The Bohr model of the atom: electrons orbiting like planets around the nucleus. Imperfect, but useful.

• Normal distributions: such as you might see in people’s height, are rarely, if ever, perfectly normal and yet can still be useful approximations.

• Supply and demand curves: approximate buyer and supplier behaviour while making assumptions about rationality and the availability of information.

• The London Underground map: famously simplified to perpendicular and angled lines, transforms travelling on the tube and confuses walking distances.

A model is a tool, and its usefulness depends on what you are trying to do. If you’re trying to plot courses on a flat map, then the Mercator projection is extremely helpful. If you’re trying to understand how large Greenland is compared to other countries, then it’s misleading.

Box advocates using economical models that allow us to interrogate practice while staying aware of where they may be importantly wrong.

It’s not lost on me that I present a lot of simpler models than reality in Sketchplanations. I think that’s because, when we consciously acknowledge their imperfections and limitations, a good model, like a good framework, can be just so helpful. As Larry Keeley said, “Building a good framework is like cutting cubes out of fog.”

Related Ideas to All Models are Wrong

Also see:

• Without data, you’re just another person with an opinion — W. Edwards Deming

• The Metrics Onion

• VUCA: Volatility, Uncertainty, Complexity, Ambiguity

• Sneaky averages

• Measures of central tendency: Mean, median, mode

• Correlation is not causation

• In theory, practice is the same as theory, but not in practice.

• Sampling bias

• Chihuahua syndrome

• Science and engineering: what’s the difference?

• The mathematics of everyday life

Rick Wicklin wrote a helpful write-up of his investigations on the quote: Did George Box say, “All models are wrong, but some are useful”? (Spoiler: Yes)

This week Rob, Tom and I dove into Accuracy vs Precision, which, surprisingly to me, are not the same thing.

Subscribe now

Listen on: Apple · Spotify · YouTube

Or, as an experiment, right here:

Accuracy is true to intention and precision is true to itself I learned from Simon Winchester’s book, Exactly: How precision engineers created the Modern World. Huge improvements in the precision of our production led to all the wonders of modern manufacturing where we expect everything to be near enough identical every time. More in the podcast.

Should they be useful, I made some blank versions of these with the blue and on white that you can use to fill out your own icebergs: Iceberg model templates

Hello!

A huge thanks to my new and paid subscribers and patrons. You enable me to do this each week. And, did you know, I handwrite 95% of my sketches but I made a Sketchplanations font from my handwriting which you can buy for your own fun projects.

This time, a classic: a model from systems thinking, psychology, culture and a multi-purpose metaphor.

Wishing you a great week,

Jono

Subscribe now

About the Iceberg Model

Icebergs make powerful metaphors because much of what matters is hidden.

Despite knowing the maths, it’s still genuinely surprising and sometimes hard to believe that 90% of an iceberg is beneath the surface.

Icebergs are, therefore, a super metaphor for when visible outcomes are shaped by unseen forces. And where we see just a small amount that is built on top of a whole lot that’s out of sight. Even better if this “whole lot more” is unexpected. In my experience, this fits a lot of things. It’s a fair representation, for example, for the unseen work that goes into near enough anything.

Icebergs have been mobilised in the name of better understanding psychology, culture, and, in this case, systems.

I like the model because it prompts us to question what could be “under the surface” and, in terms of observed behaviour, what’s driving what we see?

This version of the iceberg model is adapted from the work and teaching of the systems thinker Donella Meadows and the Academy for Systems Change.

Layers of the Systems Thinking Iceberg Model

The four layers of this iceberg are:

Above the surface

Events

What is happening? What are the facts? What behaviours do you see?

Below the Surface

Patterns

Are the events connected by trends over time? Do events relate to each other?

Structures

What influences the patterns you see? Think about routines, incentives, environments, organisations, policies, and rituals.

Mental Models

What are the values, assumptions and beliefs people hold that shape the system?

The deeper down you go, the more leverage you have to create change. For example, changing someone’s attitudes and beliefs about eating will have far-reaching effects on a person’s behaviours around meals.

Example of the Iceberg Model

What might this look like in practice?

Event

A child steals their sibling’s toys.

Patterns

• The behaviour only started recently.

• It tends to happen after swimming lessons or before bed.

Structures

• They’re tired and hungry after swimming, lowering their tolerance and patience.

• Parents are often busy preparing dinner.

• The younger child gets more attention.

Mental Models

• Older children are expected to be more self-sufficient.

• “When I act up, I get attention.”

• Overscheduling activities.

Or

Event

A colleague is late to a meeting, again.

Patterns

• They used to be on time for meetings.

• Being late to the first meeting in the morning is most common.

Structures

• Meetings rarely start on time.

• There are no consequences to being late.

• Some people have many meetings, others have few, and so don’t pay close attention to the calendar.

Mental Models

• Don’t value the meetings.

• They don’t understand the impact it has on others.

• Promptness is respect and required vs promptness doesn’t matter if you get results.

In each case, looking below the surface reveals what’s really driving the behaviour.

Many solutions focus on the events. But lasting change often comes from addressing issues below the surface.

Related Ideas to the Iceberg Model

Systems, thinking and systems thinking:

• Pace layers

• Rich pictures

• 9 Windows

• Powers of 10

• The S-Curve

• Data - Information - Knowledge - Wisdom

Icebergs:

• Overnight success

• Iceberg orientation — for the 90% bit

• Buoyancy

I created this iceberg model illustration as one of a series of visuals for about Systems Thinking.

In October last year, over the course of about a week, I built a Chrome Extension with the help of AI: Sketchplanations New Tab

Chrome extensions can be added to the desktop Chrome browser to do useful and fun things. I personally hate it when I open a new tab, and browsers try and throw news articles, stocks, and gossip at me. And I’ve enjoyed extensions that show me nice photographs or teach me something. I’m always thinking of how to better share sketches from the archive with people new to Sketchplanations, and I had the idea of building an extension that would show you a sketch from the site in each new browser tab. The only problem was that I had no idea how to build a browser extension.

This is the story of building that extension and what I learned using AI to do it. Feel free to skip if coding with AI is just not your thing.

Background: I was not Starting from Zero

First some background. Though I’m not a developer, I’ve written code since my teens, at University, in my postgraduate degree and for my own personal sites. I’ve also worked in product and design at 2 tech startups for 15 years, collaborating with developers daily. So I wasn’t starting from zero. At the same time, I’m orders of magnitude less experienced with code than the talented developers I worked with.

Over the past few years, I’ve been adding to and modifying the Sketchplanations site, first with the help of CoPilot in VS Code and, more recently, with Cursor. I bought paid plans for both. I also pay for ChatGPT.

Here are ten things I learned while coding this extension with AI—part experience, part lessons learned, and part practical advice if you want to build something yourself:

1. You Just Have to Think to Ask

2. Going from 0 to 0.7 is Fast. Going from 0.7 to 1.0 is Still Slow

3. Plan Before Building

4. Styling and Layout Sucks Time

5. Agents Don’t Work for My Model of Working, Yet

6. Finish With Tidying Questions

7. Use the AI to Learn

8. Use Good Product Development Practice and Break Features Down

9. Use the Knowledge You Have to Ask About Improvements

10. Don’t Underestimate Publishing and Release

1.
You Just Have to Think to Ask

One afternoon with nothing pressing, the idea of the extension came to me again, and, on a whim, it occurred to me to ask ChatGPT if it could be done, and then if it could create it. About three minutes later, I had a zip file to download that I could unzip and install in Chrome as a first draft.

I knew nothing of what was involved in creating an extension, what language they were built in, special instructions, how to package it, install it, nothing. And yet a few minutes later, I had a working extension. Incredible.

I could have done this six months earlier. I knew nothing about what was needed to build an extension—I just had to think to ask.

2.
Going from 0 to 0.7 is Fast. Going from 0.7 to 1.0 is Still Slow

The first draft extension was amazing, but it needed better functionality and design changes.

So I asked ChatGPT to make some changes. Each time it took a minute or so and then gave me a new .zip file to download.

Making these small changes with ChatGPT started to take time: writing what I wanted, downloading, extracting, testing, writing lengthy feedback, waiting for new files, downloading, extracting, testing...

At one point, something broke, and it stopped working. Asking it to undo provided another version that didn’t work, so I went back to a previously downloaded version and tried again. There was a lot of “It still doesn’t work.” I’m afraid to say I can get rather annoyed with our AI assistants.

The quick draft extension worked by checking an existing endpoint (like a service you can use) that an actual developer had created on my site to serve a random sketch, then scraping the page (reading the page’s code to find the information it needed) that loaded. I know from experience that web scraping is not very reliable—small changes to the page will break it, and it’s not very efficient for the small amount of information the extension needs: primarily a URL for the image.

So I switched to the Sketchplanations website codebase and used Cursor to create a new API endpoint just for the extension, returning just the information it needed. That required managing two codebases, so the extension would ask for a new sketch, and the Sketchplanations site would send it.

Because my first 365 sketches were all one a day in the first year, the older sketches are generally messier. I spent some time asking AI for simple ways to tweak the API response to skew towards newer sketches. Cursor was very smart at doing that.

Once this basic framework was in place, I still spent many hours, if not days, working on layout, styling, and additional features.

So, though AI cleared the first hurdles in a giant leap, getting over the finish line with a production-worthy product still took a long time.

3.
Plan Before Building

If you tried some coding with AI in the past year or so, you might have experienced making a suggestion, or even just asking a question, and the AI jumping on that and busying itself making code changes throughout your codebase. Undoing changes I have found, unless you have a clean point to reset to (a latest git commit or pull request), is not always easy—often unneeded code sticks around.

Cursor Plan Mode lets you share and discuss your ideas, and then Cursor will come up with a development plan. For any new feature, spending some time working on that plan, asking questions of it, considering edge cases (or asking Cursor to), and generally refining it before building was very worthwhile for me.

Iterating on a plan in plan mode helped me with everything that’s critical in software development that isn’t actually writing code. It helped me:

• Decide what I want

• Understand the approach and changes that were needed

• Learn how something is built

• Learn what belongs in a set of changes and what is best left to future changes

• Query the AI’s first approach and sometimes tweak it to match my future plans or the current codebase

• Minimise big sets of code changes that were hard to undo

4. Styling and Layout Sucks Time

One area where the AI really excels technically is presentation and layout. Its knowledge of CSS (Cascading Style Sheets)—code instructions for how things should look—is remarkable. Despite having worked with CSS for years, the AI regularly used functions and features that I didn’t even know existed.

However, the joy can be short-lived.

Good design requires considering multiple use cases, user journeys and screen sizes. You don’t expect a page to look the same on your desktop as on your phone. You might get lucky and, with a prompt, get a fully usable responsive design. But my experience is that you will need to test at different sizes, and you will likely need adjustments at each.

Getting this right was time-consuming and fiddly, even when working with a CSS genius.

Small changes to one area break another, and fixing that area breaks another. The AI often wants to write remarkably complex, interdependent rules that are very quickly hopeless to follow. It’s partly the nature of CSS with cascading and overlapping rules that, unless you’re careful, can quickly tie you in knots. Periodic requests to ‘Simplify and remove unused rules’ helped minimise clutter and reduce the risk of errors.

Good design also includes a lot of things that, as a user, you don’t tend to think of at first. Buttons and links might have hover, clicked, active, visited, and inactive states as well as transitions. They may behave or look differently at different screen sizes—changing size or hiding themselves in a menu, for example. They may need to invert colours in dark mode vs light mode, or show up better against a background they now find themselves on top of. As with all design and development, these subtleties are easy to forget and underestimate.

All in all, even in my very simple application, working with the AI on styling using CSS was the most painful part of the process.

5. Agents Don’t Work for My Model of Working, Yet

Agents are a promise of incredible productivity, like having a team of people working for you. The idea is that you can set agents to work on tasks in the background while you get on with something else. In principle, that sounds amazing. In practice, I find it difficult to use productively.

First, don’t underestimate the time it takes to give an agent good prompts. It’s tempting to think, “Ooh, I wonder if the site could have different themes,” and then pop that into a prompt and let it have at it. But in practice, there are always more decisions to make, and as I start to describe what I want, I think of more questions or more details that I need to describe. To stick with the themes example, you will quickly find you need to answer:

• how many themes you’ll have

• what these themes will be

• how you’ll select these themes

• how will the controls change at different sizes

• how themes will interact with light and dark mode

• how themes should persist across sessions

• where that information will be stored

It’s why both designing and thinking carefully about what you want, maybe creating your own product requirements document, as well as using Plan mode before setting an AI loose, is really helpful.

In my experience, setting an agent running effectively is rarely something you can dash off effectively in a moment—at least if you want a useful outcome first time.

Second, I find that when I want to work on a task, I’m ready to work on it. My experience with agents was that they’d take minutes to work on something. That was long enough that I’d rather not sit there waiting, but also not long enough that I could make real progress on something else before it finished.

When I find the right time to work on a feature, I generally want to see it through, test, iterate, and get to the end, not pick it up again in the afternoon and try to remember what I was doing each time.

What worked best for me was to have a related task to work on, say writing the support page for the app, while an agent or the AI in Cursor was working away. That meant I wasn’t completely switching tasks and was still able to make some use of that time. It wasn’t that my time wasn’t well spent while waiting—the AI was doing incredible work for me on my behalf—but it sure didn’t feel so productive.

In general, working with AI coding felt like a lot of task switching and waiting. In contrast to actual coding, where your mind is fully engaged throughout, AI coding left me with lots of gaps to fill, sitting around, and then doing the grunt work of testing the output each time. I became the software tester, which, though I know it’s critical, is one of my least favourite jobs.

Of course, during all this, I get to direct what is happening, but as an intellectual exercise, it was surprisingly unsatisfying at times.

6. Finish With Tidying Questions

While it may look like everything in your new code is working fine, it was surprising to me that with a few more prompts I would almost always find things to improve and tidy. Why didn’t it find it before?

For significant changes, I developed a habit before committing and merging my work to ask several simple questions that invariably improved my code. These are the sorts of questions I would ask:

• Can you review all the changes and check that it’s ready for committing and that there is no unnecessary code?

• Please review the code for performance and security, and suggest any necessary or recommended changes

• Can you check that our latest changes follow best practices for the tools and frameworks we use?

Regularly, asking these questions found bits of code that the AI had added during our iterations and that were no longer needed. Other times, there were important security changes to make. Asking these questions in Cursor Plan (or Ask) mode also helped before acting on them because sometimes best practice is more complex than what I needed for my use case. Asking in Plan mode helped me understand the AI’s proposed changes and choose which to implement.

7. Use the AI to Learn

I can’t say that getting the AI to write all my code made be a better coder. But I did find a lot of value in an incredibly patient and thorough teacher whenever I wanted to understand any code or understand an approach to take.

I find the AI amazing at explaining to me what the code is doing. I made use of that regularly to make sure I understood the different parts of the application.

Simple questions like: “Why is this section necessary?” or “What is this section doing?” invariably gave me great explanations and, at times, by asking, prompted the AI to make improvements or simplifications. In this respect, I did improve my knowledge of software development, even if I didn’t work on my coding skills.

8. Use Good Product Development Practice and Break Features Down Small

I worked in Product Management—choosing what to build and getting it built—for many years. I found these same skills were useful when working on a solo project with an AI.

In particular, I made use of a technique I always advocate when building almost any software: breaking things down and working on smaller changes at a time.

Because AIs don’t have the same limitations we do in terms of short-term memory and cognitive overload, not to mention motivation, it’s very possible to set an AI the task of refactoring or rewriting an entire codebase. It will busily get stuck-in to the task of changing 1,000s of lines of code without batting an eyelid. What you’ll be left with might work, but even if it does, you will have no idea why or how it works.

If you really don’t care about what’s under the hood, then perhaps that’s fine for you. But if you want to understand how something works and have confidence that it’s fast, secure, and you can build on top of it, then it’s a little disconcerting.

The simple solution I found works best is to make sure I am breaking down my project into small changes and not combining a host of changes in one.

As an example, my extension does a few things:

• calls the API to load a random sketch

• displays the page with a chosen theme

• has a responsive layout, including putting the features in a menu at mobile widths

• has a way to set preferences for how often to load a sketch

• has a way to call a new sketch if you don’t want the current one

• displays a message if there is no internet

• displays a message if the API is down

• stores preferences and previous sketches locally so that it can load fast each time

• responds to dark and light mode preferences on your computer

• displays prints and podcast links for the sketch if they have them

• has a secret testing mode (Konami code) so I can test these messages

It’s quite possible, and tempting, for a first crack at the extension to give this as a specification and ask the AI to build it. But a more practical approach, with fewer headaches, is to take each of these in turn, starting with the most fundamental features and layering on additional functionality.

Each time you complete one of these features, conduct the review questions I showed above, thoroughly test it, commit the code, and start the next feature from the new base.

This approach has several benefits:

• Reliable reset points in case the next feature doesn’t work as planned, and the code gets into a mess

• Simpler testing each time, so you can be more confident that you haven’t broken existing functionality

• Reducing the chances of current code changes breaking something else you’re also working on

• Easier reviewing of the new code

• Easier to understand the changes and what the new code is doing

Basically, with the incredible promise of a genius coding assistant at your fingertips, it’s easy to want to shortcut the standard product development process. My experience is that doing so will slow you down and lead to frustration.

As the Navy Seals (or the hare and the tortoise) say, slow is smooth, and smooth is fast.

9. Use the Knowledge You Have to Ask About Improvements

While AI coding tools can, in principle, keep your entire codebase in mind when making changes, in practice, they don’t always do so.

It would often launch into a solution for the next feature or problem that worked for that case, but didn’t consider things like:

• how you’ve done similar things in other parts of your code

• making use of existing functionality

• using libraries already installed rather than finding new ones

Many times, I got a better solution when I specified to look at how something has been done in another place.

For example, I use Tailwind CSS, which provides great default typography styles. Very often, the first response wouldn’t use the default styles that come ‘out of the box’ and instead would, very effectively, create whole new styles. I often had to prompt to make use of existing functionality whenever appropriate.

Without regular prompting of this nature, the code would easily become bloated and messy.

10. Don’t Underestimate Publishing and Release

While this last point was true for launching a Chrome extension, I would say it’s generally true for software as a whole: don’t underestimate how long it might take for publishing and release.

Software, like this Chrome extension, is a product. It’s packaged, named, submitted to, and installed from a store. And it needs to be explained to potential users in words and images. There may be a review process—as there is with the Apple App Store and the Chrome Webstore—and there may be legal terms and conditions to figure out. A privacy policy, help documents, screenshots, support, regions, pricing, exclusions, announcements and marketing.

In short, there are many decisions to make for launching any product. Having a coding genius on your team is amazing. But right now, at least, it couldn’t do all the pieces I needed to get this into people’s awareness and installed in their browsers. It can help with all of these aspects, but it sure still feels like work to figure out and coordinate all this.

I still did all of this.

It’s not a drawback, just something that still needs considering.

---

Since I wrote the initial drafts of this article, coding with AI has continued to get more impressive and do more of the process for you at a higher standard. If you have an idea you want to try, my advice is to try it. Even if you don’t launch a product, you will surely learn a lot along the way.

I’m still sceptical of services that profess to launch a whole product for you from a single sentence. Perhaps the primary lesson is that much of the hard part of building software is still figuring out what you actually want. And you’ll probably still have to do a lot of that.

If you use Chrome and want to try the extension (and please give me feedback!) you can try it here:

👉 Sketchplanations New Tab

If you give something a try, I’d love to hear how you get on.

Have you had a different experience? Things I should learn? Let me know.

Subscribe now

Have you ever found something rather wonderful about a walk in a strong wind? You might appreciate the Dutch concept of Uitwaaien.

Uitwaaien is a Dutch word that means going out into the wind to clear your head.

Uitwaaien combines two words: uit, meaning out, and waaien, meaning “to blow”, as wind blows. Pronounced roughly as o-ut-vye-en.

Together, it means going out into the wind, often for a walk or bike ride, to clear your head and refresh your mind. Like getting an airing out, I picture it blowing your worries away. A breath of fresh air.

We like to go to the southwest of England in autumn and winter. A walk on the coast or up a tor in Dartmoor, getting battered around with a strong wind in your face pulls you into the roar and immerses you in it. It’s bracing and never fails to give a satisfying, relaxed calm when you finally get back inside and exhale.

And there are plenty of windy spots across the Netherlands, where this word comes from, to enjoy a regular uitwaaien and clear your head.

A walk in nature always has the power to soothe, calm, and clear your head, be it the three-day effect, forest bathing, or solvitur ambulando. But nature, combined with a strong wind, seems to have an extra power.

(Very grateful for my Dutch friend for patience in explaining, pronouncing and correcting)

Related Ideas to Uitwaaien

Also see:

• The three-day effect

• Forest bathing

• Solvitur ambulando

• Apricity: the warmth of winter sun

• 5 Ways to Wellbeing

• How to Instantly Feel Better

Some other super, non-English words:

• Rückenfigur

• Wabi-sabi

• Kaffikok: the distance before you need a cup of coffee

• Tsundoku: buying books and letting them pile up without reading them

• Vorfreude: the pleasure of anticipation

• Schadenfreude: pleasure at someone else’s misfortune

Either way, for this week’s podcast, I updated my old Know Your Dashes sketch, which is all about knowing when to use a hyphen, an en dash, and an em dash. And we had a fun and clarifying chat about each of them too.

Listen: Apple · Spotify · YouTube

Or listen right here:

And this gives me a great excuse to share some of my favourite grammar cartoons, too.

Subscribe now

In action:

• Hyphen -

• En dash –

• Em dash —

On Mac, I use [option + -] for en dash, and [option + shift + -] for em dashes.

Of course, perhaps you think this is all rather pedantic:

I once tried to explain this one:

Here are some of other favourite grammar cartoons for education and entertainment at it’s best:

Read more

I’ve covered coffee a number of times 😵‍💫. Some of the collection linked at the bottom (kaffikok is one of my favourites).

Have a great week,

Jono

Subscribe now

Too much coffee leads to poor sleep, which leads to waking up tired, which leads to craving that glorious coffee fix to make the tired go away. An ingenious self-reinforcing cycle.

Few other substances or systems seem to manage the elegance and simplicity of this cycle. Imagine if wine cured the effects of drinking too much wine.

The stark clarity of this coffee-sleep cycle was made clear to me in ‘s recent This is Your Mind on Plants, which has one-third of the book devoted to caffeine.

Before coffee and tea made their way to Western Europe with their doses of caffeine, Michael explains, it was common to drink ale and beer throughout the day, starting at breakfast. The result surely being that many people must have been going about their duties in a light haze. The replacement of the fuzziness of alcohol with the clarity, focus, and alertness that caffeine brings may genuinely have played a major part in human progress since. Intriguing.

Although many people—though not me—can fall asleep after a late coffee, there’s evidence that it still affects sleep quality.

However, despite knowing what coffee is doing in perpetuating my need for it, I, and millions of others, happily rejoin the cycle each day.

As I sketched this, I wondered if it were clearer simply as The Coffee-Sleep Cycle. What do you think? 

Right. About finished this. I’m off for a coffee.  ☕️

More Coffee-related Ideas

Also see:

• Kaffikok: the distance you can go before you need a cup of coffee

• When drinking tea, just drink tea

• Half caff: adjust your daily caffeine intake

• Nappuccino

• The Half-life of caffeine

• Clear the fog with a redeye

• American - Long black

• Make an Irish coffee

• Make Vietnamese coffee

• Microlife: the unit of life

• The virtuous cycle of exercise and sleep

• Painkillers and vitamins

• Addiction

( from Michael Pollan)

From last week’s Volcanic Explosivity Index a number of people asked about:

• Vesuvius and Pompeii: a 5 – Paroxysmal like Mt St Helens

• And Krakatoa: a mighty 6 – Colossal

And thanks for everyone who completed the podcast survey from last week. Thanks for the kind comments and we will take all feedback onboard to keep making it better.

Separately, Amazon has Big Ideas Little Pictures at +30% off (definitely not a pyrrhic saving 😅)

For this week, perhaps you’ve heard of a Pyrrhic victory: a victory so costly that it feels almost like a defeat.

The name comes from the tale of King Pyrrhus of Epirus in 279 BCE. On defeating the Romans, yet seeing the loss of so many of his best warriors, he declared, “If we are victorious in one more battle, we shall be ruined!” It’s an apparent gain that comes at too high a cost.

Perhaps you’ll recognise then, a Pyrrhic saving.

Subscribe now

A Pyrrhic saving is a saving that costs you more than it benefits you—spending more to save money you wouldn’t otherwise have spent.

“If we save any more, we shall be ruined!”

Ever bought something you didn’t need just because it was on sale? Or chosen the bundle when you only wanted one? These are Pyrrhic savings. A saving money trap disguised as a bargain.

Some personal Pyrrhic saving examples:

• A £20 voucher that has you spending another £40 to use it.

• Low-cost memberships that make you buy more than you would have done (Prime?).

• Going to buy one digital download and choosing the discounted pack of three, then never using the other two.

• A free kids’ meal that results in eating out as a family when you would otherwise have stayed in.

In business, it can look similar:

• Getting the larger office space that’s cheaper per square foot, but largely sits empty.

• Upgrading to the higher software tier because it’s a better deal, yet barely using the extra features.

• Bulk-purchasing inventory at a discount that ties up cash and costs you to store.

• Locking into a multi-year contract at a saving when you would otherwise have switched.

Saving money is satisfying. And sometimes a saving genuinely pays you back. But it could be worth asking: is this truly a saving — or money better left for another day?

Related Ideas to Pyrrhic Saving

Also see:

• Pyrrhic Victory

• The Subscription Trap

• Contentment

• Sales aren’t always the bargains they seem

• The decoy price

• The mathematics of everyday life

• Sneaky casinos

• Spend better

• Debt’s vicious cycle

• Euphemisms for losing money

• Mental accounting

• Bull market, bear market

Listen on: Spotify · Apple · YouTube

Along the way, hear about:

• The most epic bungee jump

• The deepest hole ever dug

• Why an antipode is like putting your feet on someone else’s

• Which countries have antipodes you can visit, and why most places don’t

• Why Earth isn’t perfectly spherical

• And all sorts of other antipodal-related things

Subscribe now

Here are a few thoughts on the drawing itself and what I learned from moving the sketches to digital. Looking back, what I thought were often aesthetic choices were actually constraints — and the constraints were doing more work than I realised.

Going digital

I did this sketch shortly after I ‘went digital’ with the sketches. That is, I moved from sketching in Moleskine pocket storyboard notebooks to doing them using Sketchbook Pro on an iPad Pro (the extra large one) with an Apple Pencil. I’ve learned a lot since making the move, and it’s slightly uncomfortable to look back on earlier ones like this.

Borders and Constraints

The border on the sketches replicates the border that is part of the storyboard notebooks. I added it in as a layer on all the early digital sketches in a naïve attempt to make the change as seamless as possible. At first, I thought: wouldn’t it be ideal if no one noticed?

Of course, the border doesn’t add anything, and I later removed it from new sketches and, when updating older ones for the book for example, stripped it out there too.

Although I no longer include a border, it was an excellent constraint at the start of this project. It did a number of things for me.

• It gave a uniformity to the sketches, making them more coherent as a collection, which is one of the main assets, I think, of this project.

• It helped reduce the fear of the blank page—all I had to do was fill in this little square.

• It removed a decision: “How big should this be?”

• It kept things manageable. A small space is less daunting to begin.

• It forced me to be very selective with what I chose to put in. This made me think harder and, probably, produce something better.

I also later replaced the poor contrast sketchplanations.com — which I had been adding in batch processing in Adobe Lightroom like a watermark — with a Sketchplanations logo and settled it in a more sensible place in the bottom-right.

Tools, brushes and colours

And, as I reflect on what makes a Sketchplanations sketch feel like a Sketchplanations sketch, I notice when looking at antipodes that I hadn’t settled on the “right” pen tool and thicknesses yet—these are actually written with a brush. Which means they don’t have the clarity of later sketches. Of course, I only noticed this later.

I built my first digital palette to match the colours, as they appeared on the paper, of the Uniball Vision Elite pens I had been using. Mostly the red, blue and green. Sticking to these colours, and pens, was also a helpful constraint for me, and probably for readers.

I gradually tweaked the colours to increase contrast and make them pop a bit more, and later enlisted the help of a talented designer I knew, who helped me build out most of the palette I stick to today.

A Side Note on Gifts

As an aside, two of the most impactful gifts in my life have been receiving this iPad Pro with Pencil and, 10 or so years earlier, a digital piano when I was a grad student. Both were gifts from my parents — tools that, at the time, I could not justify with my budget. (Thanks, mum and dad!).

Yet, it’s thanks to the iPad Pro and Pencil that I’ve progressed Sketchplanations this far.

And it’s thanks to the digital piano that I started writing my own music instead of just playing others’ music.

Neither were cheap gifts. But, if you’re in a position to, supporting your children’s interests in this way is a wonderful thing to do.

If you listen, I hope you enjoy it — and maybe start an antipodes conversation this week.

Jono

Volcanic eruptions are both awe-inspiring and terrifying at the same time. They all seem enormous, but some are much more enormous than others. Here’s the scale volcanologists use to measure them — from gentle lava flows to planet-altering explosions.

You’ll also find a few other favourite scales at the bottom.

Wishing you a week not too close to any active volcanoes,

Jono

PS 2 min Podcast listener survey still open. Thanks for your responses

Subscribe now

Volcanoes are big, so eruptions are big. But how big? And how would you compare one eruption with another? Well, like the Richter Scale for earthquakes, there’s a scale for eruptions. It’s called the Volcanic Explosivity Index.

What Is the Volcanic Explosivity Index?

The Volcanic Explosivity Index (VEI) ranges from 0 to 8. It covers everything from a shoot of ash with a trickle of lava (Effusive), for example, Hawaii’s Kīlauea volcano, to the mega-colossal explosions in the distant past from the Yellowstone caldera, the largest supervolcano in North America.

Volcanoes erupt in different ways, and the index uses several measures, such as the volume of ash (tephra) ejected and the height and scale of the plume and ash clouds. And some eruptions are sudden, while others go on for years.

Because of this difficulty in classification, one division I like is red volcanoes and grey volcanoes. A red volcano is an effusive eruption with lava and often a lava lake, like Hawaii’s Kīlauea. A classic grey volcano eruption is Mt St Helens that created an ash cloud rising to around 15 miles above the summit.

Like the Richter scale, the Volcanic Explosivity Index is a logarithmic scale. This means that, after the first levels, each level ejects roughly ten times more material than the previous(!)—hence the sketch not being to scale.

The scale with some examples

Here’s the scale with associated adjectives, approximate sizes of the eruption column, and some example eruptions you may have heard of:

0 · Effusive or Non-explosive
100m, Kīlauea (Hawaii, current)

1 · Gentle/Mild
100m–1 km

2 · Explosive
1–5 km, Mt Etna (Italy, 2006 and many others)

3 · Severe
3–15 km

4 · Cataclysmic
10–25 km, Eyjafjallajökull (Iceland, 2010)

5 · Paroxysmal
20–35 km, Mt St Helens (USA, 1980)

6 · Colossal
>30 km, Pinatubo (Philippines, 1991), Krakatoa (1883)

7 · Super-colossal
>40 km, Tambora (Indonesia, 1815)

8 · Mega-colossal
> 50km (uncertain, though massive), Yellowstone (USA, several times...)

The descriptive adjectives for each level vary slightly across the sources I’ve seen. In particular, levels 4 and 5 are sometimes 4 Catastrophic and 5 Cataclysmic. But I liked the labels the Natural History Museum uses, including Paroxysmal.

Learn more about the VEI

The USGS (United States Geological Survey) have a helpful article on the VEI from geophysicist Michael Poland.

And you can read the original 1982 paper that proposes the scale from volcanologists Chris Newhall and Steve Self: The Volcanic Explosivity Index (VEI): An Estimate of Explosive Magnitude for Historical Volcanism (archived pdf), Journal of Geophysical Research

Related Ideas to the Volcanic Explosivity Index

Some more scales:

• The Fun Scale

• The Bortle Scale — Clarity of the night sky

• The Scoville Scale — Chilli heat

• Temperature scales — Fahrenheit and Celsius

• Solar System Sizes

• Time hierarchy

• Dunbar’s Number

More volcanoes:

• Red volcano, grey volcano

• Dirty thunderstorm

Have you listened to any of the Sketchplanations podcast in the last few years? Would you spare a moment to let us know what you think in the survey below? We’re looking for ways to improve.

👉 Take the survey

Did you know there are over 60 episodes?

Thank you!

Jono

(and Rob and Tom, podcast co-hosts extraordinaire)

PS Don’t like surveys? Hit reply to email me or leave a comment.