What a traditional engineer's day looked like

1. A typical day, 2015

Set the dial to 2015. Mid-sized tech company. Senior individual contributor on a product team. Five years of experience. Writes a web service in Java, Python, or Ruby.

Here's what their day looked like.

Time	What they did
9:00	Coffee. Open laptop. Read email and Slack.
9:30	Stand-up. Ten minutes. Says what they did yesterday and what they'll do today.
9:45	Pick up the next ticket. Read the description. Skim linked design doc.
10:00	Open the codebase. Read the relevant module for fifteen minutes to remember how it works.
10:15	Start typing the new function. Look up the third-party library's docs in another tab.
11:30	First draft compiles. Run it locally. Fix three things.
12:30	Lunch.
13:30	Write unit tests. Run them. Fix two more things.
14:30	Open a pull request. Tag two reviewers.
15:00	Reviewer leaves comments. Discuss one in Slack. Update the code.
16:00	Reviewer approves. Merge. CI runs. Deploys to staging.
16:30	Test in staging. One thing breaks. Open the logs.
17:15	Find the bug. Fix it. New PR. Merge. Deploy.
18:00	Check the dashboard. Numbers look fine. Close laptop.

That's the day. Not glamorous. Not painful. Steady.

2. What dominated the time

A few things take up most of the day.

The biggest is typing. Writing code is slow, even for senior engineers. Most of the hour from 10:15 to 11:30 is keystrokes: writing the function, deleting and rewriting parts of it, typing the third-party library's method names.

The second is reading. Reading the ticket. Reading the design doc. Reading the existing module to remember how it works. Reading the library docs. Reading the reviewer's comments. Reading the logs.

The third is waiting. CI takes nine minutes. Staging deploys take three. Tests take a minute. Each wait isn't long on its own. Added up across the day, it's an hour.

3. The skills the day rewarded

Three skills got used heavily every day.

Syntax fluency. The engineer knew their language cold. Java's collections framework. Python's standard library. Ruby's blocks. They didn't look up the basics. Not looking up the basics saved an hour a day.

Pattern recall. They'd seen this kind of code before. They knew the shape of a retry loop, an idempotent endpoint, a paginated query. They didn't reinvent any of it.

Tool comfort. The IDE, the debugger, the test runner, the deployment pipeline, the dashboard. Each tool had a learning curve. After a year on the team, all of them felt natural.

These three skills compounded. A senior engineer in 2015 was, more than anything else, a fast typist with deep pattern recall who didn't fight their tools.

4. What was rare in the day

A few things you might expect were uncommon.

Writing things in plain English. Specifications were short, and most communication happened in tickets and pull request comments. Most of the day was code.

Reviewing someone else's draft. Code review happened, but it was a small slice of the day. The engineer wrote far more code than they reviewed.

Verifying behavior. Tests caught most regressions. The dashboard caught the rest. Active verification of new behavior happened at the end of the day, briefly.

These three things were minor parts of the 2015 day. The next unit will show why they're now the centre of the 2026 day.