First 90 Days as a Software Engineer: Questions, Owners and a 30-60-90 Plan

Your first 90 days as a software engineer go wrong when you ship something visible in week two but still cannot explain how the system works. By week six that gap shows.

Picture a common setup. You join a team of eight that runs the refunds part of a payments app, with a few years of code behind it. The setup is made up, but each trap in it is one this guide works through.

In week one you fix three typo bugs and feel useful. In week three you are asked to change a refund rule, and git blame, the command that shows who last changed each line, names a formatting bot. You message four people. Nobody is sure who decides refund limits.

Nothing here is laziness. You chased speed before you had a map, asked questions one at a time as they came, and looked for owners in the wrong place. The first three months should build that map on purpose, and this guide shows how.

Eight terms carry the whole guide. Each one is tied to the refunds team.

• Ramp-up: the time it takes before you can pick up normal work on your own. On the refunds team, that means changing a rule without a guide beside you.
• Early win: a small change you finish and ship in your first weeks, such as fixing a flaky test, a test that passes and fails at random.
• Deep ramp: slower study of how the system works, such as reading the refund flow end to end and drawing it.
• Question budget: a plan for when and how you ask for help, so questions are batched instead of scattered across the day.
• Code owner: the person or team expected to review changes to a part of the code. On GitHub and GitLab they are listed in a file named CODEOWNERS.
• git blame and git log: git commands that show who last changed each line of a file, and the list of past changes (commits) to it.
• Architecture decision record (ADR): a short document that records one design decision, why it was made and what it costs.
• On-call shadowing: receiving production alerts alongside the engineer on duty, without being the one responsible for fixing them.

They should move from learning, to small ownership, to owning one area, with a check-in with your manager at each step. The usual name for this is a 30-60-90 plan: goals for days 30, 60 and 90.

The split is not magic, and your company may already have an onboarding plan. Treat ours as advice to adapt, not a rule. What matters is that each stage has a goal you can check, not just a list of things to read.

Do both, but choose early wins for what they teach, not for how they look. A good early win walks you through the real path a change takes, from your laptop to production.

The naive approach is to grab every quick ticket in week one. It feels productive, and it is wrong for one reason: typo fixes rarely touch the build, the tests, review or deploy. You end week three with five merged changes and no map.

The opposite mistake is reading code for a month before shipping anything. You learn names but not the friction, such as the slow test or the deploy step that needs approval. You also give your team nothing to review, so nobody sees how you work.

A better early win is small but crosses the whole path. On the refunds team, adding a log line to the refund approval step does that. You touch the code, a test, review, deploy and the dashboard where the log appears.

Ask your manager for one or two starter tasks chosen this way. Some teams label such tasks good first issue. If yours does not, the setup guide fix in the last row is usually available.

Try on your own for a fixed time, write down what you tried, then ask in a set slot, several questions at once. The budget is about timing and preparation, not about asking less.

The reason is focus. A question that arrives at random breaks someone's concentration. A batched question with what you already tried is quicker to answer, and one answer can cover several questions.

A phone data pack is a useful picture. Your daily pack is the slots your mentor offers, say two 20-minute check-ins (made up). Each question is data you spend. Writing down what you tried is like compressing a download: same answer, less spent.

Where the picture breaks: unused data expires, but unasked questions do not. They turn into wrong guesses that cost more later. Some questions also skip the budget entirely, as the list below shows.

1. 1

   Agree the slots

   In week one, ask your mentor when they prefer questions: a daily check-in, a chat thread, or both. Write the answer down.

2. 2

   Timebox your own try

   Pick a limit with your mentor, such as 30 or 45 minutes. Search the code, the docs and old chat threads first.

3. 3

   Write the question well

   State the goal, what you tried, what you expected and what happened. Paste the exact error, not a summary.

4. 4

   Batch and send

   Collect questions in one note and bring them to the slot. Mark which ones block you and which can wait.

5. 5

   Record the answer

   Add each answer to your notes or the team docs, so you rarely need to ask the same thing twice.

Skip the timebox and ask at once in three cases: anything touching production or customer money, anything about security or access, and anything blocking someone else. On the refunds team, a refund that may pay out twice is never a 45-minute puzzle.

Pause and predict: in week three, which of your questions is most likely to waste the most time? Make a guess before reading on.

Usually it is a question sent to the wrong person. That is why the next section is about finding owners.

Check three things in order: the CODEOWNERS file, the git history of the file, and then a person who can confirm. The file says who must review. The history says who has changed it. Only people can tell you who decides.

What the CODEOWNERS file tells you

A CODEOWNERS file maps file patterns to people or teams. GitHub's docs say code owners are automatically requested for review when a pull request changes code they own. Draft pull requests are the exception.

As of 29 October 2026, GitHub looks for the file in the .github folder, then the repository root, then the docs folder, and uses the first one it finds. The file on the pull request's base branch is the one that counts.

