Your First 90 Days as a Developer: The Complete Survival Guide

The first 90 days at a new developer job determine your trajectory for the next 2-3 years. No pressure.

I have seen developers get promoted within six months of starting. I have also seen talented engineers get fired during their probation period — not because they could not code, but because they misread the room. The difference between these outcomes almost never comes down to technical skill. It comes down to how you navigate the first 90 days.

This is the guide I wish someone had handed me on day zero. Not generic career advice. Specific, tactical moves for software developers entering a new team.

Why 90 Days?

The 90-day window is not arbitrary. Research from the Society for Human Resource Management shows that 90 days is roughly the time it takes for a new hire to either integrate into the team or start showing signs of misfit. It is also the standard probation period at most companies — which means someone is actively evaluating you during this time.

Here is what your manager is actually looking for during each phase:

• Days 1-30: Can this person learn? Are they asking the right questions? Do they fit the team culture?
• Days 31-60: Can they contribute? Are they picking up tasks independently? Do they communicate clearly?
• Days 61-90: Can they own things? Are they reliable? Would I trust them with a critical feature?

Notice that "Can they write brilliant code?" does not appear on this list. That is because your manager already assumes you can code — they hired you. What they are evaluating now is everything else.

Before Day 1 — The Preparation Checklist

Most developers treat the period between accepting the offer and starting the job as vacation time. Smart developers treat it as preparation time.

Research the Company, Team, and Product

Do not just skim the company's "About" page. Go deep:

• Download and use the product. If it is a web app, sign up. If it is a mobile app, install it. Use it for a week. Note bugs, confusing UX, things you like. This gives you context that no onboarding document can provide.
• Read the engineering blog. Most tech companies have one. You will learn their tech stack, their architectural decisions, and their values. If they wrote about migrating from REST to GraphQL, you now know what their API layer looks like before day one.
• Find your future teammates on GitHub/LinkedIn. Not to stalk them — to understand what the team looks like. Are they writing open-source libraries? Are they active in the community? What technologies are they excited about?
• Check Glassdoor and Blind. Not for the overall rating — for the specific engineering team reviews. You will often find comments about the codebase quality, deployment process, and team dynamics.

Set Up Your Workspace and Tools

Do not wait until IT gives you a laptop to start preparing:

• Install and configure your editor. If you know the team uses VS Code, set it up with your preferred extensions. If they use IntelliJ, get familiar with the keybindings.
• Brush up on the tech stack. If the job description mentions Kubernetes and you have only used Docker, spend a weekend running through a Kubernetes tutorial. You do not need to become an expert. You just need to not look blank when someone mentions pods.
• Set up your note-taking system. You will absorb enormous amounts of information in the first month. Have a system ready — whether it is Notion, Obsidian, or a plain markdown file. Create sections for: team members, architecture notes, codebase quirks, and questions.

Prepare Mentally

Imposter syndrome hits hardest during the first two weeks. You will sit in meetings where people throw around acronyms you have never heard. You will open the codebase and feel like you are reading a foreign language. You will wonder if they made a hiring mistake.

This is normal. Every single developer has experienced this. The codebase that seems incomprehensible on day one will feel like home by month three. The acronyms that sound like gibberish will become second nature.

Write this down somewhere visible: "Confusion is temporary. Competence is built."

Week 1 — Survive and Observe

Day 1 Survival Guide

Your first day has exactly three objectives:

1. Get your development environment running. Clone the repo, install dependencies, run the tests, build the project locally. If you can run the app on your machine by end of day one, you are ahead of schedule. Document every step, because the README is probably outdated.
2. Meet your team. Not just names and roles — learn what each person owns. Who is the person to ask about the database? Who knows the deployment pipeline? Who has been here the longest?
3. Find your onboarding buddy. Most teams assign one. If they do not, pick someone who seems approachable and ask: "Can I come to you with beginner questions this week?"

Questions to Ask Immediately

In your first week, gather this information:

