The first two weeks

Getting set up, finding your way around a codebase and a team, and learning how to ask for help well.

Also called 30-60-90 day plan

What: A written list of what you should learn and deliver in your first weeks and months, agreed with your manager.
Why: It turns vague expectations into something you can check, and it shows your manager you are taking ownership of your ramp-up.
Example: Week 1: environment running, first small fix merged. Month 1: owns small tickets in one service. Month 3: handles a medium feature with a review from a senior.

Watch out

Waiting to be told what success looks like and finding out at the end of probation.

Also called dev setup, dev environment

What: Everything needed to build, run and test the code on your machine: tools, versions, access, secrets and seed data.
Why: You cannot contribute until it works, and fixing the setup notes as you go is often a new joiner's first useful contribution.

Watch out

Silently fighting setup errors for two days instead of asking after an hour.

Also called unfamiliar codebase

What: A deliberate way to learn a large codebase: start from entry points, follow one real feature end to end, read its tests and use git log to see how it changed.
Why: Nobody reads a large codebase top to bottom. A guided path gives you a working map in days instead of weeks.

Shell

git log --oneline -- src/billing/
git log -S "applyDiscount" --oneline
git blame -L 40,80 src/billing/invoice.ts
rg "applyDiscount" --type ts

Watch out

Trying to understand everything before changing anything.

What: A question that states the goal, what you tried, what you expected, what happened and the one specific thing you need.
Why: It makes helping you fast, so people are glad to answer, and writing it often solves the problem before you send it.
Example: Trying to run the payments tests locally. I set up the env file from the README and ran make test. Expected green, got a DB connection error on port 5433. Is there a second database I need to start?

Watch out

Sending "hi" and waiting for a reply before asking the actual question.

Also called 15-minute rule, timebox

What: A fixed amount of time you spend trying on your own before asking for help, agreed with your team and adjusted as you grow.
Why: It balances learning by struggling with not wasting days. Early on, a short timebox is usually better for everyone.

Watch out

Staying stuck for a whole day because asking felt like admitting weakness.

What: A teammate assigned, or chosen by you, to answer everyday questions about the code, tools and unwritten rules in your first weeks.
Why: A buddy saves your manager's time and gives you a low-pressure person to ask. If none is assigned, ask your manager who could be one.

Also called engineering notebook, daily log

What: A private running document of commands, answers, names, terms and decisions you meet each day.
Why: You will hear hundreds of new things in two weeks. Notes stop you asking the same question twice and later feed your updates.

Watch out

Relying on memory and chat history, then losing an answer you needed.

Also called good first ticket

What: A small, low-risk ticket chosen so a new joiner goes through the whole path: branch, change, test, review, merge and deploy.
Why: The value is learning the path, not the change itself. Once you have done it once, every later ticket is less scary.

Go deeper