The advice everyone gives and nobody explains

I have lost count of how many times, during years of supporting websites and teams, I have typed the sentence “try clearing your cache.” It works often enough that it has become a ritual, like switching a device off and on again. But rituals without understanding cause trouble. People clear everything, lose their saved logins, and then complain that the fix “broke” something. Others never clear anything and wonder why a website still looks like last year’s version.

The truth is that “the cache” is not one thing. There are many caches, living in different places, owned by different people. When someone says clear it, they might mean your browser, your phone app, your computer’s address book, a content delivery network, or a plugin on a web server. Knowing which one is the difference between a ten-second fix and an hour of confusion.

A cache in everyday life

Before the computer version, think of a kitchen. You could walk to the shop every time you need salt. Instead, you keep a small jar on the counter. Fetching from the jar takes a second, going to the shop takes twenty minutes. The jar is a cache.

It has the same properties as every digital cache. It is small, so it can only hold what you use often. It is a copy, so the shop still has the real thing. And it can go stale: if the shop changes the recipe on the salt, your jar still holds the old version until you refill it.

That last point is the source of nearly all cache problems. A cache is fast because it trusts old copies, and it is annoying when the trust is misplaced.

Why caches exist: speed, in numbers

Computers have a hierarchy of storage. Closer to the processor means faster and smaller, further away means slower and bigger. As a rough scale (these are order-of-magnitude figures that vary by machine), reading from the CPU’s own cache takes about a nanosecond, from main memory about a hundred nanoseconds, from a solid-state drive around a hundred microseconds, and from a server across the internet tens of milliseconds. That is a gap of millions of times between the fastest and slowest layers.

Caching exploits that gap. The system keeps copies of frequently used things closer, so it can skip the slow trip. A simple calculation shows how much this matters. Suppose a cache hit takes 5 milliseconds and a miss, which means going to the original source, takes 200 milliseconds.

With no cache at all, every request waits 200 ms. If 85% of requests are hits, the average wait drops to 0.85 × 5 + 0.15 × 200 = 34.25 ms, nearly six times faster. At a 95% hit rate it is under 15 ms. The curve is a straight line, so every additional percent of hits is worth the same amount. That is why companies spend real money on caching.

The layers: who is caching what

This is the part most guides skip. Between you and a website, copies are stored in at least five different places.

• CPU cache: tiny, ultra-fast memory built into the processor. It manages itself and you cannot clear it.
• Browser cache: your browser saves images, stylesheets, scripts and fonts so repeat visits are quick. This is what “clear cache” normally refers to.
• Operating system and DNS cache: your computer remembers which numeric address belongs to a website name so it does not ask again every time.
• CDN cache: a content delivery network keeps copies of site files on servers around the world, close to visitors.
• Server cache: the website itself may save ready-made versions of pages, so it does not rebuild them for each visitor.

A reader can clear only the second and third. The last two belong to whoever runs the site. If you publish websites yourself, as many of my readers do, you will deal with all five.

What your browser cache actually contains

Open any web page and your browser downloads a bundle of files: the page itself (HTML), stylesheets (CSS) that control appearance, scripts (JavaScript) that add behaviour, images, and fonts. Many of these rarely change. The logo on a site is the same on every page, so downloading it fresh each time would be wasteful.

The browser therefore stores these files, and the next time it needs them it can skip the download. Here is what that looks like for a typical page, using realistic but illustrative sizes.

On a first visit this example page downloads 1,850 KB. On a repeat visit, only the 60 KB HTML needs to be fetched, a saving of about 97%. At a typical home connection of 10 Mbps, the first load needs about 1.5 seconds of transfer while the repeat takes a fraction of that. On a slow 2 Mbps mobile connection, the first visit would need around 7.4 seconds of transfer alone, which is exactly why the cache matters so much on phones.

How the browser decides whether to trust its copy

A cache that never refreshed would show you stale pages forever. So websites send instructions, in hidden headers, telling the browser how long a file stays fresh. A typical header says something like Cache-Control: max-age=86400, which means “this file is good for 24 hours.” Within that window, the browser uses its copy without even asking.

When a file goes stale, the browser does not always download it again. It can ask the server a cheaper question: “I have the version labelled with this tag. Has it changed?” The label is called an ETag. If the answer is no, the server replies with a tiny “304 Not Modified” message and the browser keeps using its copy. Only if the file changed does the server send the full new version.

Developers also use a trick called cache busting. When they update a stylesheet, they change its name or add a version number, for example style.css?v=42, so that the browser sees a brand-new file and fetches it. When this is forgotten, you get the classic symptom: new page, old styling.

Cache, cookies and history: the three things people confuse

This is where most of the damage and most of the fear come from. The “clear browsing data” screen in a browser lists several separate items. They are different things.

The practical rule: if you only tick “cached images and files,” you will not lose logins or passwords. The mistakes happen when people press the big “clear all” button and tick every box. A moment of care is worth saving yourself a password-reset afternoon.

Five situations, five different fixes

Tap through the tabs. Each one shows a real problem and which layer to clear.

Windows / Linux:  Ctrl + Shift + R   (or Ctrl + F5)
macOS:            Cmd + Shift + R

Android: Settings > Apps > [app] > Storage > Clear cache
# Clear data / Clear storage also resets the app and signs you out

Chrome: lock icon > Site settings > Delete data
# or Settings > Privacy > Delete browsing data > Cookies

# Windows
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

1. Save or update the post
2. Purge the page cache in your caching plugin
3. Purge the CDN cache (for example Cloudflare: Caching > Purge)
4. Hard refresh your browser
5. Test in a private window

Notice that “clear the cache” was the right answer in only two of those five situations. In the others, the fix involved cookies, DNS, or the layers a site owner controls. That is the lesson of this whole article: ask which cache before you clear.

Hard refresh versus clearing everything

If a single website looks wrong, you rarely need to clear your entire browser cache. A hard refresh bypasses the cached copies for that page. On Windows and Linux you press Ctrl+Shift+R (or Ctrl+F5), and on a Mac, Cmd+Shift+R. It is the scalpel; clearing the whole cache is the sledgehammer.

Another trick I use constantly is the private or incognito window. It starts with no stored cache or cookies for that session, so if the site looks right there, you know the problem is a stale copy in your regular browser. If it looks wrong there too, the problem is not your cache at all: it is the server, the CDN, or the site itself.

If you run a website: the layers pile up

Readers have one cache to worry about. Site owners have several, and that is why “I updated it but it did not change” is such a common complaint. Imagine you fix a typo in a WordPress post and click Update.

• The page cache plugin may keep serving the pre-built old page until it is purged.
• The CDN may keep serving its copy from servers near your visitors until its rules expire or you purge it.
• Each visitor’s browser may keep its own copy until it is stale.

The order matters. Clear from the source outward: plugin first, then CDN, then your own browser. If you clear the browser first, it simply re-downloads the stale copy from the layer above it. And always verify in a private window, because your own normal window is the layer most likely to mislead you.

The same thinking applies to design changes. Many themes and plugins also bundle CSS and JavaScript files. If a style tweak does not show, purge the plugin’s file cache, and then purge the CDN. A teammate of mine once spent a whole morning editing a stylesheet that was working perfectly; the browser was just refusing to fetch it.

Mobile phones: cache versus data

Apps cache aggressively. A social app saves thumbnails and video chunks so scrolling feels smooth, and over months this can grow into gigabytes. On Android, you can open the app’s storage screen and choose to clear the cache, which frees space and costs you nothing but a slightly slower first scroll afterward.

The same screen has a second button, usually called “Clear data” or “Clear storage.” This one is different and more drastic: it resets the app, signing you out and removing settings and sometimes locally stored files. People hit the wrong button all the time. Read the label twice.

On iPhone there is no per-app cache button. Options are to offload the app, which keeps its documents but removes the app files, or to delete and reinstall it. Safari has its own setting to clear history and website data, which removes the browsing history, cookies and cached files together.

When clearing the cache is a bad idea

