Writer and filmmaker Astra Taylor explains fauxtomation as "the process that renders invisible human labour to maintain the illusion that machines and systems are smarter than they are." (Faux means false or fake in French).

Taylor gives an example of standing in line to collect food and the person in front of her expressing amazement at how the app knew his order was done 20 minutes early. The server replies, "I sent you a message."

With the rise in incredible abilities driven by AI chatbots and tools, it's tempting to believe that AI can run anything. But, in many situations, claims of AI magic and sophisticated automation disguise work done by people—often outsourced and poorly paid.

An example of fauxtomation is content moderators, whose job is to review and filter objectionable content from the web when the claim is that sophisticated algorithms and AI are doing the work. Other examples are tagging or searching images, transcribing audio, responding to customer queries, making decisions, or, ironically, training machine learning models. In another twist, ordering on the app or touchscreen at McDonalds or the self-checkout at a supermarket, you, as a customer, become the labour of a server or waiter.

Some have argued that automation polarises work into vast quantities of small, menial tasks feeding the machines on one end and sophisticated, high-skilled work in designing and maintaining the machines at the other.

Amazon has long offered its Mechanical Turk service, which crowdsources assignments with a distributed workforce—they called it artificial, artificial intelligence. The original Mechanical Turk was a hoax from the 1700s where a concealed human chess player fooled onlookers into believing a machine was playing.

As a design and UX professional, I've used the Wizard of Oz prototype technique. Named after the infamous wizard secretly controlling impressive machines from behind a curtain, the idea is to give the appearance of a working software prototype by discreetly controlling what people see based on their actions.

AI promises instant automation, but that's rarely the case. As you work to automate and remove inefficiencies, it's natural that systems should be supported by people.  Human-augmented work may be a more appropriate term. In many domains, especially where safety is at stake, such as in self-driving cars, reviewing legal documents, or automated background checks, oversight by people may remain critical.

Alongside the AI revolution, a quiet revolution nearly as significant for our everyday experience is the tying together of different tools for automation. Tools like Zapier, Google Sheets, Notion, and the growth of APIs allow us to automate workflows across systems, saving massive amounts of time and effort.

While the vision of machines reducing our labour persists, history shows that they often drive increased productivity instead of reducing work. This echoes Jevon's paradox, where fuel efficiency gains usually result in increased fuel usage rather than less.

I saw an excellent talk by machine learning and AI expert James Smith, in which, before you try machine learning ("I hear you have Magic Pixie dust. Can I have some?"), he would ask, "Have you tried 50 IF statements?" These programmed rules will be more maintainable, less complex, and result in responses that are easy to understand.

I learned about fauxtomation from Tom Humberstone's remarkable visual essay What Luddites Can Teach us About Resisting an Automated Future in the MIT Technology Review. Fauxtomation is similar in concept to Potemkin AI, a term from researcher Jathan Sadowski.

You can read Astra Taylor's article, The Automation Charade, or watch her discuss fauxtomation at the AI Now 2018 symposium.

Sketchplanations continues to be done by me, by hand. If you'd like to support me, I'm improving my Patreon, which makes such a difference in helping creators like me keep creating. Thank you.

Here's a fauxtomation sketch by ChatGPT in case you're interested =)

As well as fauxtomation prints, you can get AI department prints

Fauxtomation

The Wheel of Death is a handy and simple tool to help prioritise issues and where to spend time fixing things.

I learned it from the domain of customer service. It's used something like this:

Keep track of customer issues that you encounter each week by tagging them.

At the end of the week, tally up the responses and produce the Wheel of Death to see the highest volume of questions or issues taking up the team's time.

Use the Wheel as part of a conversation about where the company should focus to improve the experience and save time for the team and customers.

The proportion of issues is only part of the story, and other factors like how critical the issue is, how much time it takes to resolve it, and how much work it is to make it go away will all be part of the decision.

I learned it from working with a talented head of customer experience as we worked on fixing support issues, though don't confine its use to that. I find "the Wheel of Death" a name that sticks with me, but it could also be called the Wheel of Fortune. If you focus on the Wheel for a spell, it's hard for things not to improve.

Worth bearing in mind that in its form as a pie chart, you'll need to combine it with volume or time metrics, or it can look like you're not making progress.

I revised this sketch slightly from the original

The Wheel of Death

Chickens and pigs is a metaphor for who's got skin in the game. Or to leave metaphors behind, who's involved in a project vs who is fully committed.

