Every five years, the engineer's day reshapes

1. The job has never been static

There's a story that gets told about software engineering: that the model showed up and broke a stable profession.

It's the wrong story. The job hasn't been stable. It reshapes about every five years. The current shift is bigger than most, but it isn't the first one, and people who've been in the field a long time have seen this pattern before.

Here's the rough timeline.

Era	Roughly	What the engineer's day was about
Mainframe	1960s	Writing programs on punch cards, submitting batches, waiting hours for output.
Terminal	1970s	Typing into a terminal connected to a shared machine. Output came back in seconds, not hours.
Personal computer	1980s	The machine on your desk was yours. Compile, run, debug, all locally.
IDE and version control	1990s	Tooling caught up. Refactoring became safe. Teams could work on the same codebase without overwriting each other.
Internet and open source	2000s	The library you needed was a download away. You wrote less code from scratch. Stack Overflow opened in 2008.
Cloud and mobile	2010s	You stopped running your own servers. You shipped to phones. Microservices broke the monolith into pieces.
AI-assisted	2020s	The model writes a first draft. You spend more time specifying, verifying, and reading.

Each shift broke something. Each shift made someone obsolete. Each shift also made the job richer for the engineers who adapted.

2. What the shifts have in common

A few patterns are worth seeing.

The first is leverage. Every shift gave the individual engineer more leverage. A 1980s engineer with a personal computer could do work that took a 1960s team a week. A 2010s engineer with the cloud could ship to millions without owning a data center. A 2020s engineer with the model can scaffold an app in an afternoon.

The second is taste. The more leverage you have, the more your decisions matter. Bad decisions get amplified faster too. The skill that becomes scarce is knowing what to build and what to skip.

The third is reading. Each era, engineers spend more time reading code and less time writing it from scratch. Open source meant you read other people's libraries. Microservices meant you read other teams' APIs. The model means you read what it just generated for you.

3. Why the current shift feels different

It feels different because of speed. The model went from "a fun toy" to "in every IDE" in about three years. There wasn't time for the field to adjust gracefully.

It also feels different because of what got automated. Past shifts automated mechanical parts of the job: typing, compiling, deploying. The model automates parts of the job that used to feel like thinking. That's why it lands harder.

But the shape of the shift is the same. Some skills got cheaper. Some got more valuable. The engineers who do well are the ones who notice which is which and adjust.

4. What the rest of this chapter does

The rest of Chapter 1 zooms in on the 2010s-vs-now comparison. Two days in the life, side by side. A skill stack, side by side. What got easier, what got harder, what disappeared. The myths people repeat. How teams are reshaping.

By the end you should have a sharper, more honest picture of what the work is now. That picture is what every other chapter builds on.