• Doing it daily out of habit. You throw away the speed benefits and re-download everything again and again.
• Doing it on a metered connection. Re-downloading a heavy site’s files uses your data allowance.
• Believing it protects your privacy. Cache is a small part of what sites know about you. Cookies, accounts and network logs are separate.
• Using it as a cure for everything. Slow internet, a failing disk and an overloaded server will not improve.

Six myths about clearing cache (tap to open)

Quick quiz: test yourself

Tap each question to reveal the answer and the reasoning.

Frequently asked questions

The post What Does “Clearing Cache” Actually Clear? appeared first on Learn With Examples.

The day cards stopped being copyable

Years ago I sat in a meeting with a fraud team at a mid-sized bank. A chart on the wall showed counterfeit card losses climbing for a decade. Then, a few months after chip cards went mainstream in a particular market, the line bent downward. Nobody in the room had changed their software or hired a hundred investigators. The only difference was a small piece of hardware inside the card.

Most people use the chip every day without ever wondering what it does. They insert the card, wait a moment, type a PIN, and carry on. In those few seconds, though, a carefully designed conversation takes place between the card, the terminal and your bank, and it is built so that anything a thief overhears is useless.

This article explains that conversation in plain language. You will learn why the magnetic stripe was easy to copy, what the chip does differently, how a one-time code defeats replay attacks, and what the chip cannot protect against. There are small interactive parts, real-world scenarios, a quiz and an FAQ.

How the old magnetic stripe worked (and why it failed)

The magnetic stripe on the back of a card is a strip of tiny magnetised particles. It stores a short block of data: your card number, expiry date and a few service codes. When you swipe it, the reader simply reads that data out and sends it to the bank.

The critical weakness is that the data is static. It is the same on Monday as on Friday, at a petrol station as at a restaurant. Anything that can read it once can write it onto another card, because the card has no way of proving it is the original. It simply says the same words every time.

Think of it as showing a photocopy-able ID. If a stranger photocopies your ID card while you are not looking, the copy looks as good as the original to anyone who only checks the print. Criminals used devices called skimmers, hidden in card slots at ATMs, fuel pumps and ticket machines, to capture exactly this fixed data, then wrote it onto blank cards. This is what “cloning” means.

What the chip actually is

The standard behind chip cards is called EMV, named after its founders: Europay, Mastercard and Visa. Inside that gold plate is a tiny secure microcontroller, a very small computer with its own processor and memory, designed to resist tampering.

It does three jobs a stripe never could:

• It stores a secret key that is built into the chip during manufacturing and is not designed to be read out. Only the card and the issuing bank know it.
• It does calculations using that key. The terminal asks a question, and the chip works out an answer that only the real card could produce.
• It counts. The chip keeps a transaction counter that goes up with every use, so no two payments look alike.

The crucial design principle is simple: the secret never leaves the chip. The terminal does not read the key. It only receives the results of calculations done with it. A recording of those results does not reveal the key, just as hearing someone’s signed answers does not reveal their private pen.

The one-time code: the cryptogram

When you pay, the terminal sends the chip the details of the sale: the amount, the currency, the date and a fresh random number it just generated. The chip mixes these with its internal counter and its secret key and produces a short code called a cryptogram.

Your bank, which also holds the matching key material, performs the same calculation on its side. If the answer matches the cryptogram, the bank knows two things: the card is genuine, and the transaction details were not altered along the way. Change the amount by a rupee and the cryptogram no longer matches.

Because the terminal generates a new random number every time, and the chip’s counter keeps climbing, the cryptogram is different for every payment, even when you buy the same coffee at the same shop for the same price. A recorded cryptogram is a receipt for one specific event. It cannot be reused for a different purchase.

A toy version you can follow with a calculator

Real chips use serious cryptography, such as 3DES or AES-based message authentication codes. To make the idea visible, here is a deliberately simple toy version. Pretend the card’s secret key is 7, and the cryptogram is calculated as:

Here are four purchases by the same card with the same secret key.

Look at the first and last rows. Both are purchases of ₹450, yet the cryptograms differ, because the counter and the terminal’s random number changed. Now imagine a thief recorded the ₹4,999 purchase, where the cryptogram was 65, and tries to reuse it for a new ₹4,999 purchase. The new terminal produces a different random number, and the bank expects the counter to have moved on. The bank calculates 85. That does not match 65, so the replay is declined.

Even this toy shows the heart of the matter: the proof of a payment is bound to that one payment. Real systems add much stronger maths so nobody can work backwards to the key, but the logic is the same.

The five steps of a chip payment

• Step 1: the terminal tells the card the details of the sale and a fresh random number.
• Step 2: the chip signs those details with its secret key, producing a cryptogram.
• Step 3: the terminal forwards the cryptogram to your bank.
• Step 4: the bank recomputes it, checks your balance and fraud rules, and approves or declines.
• Step 5: the approval comes back, and the transaction completes.

Notice what travels across the network. It is the transaction details and a cryptogram, not a reusable secret. A thief who taps into the cable, or plants a device inside the terminal, captures a record of a finished event.

Proving the card itself is real

There is a second layer. Terminals also check that the chip is a genuine card issued by a real bank, and not a clever fake that merely answers questions. EMV does this with digital signatures. The card carries data signed by the issuer, and the terminal can verify that signature using a chain of trusted certificates.

Different cards support different strengths of this check. The simplest, called static data authentication, proves that the card’s data was signed by the issuer. The stronger methods, dynamic and combined data authentication, make the card create its own signature for each transaction using a unique key pair inside the chip. A copy of the card data cannot do that, because the private key never leaves the original chip. For beginners, the takeaway is this: modern cards do not just claim to be real, they prove it, freshly, every time.

Proving you are the right person: PIN and friends

Authenticating the card is not the same as authenticating the cardholder. For that, chip cards support several methods.

• Chip and PIN: you type a PIN. It is checked either by the chip itself or by your bank. Because the PIN is secret, a stolen card alone is much less useful.
• Chip and signature: you sign a slip or screen. This is weaker and has been fading in many countries.
• No verification: small contactless taps are often allowed without a PIN, up to a limit set by the bank and local rules.

In India, the Reserve Bank of India directed banks to migrate magnetic stripe cards to EMV chip and PIN cards by the end of 2018, and later rules gave cardholders control over how a card can be used, for example switching online, international or contactless use on and off in the bank’s app. Limits and rules do change, so check your own bank’s current settings.

How the world moved to chips

The EMV standard was developed in the mid-1990s, and countries adopted it at different speeds. Several European markets moved first, with the UK rolling out chip and PIN in the mid-2000s. The United States was later, and a key push was the “liability shift” in October 2015: after that date, for most in-store payments, whichever side of the transaction had not upgraded (the merchant or the card issuer) became financially responsible for counterfeit fraud. That is a business rule rather than a technology, but it changed behaviour overnight, because shops that ignored chip terminals suddenly carried the cost.

Industry bodies in countries that completed the migration generally reported steep falls in counterfeit card fraud afterwards. I will not quote single numbers here because they vary by country and year, but the pattern was consistent: fraud on cloned physical cards dropped.

Real situations: where the chip helps and where it does not

Tap through six everyday situations to see what the chip is doing in each.

Notice the pattern. The chip is strongest where it is actually used: insert or tap on a modern terminal. It is weakest where it is bypassed, which is on a magnetic stripe fallback and in online payments where you type your card number.

Where fraud went next

Security is a moving target. When you make one door hard to open, determined criminals look for another. After chips became common, three weak points became more attractive.

1. Card-not-present fraud

When you buy online, the chip is not part of the process. The website receives a card number, an expiry date and a security code, all of which can be stolen from a breached merchant, a phishing page or a malicious script. Banks respond with one-time passwords, app approvals, risk scoring and virtual card numbers. Many countries saw online fraud take up a larger share of the total as in-store counterfeiting shrank.

2. Magnetic stripe fallback

Some cards still carry a stripe so they work on old terminals. A terminal that cannot read the chip may offer a swipe instead. Criminals sometimes try to force that fallback, for example by damaging a card, so issuers treat fallback transactions with suspicion and may decline them. If a chip reader keeps failing on your card at a shop, the sensible response is to pay another way, not to swipe.

3. Social engineering