Also known as the bacon and eggs principle, it's from the old joke (sometimes told as a short story), "In a bacon and eggs breakfast, the chicken is involved, but the pig is committed."

Many people may be interested in and share their opinions on a project or decision. But only some will be responsible for delivering the project and directly accountable for its success.

Everyone may be interested in a bet, but only some players have money to lose.

The chickens and pigs metaphor used to be part of the scrum guide for developing software but was removed. While it memorably distinguishes accountability in a project, there's a danger that it alienates or diminishes valuable input that might make a project successful.

For a more conventional grouping of stakeholders in a project, see RACI

Chickens and pigs

The XY Problem (or X-Y Problem) often comes up in software development or customer support, where someone asks for help to achieve a solution (X) that they have chosen as a way to solve a different problem (Y). Helping with their solution may not help them solve their actual problem if it's not a good approach in the first place.

An example from software development is a person asking how to extract the last three characters of a filename (solution X), because they want to know the file type (problem Y). After helping them do solution X, it still wouldn't solve problem Y as some files have extensions of more than three characters.

Another example is a customer asking for help accessing their online account without realising that what they really want to do has to be done over the phone anyway.

There's art and skill in respectfully answering questions and helping with what's asked while seeking to understand the real goal. And if you're asking questions, providing more context may help others provide better answers.

In development, it saves time and effort. In customer support, it leads to happy customers. In design, it may be uncovering unmet needs.

The name is indirectly from Eric Raymond in How to Ask Questions the Smart Way:

A: If what you want is to do Y, you should ask that question without pre-supposing the use of a method that may not be appropriate. Questions of this form often indicate a person who is not merely ignorant about X, but confused about what problem Y they are solving and too fixated on the details of their particular situation."

Also see a better hierarchy of needs, the metrics onion, challenge and clarification questions, prefer open-ended questions, ask the question at talks, don't fill the silence.

The XY Problem

Saying "no" isn't easy. But there are different ways to say "no" to someone's requests without feeling like you've let them down while being realistic and constructive and ensuring the requester feels heard.

I really like this framework of three types of "no" from Judd Antin:

With the Yes No, you say "yes" to the need and "no" to the specific ask. 

So, a child asking for an ice cream may indeed need something to eat even though they might not get an ice cream. Or the request to make the sign-up button larger might well indicate that it's easy to miss, though a better solution may be to change its colour or the layout of the page.

With the Material No, you are saying yes to the request if you have the time/budget/people/tools to do it.

So, you would love to get the kite out of the tree if you had the tools to reach it. Or the request to make an additional change might be possible on the basis that you can push back the launch date or add another person to the team.

With the Priority No, you are saying yes, we can do it as long as we're happy to drop something less important.

So, you can take the extra cuddly bear in the car if we can choose a different one to leave behind. Or that you can do that project on the basis that we postpone another we had planned.

In each type of "no", the intent is to support and meet the needs of the person requesting while clearly explaining the reasoning for what you'd need to get it done. In each case, the "no" leads to valuable discussions of larger issues of what the real need is, what's required to get a job done, and what's really important.

Read Judd Antin's article, How to Say No, in his series One Big Thought.

Here's a version with all three types of "no" in one image and individually The Yes No, The Material No, The Priority No.

Three Types of "No"

I always considered a checklist, a checklist, so I was interested to learn the distinction between two types of checklists: Read-Do and Do-Confirm.

A Read-Do checklist might be prepared in advance for several potential possibilities. You check off the tasks as you do them, like following a new cooking recipe. They may be geared towards helping people understand what they should be doing and in what order and helping them remember key steps in unusual or unplanned scenarios. So, for example, if a plane develops a particular type of rare fault, such as an engine failure, a Read-Do checklist could be pulled out for that scenario. The pilot and crew can use it to make the most of others' past experiences and failures. Even with training, given the situation's relative rarity, and especially if a serious situation might interfere with normal thinking, a Read-Do checklist helps steer the crew to safe outcomes without relying solely on training and memory. The calm security and simplicity of steps of a checklist can be just what's needed.

A Do-Confirm checklist is more of an aid to memory to make sure nothing gets missed. It's a safety net for normal operation catching lapses in memory. In principle, we know what to do, so we run through those steps from experience and memory and use the Do-Confirm checklist at a designated pause point to ensure we didn't miss anything. The WHO Safe Surgery checklist has helped save 1,000s of lives.

