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

Your superiors will without end respect you for avoiding these

on Adobe

Your superiors will without end respect you for avoiding these

Being a junior developer is tough. There are new languages to be taught, design ideas to grasp, and unfamiliar challenges to beat. It’s in no way stunning that within the means of studying, you would possibly develop just a few habits that seasoned execs have little tolerance for.

As a method to assist any up-and-coming builders, I’ve made an inventory of three frequent habits that I really feel each junior developer ought to keep away from. I got here up with this stuff by reflecting on my time as a junior developer and remembering what issues irritated my bosses essentially the most. Now that I’m on the opposite facet and managing junior builders of my very own, I really feel their ache.

Not one of the objects on this listing need to do together with your code high quality or how properly you realize a selected know-how. Being unfamiliar with a language or know-how shouldn’t be what I’d think about a behavior.

My listing accommodates habits which are straightforward to keep away from with a little bit little bit of self-discipline and self-awareness.

Reviewing pull requests could be difficult for everybody. One option to make them particularly painful is to overview one with a whole lot of traces of recent code, new information, and loads of present modifications. Following all that logic could be a tough job for anybody.

How are you going to keep away from it?

Typically there isn’t any getting across the dimension of a brand new characteristic. If you realize your closing pull request goes to be large it doesn’t matter what, you may break up your opinions into smaller, easier-to-digest items.

To illustrate you’ve been tasked with constructing a brand new signup web page. You create a brand new department from develop referred to as characteristic/new-signup.

Your signup web page has 5 elements to it:

  1. UI parts
  2. Kind validation
  3. Submission
  4. Asynchronous watch for backend affirmation
  5. Redirect to foremost utility on success

As a substitute of committing every thing to characteristic/new-signup, you may create a brand new department for every job, with characteristic/new-signup being that department’s guardian. When you end, you may create a pull request to merge your new department into characteristic/new-signup.

When you begin with UI parts, create the brand new department

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

Add all of the UI parts to your ui-elements department, commit, and make a pull request for ui-elements into characteristic/new-signup. Ask your superiors to overview your modifications within the context that it’s a small piece of a bigger characteristic. As soon as it’s been reviewed, permitted, and merged again into characteristic/new-signup, you do the identical for the subsequent job.

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

And so forth till the characteristic is full. In the long run, the pull request for characteristic/new-signup into develop will nonetheless be giant, however every thing could have already been reviewed.

The method I described above is a part of AGILE software program improvement.

Smaller extra focused pull requests usually tend to get picked up and reviewed. Massive pull requests typically turn out to be victims of procrastination.

I’ll give a non-software instance from my very own life to assist body this.

Just a few months in the past a pal of mine requested me the next query:

“Hey Jesse, how do I begin a weblog?”

The way in which this query is phrased tells me two issues:

  1. My pal doesn’t know find out how to begin a weblog. No downside there.
  2. My pal in all probability gained’t comply with by way of with writing a weblog. It looks like they don’t seem to be prepared to do a primary Google search earlier than coming to me.

The way in which a query is framed can say so much concerning the quantity of effort you’ve got put into discovering an answer.

Asking for a teammate’s assist each time you see an error or bug, with out doing any analysis of your individual, is a good way to alienate your self from the remainder of the workforce.

If individuals really feel that you’re not giving an sincere effort to analysis and be taught by yourself, they’ll probably not need to work with you. I’ve even seen it get to the purpose the place individuals cease coming into the workplace to keep away from the offender.

There’s nothing flawed with asking for assist. Nevertheless, a differentiating issue between junior and senior builders is their capacity to analysis. When you by no means discover ways to discover issues by yourself, you gained’t progress in a short time.

Model new builders could be forgiven for this, but it surely’s greatest to kick the behavior as shortly as potential.

When you assume you might be doing this, my recommendation could be to do what I did to kick this behavior. Earlier than I deliver one other teammate in on a bug or error, I at all times cease myself and ask: “Have you ever actually given an sincere effort to discover a answer by yourself?”. If the reply is sure, ask for assist. When you really feel any unease about saying sure, greatest to offer it one other shot.

Going again to my pal’s query initially, let’s see the way it might sound if it had included analysis.

“Hey, Jesse, I’m trying to begin my very own weblog. I have been wanting on-line, Squarespace and WordPress appear to be promising locations to start out. Do you’ve got any expertise with both platform?”

I’m more likely to reply that query as a result of I can really feel the questioner has put some effort into discovering an answer themselves. A little bit goes a good distance right here.

You’ll discover that very same sentiment whenever you ask for assist from different builders.

Bugs exist in each utility, senior builders know this they usually depend on everybody to be looking out for them. That’s why it will possibly irritating when apparent bugs are ignored within the means of improvement as a result of it’s not related to the present characteristic somebody is engaged on.

I’ll give two examples in Go and JavaScript the place somebody has dedicated code and ignored an apparent, close by bug.


Line 167 clearly has an unhandled error response that must be handled.


Line 685 makes use of the ==operator. It’s an outdated operator and has the potential to create a hard-to-find bug sooner or later.

If both of those examples had been seen in an actual pull request you’ll seemingly be requested:

A. Please repair it


B. Why didn’t you repair that whenever you noticed it?

Despite the fact that you might not have been the one so as to add the bug or the one who reviewed and permitted it, it is best to nonetheless attempt to repair points like these whenever you see them. The “I didn’t write that” or “not my downside” protection will fall on deaf ears. When you see one thing, do one thing.

More Posts