Your first 90 days as a junior developer set the tone for the next two years. Not because anyone is grading you on a clipboard, but because the patterns you establish, how you ask questions, how you communicate when stuck, how you receive feedback, become how senior engineers see you long after the actual habits change.
This guide is the version we wish we'd had when we started. It's also the version we coach every new junior we hire at DevEntia through. Save it. Re-read it on day 30 and day 60.
Days 1, 30: Listen more, ship something small
Get your environment running before you touch the codebase
The first signal you give your team is whether you can follow setup instructions and ask for help cleanly when they break. Onboarding docs are always slightly out of date. When a step fails, do this:
- Try one obvious fix on your own (google the error, check the version)
- Time-box at 30 minutes
- If still stuck, post in the team channel: "I'm trying to run X, hitting error Y, I tried A and B, what am I missing?"
That format, what you tried, what failed, is the universal "good question" template. Use it for the next two years.
Read the codebase before you change it
Spend the first week reading. Not skim-reading, actually opening files, tracing how a request flows from frontend to backend to database. Take notes. Draw the architecture on paper. By day 7 you should be able to explain the system in three minutes to another new hire. If you can't, you haven't read enough.
Ship one tiny, real PR by day 14
Not a "fix typo in README" PR, those teach you nothing. Find a small bug or a tiny feature, scope it down to half a day of work, and ship it through the full cycle: branch, commit, PR, review, address feedback, merge. The goal is to learn the team's review culture, not to impress anyone.
The juniors who feel paralyzed in month one all share the same mistake, they're trying to understand everything before changing anything. You will never understand everything. Ship the smallest thing that demonstrably works, then iterate.
Find your "tech mentor", informally
Not the person assigned by HR. The senior engineer who answers Slack questions thoughtfully and seems to enjoy explaining things. Ask them for a 15-minute weekly chat. Most will say yes. The signal value of that recurring meeting compounds, they'll start to vouch for you in rooms you're not in.
Days 31, 60: Take real ownership
Own a small feature end-to-end
By day 30 you should be picking up real tickets, not just paired starter tasks. By day 45 you should be the named owner of at least one small feature, meaning if it breaks, you're the one who debugs it.
This is the moment many juniors avoid because ownership feels heavy. Lean in. Own a feature you scoped yourself if necessary: an internal admin tool, a small reporting page, anything where you can say "I built this." That sentence becomes your most-used credibility builder for the next year.
Write the doc no one asked you to write
Every codebase has tribal knowledge, the deploy quirk, the env-var dance, the database backup routine, that lives in three senior engineers' heads. Write it down. Put it in the team wiki. The author of the doc becomes the de facto authority on the topic in two months. This is the cheapest credibility hack in software.
Start estimating
When tickets come in, get in the habit of estimating before you check anyone else's number. Write "I think this is a half-day" in the ticket comment. You'll be wrong constantly at first. Track the gap. By month 3 your estimates will be within 30%, better than most engineers ever get.
Common rookie mistakes to avoid
| Mistake | Why it hurts | What to do instead |
|---|---|---|
| PR-bombing reviewers with 800-line diffs | Nobody reviews them properly | Cap PRs at ~200 lines; split big work into stacked PRs |
| Silent struggling for 4+ hours | Wastes the team's time and yours | Time-box debugging; ask after 60 minutes of stuck |
| Refactoring code you don't fully understand | Breaks things in subtle, costly ways | Refactor only what you've fixed bugs in first |
| Saying "yes" to every request | Misses deadlines you committed to | "I can take this on after X, does that work?" |
| Skipping the standup with "no updates" | Reads as low engagement | Even partial progress + a blocker is a useful update |
Days 61, 90: Become a contributor, not just a learner
Lead a small project
By day 75, ask your manager for a contained piece of work to lead. Not "lead a team", lead the technical decisions on a feature with one or two collaborators. Decide the data model. Decide the API shape. Run the kickoff. Write the launch announcement. This is the transition from "junior who completes tickets" to "junior on the path to mid-level."
Give back to onboarding
You have one rare advantage senior engineers don't: you remember exactly what was confusing. Spend two hours updating the onboarding docs with the gaps you hit. Pair with the next new hire on day 1 of their first week. This is invisible work that compounds, the team starts to perceive you as a "team player" because you literally are.
Set up your performance loop
Most companies do formal reviews every six months. Don't wait. Schedule a check-in with your manager around day 90 with one question: "What would I need to demonstrate over the next six months to be considered for promotion?" Their answer becomes your roadmap.
What to ship by the end of 90 days
- 10, 25 merged PRs across small bug fixes, features, and refactors
- One end-to-end feature you owned
- One internal doc you authored
- A working relationship with one senior engineer mentor
- Comfort opening any file in the codebase without panic
The communication skills nobody warned you about
Technical skill gets you hired. Communication skill gets you promoted. The GitHub Octoverse 2024 data on remote-first developer norms confirms that asynchronous written communication is now the dominant medium, your Slack messages, PR descriptions, and design docs literally are how senior engineers evaluate you.
Five micro-habits that compound
- Write PR descriptions with screenshots and "why" not just "what." Reviewers should not have to read your code to understand intent.
- Reply to messages within an hour during work hours. Even "looking, will respond by 3pm" beats silence.
- Summarize meetings you attended in one paragraph. Post in the channel. People notice.
- Disagree in writing, calmly. "I see the case for X. My concern with X is Y. Could we consider Z?" That sentence structure works in every team.
- Acknowledge feedback without defending. "Good catch, fixing now" beats a paragraph explaining why your original code was actually fine.
The AI tools situation
You will be tempted to lean heavily on AI coding tools, Cursor, Claude Code, GitHub Copilot. Use them. But also: understand what they generate. The juniors who use AI as a typing accelerator while still building real understanding ramp faster. The juniors who paste outputs without reading them stall around month 6, when senior engineers start asking "why did you make this design choice?" and they have no answer. Our AI coding tools comparison covers this in depth.
What to do when you screw up (because you will)
You'll deploy something that breaks production. You'll merge a PR that introduces a regression. You'll write a comment in Slack that lands wrong. The pattern that matters:
- Surface it immediately. "I broke X. Investigating now." Beats waiting to be discovered every time.
- Fix the immediate problem. Rollback, hotfix, mitigate.
- Write a short blameless post-mortem. What happened, why, what would prevent it.
- Move on. Don't apologize for two weeks.
Senior engineers respect this loop because they've all run it themselves. The only unrecoverable mistake is hiding the mistake.
Working with DevEntia
If you're a tech leader hiring juniors and want a partner that ships production code while you focus on hiring, that's exactly what we do. Browse our services or tell us about your project.