Because a simple checklist can never account for every unexpected occurrence in complex environments—for example, healthcare, aviation, building a skyscraper, or software projects—both checklist types can benefit from items that require a communication step. An item can just be to ensure that all those with the relevant knowledge have discussed things. It's a simple and powerful way to improve outcomes across a wide range of unexpected scenarios.

I learned about the simple power of checklists, the two types, and the resistance to adopting them—from Atul Gawande's, The Checklist Manifesto: How to get Things Right.

Two types of checklists: Read-Do, Do-Confirm

Cake Wrecks is the blog and book of when professional cakes go hilariously wrong, by Jen Yates. But a cake wreck is also a useful metaphor for how easy it can be to misinterpret instructions—often by simply taking something literally when it was expected to be interpreted. Examples from Jen's collection include a smart-looking cake with "Nothing" written across the front, a graduation cake with "I want sprinkles" next to a graduation cap, or a cake sporting a full "Happy birthday on a gluten-free cake." If you haven't seen them, you could do much worse than look some up now. It's easy to laugh at these examples, but it's also easy to find real examples in day-to-day work.

I learned about cake wrecks from Jeff Patton's excellent book User Story Mapping. He gives cake wrecks as an all too common example of communication in software development. For example, a user story or specification for a feature is written and passed on to developers who, in the absence of other communication and with perhaps cultural or status barriers, may carefully build exactly what is written rather than what the writer intended. Cake wrecks are funny and silly—except if it was for your special occasion—but mistakes in projects are expensive in time, money and relationships and are worth avoiding.

The recipe for avoiding a cake wreck is, in principle, simple:

Don't assume that what you see is what someone else will see

Use stories and specifications as tools for talking about what's needed and not as equivalents of it

Create a safe space for everyone to question what they don't understand or don't agree with

Give everyone the 'why' behind a project and autonomy and flexibility to suggest other ways to meet the goal

Check in during a project and adjust as needed

Cake wreck

The frog boil metaphor illustrates how it's easy to miss small changes that build up over time until it's too late. The scenario, as told, is that of a poor frog who would leap away from hot water but, if put into cooler water that is gradually warmed, won't respond in time to getting boiled.

As a metaphor, it describes a powerful and pernicious shortcoming in how we perceive the world. A student kitchen that gets messy mug-by-mug, a business with gradually slowing sales, software that builds up with tech debt, a river that is slowly polluted, a road that gets busier each day, a bay that sees fewer fish each year, content that drifts, cancer that slowly spreads, a story or behaviour that becomes normal, a website that gets slower feature-by-feature, or a climate that slowly warms are all cases where we may not be happy where we end up, but we didn't notice how we got there.

It's hard to respond to gradual change, especially when it spans generations. Jared Diamond called it out as a potential fate of the Easter Islanders and how they could have cut down the last tree. One barnacle is nothing, but many barnacles can cause significant headaches for big ships.

Fortunately, there's a flip side. Many, many things are getting better without us realising. Small positive changes, such as in attitudes, education, or healthcare, add up over time—the Destiny Instinct can mislead us. Fast and slow layers make a system, like a forest, more robust. Getting one percent better each day leads to a 37x improvement in a year. And enough molehills can make a mountain.

What a frog does, in this case, is not, apparently, true—don't try it—it's much better as a metaphor, not an experiment.

The frog boil metaphor

The bus factor is how exposed you are if key people, perhaps with critical knowledge or skills, were hit by a bus.

Examples might include the only people able to keep a company running, restore a server from a backup, or someone who held the only key to unlock crypto assets of its customers. As a result, many places are set up with, or required to have by investors or insurers, some redundancy — say two experienced developers with knowledge of how a service works — to minimise the risk of a tragic accident also being a severe problem for a company or its customers.

As a metaphor, the bus factor may be helpful to consider without the need for people to actually be hit by a bus. It may be worth thinking through how you might operate if someone was late, missed their flight, was ill on the day, or simply quit. In operational roles, this will often lead to a minimum of two people for each key position if nothing else to allow one to take a break from time to time.

An alternative framing, with fewer fatalities, is 'what if we all won the lottery?' and so decided to go do something else.

Bus factor

Anyone who's tried their hand at research, built some software, or even run a kid's birthday party may relate to this idea: In theory, practice is the same as theory, but not in practice.

It's a lovely encapsulation of similar ideas to "All models are wrong, but some are useful" or "No plan survives contact with the enemy." Or one of my favourites, Hofstadter's Law: "It always takes longer than you expect, even when you account for Hofstadter's Law."

