You do it several times a week without thinking about it. You boot a laptop, reboot a router, power-cycle a stubborn smart plug. The word is so ordinary that almost nobody asks where it came from. The answer is a 200-year-old joke about doing the impossible, and it describes a problem that engineers still solve the same way today.
Booting is short for bootstrapping
The phrase "to pull yourself up by your own bootstraps" entered American English in the 19th century, and it was originally sarcastic. Bootstraps are the little loops sewn onto the back of a boot so you can tug it on. Lifting your entire body off the ground by pulling on them is physically absurd. That was the point: the expression named a task that was self-evidently impossible. Only much later did it drift into the earnest self-reliance sense most people know today.
Early computer engineers borrowed the original, sarcastic meaning, because they had a genuine chicken-and-egg problem on their hands.
The paradox at power-on
A computer with empty memory can do nothing. To load a program into memory, you need a program already running that knows how to read from tape, disk, or punched cards. But loading that program requires a program too. The machine has to lift itself into a working state from nothing.
On the earliest machines, the answer was brutally manual. An operator would flip front-panel switches to hand-enter a few dozen instructions, one word at a time, then hit run. Those instructions were just clever enough to read a slightly bigger loader off tape, which read the real program. Engineers called this short self-lifting routine a bootstrap loader, and the wry name stuck. By the 1970s it had been clipped to "boot," and "reboot" followed naturally.
The same trick, now in silicon
The manual switch-flipping is gone, but the structure is identical. Modern hardware just moves the first stage into read-only memory that ships with the chip.
Take an ESP32, one of the most common microcontrollers in IoT development. When you apply power, the CPU begins executing a first-stage bootloader that was burned into mask ROM at the factory. That code cannot be changed, cannot be corrupted, and cannot be updated. Its only job is to figure out where to get the next stage: usually a second-stage bootloader stored in external flash. That second stage reads a partition table, decides which application image to run, and hands control to your firmware.
Three stages, each one small and dumb enough to be trusted, each one pulling in something larger. That is a bootstrap.
The same shape appears everywhere in embedded work. A PC runs firmware in a SPI flash chip that initialises RAM before an operating system loader can even exist. A Raspberry Pi's on-chip ROM pulls a bootloader off the SD card. A compiler for a new language is typically first written in another language, then rewritten in itself and compiled by the earlier version, a process engineers also call bootstrapping.
Why the boot chain matters for connected devices
For a hobby project, the boot sequence is invisible plumbing. For a fleet of devices deployed in the field, it is the single most important piece of code you will write, because everything you need to stay safe over the long term lives in it.
Over-the-air updates. The bootloader chooses which firmware image to run. Give it two application slots and it can boot a freshly downloaded image while keeping the previous one intact. Without that, updating a device means physically visiting it.
Rollback protection. If a new image fails to check in after boot, the bootloader can fall back to the last known-good slot. This is the difference between a bad release being an inconvenience and it bricking hardware bolted to a wall, buried in a field, or installed on a roof.
Secure boot. Because the first stage is immutable ROM, it makes a credible root of trust. It can verify the signature of the second stage, which verifies the signature of the application. Break the chain anywhere and the device refuses to run unsigned code.
Recovery. A well-designed bootloader keeps a way back in, whether that is a serial recovery mode, a held-down button at power-on, or a factory image in a protected partition.
We see the cost of skipping this regularly. It is common for a first prototype in Manila or Cebu to be flashed over USB on a workbench, which works perfectly right up until the first hundred units are installed across several sites and a firmware bug needs fixing. Designing the boot chain before deployment, rather than after, is what makes a connected product maintainable for years instead of months.
An in-joke that outlived everyone who told it
The engineers who wrote those first switch-entered loaders picked the name because the situation genuinely was funny to them: a machine hauling itself into existence by its own straps. They could not have known the word would survive the disappearance of punched tape, front-panel switches, spinning disks, and eventually the desktop computer itself.
Every time a sensor wakes from deep sleep and runs its ROM loader, the joke runs again.
If you are building a connected product and want the boot chain, OTA pipeline, and update strategy designed properly from the start, talk to us about your project or read more about our IoT and embedded services.
Top comments (0)