Are you a junior developer embarking on your software development career?

Or a recent computer science graduate who has recently started a new job?

Maybe a self-taught developer wondering what to do next?

Starting your software development career can be scary, but also very exciting.

I know the feeling, having been there myself. Over the past 5 years, I have gone from junior developer to lead developer at a SaaS startup, learning lots along the way.

I have written this guide with my top tips, to not only survive but strive in your first year as a junior developer.

It’s OK to have gaps in your knowledge

University degrees, coding boot camps, and online courses do a great job at teaching you how to code.

Yet, the truth is that in the real world of software development there is a bit more to it than writing code. You’ll have to understand:

• Which technologies are best for different problems
• Code written by other people
• Design patterns and best practices
• How to test code
• CI/CD, source control, and branching strategies
• The software development lifecycle and different methodologies
• Working not only with your team, but with other teams, management, and clients …to name a few things.

You may already know some of this stuff, or you may have never heard of any of it before. And that’s OK. You are there as a junior software developer, your manager and your teammates know this.

So there will be gaps in your knowledge. Every developer has them! Try not to feel overwhelmed if it all doesn’t make sense straight away.

In fact, part of the beauty of being a software developer is that technology is always changing. We will always be learning, regardless of what level we are at.

Questions are good — so is asking for help

You have your first task, you get excited and dive straight in. But then…you’re stuck. Your code doesn’t work as expected, and all you have to go by is a strange, confusing error message. You've tried solving the problem yourself, but some time has passed and alas, no luck.

Stumped, you think about asking one of the other developers on your team for help, but you think:

“What if they think I can’t code? and laugh at me?!”

But in reality, that will never happen. What they will actually think is:

“OK, I’ll take a quick look and see if I can help. Ah! Yes, I’ve encountered this issue before, you can use someMethod() from somePackage() to fix it.”

Which isn’t so bad right?