The quote, in varying forms, has been attributed to a number of people — QI suggests that Benjamin Brewster should get the credit from 1882.

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

Just as mistakes and the unexpected are part of life, bugs are part of software development. In general, the longer the time between when a bug was first introduced and when the bug is identified and fixed the more expensive it is in both time and money.

If you spot a bug as you're writing a new feature everything is fresh in your mind and it can sometimes take just a moment to fix.

If a bug turns up later or perhaps soon after it's deployed you might have an idea of where it might be and track it down fairly quickly.

If a lot of time has passed since a feature was worked on and a bug is spotted or tackled then it might take a fair bit of time to figure out how everything works again before you can fix it.

And if a really long time has passed then, aside from the cost of interrupting what you are otherwise working on, it may not even be clear what was intended by the original code, probably written by others, and there's a fair chance more has been built on top of the buggy code making it more complex and a bigger task to tackle. The only way to solve it may be stepping through and figuring out behaviour slowly and steadily line-by-line.

You could probably replace 'bugs' with 'code' 'problems' or 'mistakes' in most scenarios.

Aside from it matching my experience, Joel Spolsky gives a nice explanation in his classic article The Joel Test.

The cost of fixing bugs

The chaos monkey is a smart piece of software and a brilliant idea from engineers at Netflix.

The chaos monkey deliberately switches off servers in live environments at random. It takes the pain of disappearing servers and brings that pain forward. By deliberately sabotaging their own systems it created strong alignment for the team to design-in redundancy and automation for the necessary resiliency and reliability in the face of random failures. Training for this randomness helps make stronger, more resilient and fault-tolerant systems and software and keeps your movie streaming so you can keep chilling without interruptions.

The chaos monkey is a great metaphor and trigger to actively work on what life could throw at your system before it happens.

More monkey inspiration for writing and for bananas.

Chaos monkey

When adding features to a software product it's easy to underestimate the overall time and cost they may take up. To keep the full impact in mind it can be helpful to think of Features As Pets.

When I think of Features As Pets it helps me look past the initial cost of designing and developing a feature and consider its full lifecycle. For example:

you're going to want to tell your users about it

you'll want to check it's being used as intended

you'll need to support it and check that it works in all different places and fix it when it breaks

you may need to work hard to make sure it's compatible with new features you add

you may have to return to the code and refactor it to improve performance

you may need to upgrade libraries and maintain security patches

finally you'll have to decommission it gracefully when it's no longer needed including dealing with data you may have stored

New features are probably one of the key differentiators of your offering compared to others, but it bears a little consideration before adding something — a feature is not just for Christmas.

Features Are Like Pets is from the excellent Intercom on Product Management podcast (Apple, Spotify, ebook).

Features are like pets

Yak shaving describes how when setting out to do something, you found you had to first do something else, which needed you to finish this other thing, and so on until you found yourself shaving a yak, or equally unrelated activity, to do the first thing you set out to do.

It's pretty frequent in life — tidying your room? — and particularly resonates in software development, where when tackling one thing, you often find yourself fixing something else, which needs you to fix something else, and so on. Here's the ever brilliant xkcd on fixing problems.

Yak shaving features, lovingly polished, in my book Big Ideas Little Pictures.

Here's a brilliant 40s clip of Hal changing a lightbulb from Malcolm in the Middle, classic yak shaving

Early yak shaving features in the song There's a Hole in My Bucket in which fixing a bucket requires straw, which requires a knife to cut it, but the knife needs sharpening, which needs a stone, which is too dry and needs wetting with water, which needs fetching...with a bucket

The first I found of yak shaving was a short article on productivity in the first issue of Make magazine by Danny O'Brien and Merlin Mann.

Yak in the style of Alison Green and Adam Stower's excellent children's book, What can you Stack on the Back of a Yak?

Yak shaving

Sentences that have been written in a passive voice are generally less powerful than sentences that have been written in an active voice.

Active writing hits harder than passive writing.

It's easy for passive writing to slip in. Here's a handy technique to help you spot passive writing in your sentences. Try adding "...by monkeys" to the end of the sentence. If it still makes sense, then there's a good chance it's passive.

In the example in the sketch: "The bug will be fixed" you can tack on "...by monkeys" and all makes sense. It's passive. Passive writing is an easy way to distance ourselves and our opinions from what we're writing. Active writing takes ownership and responsibility and connects with the reader. "We'll fix the bug. Sorry about that."

