What Junior Devs Get Wrong

Asking Senior Devs

We recently took to the web dev community on Reddit to ask Senior Devs the question:

What are the most damaging misconceptions amongst junior devs?

We wanted to know what junior devs get consistently wrong, and what they can do to improve. Surprisingly, the senior devs we asked gave us a ton of responses -- more than 270 to be exact!

And because there was so much valuable information here, we've decided to summarize the replies in this article.

So, have a read, and then let us know in the comments what you think :)

The Most Common Themes

Among the responses were lots of great, specific examples, but we noticed a lot of common themes within them:

• Code Quality
• Managing Time & Expectations
• Effective Communication & Teamwork

These seemed to be the topics senior devs had the most to say about. And it makes sense -- these are the things that, when you get to the core of the issues, can make or break almost any career.

It was also interesting to see that the most popular replies were issues that encompassed all of these themes. For example, here is the top-voted reply:

First Quality & Then Velocity

High code quality only indirectly affects users. The main purpose is to keep development velocity high which benefits all stakeholders
  — zoechi * r/webdev

In the "quality" debate there were effectively two camps, with those who thought quality code was about:

1. writing clean, readable code, that's easy to maintain
2. writing code that gets shipped on time and works.

The balance between meeting deadlines, shipping features, and writing the best possible code is obviously a tricky one to get right.

Some people had the opinion that business realities mean that teams often don't have time for clean code patterns. The most important point is to meet deadlines and keep clients happy.

On the other hand, many senior devs thought quality code should be the priority, and that by making it a priority you can actually increase long-term velocity, even if short-term deadlines aren't met.

This discussion can distract from Junior developers priorities though, which are to grow and improve as a developer, not lead the team to success. Therefore, we think it's probably best for Junior devs to focus on quality first, and then improve their speed of delivery second.

Btw, we're building Wasp, a full-stack React + NodeJS framework with superpowers, to be one of the best ways to level up your skills as a full-stack web developer.

By starring our repo on GitHub you're helping us continue to make web dev faster and easier, and bring content like this to you every week.

⭐️ Thanks For Your Support 🙏

Stay Humble & Manage Expectations

As a Junior developer, it's not expected that you're going to get everything right the first time.

There is an assumption that you will learn the best practices over time, and along the way you might produce inconsistent work, make mistakes, or even possibly break some things along the way.

But that's okay.

It's part of the process. It's expected. And it's important to remember that this is not a reflection of your value or worth as an engineer or individual.

In the replies, there were also many developers who recognized another developer's desire "to fix things later" as a way to brush off criticism towards their work. They generally viewed this as a bad habit to get into, as it is often one that plagues developers even as they gain more experience.

For example, "Code reviews should not be taken personally", was a common point being made by senior devs.

So being able to take criticism graciously is an important skill to develop.

After all, seniors are there to guide you towards making better decisions based on their own experiences. And juniors are there to learn.

But how often should you seek a Senior's advice? Should you do what they said, or what some dude told you is the only way to do x on YouTube or in some blogpost ;) ?

Should you ask for help every time you get stuck, or should you compromise your sanity and struggle alone for days?

Well, it depends on who you ask. But most of the replies made it clear that:

1. You should try it out yourself first.
2. Use the resources available to you (ChatGPT, Stack Overflow, Google) to try and figure it out.
3. Ask for help once you considerably slow down on making any progress.
4. If you have a possible solution and it differs from the senior dev's suggestion, that doesn't mean it's wrong -- there can sometimes be many possible ways to achieve the same goal!

Be Flexibile & Open to Change

Nothing changes faster than the world of technology. As a developer, you need to constantly be learning and adapting to new technologies and trends. If you don't like change, well then being a software developer probably isn't the right career for you.

On top of things changing constantly, it's the kind of job that challenges your assumptions. For example, what you think might be the best solution turns out to be incompatible with your team's desired goals or end product, and you're forced to use a "sub-optimal" solution instead.

Why? Because it might the best way to
get the job done given your team's constraints. ("Sorry, pal, but we can't use your favorite framework on this one.")

The developers who stay flexible and open-minded are often at an advantage here.

They're the ones that are less dogmatic about a particular technology or approach, and are more willing to adapt to the situation at hand. They're typically the ones that progress faster than their peers, and they're the ones that get the job done well.

If you found this useful so far, please show us your support by giving us a star on GitHub! It will help us continue to make more stuff just like it.

⭐️ Thanks For Your Support 🙏

So, what do you think?

Ok, so that's our summary.

What do you think about these opinions? Are the senior devs right in their assessment, or are they missing something?

Have you realized something recently that you wish you had known earlier? If yes, then share it with us in the comments!

Psst! my colleague and I also discussed the results and weighed in with our opinions at greater length in this YouTube video below. So check it out, if that's your sort of thing :)