Drawesome is a drawing toolbar for React. Seven pens, an eraser, SVG and PNG export, no dependencies beyond React. Two lines to drop into an app.

I work on a lot of creative tools, and many of them end up needing a way to draw. Annotating a screenshot, marking up a frame, circling the bit that's wrong. Rather than build it again each time, I made this.

Most of the work went into the toolbar.¹ It changes shape rather than swapping panels: pick a colour and the row of pens becomes the palette, open the size controls and it becomes two sliders, minimise it and it rolls up into a disc with the tool you're holding still in it. Every state morphs smoothly into the next.

It fills its parent container. Set a height on the wrapper.

import { Draw } from 'drawesome'
import 'drawesome/styles.css'
 
<div style={{ height: 480 }}>
  <Draw />
</div>

Each behaves like the thing it's named after. The pencil, pen and brush thin out the faster you move; the fineliner and highlighter hold one width whatever you do. The fountain pen goes by direction instead: thick one way, hairline the other. No two strokes come out quite the same.

The eraser takes away area rather than whole strokes, so you can rub out part of a line and keep the rest.

It's opinionated, and that's the point. The defaults are meant to be the version you ship, so you don't have to think about how it looks or feels to end up with something that looks and feels right. Everything below is turning things off or moving them around, not rebuilding it.²

Pick the tools and the order they sit in, and switch off anything you don't want:

<Draw
  tools={['pencil', 'marker', 'highlighter']}
  controls={{ undo: false, clear: false }}
/>

theme takes light, dark or auto, which follows the reader's system. The bar above is on auto, so it's dark if you are.

placement puts it on an edge and inset and align say exactly where. draggable lets people move it themselves. swatches replaces the palette with your own colours. look="studio" lights the tools as objects instead of shading them flat, and depth sets how physical the bar looks.

The canvas is whatever you want it to be. Give background a colour, or set it to transparent and the component paints nothing at all, so whatever is behind it shows through. The demo above is sitting on a bit of graph paper drawn in CSS.

<div className="your-paper">
  <Draw background="transparent" />
</div>

The bar is as wide as what's in it, and a phone has more height than width. So on a small screen, stand it up and drop a few tools. The demo does this under 680px:

<Draw
  placement={narrow ? 'left' : 'bottom'}
  tools={narrow ? ['pencil', 'pen', 'marker', 'highlighter', 'brush'] : undefined}
  controls={narrow ? { undo: false, clear: false, opacity: false, custom: false } : undefined}
/>

controls takes size and opacity separately, so a rail can keep one without the other stacked under it. Turn both off and the button that opens them goes too.

chrome={false} removes the toolbar entirely and leaves you the surface. DrawSurface, Toolbar and the useDrawing hook are all exported separately if you'd rather lay the pieces out yourself.

Put a ref on it to get the drawing out. toSvg() gives you a string, toPng() a file, download() saves either. What you get back is exactly what was on screen, erasing and all.

await draw.current.download('sketch', 'png', 2)

Every pen has a keyboard shortcut, shown in its tooltip. E for the eraser, [ and ] for size, ⌘Z and ⇧⌘Z for undo and redo. Hold Shift while drawing and the stroke locks to the nearest of eight directions.

It's called Drawesome, which is a lot to live up to.

1. Inspired by Apple's markup tools, and how far they take the skeuomorphism. Pens in a tray beat a row of icons. ↩

2. If you want to assemble a drawing tool from parts instead, tldraw or Excalidraw will suit you better. ↩

Probably the single best thing to happen to me in my career was having had Kellan placed in charge of me. I stuck around long enough to see Kellan’s technical decisionmaking start to bear fruit. I learned a great deal from this, but I also learned a great deal as a result of this. I would not have been free to become the engineer that wrote Data Driven Products Now! if Kellan had not been there to so thoroughly stick the landing on technology choices.

In the year since leaving Etsy, I’ve resurrected my ability to care about technology. And my thoughts have crystallized to the point where I can write them down coherently. What follows is a distillation of the Kellan gestalt, which will hopefully serve to horrify him only slightly.

Embrace Boredom.

