First Project Tips for Junior Devs

This year I talked to a few guys who were about to join a new project. For them, it was their first or second project, and they were really worried they wouldn’t manage. I used to have the same thoughts — and sometimes I still do. A new team, an unfamiliar codebase, new technologies — basically, total uncertainty.

After 9 years in front-end, across 5 companies, 7 big projects, and a bunch of smaller ones, I’ve gotten used to these doubts and learned how to deal with them. But when you’re just starting out, it’s hard to rely on your experience.

After those conversations, I kept thinking about recording a video with tips that could help junior developers start a new project a bit more easily. So later, when I meet someone who could benefit from it, I can just send them a link.

So here I’ve collected tips that will help you get into the work faster and feel less stressed.

Prepare before you start

If you have some free time between the offer and your first day — use it to prepare. Ask the recruiter or the people who interviewed you what you should learn before you start.

I had a situation like this: I was starting at a company where the project used React and TypeScript. At that time, I didn’t have production experience with React, and I hadn’t used TypeScript at all. After I passed all the interview stages and accepted the offer, I had almost a month before my first day. I asked my future manager what I could watch or read to make it easier to start.

He recommended a TypeScript book and a series of React articles — and that’s what I read before I started. As a result, when I started on the project, I already had some basics, and getting into the work was much easier.

Clarify expectations

It’s really important at the very start to clarify what your manager, team lead, or whoever will evaluate your work expects from you. This helps avoid a situation where you’re genuinely trying your best, but in the end they’re unhappy with the results because they expected something different.

Ask what the expectations are for your first month. Usually during that time you’ll manage to:

• go through all the documents and trainings,
• meet the team,
• set up your local environment,
• and complete a few tasks to get familiar with the project.

But sometimes they expect you to start delivering tasks at the same level as everyone else from day one. It’s better to ask about this just at the beginning, so you have a chance to adapt to those expectations or adjust them.

It’s also useful to know what’s expected from you by the end of your probation period. Usually there are no fixed requirements — you just need to show that you’re a solid developer who can deliver tasks and work with the team. But sometimes they expect you to finish a big feature by the end of probation. It’s better to know this at the start.

Find someone you can go to with questions

When you join a new project, you’ll have a lot of questions at the beginning.

In big companies there’s often an onboarding process: a person is assigned to you to help you adapt. It can be your manager, a mentor, or just a developer who’s been on the project for a long time and knows “how things work here.” But if no one is assigned — find someone yourself.

It can be:

• a developer who sits next to you,
• someone you find easy to talk to,
• or your team lead.

It really helps to agree in advance how often you’ll come to them with questions:

• you collect questions in a list and come 1–2 times a day,
• or you message as questions come up.

A lot of people get annoyed when they’re constantly interrupted with questions. In those cases, having pre-agreed slots for discussion the questions works really well.

Before you go with a question, try to figure it out yourself first:

• google it,
• ask an AI,
• read through the code,
• debug it.

Then the other developer will see that you made an effort to solve the problem, but couldn’t, and you really do need help.

But it’s also important not to go to the other extreme and get stuck for too long, when a simple question could solve it in a few minutes. Your priority is to start closing tasks normally and bringing value to the team as soon as possible — not to prove that you can do everything on your own.

Take notes

On a project you’ll have a lot of questions, and even if you get answers, you’ll forget them after a while. To avoid asking the same thing multiple times, write the answers down. Build your own knowledge base for the project. It can be Notion, Obsidian, Notes, or a regular notebook. The main thing is that you can quickly find the info later.

I basically write down anything that helps me build a full picture of the project. It can be:

• unclear abbreviations and terms;
• team conventions and coding approaches I haven’t seen before;
• notes about where things are located in the project;

If your meetings are online, make sure to record them. After the meeting, you can rewatch it if you forgot something or didn’t fully understand it.

Understand who’s good at what

In most teams, expertise isn’t evenly distributed. Someone knows the build setup really well, someone prefers working on styles and layout, and someone else has deeper expertise in SEO and performance optimization.

Knowing who’s strongest in what area helps when you need support. You can message the person who’s most likely to help with your specific problem.

It’s also useful during code review: you’ll know who should look at your PR, and you can add that person as a reviewer right away.

And understanding everyone’s strengths can also show where the team is missing expertise — and where you can bring the most value.

If the team is small, you’ll quickly remember who’s good at what. But if the team is large, it’s useful to write this down in your knowledge base.

At one company we even had a special table in Confluence with all team members listed and their areas of expertise. That doc was made for people from other teams, so they’d know who to reach out to when they had questions about our project. But it could’ve been useful for newcomers too — if we had thought to show it during onboarding.

Read and write documentation

If the project has documentation — read it. But first, check how up to date it is. It might be outdated, and then it won’t be that helpful for understanding the project.

If the documentation is large, don’t try to read it all in one go. Skim the main sections to get a high-level picture of the project. You can go deeper later when you start doing tasks. Docs are easier to absorb when you have specific questions.

If there’s no documentation, you can start writing it yourself. Your personal knowledge base can become the foundation for project docs. It’s a good way to understand how the app works. While you write, you’ll run into questions — and you’ll have to go and find the answers.

You can write it just for yourself and not share it with anyone. Or, if there are tasks related to documentation, you can take those tasks and write docs as part of the work.

I had a situation like this: after a few months on a project, I still didn’t understand how it worked. The project was huge and had long history. The team had long wanted to write onboarding docs for newcomers, and they needed someone to start. I thought it was a good opportunity for me to understand the project better, so I took it on.

In the end, I wrote a few sections, and then the work stopped — because it looked like many people liked the idea, but no one actually wanted to write it. I’m not sure anyone used it after I wrote it. But for me, working on the documentation gave a big boost in understanding the project.

Tests

If the project has tests — make sure to read them. Well-written tests can work as documentation for the project. Pay attention to whether the project has e2e tests. They’re usually written around real user flows, and the most important flows often have tests.

If there are tasks related to writing tests, take them. It will help you dive deeper into how the existing code works.

Refactoring

Another good way to understand a project’s code is to refactor legacy code. For example, when I joined 2GIS, one of my first tasks was rewriting class-based React components into functional components with hooks. That helped me understand how components are written in that codebase and how state is managed.

This works especially well if you combine it with writing tests for the code you refactored. Just remember: not all legacy code should be rewritten — some code is better left untouched. If you’re unsure whether you should refactor a component or a function, ask someone on the team.

Read PRs

One good way to learn how code is written in a team is to read PRs. Skim through PRs in the project and look at what reviewers write in the comments and how the review process works.

The most useful ones are usually:

• the newest PRs, because they reflect the most up-to-date changes;
• PRs with a lot of comments, because they often include important discussions. Those PRs can cover big changes in the project — for example, architecture decisions, adopting new technologies or approaches, or code style changes that affect the whole team.

You can also ask the team to add you as an optional reviewer on PRs that might be useful for you. As an optional reviewer you won’t slow down the review process (no one is waiting for your approval), but you’ll be reading the most recent code and gradually building context around the project.

Ending

That’s all the tips I have. I hope it was useful. And if you know someone who might find it useful too, share it with them. Thanks!