Demo: a day in a backend engineer's workflow, walked through

Written Explanation

The setting

The company runs a food-ordering service like the one used in earlier lessons. The backend returns a description of an order when the app asks for it. Our engineer, Sam, is a junior backend engineer on a team of five. The team uses a ticket system: a list of tasks, each with a short description and a status. Sam picks up this ticket:

Ticket ORD-142: Return the customer's email in the order response.

The ticket is short on purpose. Real tickets often are. Let us follow the day, step by step.

Step 1: Read the ticket

Sam reads the ticket, then looks at what already exists. Today the order response contains the order number and the total price in cents. The frontend team wants to show "A receipt was sent to ..." with the customer's email on the confirmation screen, so they need the email in the response too.

Reading includes reading existing code. Sam finds the class that builds the order response and its test, and reads them to learn how the code is arranged. This is the reading habit from lesson 1: code is read far more often than written, and a lot of the day is reading.

Step 2: Ask one clarifying question

Before touching the code, Sam asks one question in the ticket's comments:

"Is the email returned to anyone who asks for the order, or only to the logged-in customer who owns it? I want to be sure we are not exposing someone's email to another customer."

This is the "what problem are we solving?" habit. An email is personal data, so a wrong answer would be a privacy problem, not just a bug. The product owner replies within the hour:

"Only the owner. The existing access check already makes sure only the owner can read an order, so no change is needed there."

Sam now knows that the existing check protects the data, and that the change is small. The question took two minutes. Without it, Sam might have built a second, unnecessary access check, or worse, skipped thinking about access altogether.

Step 3: Create a branch

Sam makes a branch. In Git, the version control system used by most teams, a branch is a separate line of work, so Sam can change the project without disturbing teammates who are working on other things. A typical command is:

git switch -c feature/order-customer-email

git switch -c <name> creates a new branch and switches to it, according to Git's documentation. The branch name is a convention: this team puts a short description after feature/. (You will learn Git properly in a later module. For now, read it as "start a private copy of the work".)

Step 4: Make the change

Here is a simplified version of the code. It is a small, self-contained program so that you can see how the pieces relate. In the real service these classes would be in separate files and used by a web framework, but the shape of the work is the same.

public class OrderDemo {

    static class Customer {
        final String name;
        final String email;

        Customer(String name, String email) {
            this.name = name;
            this.email = email;
        }
    }

    static class Order {
        final long id;
        final Customer customer;
        final int totalCents;

        Order(long id, Customer customer, int totalCents) {
            this.id = id;
            this.customer = customer;
            this.totalCents = totalCents;
        }
    }

    static class OrderResponse {
        final long orderId;
        final int totalCents;
        final String customerEmail; // new field for ORD-142

        OrderResponse(long orderId, int totalCents, String customerEmail) {
            this.orderId = orderId;
            this.totalCents = totalCents;
            this.customerEmail = customerEmail;
        }

        static OrderResponse from(Order order) {
            return new OrderResponse(order.id, order.totalCents, order.customer.email);
        }
    }

    public static void main(String[] args) {
        Customer customer = new Customer("Lina", "lina@example.com");
        Order order = new Order(7L, customer, 1250);
        OrderResponse response = OrderResponse.from(order);
        System.out.println(response.orderId + " " + response.totalCents + " " + response.customerEmail);
    }
}

Running this prints 7 1250 lina@example.com. Before the change, OrderResponse had only two fields and a two-argument constructor. Sam added the field customerEmail, a third constructor argument, and the line that copies the email from the customer. The email is a real address that belongs to a customer, which is why the question in step 2 mattered. (The address shown is an obvious placeholder.)

Sam also adds a test: a small program that checks one behavior and reports pass or fail. The team uses JUnit 5, a common testing library for Java; its assertions are static methods of org.junit.jupiter.api.Assertions, according to the JUnit documentation.

import static org.junit.jupiter.api.Assertions.assertEquals;

import org.junit.jupiter.api.Test;

class OrderResponseTest {

    @Test
    void responseContainsCustomerEmail() {
        OrderDemo.Customer customer = new OrderDemo.Customer("Lina", "lina@example.com");
        OrderDemo.Order order = new OrderDemo.Order(7L, customer, 1250);

        OrderDemo.OrderResponse response = OrderDemo.OrderResponse.from(order);

        assertEquals("lina@example.com", response.customerEmail);
    }
}