Let’s say every company gets about three innovation tokens. You can spend these however you want, but the supply is fixed for a long while. You might get a few more after you achieve a certain level of stability and maturity, but the general tendency is to overestimate the contents of your wallet. Clearly this model is approximate, but I think it helps.

If you choose to write your website in NodeJS, you just spent one of your innovation tokens. If you choose to use MongoDB, you just spent one of your innovation tokens. If you choose to use service discovery tech that’s existed for a year or less, you just spent one of your innovation tokens. If you choose to write your own database, oh god, you’re in trouble.

Any of those choices might be sensible if you’re a javascript consultancy, or a database company. But you’re probably not. You’re probably working for a company that is at least ostensibly rethinking global commerce or reinventing payments on the web or pursuing some other suitably epic mission. In that context, devoting any of your limited attention to innovating ssh is an excellent way to fail. Or at best, delay success [1].

What counts as boring? That’s a little tricky. “Boring” should not be conflated with “bad.” There is technology out there that is both boring and bad [2]. You should not use any of that. But there are many choices of technology that are boring and good, or at least good enough. MySQL is boring. Postgres is boring. PHP is boring. Python is boring. Memcached is boring. Squid is boring. Cron is boring.

The nice thing about boringness (so constrained) is that the capabilities of these things are well understood. But more importantly, their failure modes are well understood. Anyone who knows me well will understand that it’s only with a overwhelming sense of malaise that I now invoke the spectre of Don Rumsfeld, but I must.

When choosing technology, you have both known unknowns and unknown unknowns [3].

• A known unknown is something like: we don’t know what happens when this database hits 100% CPU.
• An unknown unknown is something like: geez it didn’t even occur to us that writing stats would cause GC pauses.

Both sets are typically non-empty, even for tech that’s existed for decades. But for shiny new technology the magnitude of unknown unknowns is significantly larger, and this is important.

Optimize Globally.

I unapologetically think a bias in favor of boring technology is a good thing, but it’s not the only factor that needs to be considered. Technology choices don’t happen in isolation. They have a scope that touches your entire team, organization, and the system that emerges from the sum total of your choices.

Adding technology to your company comes with a cost. As an abstract statement this is obvious: if we’re already using Ruby, adding Python to the mix doesn’t feel sensible because the resulting complexity would outweigh Python’s marginal utility. But somehow when we’re talking about Python and Scala or MySQL and Redis people lose their minds, discard all constraints, and start raving about using the best tool for the job.

Your function in a nutshell is to map business problems onto a solution space that involves choices of software. If the choices of software were truly without baggage, you could indeed pick a whole mess of locally-the-best tools for your assortment of problems.

But of course, the baggage exists. We call the baggage “operations” and to a lesser extent “cognitive overhead.” You have to monitor the thing. You have to figure out unit tests. You need to know the first thing about it to hack on it. You need an init script. I could go on for days here, and all of this adds up fast.

The problem with “best tool for the job” thinking is that it takes a myopic view of the words “best” and “job.” Your job is keeping the company in business, god damn it. And the “best” tool is the one that occupies the “least worst” position for as many of your problems as possible.

It is basically always the case that the long-term costs of keeping a system working reliably vastly exceed any inconveniences you encounter while building it. Mature and productive developers understand this.

Choose New Technology, Sometimes.

Taking this reasoning to its reductio ad absurdum would mean picking Java, and then trying to implement a website without using anything else at all. And that would be crazy. You need some means to add things to your toolbox.

An important first step is to acknowledge that this is a process, and a conversation. New tech eventually has company-wide effects, so adding tech is a decision that requires company-wide visibility. Your organizational specifics may force the conversation, or they may facilitate developers adding new databases and queues without talking to anyone. One way or another you have to set cultural expectations that this is something we all talk about.

One of the most worthwhile exercises I recommend here is to consider how you would solve your immediate problem without adding anything new. First, posing this question should detect the situation where the “problem” is that someone really wants to use the technology. If that is the case, you should immediately abort.

It can be amazing how far a small set of technology choices can go. The answer to this question in practice is almost never “we can’t do it,” it’s usually just somewhere on the spectrum of “well, we could do it, but it would be too hard” [4]. If you think you can’t accomplish your goals with what you’ve got now, you are probably just not thinking creatively enough.