I love the "...by monkeys" example for spotting passive writing as it vividly shows how responsibility disappears.

This super example and technique is from Monzo's excellent tone of voice guidelines. Handy for writing copy on the web, for your brand, and for everyday life.

You might like the excellent Hemingway app to spot other non-Hemingway slips in your writing. I ran this post through it and cut out a lot of fluff.

I also love the classic The Elements of Style by Strunk and White.

By monkeys

Conway's law is, paraphrased, that the structure of software will mirror the structure of the organisation that built it.

Conway was mostly observing software development, but I would think it has some application to any large project: cruise ship design, car design, space shuttle design, and maybe even governments and law.

Law is kind of a strong word for an observation, but in any case, here are some other "laws":

Conway’s Law

This is surely at least part of the reason that “software is eating the world.”

But I’m sure coffee will stick around for a bit too.

Rival and non-rival goods

Rubberducking is a problem-solving technique where you explain your code or task to a rubber duck—or any inanimate object—and discover the solution yourself through the act of explaining. It's brilliant because it works and is effectively free.

Rubberducking, or rubber ducking, is most commonly associated with debugging in software development but can be applied to any problem-solving process.

The name comes from the book The Pragmatic Programmer by Andrew Hunt and David Thomas. In it, the authors suggest using a rubber duck as a conversation partner to clarify one’s thoughts. This is an accessible and effective way to troubleshoot problems without requiring someone else’s time.

Have you ever been called over to someone’s desk to help them solve a problem, and as they explain the problem to you or demonstrate it, they figure out the answer themselves? It happens all the time to me, particularly when someone's showing me how something doesn't work, and it magically works just by having me watch over their shoulder.

The rubber duck technique is as simple as that, except that instead of calling someone over, you can simply replace the person with a rubber duck, teddy bear or heck, even your stapler.

The psychology behind rubberducking relies on how explaining a problem forces you to process your thoughts more clearly, often revealing gaps or errors in your understanding. Here’s how you can try it yourself:

1. Set up your “duck”: Place a rubber duck, teddy bear, or any object on your desk.

2. Explain your problem: Describe your code, logic, or issue to the duck, step by step, as if you’re teaching it.

3. Watch for insights: In explaining it aloud, you’ll often uncover what’s wrong or identify a new approach to solving it.

For example, a developer struggling with a bug might explain every line of code to the duck. Verbalising their logic can highlight an overlooked detail that resolves the problem.

Rubberducking works because it forces you to articulate your thoughts clearly, moving them from abstract notions in your head to concrete statements. This shift can:

• Help you identify assumptions you didn’t realise you were making.

• Mimic the process of pair programming without needing another person.

Rubberducking a problem also reduces dependency on others for problem-solving, making it a cost-effective—basically free!—and time-efficient tool for debugging.

Here are some situations where it’s particularly useful:

• Debugging code: Talk through an error or bug in your program.

• Explaining logic: Test the clarity of your solution by explaining it step by step.

• Learning new concepts: Summarise a concept to the duck to check your understanding (see the Feynman Learning Technique)

• Decision-making: Walk through the pros and cons of a decision.

In software development, rubber duck debugging has become a recognised term for this process. It’s so common that some developers keep an actual rubber duck on their desks to symbolise this practice. Teams might 'joke' about needing “a duck” for the simplest bugs.

Debugging is an integral part of coding, and the rubber duck technique makes it less daunting. By verbalising your thought process, you streamline problem-solving without needing external help.

Frequently Asked Questions about Rubberducking

Nope. While a rubber duck is the classic choice, you can use anything nearby—your coffee cup, a stapler, or even a photo on your desk.

Q: What if talking out loud isn’t possible?

Writing out your explanation or saying it in your head can work just as well. The key is clarifying and articulating your thought process.

Q: How is this different from pair programming?

Pair programming involves working alongside another person on the same task. Some people swear by pair programming, and to be honest, I've always found it effective whenever I try it. However, rubberducking is a solo activity where the act of explanation itself is the solution.

Next time you're stuck on something, grab a rubber duck and give it a try.

Rubberducking is similar to the empty chair technique for psychotherapy, which involves speaking to an empty chair as if addressing a person.

It's also easily confused with "rubbernecking," which is slowing down to look at an accident as you drive past—a common cause of traffic jams.

What is Rubberducking? An Explanation of the Rubber Duck Debugging Technique