No chip can stop you from reading out a one-time password to a stranger posing as your bank. Scams that trick people into approving payments themselves are among the fastest-growing problems, because the technology cannot tell a genuine you from a convincing story. Your bank will never ask you to share a PIN or OTP, so any call that does is a red flag.

Contactless and phone wallets: the same idea, one step further

Tapping a card works through short-range radio, and the chip behind it still creates a one-time cryptogram. Phone wallets add another layer called tokenisation: instead of your real card number, the phone stores a substitute number valid only for that device. If a merchant’s systems are breached, the thief gets a token that is useless elsewhere. Pairing this with your fingerprint or face unlock means a payment needs something you have and something you are.

That is why security people often suggest a phone wallet for travel or for unfamiliar shops. It combines the chip’s protection with tokenisation and biometric confirmation.

Eight habits that keep your card safe

• Insert or tap rather than swipe whenever a chip option exists.
• Cover the keypad when you type your PIN. Hidden cameras still work against humans.
• Turn on instant alerts for every transaction in your bank’s app.
• Use card controls to disable online, international or contactless use when you do not need them.
• Prefer wallets or virtual cards for online purchases and unfamiliar sites.
• Look at the terminal. Loose parts, odd overlays or a card slot that wobbles are warning signs, especially at unattended machines.
• Never share OTPs or PINs, even with someone who sounds official.
• Report loss at once. Block the card in the app first, then call the bank.

Six common myths (tap to open)

Quick quiz: test yourself

Tap each question to reveal the answer and the reasoning behind it.

Frequently asked questions

The post How Does a Credit Card Chip Stop Cloning? appeared first on Learn With Examples.

The problem Git solves

I started programming long before Git was everywhere, and I remember what folders looked like in those days. site_backup, site_backup_old, site_NEW, site_NEW_fixed, and one called site_dont_touch. Nobody knew which was current. When a client said “the version from last Tuesday was better,” the honest answer was often “I think I overwrote it.”

Now picture a team of five editing the same files. Two people change the same paragraph. Someone emails a zip file. Someone else works from an older copy. Merging all of that by hand is miserable, and mistakes are guaranteed.

Version control is the fix. Instead of copying folders, you tell a tool when you have reached a meaningful point, and it stores a snapshot. The most popular version control system in the world is Git, created in 2005 by Linus Torvalds for the Linux kernel. Today it is used by solo students, small studios and the largest software companies alike.

Git vs GitHub: the part everyone mixes up

Beginners often use the two names as if they were one thing. They are not, and the difference matters.

• Git is software that runs on your own computer. It works offline. It does the actual tracking of changes.
• GitHub is a company’s website (owned by Microsoft) that hosts Git repositories in the cloud and adds features around them: pull requests, issue tracking, code review and project pages.

The analogy I use in workshops: Git is a camera, and GitHub is the photo-sharing site. You can take photos without ever uploading them, but the website makes it easy to back them up and show them to others. Similar sites exist, including GitLab and Bitbucket. They all speak Git.

The vocabulary you need (and nothing more)

Git has a reputation for jargon. In reality, you need about eight words, and each has a plain-English meaning.

How a change travels through Git

This is the single most useful mental model in the whole subject, and almost every beginner tutorial skips it. A change passes through four places.

• Working folder: the files you see and edit on your computer.
• Staging area: a waiting room where you choose exactly which changes go into the next snapshot.
• Local repository: the saved history of commits, stored in a hidden .git folder.
• Remote (GitHub): the copy online that teammates can reach.

The staging area surprises people. Why not save everything at once? Because it lets you craft tidy commits. Imagine you fixed a typo and also started a risky new feature in the same afternoon. Staging lets you commit the typo fix by itself, with a clear message, and leave the unfinished feature for later.

Setting up: install and introduce yourself

Download Git from the official site (git-scm.com) or install it with your system’s package manager. Then check that it works.

git --version

Next, tell Git who you are. Every commit carries a name and email, so this is a one-time setup.

git config --global user.name "Your Name"
git config --global user.email "[email protected]"
git config --global init.defaultBranch main

The last line makes new repositories start with a branch called main, which matches what GitHub uses today. Older installs may still default to master, so setting it avoids confusion.

Your first repository, step by step

Let us track a small recipe collection. Open a terminal, make a folder and start Git inside it.

mkdir recipes
cd recipes
git init

Git replies with something like:

Initialized empty Git repository in /home/you/recipes/.git/

Now create a file called pasta.txt with three lines of text in any editor, then ask Git what it sees.

git status

On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	pasta.txt

nothing added to commit but untracked files present (use "git add" to track)

“Untracked” means Git sees the file but is not recording it yet. git status is your best friend: run it constantly, especially when confused. Now stage the file and commit it.

git add pasta.txt
git commit -m "Add pasta recipe"

[main (root-commit) a1b2c3d] Add pasta recipe
 1 file changed, 3 insertions(+)
 create mode 100644 pasta.txt

Congratulations, you have made your first snapshot. The odd string a1b2c3d is the start of a commit’s unique ID. (Yours will look different; the examples here use made-up IDs.) Add a sauce recipe and a typo fix the same way, and your history looks like this.

git log --oneline

1f2e3d4 (HEAD -> main) Add dessert
7c8d9e0 Fix typo
e4f5a6b Add sauce
a1b2c3d Add pasta recipe

Every dot in that chain is a version you can return to. That is the whole magic: history becomes a thing you can read, search and travel through.

Writing commit messages people will thank you for

A commit message is a note to your future self, and to everybody else. Compare these two histories:

• “stuff”, “fix”, “fix 2”, “asdf”
• “Add login form validation”, “Fix crash when email is empty”, “Remove unused styles”

The second tells a story. A few habits help: write in the imperative (“Add”, not “Added”), keep the first line under about 50 characters, and describe what and why, not how. Six months later, when something breaks, you will be searching that history for answers, and clear messages turn a two-hour hunt into a two-minute one.

Telling Git what to ignore

Not every file belongs in version control. Passwords, API keys, temporary files and huge generated folders should stay out. Create a plain text file named .gitignore and list patterns.

.env
node_modules/
*.log
.DS_Store

This is more than tidiness. Never commit secrets such as API keys or passwords. Once something is pushed to a public repository, bots can find it within minutes. If it happens, rotate the key immediately. Deleting the file later does not erase it from history.

Branches: safe places to experiment

A branch is simply a movable label on a line of commits. Your main branch holds the version that works. When you want to try something, you create a new branch, work there, and leave main untouched.

git switch -c feature/bigger-portions
# edit files, then
git add pasta.txt
git commit -m "Increase pasta portion size"

Think of it as photocopying a document to scribble on, with the guarantee that the original stays clean. If the idea works, you merge it in. If it does not, you delete the branch and nothing is lost.

When you are ready, switch back to main and merge.

git switch main
git merge feature/bigger-portions

Merge conflicts are not scary

Sometimes two branches change the same line. Git cannot guess which you want, so it stops and asks you to decide. It marks the file like this.

<<<<<<< HEAD
Use 200g of spaghetti
=======
Use 250g of spaghetti
>>>>>>> feature/bigger-portions

The top part is your current branch, the bottom part is the incoming one. Edit the file to keep what you want (and delete the marker lines), then git add it and git commit. A conflict is just Git being polite and asking a question. In teams, conflicts become rare once people commit small changes often and pull regularly.

Bringing in GitHub

So far everything has lived on your computer. Now let us put it online. Create a free account at github.com, click the button to create a new repository, and name it recipes. GitHub will show you the web address of your empty repository. Connect your local project to it and upload.

git remote add origin https://github.com/YOU/recipes.git
git branch -M main
git push -u origin main

Here origin is just the nickname Git gives to your main remote. The -u flag remembers the connection so that later you can type only git push and git pull.

A practical note on logging in: GitHub no longer accepts your account password for Git operations over HTTPS. Use a personal access token, set up SSH keys, or install the GitHub CLI or Git Credential Manager, which handle sign-in for you. Their setup pages walk through it in a few minutes.

To get a project that already exists on GitHub onto your machine, you clone it.