(This test needs JUnit on the project's classpath, which a real project sets up with its build tool. Do not worry about that setup now.)

Sam then commits the work. A commit is a saved snapshot of the changes, with a short message that says what changed and why:

git add .
git commit -m "Return customer email in the order response (ORD-142)"

Step 5: Run the tests (the step Sam forgets)

The team's rule is: run all tests on your own computer before opening a pull request. The command depends on the project's build tool. Many Java projects use Maven or Gradle, and the command is often one of these (check the project's README for the real one):

./mvnw test
./gradlew test

On Windows the commands are usually mvnw.cmd test or gradlew.bat test. Running the whole test suite takes about a minute.

This is the planned mistake. Sam has just fixed a tricky formatting problem, feels done, and it is nearly lunchtime. Sam skips the full test run and moves on.

Step 6: Open a pull request

Sam pushes the branch to the team's shared repository (git push -u origin feature/order-customer-email) and opens a pull request. As GitHub's documentation describes it, a pull request is a proposal to merge the changes into the project, and a place where collaborators discuss and review the changes first. Sam writes a short description:

ORD-142: return customer email in the order response. Adds customerEmail to the order response so the app can show where the receipt was sent. Access control is unchanged: only the order's owner can read the order (confirmed with the product owner on the ticket). Added a test for the new field.

A good description says what changed, why, what was checked, and what the reviewer should know. A busy reviewer reads a clear description gladly.

Step 7: The automatic check fails

Within a few minutes, the pull request shows a red mark: the team's automatic check (the continuous integration job from lesson 3) failed. This job runs on a server whenever a pull request is opened or updated. It builds the project and runs all the tests, and reports pass or fail.

Sam opens the details and reads the message. The build fails to compile an older test called OrderResponseFormatTest, which still creates the response with the old two-argument constructor:

new OrderResponse(7L, 1250)   // no longer compiles: the constructor now needs three arguments

That is exactly what a local test run would have shown, in a minute, before anyone else saw it. Nobody is upset. The check did its job: it caught a problem before it reached the main code. Sam fixes the older test by passing an email as the third argument, runs the full test suite locally this time, sees all green, commits the fix, and pushes again:

git add .
git commit -m "Update order response format test for the new constructor"
git push

The pull request updates by itself, the check runs again, and this time it passes.

What Sam learns, and what the team's process teaches: do the cheap local check first, and read failures carefully, because the message usually says exactly what is wrong. Also, notice what did not happen: the broken code never reached users, and no one else had to stop their work.

Step 8: Respond to a review comment

A teammate, Dana, reviews the pull request and leaves one comment:

"Could we also add a test for what happens when a customer has no email (guest checkout)? What does the response show in that case?"

This is a real question about behavior. Sam checks the code: order.customer.email would be null for a guest, and the response would carry null. Whether the frontend can handle null is a decision to make. Sam replies:

"Good catch. For guests the response will contain null for the email. I'll add a test for that and ask the frontend team to confirm that the screen hides the 'receipt sent' line when the email is missing."

Sam adds the test, pushes, and messages the frontend engineer. This is the handoff as a conversation from lesson 2: the backend and the frontend agree on what the response means. Dana approves the pull request.

Step 9: Merge

With the checks green and the review approved, Sam merges the pull request, which makes the change part of the main version of the project. Merging is typically a button on the pull request page. Because of the team's pipeline, merging starts the next stage automatically.

Step 10: Release and watch

The team's pipeline builds the merged code and releases it. In many teams this is done in stages: first to a small share of traffic, then to everyone, with a quick way back (a rollback) if something looks wrong. The exact method depends on the team.

Sam does not close the laptop and leave. For a short while after release, Sam looks at the team's dashboard: a screen with charts of what the service is doing. Sam watches:

• The error rate: has it gone up?
• The response time: is the order endpoint still fast?
• The logs: are there new messages about missing emails?

Everything looks normal. Sam updates the ticket to "done", with a note: "Released. Guest orders return null email; frontend informed." The loop is closed, until a user or a chart gives the team the next idea.

The whole day, in one table

The times are invented for the story. Real days are interrupted by meetings, questions, other tickets, and surprises.