Being a junior developer is hard. At the start of my career, I used to feel overwhelmed, like I didn't know what I was doing. And that it was only a matter of time until I got exposed as the imposter that I was.

While I was at school and university, I seemed to have it all figured out - as long as you go to classes and maybe study a little, you're good. But when you're on your first day at work - what the hell do you do?

There were all these people I'd never met before (everyone was so serious), following some processes I didn't know (scrum-what?) And the codebase - larger and scarier than I've ever seen. Not to mention written in programming languages and frameworks I've never heard of (does anyone code in Groovy or use Ext.js anyway?)

I wish there was someone to reassure me or some sort of guidelines I could follow to not only survive but succeed. Well then...

After having been a professional software developer for over 7 years now, here's what I wish I knew at the beginning of my career as a junior developer.

1) First, Relax

When you're at your first job as a junior developer it's easy to get the impression you're expected to deliver results (and quickly). At least that's how it was for me - people around me were stressed, constantly talking about some deadline they have.

Don't get caught up in it. You as a junior developer are there to learn.

Nikki Siapno

@nikkisiapno

Dear Junior Developers, we didn’t hire you for your output.

We hired you for your future potential. Slow down and focus on up-skilling.

07:28 AM - 18 Sep 2022

Nobody expects you to deliver. For the company - you're an investment. And to be a good investment - you need to grow (no... I meant your skills 🤦‍♂️).

Take your time with whatever you're doing, learn as much as you can, ask questions and try to enjoy the process.

2) Solve Problems Yourself

I remember when I discovered GitHub I wanted to use a 3rd party library for any problem I had. After all, why write the code yourself, if someone else already has?

Wrong. Your early career is a time for investments. You should try to solve every problem yourself even if it isn't optimal.

Over time you'll build up a database of go-to solutions in your head. And for the more complex problems, you'll know what to look for in a 3rd party solution - because you're familiar with the problem and know what a good solution should look like.

Again, your job as a junior developer is to learn first, and you learn nothing if you never try solving problems yourself.

3) Ask For Help Early

As a junior developer, you're bound to get stuck eventually (a lot, actually). This is where many junior developers get into trouble. They think they mustn't bother anyone with their stupid issues and instead pretend they're fine.

That's a huge red flag  🚩.

Always ask for help early. As a rule of thumb, if you're stuck, feel free to spend 15-30 minutes trying to figure it out yourself, but then please ask for help.

There's nothing worse than junior developers who're struggling but are pretending they're fine.

4) Ask For Help Correctly

As a junior developer, I was scared to ask for help because I thought the senior devs will be annoyed with my questions. And frankly, they probably were. But there is a way to make the experience pleasant for both you and the senior devs.

Here is what worked well for me 👇

Batch your questions.

Don't bother the senior dev every time you run into a problem. Write your question down and work on something else for a while. Once you have 3 or more questions (or some reasonable time has passed), go and ask them for help.

Do your part

Try to solve the problem first, then look for a solution online (e.g. documentation) and when you eventually ask for help - explain what you've tried. It's very frustrating when junior devs run into a problem, try nothing to solve it, then expect you to solve the problem for them.

Show willingness to learn

Never ask for the answer. Show them that you want to solve the problem yourself, and ask for a roadmap instead. You may ask for steps to find the solution, but if you're just asking for their solution, you're learning nothing (see tip #2).

5) Practice Humility

Senior developers know better (even if they don't). Don't be a rebel. Understand that you most likely know less than someone who's been doing this thing for years, and follow their instructions exactly.

Yes, there are stupid senior engineers. And yes, there are people who're just mean. Accept their criticism, learn what you can from them, and ignore the rest. Don't get discouraged by criticism.

These realizations have helped me tremendously in dealing with imposter syndrome and negative feedback:

• Your code is not you.

• Nobody really knows what they're doing.

Your time to shine will come - there will be opportunities for you to take on responsibility and show your creativity. When that time comes - overdeliver.

6) Take Ownership and Responsibility

