Your First Engineering Ticket: From Request to Pull Request

Your first ticket often looks smaller than the uncertainty around it. “Show a reminder when a project is overdue” could mean a banner, an email, or both. Before changing code, make sure you know what outcome the team expects and how you will tell whether you reached it.

This guide uses an illustrative project tracker. A ticket asks: “Show a reminder on overdue projects.” The example is simulated; use your team’s actual conventions and ask before changing product behaviour that is unclear.

1. Read the request and name the unknowns

Read the ticket, linked designs, discussion, and repository instructions. Separate the stated requirement from assumptions you are adding.

For this ticket, facts might be: a project has a due date, users can view a project page, and the reminder should appear after the date passes. Unknowns include the timezone rule, whether archived projects count, whether the reminder is dismissible, and whether it appears to viewers without edit permission.

Write questions in a short list. Resolve the ones that can change the implementation or user experience before coding. If the answer is not immediately available, propose a default and ask the product owner or teammate to confirm it.

2. Make the outcome testable

Turn the request into acceptance criteria. For example:

• An active project with a due date before the current date shows a reminder on its project page.
• A project due today or in the future does not show it.
• Archived projects do not show it.
• The reminder is visible to every project viewer and does not expose private project data.

These are candidate criteria, not facts from the original ticket. Confirm the assumptions about date boundaries, archived projects, and permissions with the person who owns the requirement.

3. Build a minimum useful map

Start with the README, project instructions, package scripts, and current Git status. Then find the project page route, the data shape for a due date, similar status messages, and relevant tests. Trace one request or render path end to end. Avoid reading unrelated directories just to feel familiar with the repository.

Before editing, note the files you expect to touch and the checks you expect to run. If an AI assistant helps search, ask it to identify candidate files and cite the symbols or paths it used. Verify those paths yourself; a plausible summary is not repository evidence.

4. Plan the smallest safe change

A reasonable plan might be:

1. Confirm the due-date representation and timezone convention.
2. Add a small helper that decides whether an active project is overdue.
3. Render the reminder in the existing project summary.
4. Add tests for overdue, today, future, archived, and missing-date cases.
5. Run the focused test, then the checks required by the repository.

Notice what this plan does not assume: a new notification service, a database field, or a broad project-page redesign. Change the plan when the code or confirmed requirement calls for it.

5. Implement in observable steps

Create or switch to the team’s expected feature branch. Check the working tree before you start so existing edits are not mixed into your change. Implement one small slice, then inspect the diff. Keep unrelated formatting and cleanup out of the ticket unless a real blocker requires them.

AI can help explain an unfamiliar helper, suggest edge cases, or draft a test. Give it the confirmed criteria and constraints. Review every proposed edit, especially date calculations and authorization boundaries. Do not provide private user data or secrets to a tool unless your organization has approved that use.

6. Verify behaviour, not just compilation

Run the narrowest relevant test first. A good test should fail when the old behaviour is present and pass with the change. Check the key boundaries: just before the due date, the due date itself, just after, no due date, and archived status. Run the repository’s required type, lint, or build checks before opening the pull request.

Then review your own diff:

git status --short
git diff --check
git diff

Confirm only intended files changed, no secrets or debug output are included, and the tests describe the behaviour you meant to change.

7. Open a pull request that helps the next person

Use the repository’s pull-request template if it has one. State the problem, the behaviour changed, the checks you ran, and anything a reviewer should inspect carefully. Link the ticket. Include screenshots only when they help explain a visible change, and remove private data.

Example summary:

Adds an overdue reminder to active project pages. The reminder appears only after the due date and is hidden for archived projects. Verified with the focused project-page tests and npm run check. Please review the date boundary and viewer-permission behaviour.

If a decision remains open, say so directly. A concise progress update before the pull request is also useful when the task is taking longer than expected or your assumptions changed.

Checklist to take back to work

• I understand the user or engineering outcome.
• I separated confirmed requirements from assumptions.
• I traced the smallest relevant path through the code.
• My implementation is scoped to the ticket.
• I tested important boundaries and failure cases.
• I reviewed the diff and recorded the checks I actually ran.
• The pull request says what changed and where reviewer attention is useful.

Practice

Take a ticket that says “make export faster.” Write three questions that could change the solution, then draft four observable acceptance criteria. Do not choose an optimization until you know the export’s size, current latency, output contract, and which users are affected.