git clone https://github.com/YOU/recipes.git

That downloads every file and the whole history, and sets up origin automatically.

Pull requests: how teams actually work

On a team, nobody pushes straight to main. Instead, the loop looks like this.

A pull request (often shortened to PR) is a page on GitHub that shows exactly what changed between your branch and main. Teammates can comment on specific lines, request changes and approve. When everyone is happy, someone clicks Merge. Automated checks, such as tests, can run on the PR too, so a broken change is caught before it reaches the shared code.

I have watched this process save projects. A new developer once pushed a change that would have deleted a customer table. Two people spotted it in review because the diff showed hundreds of red lines where there should have been five. Without a pull request, that change would have gone straight to production.

Five real situations, five workflows

Tap through the tabs. Each one shows a realistic scenario with the actual commands.

git init
git add pasta.txt
git commit -m "Add pasta recipe"
git log --oneline

# discard edits you have not committed
git restore pasta.txt

# take a file back out of the staging area
git restore --staged pasta.txt

# undo a commit by adding a new opposite commit
git revert 7c8d9e0

git switch -c feature/search
# ...edit files...
git add .
git commit -m "Add search box"
git push -u origin feature/search
# open a pull request on GitHub, get a review, merge
git switch main
git pull

# click Fork on GitHub, then:
git clone https://github.com/YOU/project.git
cd project
git switch -c fix-typo
# fix the typo, then
git commit -am "Fix typo in README"
git push -u origin fix-typo
# open a pull request to the original project

git add index.html
git commit -m "Launch portfolio"
git push origin main
# On GitHub: Settings, Pages, deploy from branch main

You will notice the same handful of commands appearing in every tab. That is the good news: the entire daily workflow of most developers is built from perhaps ten commands.

A beginner’s cheat sheet

A daily routine you can copy

• Morning: run git switch main and git pull so you start from the latest version.
• Before starting a task: create a branch with git switch -c and a descriptive name.
• While working: run git status and git diff often, and commit each small finished step.
• When done: push the branch and open a pull request.
• After the merge: switch back to main, pull, and delete the old branch.

It feels like a lot at first, and then one day you realise you have stopped thinking about it. That is when Git becomes a superpower instead of a chore.

Seven mistakes beginners make (tap to open)

Quick quiz: test yourself

Tap each question to reveal the answer and the reasoning.

Frequently asked questions

The post Git and GitHub Explained for Beginners (With Real Examples) appeared first on Learn With Examples.

A story I tell every new analyst

Years ago I worked with a team that monitored server performance. They had an alert that fired whenever response time crossed a threshold. In the first month it fired forty times, and thirty-nine were nothing. By the second month, people stopped reading the messages. In the third month the one alert that mattered arrived, and it sat unread for two hours while a real outage grew.

That team had made both classic mistakes, one after the other. First they set the alarm too jumpy, which produced false alarms. Then, by training everyone to ignore it, they made real signals get missed. If you understand why that happened, you already understand the core of this article.

Here is the promise: by the end, you will be able to name each error, explain the trade-off between them, use the words alpha, beta and power without flinching, and decide which error matters more in a given situation. No advanced maths required. When the numbers do appear, I have computed them so you can follow along.

The idea of a null hypothesis in plain words

Before we can talk about errors, we need one setup idea. Almost every statistical test begins with a boring default assumption called the null hypothesis, written H0. It says “nothing is going on.” The new drug does nothing. The new web page converts no better than the old one. The coin is fair. The defendant is innocent.

Then you look at evidence and ask a single question: is this evidence surprising enough, under the assumption that nothing is going on, that I should stop believing it? If yes, you reject the null. If not, you fail to reject it, which is different from proving it true. It just means you did not find enough evidence.

The four possible outcomes

Any test ends in one of four situations, depending on what is true in reality and what the test says. Two are correct decisions and two are errors. The grid below is worth memorising.

Look at how symmetrical the grid is, and how differently the errors feel. A false alarm is loud and visible: someone complains, someone investigates, someone wastes an afternoon. A missed signal is silent by nature. Nobody notices what did not happen. That imbalance in visibility is why people routinely underweight Type II errors.

The memory trick that actually works

Students confuse the two constantly, and honestly so did I in the beginning. The trick that finally fixed it for me is the boy who cried wolf.

• The first time, he shouts “Wolf!” and there is no wolf. That is a false alarm: Type I. Type one, the first mistake in the story.
• The second time, a real wolf shows up and the villagers ignore him. That is a missed signal: Type II. Type two, the second mistake.

The order in the fable matches the numbering. If you remember nothing else from this article, remember the wolf.

Alpha and beta: the two probabilities behind the errors

Each error has a probability with a Greek letter attached.

• α (alpha) is the probability of a Type I error. It is also called the significance level, and you choose it before you look at the data. The most common choice is 0.05, meaning you accept a 5% false-alarm rate when nothing is really happening.
• β (beta) is the probability of a Type II error, the chance you miss a real effect.
• Power = 1 − β is the probability you catch a real effect. Researchers often aim for at least 80%.

Think of alpha as how easily you are fooled by noise, and power as how well you can hear a real signal. A good study keeps the first low and the second high.

Seeing the trade-off with two overlapping curves

Here is the picture I draw on whiteboards. There are two bell curves. The left one shows what your test statistic looks like when nothing is going on. The right one shows what it looks like when there is a real effect. You choose a cut-off: any result to the right of the line triggers the alarm.

The red tail is the false-alarm zone. Even when nothing is going on, a small share of results land beyond the line, and with this cut-off that share is 5.0%. The blue tail is the missed-signal zone. When the effect is real, some results still fall short of the line, and here that is 19.6%.

Now imagine sliding the cut-off. Move it to the left, and you catch more real effects but raise more false alarms. Move it to the right, and false alarms shrink while you miss more real effects. You cannot push both down by sliding the line. This is the fundamental trade-off of hypothesis testing. Here are actual numbers for four cut-off positions on this same pair of curves.

Read down the columns. As the cut-off rises, the false alarms fall from a wild figure to a tiny one, but the missed signals climb steadily. There is no free lunch. The only question is which mistake you can better afford.

Which error is worse? It depends on the stakes

This is the part that separates textbook knowledge from professional judgment. There is no universal answer; the answer depends on what each mistake costs. Tap through five situations below.

Notice the pattern. Courts guard hard against Type I errors (convicting the innocent). Smoke alarms guard hard against Type II errors (missing a fire). Spam filters lean cautious about Type I errors (losing real mail). Screening programs accept lots of false alarms to avoid misses. In every case the threshold is a moral and practical choice wearing the costume of a number.

A closer look at medical screening

Medical tests give the clearest illustration of why false alarms are common even when a test is good. Suppose a condition affects 2% of a population. A screening test correctly flags 90% of people who have it (sensitivity) and correctly clears 95% of people who do not (specificity). Sounds excellent. Now screen 10,000 people.

• 200 people have the condition. The test catches 180 and misses 20 (Type II errors).
• 9,800 people are healthy. The test wrongly flags 490 of them (Type I errors) and correctly clears 9310.

That gives 670 positive results, of which only 180 are real. If you get a positive result, the chance you actually have the condition is about 27%. This surprises almost everyone. It does not mean the test is bad. It means the condition is rare, so even a small false-alarm rate produces a big pile of false alarms in absolute terms. This is why doctors follow up screening with a second, more specific test, and why a single positive result is a reason to investigate rather than a diagnosis.

How to reduce both errors: more data

If moving the cut-off only swaps one error for another, how do you get better on both? The answer is to sharpen the picture itself. A larger sample makes the two bell curves narrower, so they overlap less. With less overlap, you can hold false alarms at 5% and still catch far more real effects.

Here is a concrete illustration. Suppose a real effect exists that is about 0.3 standard deviations in size, which is modest. With a one-sided test at α = 5%, power grows with sample size like this.

A study with 10 subjects has a small chance of detecting this effect at all, and its “no significant difference” result would be nearly meaningless. It tells you the study was too small, not that the effect is absent. This is one of the most common misreadings of research: treating a failure to find something as proof that nothing is there.

