# Production skill checklist *Insight · April 25, 2026 · 6 min read* # The Production Skills Checklist A practical checklist for engineers stepping into real production environments. Check every skill you can honestly say you have under pressure, not just in tutorials. Where the gaps are is where you start. --- ## Why credentials are not enough A PhD opens the door. It does not make you useful once you are inside. Production environments expose the gap between what you know in theory and what you can actually do when a system is live, a team is watching, and things are breaking. The engineers who survive that gap do one thing differently. They know exactly where they are weak, and they fix that first. This checklist is that map. --- ## Version control under pressure These are not beginner Git questions. These are the moments where not knowing costs the team real time. - [ ] You can resolve a merge conflict in a shared codebase without losing someone else's work - [ ] You understand the difference between `rebase` and `merge` and know when each one is appropriate - [ ] You have run a `git bisect` to track down a regression - [ ] You can recover a deleted branch or a bad reset using `reflog` - [ ] You know how to squash commits before opening a pull request - [ ] You have worked in a trunk based development workflow with other engineers committing simultaneously - [ ] You can read a diff and understand the intent of a change without running the code **Watch out for this:** Knowing Git commands from a tutorial is not the same as knowing Git in a team. The difference shows up the first time you touch a branch someone else is actively working on. --- ## Working with live systems Production is not a sandbox. Changes have consequences, errors have costs, and speed matters in a way that local development never prepares you for. - [ ] You have deployed code to a live environment and monitored it through the release - [ ] You have rolled back a deployment that was causing issues without being walked through it - [ ] You understand what a feature flag is and have used one to safely ship something to a subset of users - [ ] You can read application logs and identify where a failure originated - [ ] You have set up or worked with a CI/CD pipeline and understand what happens at each stage - [ ] You know how to check whether a deployed change is actually running in production - [ ] You have been on call or been responsible for a system during business hours **Watch out for this:** Moving fast in a local environment teaches you speed. Production teaches you caution. The engineers who last are the ones who treat both as skills worth developing deliberately. --- ## Cloud and infrastructure basics You do not need to be a DevOps engineer. You do need to understand the environment your code runs in. - [ ] You can navigate AWS, GCP, or Azure well enough to find logs, check resource usage, and identify what is running - [ ] You understand what environment variables are and why secrets should never be committed to a repo - [ ] You have worked with containerized applications and understand what Docker is doing at a basic level - [ ] You know the difference between a database connection limit and a timeout error - [ ] You have debugged a performance issue that turned out to be infrastructure rather than code - [ ] You understand what a load balancer does and why it matters for scaling - [ ] You can read a basic cost report and identify what is driving spend **Watch out for this:** Infrastructure knowledge compounds slowly and matters enormously. Every week you put off learning it is another week you cannot diagnose a whole category of production problems. --- ## Collaboration and code review Working alone is a skill. Working in a shared codebase with a team under pressure is a completely different one. - [ ] You have reviewed someone else's code and left comments that were specific, actionable, and kind - [ ] You have had your own code reviewed and incorporated feedback without getting defensive - [ ] You can explain a technical decision you made to someone who was not in the room when you made it - [ ] You write commit messages that a teammate six months from now would understand - [ ] You have caught a bug in a code review that would have caused a problem in production - [ ] You know when to ask for help and how to ask in a way that respects the other person's time - [ ] You have paired with another engineer to debug something neither of you could solve alone **Watch out for this:** The engineers who get promoted fastest are almost never the best individual coders. They are the ones who make the people around them faster and the codebase easier to work in. --- ## Reading your results **Mostly unchecked in version control and live systems.** Start here before anything else. These are the two areas that get engineers let go fastest, and they are both learnable in weeks with deliberate practice. **Mostly unchecked in cloud and infrastructure.** Pick one cloud provider and spend thirty minutes a day in its console for a month. You will cover more ground than you think. **Mostly unchecked in collaboration.** Find a team, an open source project, or a peer to do code reviews with. This skill only develops through real repetition with real feedback. **Mostly checked across all four.** You are operating at a professional level. The next move is mentoring someone else through this list. That is when the knowledge actually sticks. --- > "Credentials open doors. They do not make you useful once you are inside." > > Amit Maraj [Read on the site →](https://www.agenticamit.com/insight/production-skill-checklist)