Dorothy Vaughan: Adapt or Become Obsolete

By Michael Doornbos

November 24, 2025 - 15 minutes read - 3063 words

There are remarkable women in the Hidden Figures story - Katherine Johnson with her trajectory calculations and Mary Jackson breaking barriers to become an engineer, both inspirational. But Dorothy Vaughan is my favorite. Not because her contributions were more important (they weren’t), but because her response to technological disruption offers the most practical lesson for the rest of us.

In the late 1950s, Vaughan faced a problem that feels eerily familiar today: a machine was coming for her job.

She was a “Computer” at NASA’s predecessor organization, NACA. Not the kind you’re reading this on—she was a human computer, one of the brilliant mathematicians (predominantly women) who performed the complex calculations that sent rockets into space and astronauts to the moon. When NASA acquired an IBM mainframe to automate these calculations, Vaughan could have panicked. She could have resisted. She could have convinced herself that human expertise would always be needed.

From Human Computer to Programmer

Dorothy Vaughan’s story isn’t just about personal survival—it’s about leadership in the face of technological disruption. As the head of NACA’s West Area Computing unit, she didn’t just learn FORTRAN for herself. She taught her entire team of human computers to program, ensuring they would all transition successfully into the new era of automated computation.

This wasn’t about abandoning their expertise. The mathematical knowledge, the understanding of orbital mechanics, the ability to check results for reasonableness—all of that remained valuable. What changed was the tool they used to apply that expertise. Instead of slide rules, logarithm tables, and paper, they now had IBM machines that could execute thousands of calculations per second.

The computers that learned programming didn’t become obsolete. They became more powerful.

The Book vs. The Movie

If you’ve seen the 2016 film “Hidden Figures,” you know Dorothy Vaughan’s story—or at least Hollywood’s version of it. The movie is inspiring and essential for bringing these women’s contributions to a wider audience. But like most Hollywood adaptations, it compresses timelines, heightens drama, and simplifies complex realities for narrative punch.

In the film, there’s a dramatic scene where Vaughan essentially “steals” a FORTRAN programming book from the whites-only section of the library (whites only is ridiculous, such a strange idea to me), teaching herself and her team in secret before dramatically revealing their newfound skills. It makes for great cinema—the underdog overcoming systemic barriers through cleverness and determination.

The reality, documented in Margot Lee Shetterly’s book, is both less dramatic and more nuanced.

While I couldn’t verify the specifics of the library scene, sources indicate Vaughan obtained FORTRAN resources on her own initiative—though exactly how remains difficult to document. What we do know is that she didn’t learn FORTRAN in secret as an act of subterfuge. She saw the IBM machine being installed and recognized it as an existential threat and opportunity. Historical records show she had already been programming the IBM 704 in FORTRAN before the IBM 7090 (featured in the movie) even arrived. She systematically trained herself and her team, then positioned her group as the obvious choice to program the new system because they were the only ones who knew how. No grand reveal—just strategic preparation.

I have a copy of a Fortran book from 1962, she would have had access to similar materials.

FORTRAN Book from 1962

The movie also compresses the timeline significantly. The transition from human computers to programming happened over several years, not in a few dramatic weeks. Vaughan became acting head of the West Area Computers in 1949 and wasn’t officially promoted to supervisor until 1951—and even then, without the title or pay that white supervisors received. Her transition to programming the IBM machines happened in the late 1950s, a gradual process of learning and teaching, not a sudden coup.

Perhaps most importantly, the book makes clear that Vaughan’s story wasn’t just about individual brilliance overcoming racism—though she did face and overcome significant discrimination. It was about systemic leadership and organizational thinking. She didn’t just teach her team FORTRAN to save their jobs; she strategically positioned an entire unit for the future of computing at NASA.

The Hollywood version gives us heroes overcoming obstacles. The real story offers something more useful: a case study in organizational change management during technological disruption, led by someone who had every excuse to be risk-averse but chose to lead boldly instead.

What FORTRAN Looked Like Then

To understand the magnitude of this transition, let’s look at what Vaughan and her team were actually learning. Here’s a simple FORTRAN II program from that era:

C     HELLO WORLD PROGRAM
      WRITE OUTPUT TAPE 6,100
      CALL EXIT
  100 FORMAT(1H1,12H HELLO WORLD)
      END