Other ways to raise power include reducing noise in the measurements, using a more precise instrument, comparing matched pairs instead of independent groups, and looking for larger effects. Statisticians call planning this before a study “a power analysis,” and it is one of the cheapest ways to avoid wasting a research budget.

A worked example: the A/B test

Let me show you the numbers in a familiar business setting. You redesign your checkout page and compare it against the old one across 100 head-to-head comparisons. Under the null hypothesis, the new page is no better, so each comparison is like a fair coin flip and you would expect about 50 wins.

You decide in advance that you want no more than a 5% false-alarm rate. Working through the exact binomial probabilities, that means you declare the new page better only if it wins at least 59 of 100. Under a fair coin, the chance of hitting that bar by luck is 4.4%. That is your effective Type I error rate.

Now suppose the new page really is better and wins 60% of the time. How often would this test detect that? Only about 62% of the time. The other 38% of the time you would return “no significant difference” and shelve a page that really was better. That is a Type II error, and it is expensive because nobody ever finds out about the money that was left on the table.

The fix is not to loosen alpha. It is to collect more comparisons. If you had 400 comparisons instead of 100, the same 60% effect would be detected far more often while the false-alarm rate stays at 5%.

The multiple-testing trap: false alarms pile up

Here is a hazard that catches even experienced people. An alpha of 5% sounds low. But it applies to each test separately. If you run many tests on data where nothing is truly going on, the chance of at least one false alarm grows fast.

Run 20 tests and you have a 64% chance of at least one “significant” result by pure luck. Run 50 and it is 92%. This is the mathematical heart of “p-hacking”: slicing the data many ways until something looks significant. It is also why a marketing dashboard with forty metrics will always show a few “winners.” The remedy is to decide your hypotheses in advance, limit the number of comparisons, or adjust the threshold using methods such as the Bonferroni correction, which divides alpha by the number of tests.

What the p-value has to do with all this

The p-value is the probability of seeing data at least as extreme as yours, assuming the null hypothesis is true. You compare it with your pre-chosen alpha: if p is below alpha, you reject the null. The p-value itself is not the probability that the null is true, and it is not the probability that you made an error on this particular test. The false-alarm rate belongs to the procedure across many uses, and alpha sets it.

A quick way to hold both ideas: alpha is the standard you set before the race; the p-value is the time you actually ran.

Real-world places these errors hide

One more subtlety worth knowing: which error is called “Type I” depends on how you phrase the null hypothesis. If you flip the null and alternative, the labels flip. In practice, the null is the cautious default, and you should always state it out loud before you decide what each error means.

Six mistakes I keep seeing (tap to open)

Quick quiz: test yourself

Tap each question to reveal the answer and its reasoning.

Frequently asked questions

The post Type I vs Type II Errors: False Alarms and Missed Signals appeared first on Learn With Examples.

The problem with “the average”

I have reviewed reports for a long time, and the sentence that worries me most is: “the average delivery time is 27 minutes.” It sounds precise. But is every delivery close to 27, or do half arrive in 15 and the rest take 40? The average cannot tell you. It describes the centre of your data and says nothing about how spread out the values are.

Spread matters in daily life more than most people realise. A commute that averages 35 minutes but sometimes takes 75 makes you leave early. A salary band with an average of ₹67k that is really one founder and eight employees makes the average meaningless. A medicine that lowers blood pressure by 10 points on average but by 40 for some people and zero for others deserves a very different conversation.

So we describe data with two questions: where is the middle, and how far apart are the values? This article is about the second question, with the simplest measure first (range), the smarter measure next (IQR), and the quartiles that connect them.

Range: the quick, blunt measure

The range is the easiest statistic in the book. Sort the data, subtract the smallest from the largest, done. If eleven students score 52, 58, 61, 64, 67, 70, 72, 75, 78, 84 and 95, the range is 95 − 52 = 43 marks.

The range has real virtues. It is instant to compute, easy to explain to anyone, and good for sanity checks: a thermometer reading range of 200 degrees in one day tells you a sensor is broken. Many everyday questions are really range questions: “What is the cheapest and the most expensive flight?” “What are the coldest and hottest days this week?”

But the range has one serious flaw. It uses only two numbers, and they are the two most extreme ones. Everything in between is ignored. Change one value in the middle and the range does not budge. Change one extreme value and the range can explode. That makes it fragile.

Picture ten homes in a neighbourhood priced between ₹38 lakh and ₹64 lakh. Now a farmhouse worth ₹410 lakh sells at the edge of town. The range leaps from about 26 lakh to 372 lakh, even though nothing changed for the other nine families. That is exactly the situation where we need something sturdier.

Quartiles: cutting your data into four equal groups

You already know the idea from the median: line the data up in order and split it in half. Quartiles take that one step further and split the ordered data into four groups with (about) the same number of values in each.

• Q1 (first quartile, the 25th percentile): a quarter of the data sits at or below it.
• Q2 (second quartile): this is simply the median, with half the data on either side.
• Q3 (third quartile, the 75th percentile): three quarters of the data sits at or below it.

Here is a small example you can see rather than imagine. Twelve colleagues report their commute times in minutes. The dots are sorted, and colours mark the four groups of three.

Notice that quartiles are not fancy. They are just three cut-points that make four equal piles. Q1 is 28.5, the median is 36.5, and Q3 is 47.5 minutes. A quarter of people commute 28.5 minutes or less, half commute 36.5 or less, and three quarters commute 47.5 or less.

How to find quartiles by hand, step by step

Let me walk through the method most textbooks teach, using the eleven exam scores. This is the one I recommend learning first because you can do it on paper without any software.

Step 1: Sort the data

52, 58, 61, 64, 67, 70, 72, 75, 78, 84, 95. Always sort first. Skipping this step is the most common way to get a wrong answer.

Step 2: Find the median (Q2)

There are 11 values, so the middle one is the 6th: 70. Five values sit on each side.

Step 3: Find the median of the lower half (Q1)

The lower half is 52, 58, 61, 64, 67. Its middle value is 61. That is Q1.

Step 4: Find the median of the upper half (Q3)

The upper half is 72, 75, 78, 84, 95. Its middle value is 78. That is Q3.

Step 5: Subtract to get the IQR

IQR = Q3 − Q1 = 78 − 61 = 17. So the middle half of the class scored within a 17-mark window, even though the full range is 43.

What about an even number of values?

With 12 commute times, there is no single middle value, so the median is the average of the 6th and 7th values. Then you split the data cleanly into two halves of six and find the median of each. The lower half is 22, 25, 27, 30, 32, 35, and its median is (27 + 30) / 2 = 28.5. The upper half is 38, 41, 45, 50, 58, 75, and its median is (45 + 50) / 2 = 47.5. That is where Q1 = 28.5 and Q3 = 47.5 came from. No mystery.

Why your calculator and Excel sometimes disagree

Here is something nobody warns you about. If you compute quartiles in Excel and compare with the textbook, you may get a slightly different answer. That does not mean anyone made a mistake. There are several accepted methods for defining quartiles, and they agree on large data but can differ on small datasets. Here is the same exam data run through three common methods.

And for the twelve commute times:

The answers differ by a point or two. In real analysis with hundreds of records, the difference is negligible. In an exam, follow the method your teacher uses. In a report, mention which method your software uses, or just stay consistent. I once saw a two-hour argument between two analysts who were both correct, using different quartile definitions. Do not be those two.

The five-number summary

Once you have quartiles, you can describe any dataset with just five numbers: minimum, Q1, median, Q3 and maximum. It is called the five-number summary, and it is the backbone of the box plot.

Five numbers, and you already know where the centre is, how wide the middle half is, and how far the extremes reach. That is a lot of information in one row.

Same range, very different classes

Now the payoff. Here are two classes of ten students. Both have a lowest score of 45 and a highest of 95. Both have a range of 50. Any teacher looking only at the range would say the classes look identical.

Class X has an IQR of only 6. Most students scored between 62 and 68, with two students far away at the edges. Class Y has an IQR of 25, with scores spread evenly from 55 to 80 in the middle half. Same range, wildly different teaching challenges. In Class X you teach to the pack and support two outliers. In Class Y you need differentiated instruction across the whole room.