A team can also turn on Require review from Code Owners in a branch protection rule or a ruleset. Then a pull request needs approval from at least one of its code owners before merging. As of 29 October 2026, GitHub's free plans support code owners in public repositories only.

What git history tells you

Git history shows who actually changed the file and why. We ran every command below on Git 2.43.0 in a small test repository built like the refunds code. The names and emails in it are made up.

# Every change to the file, including before it was renamed
git log --follow --format='%h %as %an %s' -- src/refund_rules.py
# 0756506 2026-08-20 Dev Two Allow refunds up to 45 days
# d4f4089 2026-03-01 Formatter Bot Reformat whole codebase
# 8a0949e 2026-02-01 Dev Three Rename refunds module
# efe723b 2025-06-02 Dev Two Block refunds older than 30 days
# a9fc9e9 2025-01-10 Dev One Add refund rules

# Commits per author for a folder (pass HEAD explicitly)
git shortlog -sne HEAD -- src/
#      2  Dev Two [email protected]
#      1  Dev One [email protected]
#      1  Dev Three [email protected]
#      1  Formatter Bot [email protected]

# Which commits added or removed a piece of text
git log -S'age_days' --format='%h %as %an %s'
# efe723b 2025-06-02 Dev Two Block refunds older than 30 days

The real output of shortlog wraps each email in angle brackets; we removed them here. The %h, %as, %an and %s parts print the short commit ID, the date, the author and the commit title.

Without --follow, the first command stopped at the rename and showed only three commits. The docs say --follow works for a single file only. The -S option finds commits that change how often a string appears, so it pointed straight at the commit that added the 30-day rule.

Notice what the counts hide. The formatting bot ties with Dev One, and Dev Three only renamed the file. Commit counts are a hint about who to ask, not a list of owners.

The comment says to pass HEAD for a reason. The shortlog docs say that with no revision given, it reads standard input when that is not a terminal. In our script with input redirected, it printed nothing until we added HEAD.

Because blame shows the last commit that touched each line, and a reformatting commit touches almost every line. Tell git to skip such commits with an ignore-revs file, and blame shows the real authors.

In the test repository, a bot reindented the whole file in March 2026. Plain git blame then credited the bot with four of the six lines, including the 30-day rule's return line that Dev Two wrote in 2025.

# Plain blame: the formatting commit takes over (trimmed to the author columns)
git blame --date=short src/refund_rules.py
# ^a9fc9e9 src/refunds.py      (Dev One       2025-01-10 1)
# d4f4089e src/refund_rules.py (Formatter Bot 2026-03-01 2)
# d4f4089e src/refund_rules.py (Formatter Bot 2026-03-01 3)
# 0756506e src/refund_rules.py (Dev Two       2026-08-20 4)
# d4f4089e src/refund_rules.py (Formatter Bot 2026-03-01 5)
# d4f4089e src/refund_rules.py (Formatter Bot 2026-03-01 6)

# List the formatting commit (full ID) in a file and use it
printf '# Reformat whole codebase\n%s\n' "$(git rev-parse d4f4089)" | tee .git-blame-ignore-revs
# # Reformat whole codebase
# d4f4089e65f8ac8d08c7dcf20b41196edb8fb994
git config blame.ignoreRevsFile .git-blame-ignore-revs
git config blame.markIgnoredLines true
git blame --date=short src/refund_rules.py
# ^a9fc9e9 src/refunds.py      (Dev One 2025-01-10 1)
# ^?a9fc9e src/refunds.py      (Dev One 2025-01-10 2)
# ^?a9fc9e src/refunds.py      (Dev One 2025-01-10 3)
# 0756506e src/refund_rules.py (Dev Two 2026-08-20 4)
# ?efe723b src/refunds.py      (Dev Two 2025-06-02 5)
# ^?a9fc9e src/refunds.py      (Dev One 2025-01-10 6)

What just happened? The git blame docs say lines changed by an ignored commit are blamed on the previous commit that changed them. The question mark comes from blame.markIgnoredLines and flags a line whose credit moved.

Notice two more things in the output. The path column shows the old name, src/refunds.py, so blame followed the rename by itself. The docs say whole-file renames are followed automatically. A leading caret marks a boundary commit, here the repository's very first one.

Three details that catch people out

• Plain git does not read .git-blame-ignore-revs by itself. In our run, blame ignored the file until blame.ignoreRevsFile was set. Set it once per repository.
• If that setting points to a file that does not exist, our Git 2.43 run stopped with fatal: could not open object name list. We did not test newer versions, so avoid setting it globally.
• GitHub's web blame view reads a file named .git-blame-ignore-revs in the repository root, and shows a banner when it is hiding commits.

For a one-off check without any setup, git blame -w ignores whitespace changes, and --ignore-rev skips one commit. With -w alone, our run also showed the real authors, because the bot had only changed spaces.

Read the team's architecture decision records and recent postmortems in your first month. They answer the why behind the code, which git history rarely does.

