High code quality only indirectly affects users. The main purpose is to keep development velocity high which benefits all stakeholders
— zoechi
We recently asked the web dev community on Reddit.com what the most common misconceptions are amongst junior developers, and we got a ton of great responses -- more than 270 to be exact.
Because there was so much to discuss, Matija and I decided to summarize the replies and give our own opinions in a longer-form YouTube video, which you can watch below.
You can also continue reading further for a summary of the main concepts.
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 top replies were issues that encompassed all of these themes. For example, take the top-voted reply:
First Quality & Then Velocity
The top reply above touches on all three of the common themes we outlined, because within it is a message about quality -- about doing things correctly. And whenever you speak about quality, there is an inherent assumption that it takes longer, so we're also talking about time management. And, if you're a part of a team, you can't work effectively without good communication and teamwork.
Nevertheless, in the "quality" debate there were effectively two camps, with those who thought quality code was about:
- writing clean, readable code, that's easy to maintain
- 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 trump clean code patterns in the dash to meet deadlines and keep clients happy, while others thought that clean, 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, it's probably best for Junior devs to focus on quality first, and then improve their speed of delivery second.
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. "Code reviews are not personal", and 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:
- You should try it out yourself first.
- Use the resources available to you (Google, Stack Overflow, GPT) to try and figure it out.
- Ask for help once you considerably slow down on making any progress.
- 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. 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's 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.
Want to stay in the loop? → Join our newsletter!
Top comments (0)