But here’s what made learning FORTRAN particularly challenging: you couldn’t just type this into a computer. You’d write your program by hand on coding sheets, then transfer it to punch cards—one card per line of code. Each card had 80 columns, and you’d use a keypunch machine to punch holes for each character.

Punch card example showing FORTRAN code

Each character required a specific pattern of holes punched across the card. Spaces were no holes at all—but they still took up columns. FORTRAN cards had a specific layout: columns 1-5 were reserved for statement labels, column 6 for continuation markers, and actual code started in column 7.

Make a typo? You couldn’t backspace. You’d pull out that card, get a fresh one, and re-punch the entire line. Drop your card deck? Better hope they’re numbered. Get them out of sequence? Your program won’t run.

This is what Dorothy Vaughan and her team mastered. Not just the logic of FORTRAN, but the physical process of translating algorithms into properly sequenced stacks of cardboard rectangles with precisely placed holes. And they had to learn the specific syntax of FORTRAN II: “WRITE OUTPUT TAPE 6” instead of the modern “WRITE(6,100)”, “COSF” instead of “COS”, and Hollerith notation like “12H HELLO WORLD” where you had to count every character exactly.

Simple enough? But here’s where it gets interesting. Let’s look at a real calculation that human computers would have performed—computing a rocket’s trajectory over time. This is simplified, but it represents the type of work they did daily.

The Tools of a Human Computer

Before we look at the process, let’s understand the tools. A human computer’s desk in the 1950s would have:

Slide Rules: The engineer’s constant companion. A 10-inch slide rule could multiply, divide, find logarithms, compute trig functions, and more—all mechanically. Accuracy was typically 3-4 significant figures. Fast for approximations and checking work, but limited precision.

Adding machine from the 1950s

Mechanical Desktop Calculators: Machines like the Marchant, Friden, or Monroe calculator. These were heavy (20-40 pounds), loud, and purely mechanical—gears, levers, and rotating drums. You’d enter numbers with keys or dials, pull a handle or press a motor button, and the machine would compute sums, differences, products, and quotients. They could handle 10-12 digits of precision but were slow—a multiplication might take 5-10 seconds of mechanical grinding.

I have an R.C. Allen mechanical calculator from the 1950s that works this way. They would probably have used similar models with more advanced features.

Adding machine from the 1950s

Mathematical Tables: Thick books filled with pre-computed values. The most common:

Log tables: For multiplication via addition (log(a×b) = log(a) + log(b))
Trig tables: Pre-computed sine, cosine, tangent values at various angles
Specialized tables: Square roots, exponentials, Bessel functions—whatever the application needed

These tables were computed once (by other human computers) and printed. You’d interpolate between tabulated values to get the precision you needed.

Graph Paper and Pencils: For plotting results, organizing calculations, and recording intermediate values. Everything had to be written down because there was no “memory” except your worksheet.

The Process: Complex calculations were broken down into steps that could be done with these tools. Multiplication? Use logs and the adding machine. Trig function? Look it up and interpolate. Each step introduced potential for error, so calculations were often done twice by different people and compared.

The Manual Process (Pre-IBM)

To calculate a rocket’s position at 10-second intervals for the first minute of flight, a human computer would:

Look up values in logarithm tables for velocity calculations.
Look up values in trigonometric tables for angle calculations.
Manually compute each position using equations of motion:
- x = v₀t cos(θ)
- y = v₀t sin(θ) - ½gt²
Record each result by hand.
Double-check calculations (often by a second computer)
Plot or tabulate the results

For a single trajectory with 6 time points, this might take 30-45 minutes of careful work. If you made an error in the third calculation, you’d have to redo everything from that point forward. And you’d typically need to compute dozens or hundreds of trajectories with varying initial conditions.

The FORTRAN Process (Post-IBM)

Here’s the same calculation in FORTRAN II (the actual 1958 version NASA used):

C ROCKET TRAJECTORY CALCULATION
C COMPUTE POSITION AT TIME INTERVALS
C
C     INITIAL CONDITIONS
      V0=500.0
      THETA=45.0
      G=32.2
C     CONVERT ANGLE TO RADIANS
      THETA=THETA*3.14159/180.0
C     PRINT HEADER
      WRITE OUTPUT TAPE 6,100