It’s helpful to write down exactly what it is about the current stack that makes solving the problem prohibitively expensive and difficult. This is related to the previous exercise, but it’s subtly different.

New technology choices might be purely additive (for example: “we don’t have caching yet, so let’s add memcached”). But they might also overlap or replace things you are already using. If that’s the case, you should set clear expectations about migrating old functionality to the new system. The policy should typically be “we’re committed to migrating,” with a proposed timeline. The intention of this step is to keep wreckage at manageable levels, and to avoid proliferating locally-optimal solutions.

This process is not daunting, and it’s not much of a hassle. It’s a handful of questions to fill out as homework, followed by a meeting to talk about it. I think that if a new technology (or a new service to be created on your infrastructure) can pass through this gauntlet unscathed, adding it is fine.

Just Ship.

Polyglot programming is sold with the promise that letting developers choose their own tools with complete freedom will make them more effective at solving problems. This is a naive definition of the problems at best, and motivated reasoning at worst. The weight of day-to-day operational toil this creates crushes you to death.

Mindful choice of technology gives engineering minds real freedom: the freedom to contemplate bigger questions. Technology for its own sake is snake oil.

Update, July 27th 2015: I wrote a talk based on this article. You can see it here.

1. Etsy in its early years suffered from this pretty badly. We hired a bunch of Python programmers and decided that we needed to find something for them to do in Python, and the only thing that came to mind was creating a pointless middle layer that required years of effort to amputate. Meanwhile, the 90th percentile search latency was about two minutes. Etsy didn't fail, but it went several years without shipping anything at all. So it took longer to succeed than it needed to.
2. We often casually refer to the boring/bad intersection of doom as “enterprise software,” but that terminology may be imprecise.
3. In saying this Rumsfeld was either intentionally or unintentionally alluding to the Socratic Paradox. Socrates was by all accounts a thoughtful individual in a number of ways that Rumsfeld is not.

4. A good example of this from my experience is Etsy’s activity feeds. When we built this feature, we were working pretty hard to consolidate most of Etsy onto PHP, MySQL, Memcached, and Gearman (a PHP job server). It was much more complicated to implement the feature on that stack than it might have been with something like Redis (or maybe not). But it is absolutely possible to build activity feeds on that stack.

   An amazing thing happened with that project: our attention turned elsewhere for several years. During that time, activity feeds scaled up 20x while nobody was watching it at all. We made no changes whatsoever specifically targeted at activity feeds, but everything worked out fine as usage exploded because we were using a shared platform. This is the long-term benefit of restraint in technology choices in a nutshell.

   This isn’t an absolutist position--while activity feeds stored in memcached was judged to be practical, implementing full text search with faceting in raw PHP wasn't. So Etsy used Solr.

Three Six Mafia

Most guys my age have "the chat". The one with your college buddies that only exists to share memes, argue, bully, and occasionally announce that you got a promotion or had a kid. I am like most guys.

Recently the discussion switched to the Three Six Rule. The idea that, to be date-able, a guy must be a 6 in 3 categories:

• 6 figure income
• 6 feet tall
• 6 inch pecker

I'm pretty far from 6 feet. You can make any other assumptions you wish. However, I'm happily married. What's the deal? Was my wife ignorant of the rule; did she take pity on me? Or perhaps it's possible to compensate for poor performance in one area with exceptionalism in another. If so, what is the conversion rate and is there an opportunity for arbitrage?

These are the important questions of our day.

The Approach

Back in your very first stats class you probably talked about the heights of third-graders, and someone drew a pretty bell curve. Distribution of heights is like bell curve 101, and bell curves are incredibly useful. With just two numbers, a mean (μ) and standard deviation (σ), you can describe an entire population and run all types of analysis.

Where I live in the USA being 6' or great is actually pretty rare. 91% of all adult men are below this height. However, older people tend to shrink with age and are far less likely to be in the dating pool. Especially for a connoisseur of the Three 6 Rule. Let's only look at American males between the ages of 20 and 30.

Height Distribution of Males aged 20-30