This is why I say the IQR is often the honest sibling of the range. It answers “how spread out are the typical values?” rather than “how far apart are the two weirdest values?”

Outliers and the 1.5 × IQR rule

The IQR does a second job that I use constantly: it gives you a fair way to flag unusual values. The statistician John Tukey proposed a simple rule that is now standard in box plots.

For the exam scores, the fences are 35.5 and 103.5, so nobody is unusual. Now look at the startup where nine people earn between 28 and 45 (thousand rupees a month) and the founder takes 320.

The upper fence is 62.25, so 320 is flagged. Two things are worth noticing. The mean pay is 67.2, higher than eight of the nine people, so the average paints a false picture. The median is 36, which is far more representative. And the IQR of 12.5 describes the spread among typical employees, uninfluenced by the founder. Whenever a dataset has one or two giant values, the median and the IQR should be your default pair.

A word of caution I give every junior analyst: an outlier flag is a prompt to investigate, not a permission slip to delete. It might be an error (someone typed 410 instead of 41), or it might be the most important data point you have. Look before you remove.

Range versus IQR on the same datasets

To see the difference at a glance, here are four datasets used in this article, each with its range (orange) and IQR (navy).

For exam scores and commute times the two measures are in the same neighbourhood. For house prices and startup pay, the range towers over the IQR because of one extreme value. That gap is itself a diagnostic: when the range is many times bigger than the IQR, you almost certainly have outliers or heavy skew.

Five real cases to explore

Tap a tab below. Each example uses actual numbers I ran through the method, with the sorted data shown so you can check my work by hand.

In every tab, the same routine applies: sort, find the median, find the halves’ medians, subtract, check the fences. Learn the routine once and you can use it on any list of numbers, from test marks to server response times.

Reading a box plot like a professional

A box plot squeezes the five-number summary into a picture. Once you know the anatomy, you can read one at a glance.

• The box spans Q1 to Q3, so its width is the IQR. A wide box means a wide spread among typical values.
• The line inside is the median. If it is off-centre in the box, the data is skewed.
• The whiskers reach the smallest and largest values that are still inside the fences.
• The dots beyond the whiskers are the flagged outliers.

Two extra reading tips. If the median sits close to Q1 and the upper whisker is long, the data is skewed to the right, as with incomes or house prices. And when you compare several box plots, look at the boxes first and the whiskers second. The boxes tell you about typical performance, and the whiskers tell you about extremes.

Where these measures show up in real life

In finance, the middle 50% of returns or prices is often more informative than the extremes. In education, admissions offices publish the middle 50% of test scores for admitted students. In sports analytics, a player’s IQR of scores describes consistency: a wide IQR means unpredictable, a narrow one means reliable.

Range, IQR or standard deviation?

You will sometimes be asked which measure of spread to use. Here is my rule of thumb after years of picking wrongly and correcting myself.

• Use the range for quick checks, small datasets and situations where the extremes themselves matter, such as safety limits.
• Use the IQR with the median when the data is skewed or contains outliers: incomes, prices, response times, hospital stays.
• Use the standard deviation with the mean when the data is roughly symmetric and you plan further statistical work.

None of these is universally best. Each answers a slightly different question, and reporting two of them together, such as the median and the IQR, usually gives a fair picture.

Seven mistakes I see all the time (tap to open)

Quick quiz: test yourself

Tap each question to reveal the answer and the working.

Frequently asked questions

The post Range, IQR and Quartiles Explained appeared first on Learn With Examples.

The puzzle, exactly as it is usually told

The French mathematician Joseph Bertrand published this puzzle in 1889, and more than a century later it still catches smart people out. I have used it in workshops for years, with analysts, teachers and engineers, and the pattern is remarkably stable: about four in five people answer 50% within seconds and defend it with real conviction.

Here is the setup. There are three identical boxes, each with two drawers. Inside them:

You choose a box at random, open one drawer at random, and see a gold coin. What is the probability that the other drawer in the same box also holds gold?

Before I explain, I want you to feel why 50/50 is so seductive, because if you understand the temptation you will spot the same mistake in a medical report or a court case.

The argument that feels airtight

Here is the reasoning almost everybody uses. “I drew a gold coin, so this cannot be the silver-silver box. That leaves two boxes: gold-gold and gold-silver. They were equally likely at the start, so it is a coin toss whether I am holding the gold-gold box or the mixed one. Half the time the other coin is gold.”

Every sentence in that paragraph sounds fine. The first step is correct: silver-silver is out. The second step is where it quietly goes wrong. The two remaining boxes were equally likely before you saw a coin. But you did not just learn that the box is not silver-silver. You learned something more specific: a gold coin came out. And the two boxes are not equally good at producing gold coins.

• The gold-gold box can only ever give you gold.
• The gold-silver box gives you gold only half the time.

So the observation of gold is stronger evidence for the box that always produces it. That is the whole secret. Evidence does not just eliminate possibilities; it reweights the ones that survive.

The clean way to solve it: count coins, not boxes

When I teach this, I tell people to stop thinking about boxes altogether. Boxes are a distraction. The thing that is randomly chosen, in effect, is one of six coins, each equally likely to be the coin you touch. Label them and list their situations.

Now apply the evidence. You saw gold, so throw away every case where you drew silver. Three outlined cases remain:

• Gold coin A from the gold-gold box. The other coin is gold.
• Gold coin B from the gold-gold box. The other coin is gold.
• The gold coin from the mixed box. The other coin is silver.

Three equally likely possibilities, and in two of them the other coin is gold. That gives 2/3. No formulas, no jargon, just counting the things that really are equally likely.

The reason I love this puzzle as a teaching tool is that the correct method is a habit rather than a trick: list the equally likely basic outcomes, cross out the ones that contradict what you saw, and count what is left. Once you adopt that habit, entire families of confusing probability questions become easy.

Do not trust me: run the experiment

Whenever a probability answer feels wrong, do not argue about it, simulate it. I wrote a short program that repeats the experiment: pick a box at random, open a random drawer, keep the run only if the coin is gold, and record whether the other coin was also gold. Here are the results, at increasing numbers of gold-first draws.

At 10 draws the number can bounce around, because small samples are noisy. At 1,000 draws it sits close to two thirds, and by 100,000 it is unmistakable. This is the law of large numbers doing what it does. If you want to convince a stubborn colleague, a simulation is more persuasive than any argument, because it removes the feeling that you are just trying to trick them with words.

You can even do a physical version at home. Put two gold and one silver stickers on a few index cards, or use red and white cards, and repeat it about fifty times. You will see about two thirds emerge, not exactly, but clearly.

The same idea, five different costumes

Bertrand’s puzzle is not really about coins. It is about how new information changes probabilities when the information arrives through a process that favours some cases over others. Once you have the pattern, you will start noticing it everywhere. Tap through the tabs below. Each one is a real, well-known version of the same reasoning, with the numbers worked out.

Notice how each tab has the same three moves: list the equally likely cases, remove the ones contradicted by the evidence, and count what remains. The medical and spam examples add a fourth idea, that rare things stay rare even after a positive signal, which brings us to Bayes.

The Bayes view: updating your beliefs

Statisticians phrase all of this in terms of Bayes’ theorem. Do not let the name scare you. It is a rule for updating a belief when you get new evidence. Start with what you believed before (the prior), ask how likely the evidence is under each possibility (the likelihood), and rescale.

For the boxes:

• Prior: each box is chosen with probability 1/3.
• Likelihood of drawing gold: gold-gold gives 1, gold-silver gives 1/2, silver-silver gives 0.
• Multiply: 1/3 × 1 = 1/3 for gold-gold, 1/3 × 1/2 = 1/6 for gold-silver, 0 for silver-silver.
• Rescale so the total is 1: gold-gold gets (1/3) / (1/2) = 2/3, gold-silver gets 1/3.

The two thirds falls right out. The gold-gold box started at one third and rose to two thirds because it was better at explaining the evidence. Same answer, different language. Some people find the coin-counting version more natural, others the Bayes version. I suggest learning both, because when the numbers get bigger, Bayes becomes the safer bookkeeping.

