I started way back in the 1900s, which would be a long time in and of itself. But I actually took CS-100 in 1987. <PAUSE> 39 years ago. Whew. It’s been a minute.
including: * COBOL. — Blech! I didn’t like that at all. * Visual Basic. — Meh. I actually liked it until I tried real OO. * And, JavaScript. — I actually like CSS better than JavaScript. My favorite language, by far, is Ruby.
Having lived through those other transitions, not one of them had the impact on me that AI is having. <PAUSE> In the past, I rejoiced at the changes: The Internet felt like like a world of creative opportunities opening up to me. Extreme Programming felt like it was designed by someone who actually wrote code for a living, not some project manager in an ivory tower somewhere. And, I adore Ruby! (I tolerate Rails.)
cultivated with my own hands. I tilled the soil. I pulled the weeds. I tended to its needs. <PAUSE> Now, my employer has asked that we do 100% agentic coding. So, I no longer get to feel the code as it flows through my fingers. <PAUSE> I really miss getting my hands dirty. <PAUSE>
to the process of building software. Even though the role of programmer is transitioning to AI, we humans remain absolutely essential to the creation of software systems. The machine may be able to write code. But it doesn’t know what code to write or necessarily even how to structure it until we give it a prompt. <PAUSE> And there’s actually historical precedent! We’re not the first to face this. Machines have arrived before. And when they did, there were humans in the room whose jobs were threatened.
women, many of who had degrees in mathematics, ran the numbers for engineers at research facilities across the country. The women in this photograph are computers from the Jet Propulsion Laboratory in Pasadena, California, circa 1960. As NASA (and it’s predecessor NACA) started to use IBM mainframes in the mid-1950s, these women’s jobs were in peril. Many were reassigned. Some retired. But some remained central to the mission. <PAUSE> This is the story of how…
made themselves integral to NASA’s Project Mercury. If you’re familiar with the book or film “Hidden Figures,” then you might recognize them. They are Dorothy Vaughan, Mary Jackson, and Katherine Johnson. Three human computers who thrived even as NASA pivoted from human to electronic computing. Before I tell you their stories, though…
not just facing new machines. They were facing segregation, sexism, and a society that saw the advanced mathematics they performed by hand as clerical, not professional work. <PAUSE> The strategies they used to stay ahead of the machine were forged under pressure many of us do not face today. <PAUSE> But their strategies do generalize. And we need them, today. So, I'm borrowing them here, with gratitude. <PAUSE> Ok… Allow me to introduce you to…
— a group of talented mathematicians who did all the calculations required for the aeronautics research going on at Langley, by hand, with mechanical calculators and slide rules. In 1949, Dorothy became department supervisor making her the first Black supervisor at NACA (of any gender). When NACA became NASA in 1958, the segregated West Area Computing Unit was disbanded. Dorothy and her team were reassigned to the new Analysis and Computing Division inside NASA. In the process, she lost her management position and never got it back. But she could see what was coming.
computing in the mid-to-late 1950s. This (clearly staged) photograph shows an IBM 704 at Ames Research Center, in the Bay Area. The giant building in the background is a full-scale wind tunnel that is still in use today. We know it’s staged because typically men operated the machines and women wrote the programs that performed the calculations. Programming was considered clerical work, because it involved typing.
at NASA in November, 1959. This is a photo of the two actual IBM 7090 mainframes that calculated flight data and tracked the Mercury flights in real time. This one is also staged, but it gets the demographics right. How can we tell? Well, if you zoom in, you’ll see that…
a “Hello, World” program. Note that the maximum number of characters was 80 per line. So, now you know why the first line of your git commit should be shorter than 80 characters. You’re welcome. But let’s get back to Dorothy. No one told her to…
local library and taught herself FORTRAN. Then she taught her entire team. In the movie version of the story, this happened in the West Area Computing Unit. But as I mentioned, that group was disbanded in 1958. She was no longer the manager in 1961. She was just one of the computers in the pool. She went on to become an expert FORTRAN programmer. She remained a programmer until her retirement in 1971.
title. The institution had stopped investing in her career. So she invested in herself. <PAUSE> Nobody told her to learn FORTRAN. There was no program to retrain the human computers. She built one. She taught herself, and then she taught her team. That's her lesson. When the ground shifts beneath you, retool yourself. <PAUSE> As a programmer, today, that might look like going deep into understanding AI and how best to leverage it and how to gain compliance from the LLMs. <PAUSE> Next, I’d like to introduce you…
an engineer named Kazimierz Czarnecki recruited her to work on the Supersonic Pressure Tunnel — a 60,000-horsepower, scaled wind tunnel at Langley Research Center in Hampton, Virginia. She accepted the offer and began working in the tunnel, simulating airflow at nearly twice the speed of sound. Though she switched departments, she remained a computer.
that she become an engineer. But to do so, Mary needed to take graduate level classes in mathematics and physics. Working and going to school meant she needed to attend the classes locally. But the University of Virginia only offered the night classes at the segregated, all-white Hampton High School. So, Mary petitioned the city of Hampton for permission to attend. She was granted permission. She completed the courses. And in 1958, she became NASA's first Black female engineer.
paper entitled “Effects of Nose Angle and Mach Number on Transition on Cones at Supersonic Speeds. This paper analyzed the boundary effects of different conical shapes and nose angles which informed the front end shapes of supersonic airplanes and rockets. And in 1961, Mary coauthored two more papers…
Transition at Super Sonic Speeds, and Boundary-Layer Transition on a Group of Blunt Nose Shapes at a Mach Number of 2.20. These papers were essential research for understanding how to minimize friction and manage the heat generated on the nose of spacecraft and jets traveling faster than sound. Her findings were directly applicable to confirming flight hardware designs, helping the United States return astronauts from space successfully.
Char-NETS-kee offered her a different path — not just a promotion, a transformation. Stop computing. Start engineering. The path had a cost: graduate classes at a segregated high school that she had to petition the city to attend, and years of night school after full days of work. She paid the cost and transformed herself into an engineer. That's her lesson. The job that hired you may not be the job that keeps you. Be willing to transform. Be willing to become someone new. This will be hardest for those of us who answer the “What do you do?” question with, “I’m a programmer,” or “I write software.” But the shift doesn’t need to be as large as Mary’s. Try this on for size: “I design software systems,” or “I’m a software architect.” <PAUSE> <PAUSE> Finally, allow me to introduce…
1953. Two weeks in, Dorothy assigned her to the Flight Research Division. Her knowledge of analytic geometry was so advanced, they never gave her back to the computing pool.
to attend the editorial reviews where research reports were finalized. But very quickly into her tenure in the Guidance and Control Branch, Katherine began asking “how” and “why” questions about her work rather than just completing tasks. She also began asking to attend the editorial review meetings where engineers discussed research reports before publication.
— the team that would put Americans into space — she was the only Black woman transferred in. She worked as a Research Mathematician in the Spacecraft Controls Branch. But she still wasn’t invited to the editorial review meetings. Instead, she was told it wasn’t “customary” for women to attend. So, she asked, “Is there a law that says I can’t go?” And finally, her boss relented. Once she broke this barrier, she became a regular participant in the briefings. Katherine’s expert knowledge in analytic geometry made her a valued engineering partner. And by 1960, she became the first woman in her division to receive author credit for a research report.
for Placing a Satellite Over a Selected Earth Position” — was the paper that told NASA the launch angle and burn times a vehicle would need to reach orbit and come back down at a specific location. This is how NASA knew where to position the Navy in order to retrieve the astronauts and their capsules. Note that Katherine’s name was not the only one on this paper. The other name is Ted Skopinski. Ted was Katherine’s colleague. He advocated for Katherine to receive credit, saying, “Katherine should finish the report, she’s done most of the work anyway.”
for Gus Grissom’s Liberty Bell 7 flight. The flight and splashdown went well. But the hatch on the capsule blew too soon, and Grissom’s space suit began filling up with water. He had to evacuate the capsule before it sank. The capsule was located and retrieved in 1999.
she wrote 26 research papers before retiring in 1986. The one she co-authored in 1960 — the azimuth paper — laid out the equations for putting a satellite in orbit and bringing it back to a chosen point on Earth. <PAUSE> When she hand-computed the flight data for Shepard and Grissom’s flights, she was using her own math. Her worth came from her skills as a mathematician, not as a computer. That's her lesson. Move upstream. Specify the domain. Write the ticket. Include the user story and acceptance criteria. Document the edge cases. Then confirm that the agent generated the correct tests before continuing on to implementation. Do what AI cannot. Specify what the system should and should not do. Own the definition. Own the requirements. Get ahead of the machine.
Computing Division at Langley alongside many other former human computers who’d also made the transition. Her division operated these twin IBM 7090 mainframes. Turns out, the machines that were supposed to replace human computers were programmed by those very same women.
brutal aerodynamics of leaving and re-entering the atmosphere. Her work on boundary-layer behavior around blunt-nosed bodies helped prove out that the Mercury capsule shape could survive the forces it would face — the heat, the pressure, the transition through Mach 1. Without that work, no one would have known the capsule would hold. Illustration credit: Mark Karvon.
the IBM was running. And Glenn — Glenn didn't trust the machines. Before the launch, he asked the engineers to 'get the girl' — Katherine — to run the same numbers, by hand, on her mechanical calculator. 'If she says they're good,' he said, 'then I'm ready to go.' She ran the numbers. She said they were good. So, he flew.
the Atlas rocket is a bit larger than the Redstone rocket used in the sub-orbital flights. <PAUSE> Both were significantly smaller than <ANIMATE> the Saturn V rocket that sent us to the moon, which was more than twice as tall as the Statue of Liberty..
his right shoulder is a camera. <PAUSE> The gauge over his left shoulder shows the cabin pressure and the pressure in his suit. <PAUSE> The star-shaped knob is an emergency override for the environmental controls. If he were to detect a drop in the pressure in his suit, he could pull that to release oxygen directly into his suit. Different components of the cockpit were different shapes so the astronaut could detect which control it was even if they couldn’t see it.
<PAUSE> The yellow dye was released in order to assist the helicopters in locating the capsule upon splashdown. <PAUSE> The capsule isn’t sinking because it’s sitting atop a giant airbag that inflated just before splashdown. <PAUSE>
These strategies aren’t a ladder. They’re not levels. They’re choices. Dorothy retooled. Mary transformed. Katherine specified. Each chose the path that fit who and where they were. <PAUSE> Three strategies. One mission. One man in orbit on our way to the moon.
be, too. <PAUSE> I’ve proudly identified as a programmer for 39 years. <PAUSE> And as a manager, I see it in my team. I see the various stages of grief: resistance, anger, bargaining, etc. So, I’ve also been trying to help them navigate this grief — even while experiencing it myself. It’s challenging. It’s also empathetic and necessary — especially if I’m going to train my team how to retool the way Dorothy did, encourage them to transform themselves the way Char-NETS-kee did, and enable them to write the specifications the way Skopinski did.
left hopeful. I’m reminded why I’m actually here. I’m here to serve the mission. The code was how I served in the past. It’s how we all served. <PAUSE> Like the human computers before us, the task of programming is moving to machines. But, the mission is still here. <PAUSE> So what do we do? We can retool. We can transform. We can specify. But we can’t do it in a vacuum. Because while we are working to find our place, our industry is also at a crossroads.
direction. Many in the industry see AI and think: efficiency. But that’s a failure of imagination. Think back to the 1960s. NASA didn't bring in the mainframes to cut costs. Those things were $20 million, each! They brought them in because their mission had expanded. They were no longer only doing aeronautics research. The space race had dawned. They were in a race to the moon. And, they pulled it off with less computing power than the toaster oven in your break room. In fact, today, a single week of computing on your laptop would have taken an IBM 7090 longer than the age of the universe to complete. And, that’s just a laptop. Image what we can do with all the competing power in these AI datacenters. With that much power at our fingertips, why limit ourselves to reducing the cost of today’s mission? Why not be more ambitious? And, I don’t just mean that for the leaders in the room. It’s a choice any of us can make sitting at our desk on a Tuesday morning. Why not upgrade Rails? Why not re-enable the linter rules you never had time to resolve? Why not take on that architectural change that would have previously required too much toil to be worthwhile.
but it cannot choose the destination. The machine can write code. But we’re the ones with the ambition to shoot for the moon. When we retool, transform, or specify, we aren't just protecting our careers—we are becoming the architects of new, more ambitious mission. We are turning efficiency gains into real, human breakthroughs.
aridlehoover
manfredsteyer
panda728
mshibuya
yuppeeng
tomoyakitaura
kajitack
yug1224
kuranuki
pluu
monochromegane
akashhashmi
reverentgeek
livdayseo
trallard
mojombo
aleyda
portentint
rkendrick25
afnizarnur
stephenakadiri
stephaniewalter
geoffreycrofte
