The Software Engineer Workflow: From PRD to Merging into Main

Many people picture a software engineer's job as "writing code all day". In reality, writing code is only one part. Before code is written there are requirements to understand, and afterwards there's review, testing, merging, and releasing.

This article gives an overview of the software engineer workflow — how engineers work on a product team — from reading the requirements document to code landing in the main branch.

The big picture

Every company's workflow is different, but the general pattern is similar:

1. Understand the requirements — from a PRD, a ticket, or discussion with the product team.
2. Plan — break down the work and decide on the technical approach.
3. Create a branch — work separately from the main code.
4. Write code and commit in small steps.
5. Test — make sure the change works and doesn't break anything else.
6. Open a Pull Request.
7. Automated checks (CI).
8. Code review — receive feedback and improve.
9. Merge — the change lands in the main branch.
10. Release and monitor.

Let's go through them one by one.

1. Understand the requirements: reading the PRD

Work usually starts from a PRD (Product Requirements Document) or a ticket. This document explains the problem to solve, who the users are, and what success looks like.

An example section of a simple PRD:

User story: As an admin, I want to filter orders by status, so I can immediately see orders that haven't shipped.

Acceptance criteria:

• A filter is available for pending, paid, and shipped statuses.
• The filter can be cleared to show all orders.
• The page stays responsive with thousands of orders.

The engineer's job at this stage is to ask questions when something is ambiguous. For example: can the filter select more than one status? Does the result need pagination? Questions asked early are far cheaper than code that has to be rewritten.

2. Plan the technical approach

Before writing code, engineers think about:

• which parts of the codebase will change,
• whether database schema changes are needed,
• how to keep performance good as data grows,
• how to test it.

For large pieces of work, this plan may be written as a short design document and discussed first. For small ones, it's enough to think it through or note it in the ticket.

3. Create a branch

Each piece of work is done on a separate branch so the main branch stays stable:

git switch main
git pull
git switch -c feature/order-status-filter

Branch naming conventions vary by team, for example feature/..., fix/..., or including the ticket number. If the Git commands aren't familiar, see Git for Beginners.

4. Write code and commit in small steps

Experienced engineers rarely write everything at once and commit once. They work in small steps: one logical change, one commit with a clear message.

git commit -m "Add status parameter to the order list query"
git commit -m "Add status filter dropdown component"
git commit -m "Sync filter to the URL so it can be shared"

Small commits make review easier and make it easier to find the cause if something goes wrong later.

5. Test the change

Before asking for review, engineers make sure the change works:

• running the application and trying the main scenarios,
• trying edge cases — empty data, odd input,
• running existing tests and adding new ones where needed.

6. Open a Pull Request

After pushing the branch, the engineer opens a Pull Request with a title and description explaining what changed, why, and how to test it. Details are covered in What Is a Pull Request?.

7. Automated checks (CI)

On many teams, opening or updating a PR triggers Continuous Integration (CI) — an automated pipeline that runs the build, tests, linters, and other checks. PRs with failing CI are usually fixed before being reviewed.

8. Code review

Teammates read the change and give feedback: questions, suggestions, or requested changes. The engineer responds to every comment, improves the code, and pushes again to the same branch. This cycle can repeat several times.

What reviewers usually check and how to respond is covered in Code Review for Beginners.

9. Merge

Once approved and CI passes, the PR is merged into the main branch. Teams usually have rules, such as at least one approval and all checks green.

10. Release and monitor

Depending on the process, changes may be released automatically or batched into the next release. After release, engineers watch for errors or complaints and are ready to fix any issues.

Non-technical skills that get trained too

This workflow demands more than the ability to write code:

• Written communication — in tickets, PR descriptions, and review comments.
• Asking the right questions — clarifying requirements before building.
• Receiving feedback — improving without getting defensive.
• Estimation and prioritization — breaking big work into achievable steps.

Why is this workflow rarely taught?

Most learn-to-code material focuses on how to write code: syntax, frameworks, and sample applications. A team workflow is hard to teach through video because it needs specifications, a codebase, reviewers, and a running process. As a result, many new developers experience it for the first time at their first job.

The way to learn it earlier is to practice it: work on a real project with a specification, work through branches and Pull Requests, and seek review of your code.

Conclusion

The software engineer workflow covers much more than writing code: understanding requirements from a PRD, planning, working through branches and small commits, testing, opening a Pull Request, passing CI and code review, then merging and monitoring the release.

In the KodingCamp software engineer job simulation, you go through this workflow directly: receive a PRD, work the mission in a private GitHub repository, open a Pull Request, and pass the AI Tech Lead's review until the code is ready to merge.