C     CALCULATE POSITIONS AT 10 SECOND INTERVALS
      DO 200 I=0,6
         TI=I
         T=TI*10.0
         X=V0*T*COSF(THETA)
         Y=V0*T*SINF(THETA)-0.5*G*T*T
         WRITE OUTPUT TAPE 6,150,T,X,Y
  200 CONTINUE
      CALL EXIT
C
  100 FORMAT(1H1,4HTIME,5X,5HX POS,5X,5HY POS)
  150 FORMAT(1X,F8.2,2F10.2)
      END

A few things to notice about this FORTRAN II code that make it distinctly different from modern FORTRAN:

No PROGRAM statement - FORTRAN II didn’t have that yet
No type declarations - Variables starting with I-N are integers, everything else is real
WRITE OUTPUT TAPE 6 instead of WRITE(6,100) - The old tape-based I/O syntax
COSF and SINF instead of COS and SIN - The “F” suffix for floating-point functions
Hollerith notation - “4HTIME” means “4 characters: TIME” - you had to count exactly
CALL EXIT instead of STOP - The proper way to end a FORTRAN II program

Run this program once: you get all seven time points in seconds. Need to check a different launch angle? Change one number and run it again. Need 100 different angles? Wrap it in another loop and let it run while you work on something else.

I have an emulator that can run FORTRAN II code as an IBM 7090, close enough to show you the output but is MUCH faster than the original hardware.

FORTRAN and Python Results

The Real Difference

The calculation itself didn’t change—the physics remained the same. What changed was:

Speed: Hours of work became seconds
Accuracy: No transcription errors from tables
Iteration: Testing variations went from hours to minutes
Scale: Computing 100 scenarios became trivial instead of impossible

But here’s what Vaughan understood that made her invaluable: someone still needed to know that the formula was correct, that the initial conditions made physical sense, that a negative altitude at T=60 seconds meant the rocket had crashed. The IBM couldn’t tell you if the results were nonsense. The human computers-turned-programmers could.

They didn’t become obsolete. They became more powerful, able to check more scenarios, catch more problems, and contribute to more missions. Vaughan’s team went from computing a handful of trajectories per day to validating thousands of simulation runs. Their expertise didn’t diminish—it scaled.

The Same Calculation in Commodore BASIC

Fast forward a couple of decades to the home computer revolution. Here’s how you’d write the same trajectory calculation on a Commodore 64 in your living room:

10 REM ROCKET TRAJECTORY CALCULATION
20 REM BY MICHAEL DOORNBOS
30 PRINT CHR$(5)
40 REM INITIAL CONDITIONS
50 V0 = 500: REM VELOCITY FT/SEC
60 TH = 45: REM LAUNCH ANGLE DEGREES
70 G = 32.2: REM GRAVITY FT/SEC^2
80 P = 3.14159
90 :
100 REM CONVERT ANGLE TO RADIANS
110 TR = TH * P / 180
120 :
130 PRINT "TIME","X POS","Y POS"
140 PRINT "----","------","------"
150 :
160 REM CALCULATE POSITIONS
170 FOR I = 0 TO 6
180   T = I * 10
190   X = V0 * T * COS(TR)
200   Y = V0 * T * SIN(TR) - 0.5 * G * T * T
205   REM ROUND TO 2 DECIMAL PLACES
210   XR = INT(X*100+.5)/100
215   YR = INT(Y*100+.5)/100
220   PRINT T;TAB(10);XR;TAB(20);YR
230 NEXT I

The calculation is identical. The syntax is different—line numbers, simpler I/O, fewer formatting options. But the fundamental problem solving is the same. A child in 1982 with a Commodore 64 could compute trajectories that took NASA’s human computers 45 minutes in 1955.

The abstraction level kept rising. The expertise needed kept shifting. But the ability to understand what the numbers meant remained essential.

Commodore Results

The Same Calculation in Python

And today? Here’s Python doing the same thing:

import math

# Initial conditions
v0 = 500        # velocity (ft/sec)
theta = 45      # launch angle (degrees)
g = 32.2        # gravity (ft/sec^2)

# Convert to radians
theta_rad = math.radians(theta)

# Print header
print(f"{'TIME':>6} {'X POS':>10} {'Y POS':>10}")
print("-" * 30)

