The professional engineer workflow
How every tech company in the world ships code
⏱ Est. ~13 min
01 · Read
You've learned every individual skill: terminal, files, git, web server, APIs, Claude Code, debugging, deployment. Now let's combine them into the workflow every professional development team follows.
The tools vary — some teams use GitLab instead of GitHub, some deploy to AWS instead of Render, some use a different language. But the workflow is always the same. Learn this workflow, and you can walk into any tech company and understand how they ship software.
💡 Picture thisIndividual skills are like learning to dribble, pass, and shoot. The professional workflow is the actual game — the coordinated sequence that combines what you've learned into a result. Understanding the workflow is the difference between knowing how to code and being able to ship.
02 · Step-through
The full development cycle. Every feature, bug fix, and improvement follows this exact loop.
1. ISSUE
Someone reports a bug or requests a feature. It's tracked in GitHub Issues, a Jira board, or a simple to-do list. Every piece of work starts with a clearly described problem or goal.
2. BRANCH
Create a branch: git checkout -b fix-login-bug. Never work directly on main. Branches isolate your changes so you can experiment without breaking anything.
3. CODE
Use Claude Code to implement the fix or feature. Describe what you want clearly, review the output, and iterate until it's right. This is where the actual building happens.
4. TEST
Verify it works locally. Check the edge cases. Will it break anything else? Try weird inputs, empty fields, unexpected scenarios. Run the automated tests if you have them.
5. REVIEW
Run git diff. Review your own changes line by line. Would you approve this if someone else wrote it? Look for leftover console.log, hard-coded values, or anything that shouldn't be there.
6. COMMIT
Stage and commit with a descriptive message. One logical change per commit. 'Fix login validation to reject empty passwords' tells a story. 'Fixed stuff' doesn't.
7. PUSH
Push your branch to GitHub: git push -u origin fix-login-bug. This makes your changes available for others to see and review.
8. PULL REQUEST
Create a PR on GitHub. Describe what you changed and why. This is where teammates (or future you) review the code before it ships. Include context: what was the bug? How did you fix it? How can someone else test it?
9. MERGE
After review and approval, merge into main. The feature branch has done its job and can be deleted. Your changes are now part of the official codebase.
10. DEPLOY
If automatic deployment is set up (like Render), your changes go live automatically when merged to main. Otherwise you trigger a manual deploy. Either way, the cycle is complete — from idea to live feature.
03 · Read
Let's walk hands-on through the key git steps of this workflow. You have a project that isn't tracked by git yet — initialize it, create a feature branch, make a change, and stage it.
04 · Terminal exercise
Every project starts with git init. It turns a regular folder into a git repository so you can track changes.
(This section is interactive — please enable JavaScript.)
05 · Terminal exercise
Step 1: BRANCH — create a new feature branch. Never work directly on main. A branch lets you experiment safely.
(This section is interactive — please enable JavaScript.)
06 · Terminal exercise
Step 2: CODE — make changes to the project. Let's add a login form to an HTML file.
(This section is interactive — please enable JavaScript.)
07 · Terminal exercise
Step 3: COMMIT — stage the file and commit with a descriptive message. A good commit message explains what changed and why.
(This section is interactive — please enable JavaScript.)
08 · Read
🎯 Halftime — BRANCH → CODE → COMMIT, done
You just walked through the first three steps of a professional engineer's day-to-day: create a branch → write the code → commit with a descriptive message. Every team does this three-step dance, no matter how big the project.
What's left in the second half is PR (pull request) → code review → merge — that is, how you propose your branch get merged into the team's main line.
Why can't you just merge straight into main? Because if nobody reviews it before it's merged, bugs sail through unchallenged. A PR lets your teammates look at your changes, give feedback, and confirm it's good to go. That layer of process is the heart of professional engineering.
Key points
- Three-step dance: branch / code / commit (done)
- Three steps to go: push / pull request / code review + merge
- A commit message explains what changed and why — future you will thank present you
09 · Quiz
In the professional workflow, what do you create before you start writing code?
- A new repo
- A database
- A new branch
- A GitHub issue describing the work
10 · Fill in the blank
After finishing a feature, you create a pull _____ to propose merging your changes.
11 · Read
Congratulations. You just followed the same workflow used by Google, Stripe, Shopify, and every other tech company. The scale is different, but the workflow is the same: issue, branch, code, test, review, commit, push, PR, merge, deploy.
Big companies run the cycle hundreds of times a day. Now you do too.
12 · Quiz
You just finished a bug fix on a feature branch. What should you do before committing?
- Run git diff to review your changes line by line
- Push directly to main
- Create a pull request
- Delete the branch and start over
13 · Fill in the blank
In the professional workflow, every piece of work starts with a clearly described _____ — a bug report or feature request.
Other lessons in this chapter
⚠ The full interactive experience needs JavaScript. Please enable it and reload.
※ This is an independent Traditional Chinese teaching project — not an official Anthropic product. Claude™ is a trademark of Anthropic, PBC.