• "What is the team's deployment process?" (You will need this sooner than you think.)
• "Where do I find the architecture documentation?" (The answer is often "we don't have one," which is also useful information.)
• "What are the coding conventions?" (Tabs vs spaces is the least of it — learn about naming conventions, PR size expectations, and test requirements.)
• "What is the biggest technical challenge the team is facing right now?" (This tells you where the team's attention is focused.)
• "What does a successful first month look like for me?" (Ask your manager this directly. Write down the answer.)

What NOT to Do

This is critical. In your first week, do not:

• Do not suggest changes to the codebase. You do not have enough context yet. That "ugly" piece of code might exist for a reason you cannot see from the outside.
• Do not refactor anything. Even if you see obvious improvements. You will get your chance. Right now, you are building trust, not showing off.
• Do not skip meetings to write code. Your instinct is to prove yourself through output. Resist it. The relationships you build in meetings are more valuable than any code you write in week one.
• Do not pretend to understand something when you do not. Saying "I'm not familiar with that — can you explain?" is a sign of maturity, not weakness.

Month 1 — Learn and Contribute

Building Relationships

In a remote-first world, relationships do not build themselves. Be intentional:

• Schedule 15-minute 1-on-1s with every team member. Ask them: What do you work on? What is your biggest frustration? What do you wish new developers knew? People love talking about their work, and you will learn more in these conversations than in any documentation.
• Be visible in Slack/Teams. Respond to questions in team channels. Share interesting articles. React to messages. Presence matters.
• Show up to optional events. Team lunches, virtual coffee chats, demo days. These are where real bonds form.

First Code Contributions

Your first PRs should be small, safe, and well-documented. Here is the ideal progression:

1. Documentation fixes. Find an outdated README, fix it. This shows you are reading the docs and paying attention.
2. Bug fixes. Pick small, well-defined bugs from the backlog. Something like "fix alignment on the settings page" is perfect — contained scope, visible result.
3. Test additions. Adding tests to untested code is pure gold. Nobody will ever complain about more test coverage. And writing tests forces you to understand the code.
4. Small features. By the end of month one, aim to complete at least one small feature end-to-end (write the code, write the tests, submit the PR, address review comments, deploy it).

Understanding the Codebase

Do not try to understand everything at once. Use this approach:

• Trace a request end-to-end. Pick a simple API endpoint. Follow the request from the router through the controller, service layer, database query, and back. Map it out on paper. Now you understand the architecture better than most documentation could explain.
• Read recent PRs. The last 20 merged PRs tell you what the team is working on, how they structure changes, and what standards they enforce in reviews.
• Draw diagrams. Seriously. Box-and-arrow diagrams of the system architecture, data flow, and service dependencies. Keep them in your notes. Update them as you learn more.

Documenting What You Learn

This is your secret weapon. New developers have a superpower: fresh eyes. Things that seem obvious to the team are confusing to you — and they are probably confusing to the next new hire too.

Document as you go:

• "I spent 2 hours figuring out how to run migrations locally. Here is the process." Push that to the wiki.
• "The env variable names in the README do not match what is in the .env.example file." Fix both.
• "There is no documentation for how the auth flow works." Write it after you figure it out.

Managers notice when someone improves the onboarding process for the next person. It shows initiative, communication skills, and team-first thinking.

Month 2 — Own and Deliver

Taking Ownership of Tasks

By month two, your manager should be assigning you work without hand-holding. Here is how to handle it well:

• Break tasks down before starting. When assigned a feature, write out the subtasks before writing a single line of code. Share them with your manager or tech lead. "Here is how I am planning to approach this — does this make sense?"
• Estimate honestly. If you think it will take 3 days, say 4. Under-promising and over-delivering builds trust faster than anything else.
• Communicate blockers immediately. Do not spend two days stuck on something before mentioning it. The moment you feel stuck for more than 30 minutes, ask for help. This is not a weakness — it is efficiency.

Building Your Reputation

Your reputation in month two comes from three things:

1. Reliability. Do what you say you will do, when you say you will do it. If you are going to miss a deadline, communicate early.
2. Quality. Write clean code. Write tests. Handle edge cases. Leave the codebase better than you found it.
3. Communication. Send clear PR descriptions. Write concise Slack updates. Keep your Jira tickets current.

These sound basic, but most developers fail at least one of them consistently.

Handling Your First Code Review

Code reviews are the crucible where reputations are forged.

As a receiver:

• Do not take feedback personally. A comment like "this could use early return here" is not an attack. It is a gift.
• Ask for clarification on feedback you do not understand. "Can you explain why you prefer this approach?" shows you want to learn.
• Implement feedback quickly. A PR that sits in "changes requested" for a week tells the team you do not prioritize their feedback.

As a giver:

• Start reviewing others' code as soon as you feel comfortable (usually around week 3-4). You do not need to be an expert to catch typos, missing tests, or unclear variable names.
• Be kind and specific. Not "this is wrong" — instead: "I think using .filter() here instead of a for loop would improve readability because..."
• Ask questions instead of making demands. "What happens if user is null here?" is better than "Handle the null case."

Month 3 — Impact and Visibility

Quick Wins That Matter

By month three, you should be looking for opportunities to make a visible impact. The best quick wins for new developers:

• Fix a long-standing bug that everyone has just gotten used to. Every team has a "yeah, that has been broken for months" item. Fixing it takes you from "new developer" to "developer who ships."
• Automate a manual process. If the team spends 30 minutes on every deployment doing manual checks, write a script. If test data setup is painful, create a seed script.
• Improve developer experience. Speed up the CI pipeline. Add a linting rule that prevents a common bug. Set up a shared debugging tool.
• Write an internal tech talk or brown-bag presentation. Share something you learned — a new library, a debugging technique, something from your previous experience.

Preparing for Your First Performance Review

Most companies do a review around the 90-day mark. Here is how to walk into it prepared:

• Keep a "wins" document. Every week, write down what you accomplished. PRs merged, bugs fixed, features shipped, documentation written, processes improved. You will forget half of this by review time if you do not write it down.
• Quantify your impact when possible. "Fixed 12 bugs" is better than "fixed some bugs." "Reduced CI build time from 18 minutes to 9 minutes" is better than "improved the build."
• Ask for feedback before the review. Do not wait for the formal review to hear how you are doing. Ask your manager in your regular 1-on-1: "What should I be doing more of? Less of?"

Setting Goals for the Next Quarter

In your review, come prepared with goals for Q2. Good goals for a developer finishing their first quarter:

• Own a specific system or feature area end-to-end
• Contribute to architecture decisions in your area
• Mentor the next new hire (yes, already — you are now the most qualified person to improve onboarding)
• Complete a specific technical learning goal (a certification, a new framework, a deep dive into the database layer)

The 10 Mistakes That Kill New Developer Careers

I have watched dozens of developers stumble during their first 90 days. Here are the mistakes that cause the most damage:

1. Going dark. Disappearing into your code and not communicating for days. Your manager assumes silence means trouble.
2. Over-engineering your first tasks. You do not need to build the perfect abstraction for a bug fix. Ship it. Iterate later.
3. Not asking for help. Spending 8 hours on something a teammate could explain in 10 minutes is not persistence — it is stubbornness.
4. Criticizing the existing codebase. "Who wrote this garbage?" — probably someone sitting next to you. Show respect for the context you do not yet have.
5. Skipping 1-on-1s with your manager. These are your most important meetings. Never cancel them.
6. Trying to prove you are the smartest person in the room. Nobody cares. They care if you are reliable, pleasant to work with, and getting better every week.
7. Ignoring non-code responsibilities. Sprint ceremonies, documentation, on-call rotations, team retros — these matter as much as code.
8. Not writing tests. "It works on my machine" is not a testing strategy. Shipping untested code in your first 90 days is a reputation killer.
9. Comparing yourself to senior developers. They have years of context you do not. Compare yourself to where you were last week.
10. Not having a learning plan. Wandering randomly through the codebase hoping to absorb knowledge is not a strategy. Be deliberate about what you learn and when.

The One Thing That Matters Most

If you take nothing else from this guide, take this:

Build trust through reliability.

Trust is the foundation of every successful developer career. And trust is built through one simple mechanism: consistently doing what you say you will do.

Say you will finish the PR by Thursday? Finish it by Wednesday. Say you will look into the bug? Follow up with findings by end of day. Say you will update the documentation? Actually do it.

Every kept promise is a deposit in your trust account. Every broken promise is a withdrawal. In your first 90 days, you cannot afford a single withdrawal.

The developers who thrive are not the ones who write the cleverest code. They are the ones their teammates trust to get things done — reliably, consistently, and without drama.

Your first 90 days are not about proving you are brilliant. They are about proving you are dependable. The brilliance can come later. The trust has to come first.

---

Want a complete day-by-day playbook? The First 90 Days Survival Guide includes a pre-Day-1 checklist, day-by-day first week plan, week-by-week first month plan, 20 strategic questions for your manager, stakeholder mapping template, quick wins framework, and performance review preparation guide. Don't wing it — plan it. Get it on Boosty.