My Advice to Junior Developers
Tags: beginners
Published: 2020-07-29 12:43:28

---
title: My Advice to Junior Developers
published: true
description: Here are some of my tips on how to develop soft skills and habits to help to learn and grow as a junior developer.
tags: Beginners
canonical_url: https://blog.rstankov.com/my-advice-to-junior-developers
---

I talk to junior engineers a lot and find myself giving the same advice. So I decided to write a post about it.

There are many online resources about coding or finding a job in the tech sector. This post is not one of those. It is focused on soft skills, which I think a junior developer should have. 

So let's get started. 🚀

Your biggest goal is to learn and grow. Most of the habits you pick up in the early days of your career will stick. 

## Be reliable

**ALWAYS** follow up on your task commitments.

Don't leave `TODO` comments in your code, fully complete your work. [Leave your code better than you found it](https://deviq.com/boy-scout-rule/#:~:text=The%20Boy%20Scout%20Rule%20can,cleaner%20than%20they%20found%20it.). 

When you find out that you can't finish a task on time, don't hide it. The moment you think you can't deliver, ask for help.

You have to show that you are reliable. It is the most important thing to do.

Your teammates will quickly learn if they can count on you. The more people count on you, the more critical projects you are given.

## Take ownership

Try to be involved in time estimations -- often, you won't be consulted with them *(this is a mistake on your team's part)*. 

Don't rush to estimate. Take your time to think about the problem. Consult with team members.

One mistake that *everyone does* is to provide a time estimation that's as low as possible and then don't deliver. Be honest and conservative.

*...and no, doing an all-nighter to finish a task on time is not a proper time planning.*

Estimates are tricky, don't hide when you're behind, but embrace it and raise the issue, look for help.

## Handling "No"

You will be full of ideas, this is great. However, you will often be told "No".


"[No](https://www.intercom.com/blog/product-strategy-means-saying-no/)" is essential in product development.

This can be quite painful. Don't get discouraged. Understand the reasoning behind the "No".

Sometimes the idea is just not right or was already tried. Other times, "No" is *"we don't have time right now"* because of other priorities.

Show, don't tell. If you have an idea, implement it and make a demo. The ability to present your ideas is a valuable skill.

Programmers tend to disagree a lot in abstract and agree when they see the working code.

When I was trying to convince my team at [Product Hunt](https://www.producthunt.com/) to switch from a standard [RESTful API](https://en.wikipedia.org/wiki/Representational_state_transfer) to [GraphQL API](https://graphql.org/), I didn't just say "Let's move to GraphQL".

Instead, I implemented a very complex page with GraphQL in a separate branch. I gave a presentation showing all problems GraphQL will solve for us and presented a migration plan. I didn't hide any of the risks associated with GraphQL.

Again, don't get discouraged even if your code prototype is rejected. Understand why.

## Be curious

Be curious and ask questions. Don't be content with not understanding things. This is a nasty habit.

Try to review other people's pull request changes. If you don't understand something, ask, often you aren't the only one who doesn't understand. If you are too shy to ask in public, ask directly via private chat message.

I love working with juniors, who ask questions. They are good at spotting too clever code tricks and unnecessary code complexity.

One of the best ways to learn is to work with other people. Ask people if they want to [pair program](https://en.wikipedia.org/wiki/Pair_programming) with you.

## Boring tasks

In your early days, you will work on many "boring" tasks like bug fixes or minor UI changes. It would help if you tried to find joy even in boring tasks. 

Fixing small bugs will show you how your systems are built and how to avoid writing them in the first place. 

Once, I was tasked with keeping our application clean of runtime exceptions. This was a very useful experience. It showed me how the system was breaking. I built a lot of internal tooling to handle errors and started designing my code to be more robust.

For small repetitive tasks, you can think about how to automate them or use them as training for your editor skills. I learned my VIM shortcuts by doing a lot of CSS fixes.

## Final words

A great book that I'd encourage you to read is [The Pragmatic Programmer](https://pragprog.com/titles/tpp20/). I think every programmer should read it. 

On the technical side - master your editor and the programming language you are working with.

Last but not least - take care of yourself. Work hard, but don't overwork. Get [enough sleep every night](https://www.goodreads.com/book/show/34466963-why-we-sleep?from_search=true&from_srp=true&qid=1xuxAN1SZI&rank=1).

## TL;DR

A lot of the habits and skills you build at this stage in your carer will stick.

* **ALWAYS** follow up on your time commitments
* Try to have a positive attitude
* Be pro-active, curios and learning  (even from tedious tasks)
* Don't get discouraged when people say "No" to your ideas
* Read the  [The Pragmatic Programmer](https://pragprog.com/titles/tpp20/)
* Take care of yourself


If you have any questions or comments, you can ping me on [Twitter](https://twitter.com/rstankov).