Smaller software releases generally means fewer bugs, and bugs that are easier to fix. The number of bugs created typically increases with the complexity of interactions of code, which in turn increases with the size of release. This means that a number of smaller releases can hopefully get you to a large change in a safer way with less bugs, and less problematic bugs, created along the way than a single release with the whole lot. There’s probably a somewhat more general relationship with amount of unexpected problems created and the size of any change.

Bugs and releases

I love this diagram by Henrik Kniberg for determining what to release to your customers and when.

The idea is that a standard approach of having your grand plan of what you think people want at the start and then working on each bit at a time until finally, after months of work, you have something that works is not so smart. Each piece, in the car example, doesn’t help the customer at all until it’s all put together.

Instead, you can focus on providing the next piece of functionality that helps someone get their job done a little better than before. In the beginning, they’ll probably have to put up with a lot if they want to use it, but with each successive release, they find they can get their job done a little better than before and get value out of what you’re building. A side-effect is the feedback you get along the way will likely help you learn and build something that is better than what you had in mind at the beginning, and all along the way, the customer had some value instead of waiting for months.

Providing usable functionality at every step is not always easy, and it requires rework as you move from one step to the other. But it’s generally a price worth paying to give your customers value sooner and start learning as soon as you can.

This diagram is explained in the brilliant product management book User Story Mapping by Jeff Patton.

A release strategy for happier customers, sooner

Idempotence is essentially an operation that, no matter how many times you do it, you’ll still get the same result, at least without doing other operations in between. A classic example would be view_your_bank_balance being idempotent, and withdraw_1000 not being idempotent. It’s a property that’s often handy as you can retry the operation without worrying about unintended effects.

Idempotence is a concept from mathematics and computer science but can be applied more generally. For example, simple on and off buttons are idempotent, a property that can be very useful in emergencies.

Idempotence

A way of helping decide what to do next based on Must do, Should do, Could do and Would do.

Strangely, so many of the things you’d really like to do when put in this organisation end up in the Would bucket.

MOSCOW Prioritisation.

Desire paths: created by desire and use. Sometimes I find myself walking on the traces of one as a statement that ‘there ought to be a path here’ - voting with my feet.

There’s the classic, perhaps apocryphal, story of the architect who didn’t build any paths on a campus until people had worn them in, showing where the paths should be.

The phenomena has found use in technology with the phrase 'pave the cowpaths’.

One emergent behaviour-related concept arising from architecture and planning which has also found application in human-computer interaction is the idea of desire lines, desire paths or cowpaths. The usual current use of the term (often attributed, although apparently in error, to Bachelard’s The Poetics of Space (1964)) is to describe paths worn by pedestrians across spaces such as parks, between buildings or to avoid obstacles—“the foot-worn paths that sometimes appear in a landscape over time” (Mathes, 2004) and which become self-reinforcing as subsequent generations of pedestrians follow what becomes an obvious path. Throgmorton & Eckstein (2000) also discuss Chicago transportation engineers’ use of ‘desire lines’ to describe maps of straight-line origin-to-destination journeys across the city, in the process revealing assumptions about the public’s ‘desire’ to undertake these journeys. In either sense, desire lines (along with use-marks (Burns, 2007)) could perhaps, using economic terminology, be seen as a form of revealed user preference (Beshears et al, 2008) or at least revealed choice, with a substantial normative quality.

Architecture, urbanism, design and behaviour: a brief review, Dan Lockton, Sep 2011

Or see this very concrete example from UC Berkeley at peterme.com.

Desire path

I learned about this nice principle from agile software development. Basically, that when thinking about how much you’ll get done next week, what you got done this week is a good proxy. Sure this week was different because you had that external presentation and an offsite, a bug to fix on live and Amy was sick. But the reality is things will interrupt you next week too. Just like the weather, what happened before is a good first guess at what will happen next.

Yesterday’s weather

Hofstadter's Law is “It always takes longer than you expect, even when you account for Hofstadter’s Law.”

Hofstadter's Law is one of my favourites, and I share it time and time again.

We are bad at estimating. We don't allow for the unexpected. We don't know the unknown unknowns. We are overly optimistic. We suffer from recency bias. Generally, we struggle with big, complex things.

In the law's recursion, it's a little like this guidance from Clean Code:

“The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that.”—Clean Code

Or omit unnecessary words from Steve Krug

Given how easy it is for us to underestimate how long things will take, be kind to each other.

From Douglas Hofstadter, Gödel, Escher, Bach: An Eternal Golden Braid (1979)

Software sketches