Backend Developer

Building a web service used to be one person's job. The same developer wrote the screen, put the server up, and typed the data in by hand. While the service was small this was fast. One person built a button and the address that button called, so there was nothing to meet about.

That arrangement stops holding once the user count climbs. A service ten people used and ten thousand now use splits into two kinds of problem. On the screen side the pile is browsers that render the same page differently and a first paint that takes three seconds. On the server side it's two requests landing in the same instant and touching the same value until the number comes out wrong, and a machine that falls over at four in the morning. The two are fixed differently and checked differently.

When one person carries both, the urgent side takes the person. Pagedeck went through this. While Theo held the screen and the server together, every day an incident alert fired was a day the screen work promised for that week slid into the next one. So the building work was cut in two. A frontend developer takes the part users see and click, and a backend developer takes the part behind it that pulls the data and applies the rules.

Roughly half the day goes into building something new and the other half into fixing and guarding what already runs. In order it usually looks like this.

1. Checking the night — error logs and response times from overnight come first. Two hundred errors at three in the morning with no support tickets is the more urgent case, not the less: data is drifting out of shape and nobody noticed.
2. Design — turning a requirement into a shape data can hold. "Let people comment on a document" arrives as a sentence, and the first decisions are which table the comment lands in, which fields it carries, and what happens to it when the document is deleted.
3. Agreeing on the interface — what the screen side receives, and in what shape, gets written down as an API (application programming interface), a pact two programs make in advance about what they hand each other. Once it exists on paper, both sides work at the same time instead of waiting on each other.
4. Implementation — writing the code that was agreed. Most of the hours go into pulling exactly what's needed out of the database quickly, and into deciding what comes back when a request arrives malformed.
5. Review and release — a colleague signs off through code review, then CI/CD (continuous integration and continuous delivery) runs the checks automatically and pushes the result to the server.
6. Interruptions — the incidents and questions that arrive in between. This is the one item that never fits in the plan, which is why the hours actually available in a cycle run shorter than expected.

One standard runs through all six. The question isn't whether the code works now but whether it still works with ten times as many users. Code that fetches an entire list in one go runs fine against a hundred rows and takes the service down the day there are a million.

The list of people a backend developer talks to daily is short and fixed.

With the frontend developer the interface gets renegotiated constantly. Adding one field to a response, or deciding a list comes back twenty items at a time, changes what the screen can look like. When one side settles it alone, the other side's work gets thrown out and started again.

With the product manager the conversation is about cost. Mia describes a feature and Theo says whether it touches the data structure. Two requests that look equally small from outside routinely come out at one day and three weeks, and that gap is where priority order actually gets decided.

With the DevOps engineer and the SRE (site reliability engineer) the line is drawn by layer. The servers the code runs on and the release pipeline belong to them; the code running on top belongs here. When something gets slow, neither side can tell from its own layer whether the cause is the code or the machine, so incidents put everyone in one room. At a company with few people these seats don't exist separately and backend developers absorb the work.

With the data engineer the subject is records. Anything the company wants to count later has to have been written down at the moment it happened, so logging is decided while the feature is built, not after. With the QA engineer the subject is what breaks. The argument is rarely about the path where everything goes right; it's about what the server does with input nobody expected.

"That's not a screen-only change — the backend has to move too. The storage structure changes."

A signal that a request which looks small is actually a large piece of work.

"Just give me the response shape first. I'll wire the screen up against fake data in the meantime."

An agreement to work in parallel instead of in sequence.

"One of our two backend developers is on incident duty this week, so we can take less."

The headcount is unchanged, but the amount that fits in the plan is not.

At Pagedeck someone asked for expiry dates on shared document links. The screen Noa drew was a single date picker, and Mia read it as work that would land inside the week. What Theo saw sat a layer down. The four hundred thousand links already out in the world carried no expiry field and every one had to be filled in, and the decision to refuse a request arriving on an expired link had to live on the server rather than the screen, because anyone typing the address directly walks straight past whatever the screen checks.

It came out at one day of screen work and seven days of server work. Schedules slip most often over differences that aren't visible from the outside.

The most common misreading is that a job with no user contact is a job far from user experience. Nothing visible gets built here, so it looks that way. But a large share of what users feel as friction is settled on the server: the four seconds a list takes to appear, the double charge when someone presses the payment button twice. Treat this seat as unrelated to the screen and the product comes out clean to look at and tiring to use.

The second is that knowing a language and a set of tools is the skill. Job posts lead with language names, so it reads that way. What separates people is the judgment about what gets stored where. A data structure chosen wrongly at the start is not covered up by good code later, and fixing it means moving everything already stored, which multiplies the cost. Tools take about six months to pick up; this judgment takes a few failures.