Use the first month to learn the codebase, the people and how work flows; the second to ship small things reliably; the third to own something a bit bigger. Agree expectations with your manager early, write down what you learn, and ask good questions quickly instead of struggling alone.
What people tell me
I am starting a new developer role soon, and the last time I joined a company I felt lost for months. The codebase was huge, everyone used acronyms I did not know, and I was afraid to ask too many questions. I spent weeks quietly struggling. I want this time to be different and to make a good impression without burning out trying to prove myself in the first week.
A composite of the messages behind this question, with personal details left out.
Key takeaways
- Nobody expects you to be productive on day one. They do expect you to learn visibly and ask good questions.
- Agree with your manager in week one what a good first 30, 60 and 90 days look like.
- Ship something small in the first two weeks, even a documentation fix, to learn the full path to production.
- Keep a running notes file of systems, people and terms. It becomes your onboarding guide for the next person.
- By day 90, aim to own one small area end to end, not to know everything.
What people actually judge you on early
In the first three months, your team is not measuring how much you know. They already know you do not have their context. They are quietly watching three things:
- How quickly you learn, and whether you remember what you are told.
- How you ask for help, and whether your questions get sharper over time.
- Whether you finish things, even small ones.
If you get those right, the technical depth follows.
Week one: set expectations
In your first one-to-one with your manager, ask:
- "What would a good first 30, 60 and 90 days look like for me?"
- "Who are the three or four people I should get to know first?"
- "How do you prefer updates: written, in standup, or in our one-to-ones?"
- "What is one thing previous new joiners struggled with here?"
Write the answers down and send a short summary back. You now have a shared definition of success, which removes a lot of anxiety.
A 90-day plan
| Period | Focus | Concrete goals |
|---|---|---|
| Days 1 to 14 | Environment and people | Local setup working, first small change merged, met your immediate team one to one |
| Days 15 to 30 | How work flows | Understand the path from ticket to production, pick up two or three small tickets |
| Days 31 to 60 | Reliable delivery | Deliver normal-sized tickets with light guidance, start reviewing others' code |
| Days 61 to 90 | Ownership | Own one small feature or area end to end, suggest one improvement |
The first two weeks
- Get your environment working and document the gaps. If the setup guide was wrong, fix it. That is often the most useful first contribution you can make.
- Ship one tiny change to production. A typo fix, a log message, a test. The point is to walk the whole path: branch, review, CI, deploy. The post What Actually Happens Between Your Pull Request and Production is a good primer.
- Meet people. A 20-minute chat with each teammate: what they work on, what they wish new people knew.
Learning the codebase
Do not try to read everything. Follow one request or one feature through the system from the user's click to the database and back. Draw it. Then do the same for a second feature. How do I learn to read a large codebase when I can handle small projects but get lost in real ones? goes into techniques for this.
Keep a notes file with three sections: systems (what exists and what it does), people (who knows what), terms (acronyms and internal names). Review it on Fridays.
Asking questions well
The fear of asking too much is common, and the cost of asking too little is much higher. A simple rule: try on your own for a set time, then ask with context.
"I am trying to get the payments service running locally. I followed the README, and it fails at the migration step with this error. I checked that my database version matches. Is there a step that is not documented?"
That question shows effort and is easy to answer. Batch small questions and ask them together once or twice a day, rather than interrupting every ten minutes. How do I ask for help at work without making people think I am incompetent? covers more phrasing.
Days 60 to 90: show ownership
By now you should be able to take a normal feature with light guidance. Pick one area, ask to own it, and treat it as yours: fix the small bugs, improve its tests, document it. Suggest one improvement you have noticed, framed as a question: "I noticed builds take 15 minutes. Would it help if I looked into caching?"
At day 90, ask your manager for feedback directly: "What is one thing I am doing well and one thing I should change?"
A weekly update habit
A short written update every Friday does a lot of quiet work for you in the first three months. It shows progress, surfaces blockers early and gives your manager something concrete to reference. Keep it to five lines:
- Done this week: what you finished or merged.
- Learned: one system, tool or process you now understand.
- In progress: what you are working on and when you expect to finish.
- Blocked or unsure: anything you need help with.
- Next week: what you plan to pick up.
It takes ten minutes. After a few weeks, your manager has a clear record of how quickly you are ramping up, and you have one too. When you feel like you are not progressing, reading back your first four updates is usually reassuring.
Common mistakes
- Trying to prove yourself with long hours. You will burn out before month three and the habit becomes expected.
- Rewriting things in the first month. You do not yet know why they are the way they are.
- Staying silent when stuck. Two days lost quietly looks worse than one clear question.
- Comparing with people who have been there for years. Compare yourself with where you were last month.
- Skipping the relationship part. People help those they know.
If you are still stuck
The Your first tech job roadmap walks through onboarding in stages, and the book The Missing README is a practical guide for new engineers. To go further, join Sefism: learning is free, and joining gives you credits plus your first roadmap. As a member you can ask your own question about your new team, or book a 1:1 session to plan your first three months.
Was this answer helpful?
Read next
Your situation is not quite this one?
Members get written answers to their own questions, a roadmap built for them and feedback on their projects. Early access is open: sign up and your account is active shortly after. Prefer to talk? A free call works too.