Where this goes wrong in real life

Medical screening

Consider a test for a condition that affects 1% of people. The test catches 90% of true cases and wrongly flags 9% of healthy people. You test positive. Intuition shouts that you are 90% likely to be sick. Let us count in a population of 10,000.

Of the 100 sick people, 90 test positive. Of the 9,900 healthy people, 891 also test positive. So among 981 positives, only 90 are truly sick: about 9.2%. The test is not bad. The condition is just rare, so false alarms outnumber true detections. Doctors in famous studies have made this exact error, which is why good clinics follow a positive screening with a confirmatory test rather than reacting to the first result.

Fraud alerts and spam filters

Banks send you a “suspicious transaction” text. Most of the time it is a false alarm, because fraud is rare among millions of transactions. This does not mean the fraud system is broken. It means its precision is limited by the base rate, and it is a deliberate trade: a few annoying alerts for a lot of caught fraud.

Evidence in court

Lawyers call the mistaken version the prosecutor’s fallacy: taking “the chance of this evidence if the person were innocent is one in a million” and hearing it as “the chance the person is innocent is one in a million.” Those are two different conditional probabilities. Confusing them has contributed to real miscarriages of justice, and it is the same logical slip as reading “gold came out of the gold-gold box” as if it were “the box is gold-gold.”

Hiring and screening

A company designs a screening test that 95% of great candidates pass. Then it assumes anyone who passes is 95% likely to be great. If only a small percentage of applicants are great, most passers are not. Again the rate at which the thing occurs in the population is the piece people forget.

Why our brains keep choosing 50/50

Psychologists have a few explanations, and I find them all helpful when I am teaching this.

• We count the visible options, not the weights. After the silver box is excluded, two boxes are visible, so we say half and half. The weights are invisible unless you deliberately look for them.
• We confuse the box with the coin. The question is about boxes in our heads, but the random selection was really about coins.
• We love symmetry. Two options often feel symmetrical even when they are not. The mind reaches for 50/50 when it is unsure.
• We ignore how evidence was generated. A gold coin is more likely to appear from a box with more gold in it. Whenever a signal is easier to get from one hypothesis than another, seeing the signal shifts the odds.

Once you know these four traps, you can build a checklist. It is what I use before I trust any probability I have just worked out in my head.

Variations that test your understanding

A good way to make sure you really understand a puzzle is to change it slightly and predict what happens. Try these.

What if you are told only that the box is not silver-silver?

Then the two remaining boxes really are equally likely, and the chance that the box is gold-gold is exactly 1/2. The difference between this and the original is that you did not see a coin. The coin observation is what carries the extra weight. This variation is a fantastic reminder that how you learned something can matter as much as what you learned.

What if a coin is chosen at random from the gold coins?

Suppose someone gathers all three gold coins and hands you one at random, then asks whether its box-mate is gold. You would get the same 2/3, because you are effectively picking among the same three cases.

What if there are four boxes?

Add a second gold-silver box. Now there are four gold coins in total, two in the gold-gold box and two in the mixed boxes. Draw gold, and the chance the other coin is gold is 2 out of 4, or 1/2. The count changes, so the answer changes. This shows the method is flexible: nothing magical about two thirds, it is simply the result of the count.

What if the coin-drawing is not random?

If somebody peeked and deliberately showed you a gold coin whenever they could, the mechanism changes and the probabilities can change again. This is the same subtlety that makes the Monty Hall problem sensitive to the host’s rules. Always ask how did this evidence reach me?

A short history and why the name “paradox” is fair

Strictly speaking it is not a contradiction; the mathematics is completely consistent. It is usually called a veridical paradox: the answer is true, but it clashes with a strong intuition. The name “paradox” was attached to the puzzle later, and it is not something I would claim Bertrand himself chose. What he did give us is a lovely argument for why 1/2 cannot be right, and it needs no counting at all.

The symmetry argument against 1/2

Choose a box. Before you look at anything, the chance that it holds two coins of the same kind is 2/3, because two of the three boxes are matched. Now point to a drawer. You will see gold or silver. If seeing gold moved the chance of a matching box down to 1/2, then by symmetry seeing silver would move it to 1/2 as well. But if it moves to 1/2 whichever coin you see, you did not need to look: the answer was already 1/2 before opening the drawer, which contradicts the 2/3 we started with. The probability cannot change by looking when every possible look changes it the same way. So it stays at 2/3, and the matching box is just as likely to contain gold as silver. That is the cleanest way I know to see why the tempting answer fails.

The same family includes the Monty Hall problem and the two-child problem. If you enjoy Bertrand’s boxes, those are the natural next puzzles. They share a structure: some information is revealed, and the trap is to treat the remaining cases as equally likely when they are not. One caution on the two-child family: small changes in wording can really change the answer. “At least one is a boy” gives 1/3 for two boys, while “at least one is a boy born on a Tuesday” gives 13/27. The day is not irrelevant, because it changes which families qualify, and the symmetry argument above does not carry over: a family can have boys born on several different days, so the possible Tuesday-style announcements overlap instead of splitting the families into clean groups. The answer also depends on how you learned the fact. Meeting a random child who turns out to be a boy born on a Tuesday leads back to 1/2 for the other child.

The Sleeping Beauty problem is a different kind of puzzle, and I would not file it here. It asks about a self-locating belief after memory erasure, and thoughtful people still disagree. “Thirders” say 1/3 and “halfers” say 1/2, depending on how they model what waking up tells her. There is no settled consensus, so treat anyone who calls it closed with some suspicion.

Five mistakes people make with conditional probability

Quick quiz: test yourself

Tap a question to reveal the answer and its reasoning.

Frequently asked questions

The post Bertrand’s Box Paradox: Why “It’s Obviously 50/50” Is Wrong appeared first on Learn With Examples.

Why I still start every probability class with a coin

I have spent a lot of years explaining probability to engineers, analysts, nurses, marketers and one very patient group of warehouse supervisors. Every time, I start with a coin, and every time somebody looks slightly insulted. A coin? Really? But a coin is the cleanest possible laboratory. Two outcomes, no hidden moving parts, a probability everyone already believes. Once the coin makes sense, you can swap the word “heads” for “defective charger” or “customer clicked” or “seed sprouted” and the maths does not change at all.

That swap is the whole story of the binomial distribution. It is the tool for counting successes when you repeat the same yes-or-no event a fixed number of times. It answers questions like these:

• If I flip a coin 10 times, what is the chance of exactly 4 heads?
• If 5% of chargers are faulty and I test 20, how likely is it that I find none?
• If a shooter makes 80% of free throws, how likely is a perfect night?
• If I email 200 people and 5% usually click, is 15 clicks luck or a real improvement?

By the end of this article you will be able to answer all four, by hand if you want, and you will know when the answer can be trusted and when it cannot. We will move from coin flips to quality control, then into free throws, exam guessing, email campaigns and airline overbooking. There is a small interactive panel, a few graphics, a quiz and an FAQ at the end.

Is my situation actually binomial? The four checks

Before you use any formula, check that the situation qualifies. Skipping this step is the number one source of bad statistics I have seen in reports over the years. The formula will happily give you a number even when the setup is wrong. A wrong setup just gives you a confident wrong number.

A quick habit that helps: say the four conditions out loud about your problem. “I have 20 chargers, each is defective or not, one charger does not affect another, and the defect rate is 5% for all of them.” If any sentence makes you hesitate, stop and think before calculating.

The coin flip: building the idea from scratch

Let us take the smallest interesting case. Flip a fair coin 4 times and ask for exactly 2 heads. Each flip is independent and heads has probability 0.5, so any particular sequence of four flips has probability 0.5 × 0.5 × 0.5 × 0.5 = 1/16.

Now the key question: how many different sequences contain exactly two heads? Here they are all.

There are six. Each has probability 1/16, and they cannot happen together, so we add them: 6 × 1/16 = 6/16, which is 37.50%. That is the entire logic of the binomial distribution. Count the ways, then multiply by the probability of each way.

