3 Common Habits to Avoid as a Junior Developer | by Jesse Langford | Feb, 2022

Your superiors will forever appreciate you for avoiding these

Jesse Langford
Andrey Popov on Adobe

Your superiors will forever appreciate you for avoiding these

Being a junior developer is difficult. There are new languages ​​to learn, design principles to understand, and unfamiliar challenges to overcome. It’s not at all surprising that in the process of learning, you might develop a few habits that seasoned pros have little tolerance for.

As a way to help any up-and-coming developers, I have made a list of 3 common habits that I feel every junior developer should avoid. I came up with these items by reflecting on my time as a junior developer and remembering what things irritated my bosses the most. Now that I am on the other side and managing junior developers of my own, I feel their pain.

None of the items in this list have to do with your code quality or how well you know a specific technology. Being unfamiliar with a language or technology is not what I would consider a habit.

My list contains habits that are easy to avoid with a little bit of discipline and self-awareness.

Reviewing pull requests can be challenging for everyone. One way to make them especially painful is to review one with hundreds of lines of new code, new files, and plenty of existing changes. Following all that logic can be a difficult task for anyone.

How can you avoid it?

Sometimes there’s no getting around the size of a new feature. If you know your final pull request is going to be huge no matter what, you can break up your reviews into smaller, easier-to-digest pieces.

Let’s say you’ve been tasked with building a new signup page. You create a new branch from develop called feature/new-signup.

Your signup page has 5 parts to it:

  1. UI elements
  2. Form validation
  3. Submission
  4. Asynchronous wait for backend confirmation
  5. Redirect to main application on success

Instead of committing everything to feature/new-signupyou can create a new branch for each task, with feature/new-signup being that branch’s parent. Once you finish, you can create a pull request to merge your new branch into feature/new-signup.

If you start with UI elements, create the new branch

git checkout feature/new-signupgit checkout -b ui-elements

Add all the UI elements to your ui-elements branch, commit, and make a pull request for ui-elements into feature/new-signup. Ask your superiors to review your changes in the context that it’s a small piece of a larger feature. Once it’s been reviewed, approved, and merged back into feature/new-signupyou do the same for the next task.

git checkout feature/new-signupgit checkout -b form-validation

And so on until the feature is complete. In the end, the pull request for feature/new-signup into develop will still be large, but everything will have already been reviewed.

The process I described above is part of AGILE software development.

Smaller more targeted pull requests are more likely to get picked up and reviewed. Large pull requests often become victims of procrastination.

I’ll give a non-software example from my own life to help frame this.

A few months ago a friend of mine asked me the following question:

“Hey Jesse, how do I start a blog?”

The way this question is phrased tells me two things:

  1. My friend does not know how to start a blog. No problem there.
  2. My friend probably won’t follow through with writing a blog. It feels like they aren’t willing to do a basic Google search before coming to me.

The way a question is framed can say a lot about the amount of effort you have put into finding a solution.

Asking for a teammate’s help every time you see an error or bug, without doing any research of your own, is a great way to alienate yourself from the rest of the team.

If people feel that you are not giving an honest effort to research and learn on your own, they will most likely not want to work with you. I’ve even seen it get to the point where people stop coming into the office to avoid the offender.

There’s nothing wrong with asking for help. However, a differentiating factor between junior and senior developers is their ability to research. If you never learn how to find things on your own, you won’t progress very quickly.

Brand new developers can be forgiven for this, but it’s best to kick the habit as quickly as possible.

If you think you may be doing this, my advice would be to do what I did to kick this habit. Before I bring another teammate in on a bug or error, I always stop myself and ask: “Have you really given an honest effort to find a solution on your own?”. If the answer is yes, ask for help. If you feel any unease about saying yes, best to give it another shot.

Going back to my friend’s question at the start, let’s see how it could sound if it had included research.

“Hey, Jesse, I’m looking to start my own blog. I’ve been looking online, Squarespace and WordPress look like promising places to start. Do you have any experience with either platform?”

I’m much more likely to answer that question because I can feel the questioner has put some effort into finding a solution themselves. A little goes a long way here.

You’ll find that same sentiment when you ask for help from other developers.

Bugs exist in every application, senior developers know this and they rely on everyone to be on the lookout for them. That’s why it can irritating when obvious bugs are ignored in the process of development because it’s not associated with the current feature someone is working on.

I’ll give two examples in Go and JavaScript where someone has committed code and ignored an obvious, nearby bug.


Line 167 clearly has an unhandled error response that should be dealt with.


Line 685 uses the ==operator. It’s an outdated operator and has the potential to create a hard-to-find bug in the future.

If either of these examples were seen in a real pull request you will likely be asked:

A. Please fix it


B. Why didn’t you fix that when you saw it?

Even though you may not have been the one to add the bug or the one who reviewed and approved it, you should still try to fix issues like these when you see them. The “I didn’t write that” or “not my problem” defense will fall on deaf ears. If you see something, do something.

Leave a Comment