The lightweight ADR format was set out in a 2011 post by Michael Nygard. He describes the problem new team members face: without the reasons, they either accept a decision blindly or reverse it blindly. Both are risky.

His format has five parts: title, context, decision, status and consequences. Records are numbered and kept in the repository. When a decision changes, the old record stays and is marked superseded, so you can read the history in order.

On the refunds team, imagine an ADR that explains why refunds over a limit go to manual review. Before you suggest removing that step, you would know which fraud problem it answered. That saves you a proposal your team has already rejected.

Postmortems, written reviews of what went wrong in an incident and why, teach you how the system fails. The on-call chapter of the Google SRE book says regular readings of past outages help new engineers understand production. It mentions teams that run postmortem reading clubs.

If your team has no ADRs, ask the person who has been there longest for the three decisions they would explain to a newcomer. Write them up as your first ADRs. SevyDevy's guide on architecture decision records for AI systems shows the format in more depth.

Receive real alerts alongside the person on call, follow what they do, and only later swap roles. On-call means being the engineer who answers production alerts during a set rotation.

The Google SRE book's chapter on bringing new engineers to on-call describes this. It suggests copying incoming pages to the new person, at first only during business hours. It notes that a shadow is not the appointed on-caller, which removes time pressure.

The same chapter describes reverse shadowing. You lead the response, while the experienced engineer diagnoses independently without changing anything. That is the step just before you go on call alone.

1. 1

   Get access early

   In month one, request read access to dashboards, logs and the alerting tool. Ask early, because access approvals can take time.

2. 2

   Read the runbooks

   A runbook is a step-by-step guide for one alert. Read the ones for your area and note any step you do not understand.

3. 3

   Shadow during work hours

   Ask to be copied on pages. For each alert, write what fired, what the on-caller checked and what fixed it.

4. 4

   Reverse shadow

   Lead a few responses while the on-caller watches. Say your next step out loud before you take it.

5. 5

   Join the rotation

   Go on call with a named backup for your first shift. Agree who to call, and when, before it starts.

Check it worked: by day 60, you should be able to take an alert from the refunds service to its dashboard, the matching logs and the right runbook without help. If you cannot, extend the shadowing; do not rush the rotation.

Write it in your first week, keep it to one page, and make each goal checkable. Then review it at days 30, 60 and 90 and change it openly.

A plan written alone tends to fail in one of two ways. It is either a reading list with no outcomes, or a list of features nobody agreed to. Draft it, then rewrite it with your manager.

1. 1

   Ask what success looks like

   In week one, ask your manager what a good first 90 days looks like for this role. Write their words down.

2. 2

   Draft three goals per stage

   Use the table earlier in this guide as a starting shape. One learning goal, one shipping goal and one people goal per stage works well.

3. 3

   Add a check to each goal

   Next to each goal, write how you both will know it is done, such as a change shipped or a diagram reviewed.

4. 4

   Keep a weekly log

   Each Friday, write three lines: what you shipped, what you learned and what blocked you. It makes check-ins quick.

5. 5

   Review and adjust

   At each check-in, mark goals done, dropped or moved. Moving a goal is normal; hiding that it moved is not.

The people goal matters more than it looks. Meet each person on your team one to one in the first month, and ask what they work on and what they wish newcomers knew. That is also how you find the real owners.

How do you ramp up without burning out?

Set a pace you could keep for a year, not for a month. Long evenings in the first weeks feel like progress, but they set an expectation you will later need to undo.

Three habits help. Leave a written note of where you stopped each day, so the next morning starts fast. Say when you are blocked within a day. Count reading and drawing as real work in your weekly log, because in the first month it is.

The weekly log has one more use. It becomes the raw material for your performance review and, later, for interview stories. SevyDevy's guide on building a behavioural interview story bank shows how to turn such notes into answers.

Explain it the way you would answer a system design interview question: requirements first, then the main parts, the data flow, the scale and the failure modes. Doing this by day 30 shows you have the map.

It also gives your team an easy way to correct you. Ask a teammate for 30 minutes, draw the refund flow, and invite them to interrupt. Every correction is a deep ramp lesson you got for free.

1. 1

   State what the system must do

   Approve or reject refunds, pay them out once, and record why. Name who uses it: customers, support staff and finance.

2. 2

   Draw the main parts

   The API that takes refund requests, the rules engine, the payout worker, the database and any queue between them.

3. 3

   Trace one request

   Follow a single refund from the support tool to the bank payout, naming each hop and what is stored where.

4. 4

   Give rough scale

   Ask for real numbers: refunds per day, peak hours, data size. Write down where they came from.

5. 5

   Name the failure modes

   A double payout, a stuck queue, a slow bank API. For each, say which alert fires and which runbook applies.

6. 6

   Name the owners and decisions

   For each part, say which team owns it and which ADR explains its shape. Mark anything you could not find.

The same frame answers a common interview question: how do you get up to speed on an unfamiliar codebase? Describe the steps above, then one place where a correction changed your understanding.