Your team is there to support you, especially in the early parts of your career, so ask them for help (if you're interested, I go into a bit more detail about how to be a good teammate here).

Likewise, if you do not understand something, ask questions. I’m still asking loads of questions every day! There is no such thing as a stupid question. Your team would rather help you instead of having you stare at your screen with confusion for most of the day.

Code Reviews are your friend

I’ll never forget my first code review as part of my first junior developer job. My code was being reviewed by an experienced senior developer. At the time I found this nerve-wracking. And, of course, there were more comments from him than I could count!

But in hindsight, this was a good thing.

Code reviews are not a stage for criticism, but for learning and giving feedback on all sides.

The senior developer sat down with me and explained what each of the comments meant, and also why he had made them. Needless to say, I learned a lot. So when your code is being reviewed, remember that any feedback is to help you learn and improve as a software developer.

Likewise, when you come to review code for other people, you will be able to see how different people approach different problems. You will even help them improve by making suggestions of your own!

Break it down, and break it down some more
Ok so you have your first real task, depending on the size of the task, you might feel a bit overwhelmed:

“Where do I start? I guess I’ll start by doing X, but what about Y? But then if I do Y there’s A, B, and C….what’s happening with X again?!”

Don’t worry we’ve all been there. It’s easy to get lost in the proverbial rabbit hole when trying to solve a problem. The next time you have a large problem to solve, try remembering this quote,

“How do you eat an elephant? One bite at a time.”

In other words, make a task that seems impossible more manageable by breaking it up into smaller tasks.

So how do you do that?

Before writing any code, try writing out the steps in plain English (or the language of your choice). Let’s take an example.

How do you pour a glass of water?

A plain English approach would be

• Open the cupboard
• Get a glass
• Place glass under the tap
• Turn on the tap
• When the glass is full, turn off the tap
• Remove glass from under the tap
• By writing out the steps, it is easier to visualize each part of the problem and come up with a solution for each step.

Keep it simple

A common mistake many junior developers make (myself included when I started) is to try and reinvent the wheel.

It might look impressive to solve a problem by using a super-fancy technique within your code.

But this causes other problems:

• Code that is completely different from how similar parts of the system - work is harder to maintain
• Your code may become more verbose that it needs to be, and there will be an increased risk of bugs -It may take you longer to complete your task

So how exactly do you keep it simple?

1. Make it work. Don’t overthink too much, and do whatever your gut says to get your code working
2. Refactor. Now that your code is working, it’s time to refactor. Make your code easy to read by naming things well, and use of proper formatting. More on this in ‘Learn how to write clean code’ below
3. Speed it up. Once you have finished refactoring, you might notice bottlenecks in the performance of your code. Now is the time to optimize it. Be wary not to fall into the trap of over-optimizing too early! Only do this if you need to.

BONUS TIP. Consider writing some failing tests before writing any code. This is called Test Driven Development. Not only will this give you good test coverage, but it will help you think about the structure of your code.

Learn how to write clean code

So, clean code is a bit of a vague term. Some people swear by it, some people think it's nonsense. A better way to put it is learn how to write readable, maintainable, testable code

Any fool can write code that a computer can understand. Good programmers write code that humans can understand. — Martin Fowler

I won’t go into too much detail here, but the book, Clean Code: A Handbook of Agile Software Craftsmanship by Robert C Martin will give a much deeper insight into this area. If you are serious about writing clean code and breaking out of the junior developer level, I highly recommend this book.

Writing clean code shows that you are passionate about what you do, and can create maintainable reliable software. Not to mention that you will be making life a bit easier for the next person who comes along to add to your code.

“There’s a library for that”

Have you ever told a friend about a problem you were having, and they respond with “Yeah, there’s an app for that”?

Software development is a bit like this.

There are already a lot of answers to the problems you are trying to solve. So when you are trying to complete a task, check to see if someone else has already solved the problem.

You can do this by:

• Looking for existing packages and libraries
• Browsing sites such as GitHub and StackOverflow for similar solutions to your problem.

But hold it right there! This doesn’t give you free rein to copy and paste code without a thought. If you are using someone else’s code as an example, it is important that you understand what their code is doing and why.

• Why is it using a particular design pattern?
• Why is it written in a particular language? (Node.js vs Python for example)
• What are the drawbacks? Will it work with your current codebase?
• If you’re not sure, you can ask someone on your team for some guidance. Searching Google for an answer is a common approach to solving coding tasks. So don’t be afraid to turn to your teammates and say:

“I’m thinking about using this library X or this package Y, I have seen some examples on here, what do you think?”

Not only will this show that you are proactive, but it’ll also spark some conversation/debate from the team. You might have discovered something awesome no one else knew about yet!

Learn how to read code

We have all seen those movies. The ones where a hacker types rapidly as pages of code scroll down the monitors in front of them.

In the real world, developers spend more time reading code than actually writing code.

When adding new features or fixing defects, you will have to understand the current codebase you are working on. How do you do this? Read, read, read!

Reading code is also a beneficial learning technique. Reading existing code lets you see how others have developed a certain feature.

Things to keep an eye out for:

• The use of design patterns
• The naming of methods, classes, and variables
• The use of comments
• How to structure project files
• The use of tests and how they are structured

So where do you find code to read?

• Repositories in your source control at work
• Projects on GitHub
• Read answers/questions on StackOverflow
• Code challenge websites such as codewars.com, which show the answers to challenges

Have fun!

If you take one thing away from this article, let it be this — is it important to have fun. Enjoy writing code, solving problems, and continuing to learn. You are at the start of an exciting career, so sit back and enjoy the ride!

BONUS TIPS

• Learn the lingo. We developers have our own funny language (“creating a - branch” has nothing to do with trees!) so make sure you understand the key terms
• Get to know your IDE. Learn the hotkeys, shortcuts, and customize it - until you are comfortable with it. This will increase your productivity.
• Working on bugs is a great way to learn about the codebase. So don’t be afraid to pick these up!
• Bring a notebook, listen with intent and write everything down.
• Take on some side projects in your spare time. It’s a great way to learn different technologies you don’t learn in your day job and will boost your CV.
• Getting involved in work events is a great way to get to know your colleagues. Why not organize one yourself?

Thanks for reading! If you liked this post, why not subscribe to my newsletter? Every week I send out an email with my latest articles, links, tips, and resources junior developers. You'll also get some free stuff!