A height of 6' is roughly at the 75th percentile. Hold up, percentile? We're not talking about SAT scores you nerd. We're drastically eliminating men from the dating pool based on three arbitrary numbers. Let's subtract it from 1 and call it an "Exclusivity Score".

Much better. By eliminating guys under 6' we have removed 75% of the population from the dating pool and are left with the top quartile of most exclusive men. In a room of 100 fellas, 75 aren't even worth talking to.

Now what about pecker size? Fortunately, this also follows a pretty standard bell curve and there's public data so I don't have to do my own research. A 6" wiener is even rarer than being 6' tall. The average erect penis length is 5.166" with a std dev of 0.654".

Erect Penis Length Distribution

Do the math, carry the 1, and a 6" pecker puts you right at the 90th percentile for an Exclusivity Score of 10%.

In that same room, we've eliminated 90 of them for having the pedestrian member of a mere mortal. The 10 guys left are the cream of the crop.

Getting Too Big for Our Britches

Here is where we starting getting a little dumb. I've got a room of 100 potential dating partners. 25 of them meet my height criteria while 10 of them have exclusive enough peckers. What are the odds that somebody is in both groups?

To combine the odds of two independent actions, you just multiply them. The odds of rolling a die and getting a 5 are 1/6. The odds are doing it a second time are also 1/6. So the odds of rolling 5 two times in a row are:

What if the actions aren't independent? If I take a deck of cards and draw one randomly, there is a 1 in 2 chance it is red. If I keep that card, what are the odds the next card I draw is also red? It's not 1 in 2. The deck now has 51 cards, 26 black cards and 25 red cards. On my second turn, the odds of drawing a red card are 25 in 51. Just slightly worse than 50/50. The odds of the second action are dependent upon the first action. The odds of drawing two red cards in a row are:

Height and pecker length seem to be correlated, but there isn't a lot of great data out there. But generally speaking, a taller person is more likely to have a longer pecker. Since we can't model this relationship with a high degree of confidence, and because this exercise is incredibly low stakes, we're going to ignore it. While there appears to be some dependent relationship between height and pecker, I'm going to treat them as two independent events.

So back to these two groups of 25 and 10 guys. Since we're treating them as independent characteristics we can just multiply the odds to arrive at our Blended Exclusivity Score.

Now we're talking! The Three 6 rule is really starting to shine in it's ability to enforce exclusivity. In a room full of 100 random guys, you may find two or three that can meet our criteria so far.

Let's Talk About Money

Humans have gotten bigger over time. However, I've yet to see height or pecker size in any CPI basket-of-goods when measuring inflation. Neither party's economy policy is to blame for the rising cost of peckers in the grocery store that is destroying the middle class. The heights of American men aren't driven by interest rate policy. Incomes are.

So when we talk about a 6 figure income, we need to nail down a date. For now we'll look at 2014 since that is the most recent data I found.

The other trouble with distributions of income is they aren't normal. Look at that long tail off to the right. But if we take the natural log of our incomes, it suddenly becomes normalized with a mean of 10.8 and standard deviation of 0.758. We can always convert our values back to dollars by raising e to that number as the exponent.

Income Distribution

Normalized with Natural Log

Taking the natural log of $100k gives you 11.513 or an Exclusivity Score of 17%. To illustrate that 11.513 corresponds to $100k we can quickly check:

Setting a Baseline

We already talked about the odds of finding someone in a group of 100 guys that is both 6' tall and 6" endowed. If we add in their salary we arrive at our Improved Blended Exclusivity Score.

In a gaggle of 100 suitors, it's actually unlikely that a single one will meet all three criteria. Perfection. We now have a truly unreasonable set of standards by which to choose our dating partner.

Even better, we now have a standard by which we can measure other permutations of height, pecker length, and income. As long as we remain more exclusive than 0.425% of the population we can explore the data and start to answer the big questions:

• Can you still date someone that is 5'3" if their income is $200k+?
• How tall does someone need to be to compensate for a micro-penis?
• Is there a pecker length at which height and income become irrelevant?

Sure, we're not following the letter of the law, but Jesus told me to follow the spirit of the law. I'm pretty sure this is what he was talking about.

Diving In

