ritical Pitfalls New Developers Must Avoid in Their First Weeks

For the past 6 years, I’ve worked across 5 teams at Palantir.

I wish someone had warned me about these 7 mistakes at the start of my career.

Ready? Let’s get started.

? Download my FREE 101 React Tips And Tricks Book for a head start.

Mistake #1: Giving strong opinions about things you don’t fully understand yet

We want to prove our value during the first days of a job.

It’s natural to want to show your colleagues that you were worth hiring ?.

However, this can lead to giving strong opinions on things you don’t fully understand yet.

Examples

• Someone asks about testing → you proclaim, “It’s criminal not to have 100% coverage.”

• Someone talks about state management libraries → you question why the team uses Redux and suggest Zustand.

• The team decides to cut features to meet a deadline → you talk about how this would’ve backfired at your previous company, lost users, yada yada...

I can tell you right now: this will not land well 99% of the time.

Why?

• You don’t have the full context, so your input is, at best, noisy and, at worst, counterproductive.

• You waste your colleagues’ time as they argue or explain things to you.

• You may come across as “show-offy” without realizing it. This isn’t the best way to make friends ?.

So, should you keep quiet during your first weeks? Absolutely not.

You were hired to contribute to the team and share your perspective. However, make sure that:

• You collect as much context about the team and product as possible—ask “why” first.

• You don’t get too attached to your opinions. Present them as suggestions rather than hard truths.

• You “show, don’t tell” whenever possible.

Mistake #2: Trying to figure out everything by yourself

Unless you’re the only person on your team, ask for help.

Ask after trying for a reasonable amount of time. What’s reasonable depends on the type of question:

• If you’re sure you won’t find a solution even after an hour—or if the issue blocks your productivity—ask immediately. For example, you should ask questions like “How do I set up this computer to work with tests?” instantly.

• If it’s a technical problem you can solve by Googling or using AI tools, try that first. If it doesn’t work, ask for help after 30 minutes.

Why ask for help?

• You don’t know what you don’t know.

• Time spent figuring out what others already know is time you could spend on productive work.

If you’re in an environment where help isn’t readily available, you’ll have to figure things out.

Make sure to document your findings for the next person. This builds a knowledge base and earns you “good teammate” points.

Mistake #3: Focusing too much on onboarding and ignoring your colleagues’ work

I’m super introverted ?.

So, I find it hard to reach out randomly to new people.

However, whenever I’ve joined new teams, I’ve forced myself to talk to teammates—and it’s always paid off.

How?

• Onboarding felt less intimidating when I realized my colleagues were normal people willing to help.

• I gained valuable context and understood what mattered most to the team.

• I built a network of people I could turn to for support.

So, as soon as you join a new team, set up 1-on-1 meetings with teammates.

Ask them about their work, the team’s history, how they see their role, and any advice they might have.

Mistake #4: Trying to memorize everything

On my first team, I felt super lost ?.

People used acronyms in meetings, and I struggled to follow conversations. Even when I knew some of the acronyms, I still felt overwhelmed.

I tried to memorize everything.

But this was pointless.

Everything will eventually become second nature. It’s normal to feel overwhelmed at first.

The key is to keep asking clarifying questions.

Over time, you’ll understand things better and build muscle memory.

Mistake #5: Complaining excessively about your team systems

No codebase is perfect.

No team is perfect.

Books and blogs often give the impression that:

• Everyone should use the latest libraries or frameworks.

• All legacy code should be refactored.

When you land on a team with different practices or “messy” code, you might start complaining.

You might even make a list of everything that’s “wrong.” ?‍♀️

This is the worst way to start a new job.

Unless you were hired to overhaul the team and its processes (and even then), don’t do this.

Why?

• You’re implying that the team is “poor” for missing things.

• You’re adding unsolicited work for your colleagues.

• You’re alienating people who built the systems without understanding the constraints they faced.

Instead, have a positive attitude:

• Look for ways to provide value.

• Show, don’t tell: introduce better patterns in your pull requests.

• Open technical discussions with the team.

If you’re unhappy with the systems, consider interviewing elsewhere ?.

Mistake #6: Attempting to refactor code without context

I’ve made this mistake.

I wanted to provide value, so I refactored code without being asked.

It didn’t go as well as I hoped.

Later, when someone joined the team and refactored my code without asking, I got a taste of my own medicine ?.

Refactoring someone’s code without context can feel like an attack. It’s like someone spoiling your art.

Don’t @ me: I know this is not healthy?.

Why it’s a problem:

• You miss the context for why the code exists.

• You overlook more essential tasks.

Instead, only refactor code if:

• Someone asks for help.

• You can integrate the refactor into meaningful work (e.g., a pull request).

Mistake #7: Setting unrealistic expectations

Don’t work 12–14 hours a day during your first weeks unless you plan to do so long-term.

It might seem like a good idea because:

• You want to prove your value.

• You feel there’s too much to learn.

• You’re on probation.

But this can backfire:

• It sets unrealistic expectations for your team. Scaling back later could create friction.

• It’s unsustainable and might lead to burnout.

Instead:

• Meet the team’s expectations first.

• If you want to do more, ensure it’s sustainable and beneficial.

The first weeks are a grace period. People expect you to learn, not to immediately deliver value.

That's a wrap ?.

Onboarding is challenging.

But some mistakes can make it far worse:

• Sharing strong opinions without context.

• Taking actions without context.

• Not leveraging your colleagues.

Avoid these mistakes, and you’ll settle into your new team quickly.

And don't forget to drop a "???".

If you're learning React, download my 101 React Tips & Tricks book for FREE.

If you like articles like this, join my FREE newsletter, FrontendJoy.

If you want daily tips, find me on X/Twitter or Bluesky.

? TIP OF THE WEEK

? FOOD FOR THOUGHT

<script> // Detect dark theme var iframe = document.getElementById('tweet-1877747297402142883-419'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1877747297402142883&theme=dark" } </script> <script> // Detect dark theme var iframe = document.getElementById('tweet-1876901704563872142-960'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1876901704563872142&theme=dark" } </script>

The above is the detailed content of ritical Pitfalls New Developers Must Avoid in Their First Weeks. For more information, please follow other related articles on the PHP Chinese website!