# Calculate positions at 10 second intervals
for i in range(7):
    t = i * 10
    x = v0 * t * math.cos(theta_rad)
    y = v0 * t * math.sin(theta_rad) - 0.5 * g * t * t
    print(f"{t:6.1f} {x:10.1f} {y:10.1f}")

Clean, readable, expressive. Built-in math functions. No FORMAT statements or line numbers. You can probably understand this code even if you’ve never programmed.

But notice what hasn’t changed across 70 years of computing: someone still needs to know that you’re calculating projectile motion, that gravity points down, that you need radians for trig functions, and that a negative Y position means the rocket hit the ground.

Dorothy Vaughan learned FORTRAN in the 1950s. If she were starting today, she’d learn Python—the language changes. The need to adapt doesn’t.

FORTRAN and Python Results

The Parallel to Today

If you’re in tech right now, you know the feeling. AI is coming for parts of your job—maybe big parts. Code completion tools, chatbots that can draft entire programs, and models that can debug, refactor, and optimize. It’s easy to feel threatened. It’s easy to dismiss it as hype, to insist that human expertise can never be replaced.

But that’s not what Dorothy Vaughan would do.

The parallel isn’t that AI will completely replace programmers any more than IBM mainframes completely replaced mathematicians. NASA still needed people who understood mathematics, could verify results, and could design algorithms. What changed was the level of abstraction and the tools available.

The question isn’t whether the technological landscape is changing—it is. The question is: are you going to adapt?

What Adapting Actually Means

Vaughan’s approach offers a clear blueprint:

Don’t Deny the Change

The IBM mainframe was coming whether the human computers liked it or not. Pretending otherwise wouldn’t have saved anyone’s job. Similarly, AI capabilities are advancing rapidly. Denying this reality or waiting for it to fail isn’t a strategy—it’s surrender.

Learn the New Tool

Vaughan didn’t just read about FORTRAN—she learned it deeply enough to teach others. She understood that the new technology wasn’t her enemy; it was her next tool. Today, that means actually using AI coding assistants, understanding their strengths and limitations, learning prompt engineering, and understanding how LLMs work.

Leverage Your Expertise

The mathematicians-turned-programmers didn’t throw away their knowledge of orbital mechanics. They applied it at a higher level of abstraction. Your expertise in software architecture, system design, debugging complex systems, and understanding business requirements—that doesn’t become obsolete. It becomes more valuable when combined with more powerful tools.

Help Others Adapt

Perhaps most importantly, Vaughan didn’t just save herself. She brought her entire team forward. In times of technological change, knowledge hoarding is a losing strategy. The people who thrive are the ones who help their organizations and colleagues adapt.

The Stakes

Here’s the uncomfortable truth: if you don’t learn to work with the new tools, someone else will. And they’ll be more productive, more valuable, and more employable than you.

This isn’t about AI replacing programmers wholesale—that’s missing the point. It’s about programmers who use AI replacing THE programmers who don’t. Just like programmers who used high-level languages replaced those who insisted on writing everything in assembly. Just like assembly programmers replaced those who insisted on toggling switches. Just like those switch-togglers replaced human computers with slide rules.

The technology stack keeps evolving. The people who grow with it survive and thrive. The people who don’t… well, their skills become historical curiosities.

What to Do Now

Dorothy Vaughan’s example gives us a clear path forward:

Acknowledge reality: The tools are changing. Fast.
Learn the new tools: Not superficially, but deeply enough to understand their capabilities and limitations.
Apply your expertise: Use your existing knowledge alongside new tools to work at a higher level of abstraction AFTER you learn first principles. Dorthy’s team could not have done that work without knowing how the calculations they asked the computer to do actually worked.
Share knowledge: Help your team, your organization, your community adapt.
Stay curious: Technology will keep changing. The skill that matters most is the ability to keep learning.

Conclusion

Dorothy Vaughan didn’t become a footnote in history despite technological change. She became a crucial part of the space race because she adapted to it. Her legacy isn’t her skill with a slide rule—it’s her leadership in transitioning an entire team from one era of computing to the next.

The technological landscape is changing again. You have the same choice Vaughan had: adapt or become obsolete.

Dorothy Vaughan's transition from human Computer to IBM programmer at NASA offers timeless lessons for navigating today's technological upheaval