Let's hold income steady at $100k for a bit and focus on just height and pecker so we can start building a model for conversion. Remember that our mean height is 70" with a std dev of 3". This means that for every inch we grow, we move 0.333 std dev from the mean. At 6' we are 0.666 std dev from the mean.

Meanwhile, every inch that our pecker grows moves us 1.53 std dev from the mean. An inch of pecker is worth a lot more than an inch of height when measuring our Blended Exclusivity Score. How much more?

We already determined that our target Blended Exclusivity Score (BES) is 0.425%. If we hold salary constant at $100k, which has an exclusivity score of 17%, we can choose any length of pecker and determine the minimum height required to reach 0.425%.

Since we need to use Exclusivity Scores (ES), not inches, we will use some excel functions to make this easier. To find the ES of a certain pecker we type in:

To take an Exclusivity Score and convert it back to a height we just do the inverse function:

If we build a table for various pecker lengths roughly between -3σ and +3σ and throw it on a chart, we get something like this. Notice that for 6" peckers we need the predicted ES_Height of 25% which corresponds to 72":

Now this is an interesting chart. On the shorter end of the penile spectrum our height is essentially flat at almost 6'6". At the extreme short end of pecker length there is very little exclusivity difference between 3.25" and 4.25". They're so small that you have to be on the extreme end of the height curve to get back to a BES of 0.425%.

In the middle of the chart, we see the steady curve that we likely expected where height is being driven by pecker length.

Then we reach the right side of the chart and things get crazy again. Once our pecker length reaches 6.5" (2σ from the mean), our ES_Pecker score becomes so high that height becomes a non-factor. In fact, ES_Pecker * ES_Salary is already more exclusive than our target of 0.425%. Exclusivity score have to be between 0 and 1. There is no number in that range you can multiply by to get a bigger number. This creates the concept of a valley that we'll come back to.

Let's do this one more time but hold pecker size constant at 6". This time we will measure the salary required for various heights to maintain our BES. To measure our required salary, we do the same thing as before except we also have to convert our normal distribution back to dollars.

Again we need to convert our heights into Exclusivity Scores using Excel:

This will give us our salary exclusivity score. Not only do we need to convert our Salary ES back to a number, we also need to raise e to that power to convert it back into dollars.

We have another valley on the right hand side. Once you reach heights of 6'4" with a 6" pecker, those two factors alone make you so exclusive that salary becomes irrelevant. These guys are such a catch that we can ignore their income entirely. I call this the "Valley of the Sexy Hobo".

We can continue this exercise for all combinations, but I know the reason why you're still here. You want an executive level view where you can quickly determine your own Blended Exclusivity Score. I got ya.

Let's start building some views we can action on. Something to laminate and keep in your wallet for that next round of speed dating. I promise this data will come across as very convincing and not at all creepy.

We'll start by building a simple data table, heights on the x-axis and pecker length on the y-axis. Both axis roughly represent plus or minus 3σ. Fill out our data table with required incomes, add a heat map, and voila.

Let's gather some insights. I've highlighted the intersection of 6' and 6" while the star represents the average height and pecker length. Notice that a man who is physically average needs an income of roughly $250k to meet the same criteria as our ideal Three 6 man, that's a fairly exclusive salary. Income increases drastically as you move left and up the chart, and quickly drops to our floor of $951 as you move down and to the right.

The really interesting stuff with bell curves happens at the extremes. Now our "Valley of the Sexy Hobo" is two-dimensional. It wraps around the entire bottom and right of the table. And on the top left we have the "Peak of the Emasculated Rich".

The other interesting thing with bell curves is their distribution, how wide they are. We'll dive deeper into the value of an inch later, but for now we can start to see some trends. An inch of pecker is worth way more than an inch of height, so we need to compare standard deviations.

