Engineering

For a long time, making software went by a single word: coding. Hire someone good, sit them down, and a product comes out the other end. For a small program that was more or less true. Things stopped being true once the program was sold and had to run every day.

A live service takes work that has nothing to do with writing new code. Somebody puts the new code onto the server. Somebody checks afterward that it still behaves. Somebody wakes up at 3am when it stops. Somebody adds capacity when the user count climbs. Somebody makes sure nobody else's account can be broken into. Every one of those costs a person a day of their week, and none of them fit inside the word coding.

So Friday nights at early companies tended to look the same. A developer pushed the file they had just edited from their own laptop straight onto the server, loaded the page once to confirm it appeared, and went home. On Monday a report arrives that payments are failing, and the first job is working out what changed last week — except that nothing recorded the change apart from the memory of the person who made it. Rolling back is not possible either, because there is no point to roll back to.

The word engineering is a claim that this work is a process rather than a personal knack. Fields that carry the name have a trait in common: follow the same steps and different people get comparable results, and when the result comes out wrong you can point to the stage where it went wrong. The attempt to give software that trait is what produced the stages — design, implementation, deployment, operation — and each stage grew named work and people who own it.

The work under this heading splits along two questions. Who does it is the roles branch; what it acts on is the other twelve. Those twelve sit in the order a line of code travels on its way to a user's screen: architecture, implementation layers, communication, data storage, infrastructure, deployment, collaboration, quality, operations, security, performance, and AI.

Roles divide the people. There are eleven seats, and they fall into four groups by the kind of work involved.

1. Building seats. A frontend developer owns the screen people look at and click; a backend developer owns the server behind it that fetches data and applies the rules. A full-stack developer does both jobs, and a mobile developer does the same work on a different stage — an iPhone or Android app instead of a browser.
2. Running seats. A DevOps engineer automates the path that carries finished work onto servers. A site reliability engineer (SRE) fixes a number for how many minutes a month the service is allowed to be down, then defends that line. A data engineer collects records scattered across systems and reshapes them into something analysis can use.
3. Guarding seats. A QA engineer finds what is broken before it ships. A security engineer finds the hole an attacker would use before the attacker does.
4. Leading seats. A tech lead owns the technical decisions of one team. A chief technology officer (CTO) owns the whole technical organization, hiring and budget included.

Eleven seats does not mean eleven people. Pagedeck has 45 employees and no dedicated SRE or security engineer at all; that work is split between one DevOps engineer and the backend developers. Seats usually separate at the moment one person can no longer hold two kinds of work at once. Ask someone to write a new feature while incident alerts land on their phone and the alerts take the person first, every time, while the feature keeps slipping.

Architecture is the branch that draws before anything gets built. Software architecture decides what chunks the system is cut into and how those chunks talk to each other — whether payments, notifications, and document storage live in one piece or three. Once decided, changing it is expensive. Fixing a feature costs a day; recutting the chunks costs a quarter.

Implementation layers divide what gets built by where it runs. The frontend runs inside the browser, the backend runs on the company's servers, and a single save button touches both. The button turning grey the instant it is pressed belongs to the frontend. The content actually surviving until tomorrow belongs to the backend. Splitting them this way is what lets two people work on the same feature without reading each other's code, as long as they agree first on what passes between the layers.

Communication joins those two layers, and separate systems to each other. An application programming interface (API) is an agreement fixed in advance about what two programs send each other and in what shape. When the agreement is written down, the screen side and the server side can work at the same time instead of waiting on each other, and pulling in another company's service goes through the same kind of door.

Data storage keeps what has to be kept. A database puts one document, one payment, one account in a defined place and hands it back quickly when asked. Finding one row out of a million in a hundredth of a second does not happen by accident, which is why it gets treated as its own area.

Infrastructure is the floor everything else stands on. Infrastructure means the servers, networks, and storage that actually run the service. Ten users and a hundred thousand users need different floors, and a team that has not decided in advance how it grows and shrinks tends to go down on the exact day things go well.

Deployment and collaboration cover merging work and sending it out. Version control records who changed what and when, and merges several people's edits without them overwriting each other. Continuous integration and continuous delivery (CI/CD) takes the merged code, checks it automatically, and carries it onto the server when the checks pass. Those two are what killed the Friday night story above.

Quality protects the product before and after it ships. Testing gets a machine to confirm the code still does what it was meant to do. Code quality keeps that code in a state where a stranger can read and change it six months later. The first catches what is broken now; the second lowers the odds of something breaking later.

Operations watches the system while it runs. Observability means planting logs and metrics ahead of time so that what is happening inside can be read from outside. Incident management is the agreed procedure for who moves first and what gets restored first when something actually stops. DORA metrics measure how often and how safely the organization ships, using four figures: deployment frequency, lead time for changes, change failure rate, and time to restore service.

Security keeps what comes from outside out. Application security means making sure the code leaves no path to log in as someone else or open someone else's documents. One breach removes every bit of trust built up to that point, so this gets folded into the design stage rather than bolted on after the features are finished.

Performance deals with speed. Web performance measures and shortens how many seconds a screen takes to appear and how fast it answers a click. Push a first load from one second to three and the number of people who leave in between rises visibly, which is why slowness gets treated as a revenue question rather than an inconvenience. It also tends to arrive as a late surprise: a page that felt instant with 20 test documents can crawl for the customer who has 20,000 of them.

AI is the newest branch here. AI engineering covers pulling language models into a product. It differs from the branches above in one respect: the same input does not reliably produce the same output, so the method for judging whether an answer is right has to be built before anything else.

The thirteen branches are not stages in a line — they feed each other. How the architecture was cut decides what a deployment unit is. Frequent deployment cannot survive without testing and observability. What observability records becomes the raw material for tracing the next incident and for the next round of performance work.

"That's an engineering call, not a product call. Which of the two ways we build it is ours to decide."

Drawing a line: product decides what gets built, engineering decides how.

"We've got two people's worth of engineering this quarter. The priorities need another look."

Headcount converted into usable time, as a statement about how much work can fit.

"This quarter's engineering work is the deploy pipeline, not new features."

A declaration that a full quarter is going to something with nothing visible on screen at the end.

At Pagedeck, Theo goes into feature meetings checking two things: what has to be built, and how it can be built on top of the structure that already exists. When Mia proposes expiry dates on shared document links, Theo works out on the spot how many screens change, whether the agreement between screen and server has to change, and what happens to the millions of links already out in the world. The last of the three is usually the long one.

In quarterly planning, Grace asks how many people go to features and how many go to foundations. Load only features and the quarter's numbers look good, while the same work costs twice as much next quarter. Theo brings numbers into that conversation — how long one deployment takes end to end, how many minutes of downtime last quarter held. Arguments made in those terms survive the meeting; arguments made as a preference do not.

The most common mistake is reading engineering as a synonym for writing code. Code is the only visible output, so the reading comes naturally. In practice, writing new code is a fraction of a developer's day; the rest goes to reading code other people wrote, working out why something fails, deciding how to build the next thing, and defending what already shipped. Left uncorrected, this shapes schedules that budget only for the writing. Review, testing, deployment, and incident response have no square on the calendar, so they get pushed into evenings, and a few quarters of that is when people resign.

The second mistake is treating engineering as a department that fulfills feature requests. Features are what shows from outside, so there's a pull toward measuring the group on how fast features arrive. But technical decisions set the product's lifespan. A system built as one piece and split apart two years later costs something close to building it again. Keep the technical side purely on order-taking duty and nobody makes those decisions early, until one quarter the time to ship a single feature has quietly doubled.