This is the best way to shake off the "junior" label. From the start, I was happy to help other junior developers, which in the eyes of others has made me the most "senior" of the lot (even though we started at the same time with no prior experience).

Over time, I've learned some cool new tech by myself, which got popular (TypeScript), so then even senior devs went to me for help (huge confidence boost). In 2 of the companies I've worked at I was known as "The TypeScript Guy". Creating a niche for yourself is an excellent way to level up your career.

Voice your opinions, share your learnings, and when the opportunity for you to step up and show initiative comes - take it.

Here's a tip from me - write end-to-end tests. Nobody likes setting them up, nobody likes writing them, and nobody likes to be responsible for them. That's the perfect opportunity for a junior dev to show initiative 😉.

7) Build Side Projects

Most good developers I know build stuff in their own time. And I know many bad ones that don't. Building side projects is the best way to fast-track your career.

Let me put it this way - when you go to an interview, the interviewer is looking for proof that you're good, that you can get shit done. When you can point him to a real-world app you've built and deployed by yourself - you have undeniable proof that you can build and release apps.

I improved the most as a developer when I was building my side project mediabits.io. Also, it's been invaluable for my career - it has quite literally doubled my salary.

Instead of being a mere coding monkey, you become someone who builds products.

Ideally, the stuff you build should be something you need yourself and something you've built on your own (don't just follow a tutorial). Here are some ideas 👇

Vincas Stonys

@vincasstonys

The best way to learn ReactJS is by building real-world applications.

Not sure what to build?

Here are 5 ideas for real-world frontend applications using free public APIs 👇

18:28 PM - 12 Aug 2022

8) Focus on Fundamentals

Once you start building side-projects it's easy to get caught up trying to learn all the new technologies. This is overwhelming.

Make it your goal to deliver a working app, instead of learning the latest-greatest shiny new framework. Just pick a solid technology that's been around for a while and use that. New technologies come and go, but fundamentals stay.

Guess what, most new tech is just a flavor of the same old thing with some sprinkles on top. It's a lot better to spend time mastering JavaScript instead of learning about the nitty-gritty details of react-router.

Don't make it harder than it needs to be. You're inevitably going to learn a lot anyway.

9) Learn in Public

Not writing a blog or creating YouTube videos is the biggest regret I have from my early career. Even as I'm writing this blog, I've already forgotten a lot of the struggles I've had as a beginner.

Two things are well-known:

• We learn best when we teach what we learn.

• We learn best not from experts, but from someone who's only one step ahead.

Somebody else will find your content invaluable, and as a bonus, you'll be building an audience that you can monetize later to earn some side income.

At the moment, hashnode.dev and dev.to are the easiest way to start blogging for developers.

10) Don’t Stay In Your First Job for Too Long

This one is a bit controversial and you're free to ignore it, but it's something I regret doing early in my career.

I think it's best to change your first job after 1-2 years in the company (unless you landed a job at Google in which case, ignore what I tell you). Here's why:

• Your opportunities for learning will be mostly exhausted.

• You'll forever be junior in the eyes of the devs you first worked with.

• You were underpaid when you started, and you will stay that way until you get a new job.

Money should not be the reason to leave your first job, but just keep in mind that salary grows relative to your current salary (usually around 5-10%). A market-level salary for a developer with 2-3 years of exp is at least 2x higher than an entry-level salary (quick math 🤔 ~50% increase for every year).

If you feel like you're becoming stagnant, don't let the fear or "loyalty" stop you from getting another job. Your company is not your family, as much as they wish it were true.

Conclusion

Early career as a junior developer is a scary period, but it gets very rewarding later on. I'm glad I had a few friends doing the same thing and struggling with the same feelings. I can't imagine how lonely it would've felt otherwise.

If you don't, I want you to at least have the guidelines I wish I had when I was just starting out. It all comes down to:

• Learn as much as you can;

• Share what you learn;

• Build a solid foundation both in terms of skills and career.

Introduce yourself in the comments and let me know what you're struggling with. Feel free to connect with me on Twitter, where I share regular tips for junior developers building their first web app with React.

This is a repost from my blog at codefrontend.com, come say hi.