Our ideal Three 6 man is 1.27σ above the pecker mean, but only 0.66σ above the height mean. If he was interested in increasing his BES, he could get out sized returns by focusing on penile growth. With just 1σ of pecker length (0.65") he will drop into the "Valley of the Sexy Hobo". However, if he grows by 1σ he still needs to earn $20k. I'd hate to be the man tearing up my 2 week notice because I paid for the wrong growth surgery. How embarrassing.

Now for fun, let's put salary on the z-axis and see just how high the "Peak of the Emasculated Rich" is. Remember, our income distribution doesn't include negative numbers, so we've created a floor for our lowest salary. Theoretically, we should expect the salary requirements to drop below zero at the extreme corner of the "Valley of the Sexy Hobo". Which of course suggests that our tallest and most well endowed men should actually be paid for their dating services.

How Much Should I Pay for an Inch?

Sadly, there isn't a linear relationship. I can't tell you that 1" of penis is always worth 10 Schrute bucks while an 1" of height is worth 75 Stanley nickels.

What we can do is model an inch based on your current measurements. We can brute force it using our laminated height vs pecker data table that we keep in our wallets at all times. For the Average Man, gaining an inch of height is worth losing roughly $25k in annual salary. Meanwhile, an inch of pecker is roughly offset by reducing annual salary by $128k.

But as pecker length hits the extremes, the extra inch of height becomes irrelevant. The same thing happens when talking about an inch of pecker for extremely short and tall guys.

What we need is a unifying equation that perfectly models the value of an inch in either department. I probably need to start practicing my Nobel acceptance speech.

The value of an inch of pecker can be modeled by:

Where N is your current height in inches and Blended Exclusivity Score is a constant defined as 0.425%. In preparation for my Nobel Prize, this constant should have a name. Perhaps "The Shallow Constant".

Life's Big Question

Earlier, I posed three big questions that keep many people up at night. Now that we finally have the framework, let's go about answering them as a bit of a wrap up.

Can you still date someone that is 5'3" if their income is $200k+?

I wish the answer was "Date whomever you love!", but sadly a 15 second clip on instagram authoritatively told me that there are rules. Three rules to be precise. Now, 5'3" is pretty short with an Exclusivity Score of 99%. But on the flip side, $200k is a pretty high income with an ES of 3.2%. Taken together, our Blended Exclusivity Score is 3.1%. Pretty exclusive, but still higher than our Shallow Constant of 0.425%. We just need to figure out what ES_Pecker we need.

This man is still dating material as long as their pecker has an ES of 13.7% or 5.88". Good to know he's still got a shot.

How tall does someone need to be to compensate for a micro-penis?

I don't really care to Google the exact definition of a micro-penis, so I'll just say that it's 3.5".

This question is actually pretty tricky, because the required compensation is dependent on the salary. Remember our peaks and valleys. To provide an answer, we will assume that we are thinking of the prototypical Three 6 man. This man went to bed 6' tall, with a 6" pecker and earning exactly $100k a year. How do we plan for the morning when he wakes up to a 3.5" pecker?

This new-found micro-penis has dropped the ES_Pecker from 10% to 99%. To compensate for that, the ES_Height has to increase by the same but opposite scale.

We can then multiply his current ES_Height by 0.10101 to get a new score of 0.25% or 75.9". This man needs to grow by almost 3" to compensate for his 2.5" pecker loss.

Is there a pecker length at which height and income become irrelevant?

Ahh, the man whose pecker is so long and so rare that he needs neither personality, height, nor salary to be a high-value target in the dating market.

The answer to this question is relatively straight forward. Remember that our ES are always between 0 and 1. They can only ever make you more exclusive, never less exclusive. We can ignore height and salary if our pecker has an ES of 0.425% by itself.

Plugging 0.425% into our NORM.INV() function determines that a pecker of 6.89" is the point at which you can forgo all other attempts at wooing the fairer sex.

But Why?

I warned you this was dumb, but dumb is fun. It's a cool way to explore data and concepts and not worry about getting everything right. I'm sure I got quite a bit wrong. Awesome, let me know and I'll learn a little bit more.

Download Excel File Used for Visualizations

LLMs can’t jump
• Deduction (Rule + Case → Result) is the analytic
application of a Rule to a Case to predict a Result. It
is the only mode that guarantees truth (e.g., executing
code to verify output).
• Induction (Case + Result → Rule) is the synthetic
derivation of a Rule from the accumulation of Cases
and Results. It validates hypotheses through statistical
frequency (e.g., generating a function to satisfy unit
tests).
• Abduction (Rule + Result → Case) is the inference of
a Case (or a new Rule) to explain a surprising Result.
Unlike deduction, which guarantees truth, or induction,
which finds pattern that generalize in data, abduction is
a creative leap that invents a cause for a singular phe-
nomenon. Crucially, Einstein achieved this via embodied
simulation—using thought experiments to ground abstract
symbols in physical sensation—enabling him to formulate
axioms where no symbolic data previously existed.
We argue that while Large Language Models have mas-
tered the inductive compression of data and the deduc-
tive verification of theorems, they are structurally in-
capable of the abductive ’jump’ required for scientific
invention. We posit that this creative leap demands not
just better language processing, but the integration of
physically consistent World Models that ground abstract
symbols in sensory simulation.
2. Background
2.1. Mechanics
In the 19th century, mechanics was regarded as the founda-
tion of all physics. Through the lens of partial differential
equations, scientists could explain a vast array of phenom-
ena: the propagation of sound, hydrodynamics, the motion
of discrete masses, and even the kinetic theory of gases
(linking viscosity, heat conduction, and diffusion). At the
time, even light was understood through this mechanical
framework, described as a wave moving through the ether.
Yet, the mechanical worldview began to fracture. Through
the contributions of Maxwell, Faraday, Hertz, and Mach,
the laws of electromagnetism were unified into Maxwell’s
equations. Newtonian mechanics struggled to explain these
electromagnetic fields, signaling the end of mechanics as
the sole governing paradigm of physics. Physics found itself
divided into two conceptual elements: material points with
forces at a distance between them and continuous fields.
Einstein found this division unacceptable and was driven to
create a field theory for gravity that would replace the old
idea of action at a distance.
Meanwhile, a crisis was brewing regarding the nature of
light. Because light behaves as a wave, scientists assumed it
traveled through a medium they called the ether. However,
the famous Michelson-Morley experiment in the late 19th
century shattered this assumption. They attempted to mea-
sure Earth’s velocity relative to the ether but failed to do so.
Even more shocking was the observation that the speed of
light did not vary with the Earth’s movement around the Sun.
Attempts to salvage the ether theory resulted in increasingly
complex and artificial explanations, such as ether wind, all
of which ultimately proved futile.
In addition, Newton’s theory of gravitation was incred-
ibly robust, accurate to an astonishingly small margin
of error. Newton confirmed Galileo’s discovery that all
bodies fall at the same speed regardless of mass by per-
forming pendulum experiments. In particular we have,
Fgrav = mi d2x
dt2 = mg g, so if mi = mg we have that
the acceleration is constant d2x
dt2 = g and independent of
mass. Newton’s experiments validated that mi
mg = 1 with
an accuracy of 10−3. Over the centuries, this precision was
refined even further—Laplace achieved 10−7 and E¨otv¨os
reached 10−9.
In fact, there was only one known anomaly: a tiny shift in
Mercury’s orbit known as the advance of perihelion (Lever-
rier 1845). Scientists were so confident in Newton’s laws
that they didn’t question the theory; instead, they hypoth-
esized that an undiscovered planet, dubbed ’Vulcan,’ was
hiding near the Sun and causing the disturbance.
2.2. Special relativity
In 1905, Einstein resolved the contradictions of the
Michelson-Morley experiment in a way that fully aligned
with Maxwell’s equations. He founded his new theory on
two key postulates. Principle of relativity: The laws of
physics are identical in all inertial frames of reference. In-
variance of the speed of light: The speed of light in a vac-
uum, c, is constant in all inertial frames of reference.
The Michelson-Morely experiment was designed to detect
Earth’s movement through a hypothetical ether, and found
that there is no change in light speed; Light always travels
at c so its speed doesn’t change relative to a moving Earth,
exactly the second postulate.
From the two postulates, Einstein derived the Lorentz trans-
formation, which relates the coordinates of a rest frame to
one moving at a constant relative velocity v. The resulting
transformation for time is:
t′ = t − v
c2 x
q
1 − v2
c2
. (1)
Historically, predecessors like Poincar´e referred to the vari-
able t′ as ’fictitious time’. However, Einstein’s interpreta-
2