Listing sequences works for four flips. For twenty flips you would need over a million lines. So mathematicians invented a shortcut for the counting part, and it has a friendly name: “n choose k.”

Counting the ways with Pascal’s triangle

The number of ways to choose k successes among n trials is written C(n, k). You can compute it with factorials, but there is a prettier way. Each number in Pascal’s triangle is the sum of the two numbers above it, and row n, position k gives C(n, k). The highlighted circle below is C(4, 2) = 6, our six coin sequences.

Notice how the numbers rise toward the middle of each row. There are far more ways to get a balanced result than an extreme one. Only one sequence gives 4 heads out of 4 (HHHH), but six give 2 heads out of 4. That simple fact is why the middle of the binomial chart is always the tallest for a fair coin.

The formula, one piece at a time

People stare at this and feel intimidated. Do not. It is three pieces you already understand:

• C(n, k) counts how many different orders produce exactly k successes.
• p^k is the probability that k particular trials all succeed.
• (1 − p)^{n − k} is the probability that all the remaining trials fail.

Worked example: exactly 5 heads in 10 fair flips

Here n = 10, k = 5, p = 0.5. Then C(10, 5) = 252. Each specific sequence has probability 0.5¹⁰ = 1/1024. So the probability is 252/1024, which is 24.6%. Not quite one in four. Most people guess it is closer to half, because “five is the average.” The average is five, but the exact value of five is only one of eleven possible outcomes competing for probability.

Look at the tails of that chart. Zero heads or ten heads each has a probability of 0.10%, about one in a thousand. Meanwhile, getting between 4 and 6 heads happens 65.6% of the time, and 8 or more heads happens 5.5% of the time. A run of 8 heads out of 10 is unusual, but it is not a miracle. I tell people that if they never see it once in a while, the coin is the strange one.

Quality control: the same maths on a factory floor

Now change the story. A company buys phone chargers from a supplier who says the defect rate is 5%. The receiving team pulls 20 chargers from a shipment and tests them. Is this binomial? Fixed n (20), two outcomes (defective or fine), independent units, and a constant defect rate. Yes, with the usual caveat that we treat a large shipment as if each pick is independent.

Here, “success” means “defective”. That trips people up. Success is just the thing we count. So n = 20, p = 0.05, and we can produce the whole table of outcomes.

Read that chart carefully because it corrects two common instincts. First, a defect-free sample happens only 35.8% of the time, even though the supplier really is at 5%. Finding zero defects in 20 does not prove the supplier is perfect. Second, finding one defect (37.7%) is just as likely as finding none. Three or more defects has probability 7.55%, so if that happens you have a real reason to call the supplier.

The “at least one” shortcut every analyst should know

Suppose your manager asks, “What is the chance we see at least one defective charger?” Do not add up 20 terms. Use the complement: P(at least one) = 1 − P(none). Here, that is 1 − 0.95²⁰ = 64.2%. Nearly two in three samples of 20 contain at least one bad unit, even at a healthy 5% rate. It is one of the most useful tricks in the whole subject, and it works for any “at least one” question.

The wrong shortcut goes: 20 chargers × 5% each = 100%, so we are sure to find one. Nope. Percentages of different events do not simply add up unless the events cannot overlap, and here they can.

Mean and standard deviation: what to expect and how far off you can be

The binomial distribution has two beautifully simple summary numbers.

For 10 fair coin flips, the mean is 5 and the standard deviation is √(10 × 0.5 × 0.5) = 1.58. For 20 chargers at 5% defect, the mean is 1 and the standard deviation is 0.97. So you expect about one defect, plus or minus one. That explains the chart above, where 0, 1 and 2 defects are all perfectly normal.

When I coach new analysts, I ask them to memorise this rule: the mean tells you what to expect, the standard deviation tells you how surprised to be. A result within about two standard deviations of the mean is ordinary luck. A result far beyond that deserves an investigation.

Five real situations, one formula

Below is a small panel. Tap a tab to switch situations. It runs on plain HTML and CSS, so it works anywhere the article does. In each case, I ran the exact numbers so you can see the formula do real work.

Notice the pattern. In every tab the mean tells a comforting story (8 baskets, 10 clicks, 10.8 sprouts), but the interesting decisions live in the details of the spread. The exact result is rarely the average result. That is not a flaw of the model. It is the model working as intended.

How the shape changes with p

A fair coin gives a symmetric, hill-shaped chart. But change p and the hill slides sideways. When p is small, successes are rare and the pile of probability sits near zero. When p is large, it sits near n. Only p = 0.5 gives perfect symmetry. The three charts below all use n = 10.

Here is a practical reading of those pictures. A left-leaning chart (p = 0.1) tells you that “zero” and “one” are the typical answers, and that seeing four or five is a real signal. A right-leaning chart (p = 0.9) is the mirror image. If you understand one, you understand the other by swapping the words “success” and “failure”.

Acceptance sampling: how factories really use it

Let me show you the most valuable use of this distribution in industry. Testing every unit is expensive, and sometimes destructive (you cannot crash-test every car). So companies test a sample and use a rule. A classic example: test 20 units; accept the lot if you find at most 1 defective, otherwise reject.

The natural question is how good this rule is. It depends on the true defect rate of the lot, which nobody knows. But the binomial lets us compute the acceptance probability for each possible defect rate.

This is a real piece of quality engineering, called an operating characteristic curve. Read it like a report card on your inspection rule. A 1% defective lot is accepted 98% of the time, which is good for the supplier. A 5% lot is accepted 74% of the time, which may be too lenient if 5% is unacceptable to you. A 10% lot is still accepted 39% of the time. If that bothers you, you do not change the maths, you change the plan: test more units, or accept only when zero defects appear.

What I love about this example is that it turns an argument (“is this sample big enough?”) into a number. Instead of saying “20 feels low,” you can say, “with 20 units we still let a 10% bad lot through about two times in five.” That sentence changes meetings.

Cumulative probability: “at most” and “at least”

Real questions are rarely about exactly k. They are about ranges. “At most 2 defects.” “At least 8 baskets.” “Between 40 and 60 heads.” The rule is simple: add the individual probabilities in the range.

• At most k: add P(0) up to P(k). This is the cumulative column in the charger table.
• At least k: use 1 minus P(at most k − 1). Careful with that minus one, it is where most slips happen.
• Between a and b: add P(a) through P(b), or subtract two cumulative values.

As an example, in 100 fair flips the chance of exactly 50 heads is only 8.0%, but the chance of landing anywhere from 40 to 60 heads is 96.5%. The exact value is stingy, while the range is generous. In real work you almost always want the range.

When n gets big: the normal approximation

Computing C(200, 15) by hand is unpleasant. Before computers, statisticians noticed something lovely: as n grows, the binomial chart looks more and more like the smooth bell curve, centred at np with width equal to the standard deviation. That gave them a shortcut. Treat the count as roughly normal with mean np and standard deviation √(np(1 − p)).

A common rule of thumb says the approximation is decent when both np and n(1 − p) are at least 10. Our email campaign (n = 200, p = 0.05) has np = 10, right at the edge, so it works but not perfectly. Today, software gives exact binomial answers instantly, so the approximation matters more for understanding than for calculation. Still, the ideas are the same: a big sample makes the outcome more predictable in proportion, even though the raw count can wobble more.

That last point deserves emphasis. With 10 flips, the share of heads can easily land at 30% or 70%. With 1,000 flips it rarely strays beyond 47% to 53%. Bigger samples do not make luck disappear. They make luck small relative to the total.

Six mistakes I keep seeing (tap to open)

Where else you will meet this distribution

Any time your data is “how many out of how many,” the binomial is probably lurking underneath.

Quick quiz: test yourself

Tap a question to reveal the answer with the reasoning behind it.

Frequently asked questions

The post Binomial Distribution Explained with Coin Flips and Quality Control appeared first on Learn With Examples.

The post What Is a Probability Distribution? appeared first on Learn With Examples.

The post CAC and LTV: The Two Numbers That Decide If a Business Survives appeared first on Learn With Examples.

The post Coefficient vs Constant: What’s the Difference? appeared first on Learn With Examples.