Hartley Brody

The 3 Mistakes Every Junior Developer Makes (And How to Stop Making Them)

As more and more people are learning to code, there are an increasing number of new developers in the work force. Code bootcamps are springing up everywhere that promise to land candidates a job with only a few months of experience.

Having worked with a number of junior developers (and having been one myself, at one point ;) ) I’ve noticed a lot of the same mistakes crop up.

In an effort to help junior developers level up to eventually become engineers, I decided to enumerate some of the mistakes I see most often, as well as my recommended solutions and takeaways.

Saying You’re “Done” with a Task Prematurely

This is probably the most common so I mention it first. New developers have tendency to slap the last semicolon onto whatever code they’re writing, hastily commit it and proudly declare that they’re “done” to the rest of the team.

As soon as they’ve finished their first pass at an implementation, it’s “ready” for code review and testing. Except usually, it’s not.

Features of the product are very obviously broken, and it only takes someone a few seconds to notice. Or their code only implements half of the features it was supposed to, or doesn’t work for common use cases.

Since the junior developer has been heads down in the weeds wrestling with language syntax or the API of some new library, they haven’t yet lifted their head to survey the scene of where they came from and where they still need to go.

As a result, code reviews can be brutal, product and business stake holders are confused about why things don’t work as they should, and the team generally loses faith in the junior developer’s autonomy. “Why would she say this is done when it clearly needs more work?”

The solution I always advocate for is the “step away from your desk” maneuver. If you’ve pushed up your last commit and are ready to check off the asana ticket or move the trello card – PAUSE.

Go get some water, walk around for 5 minutes and then come back to your desk. Reread the spec or ticket that you’re working from, and go back through the email thread where the last-minute adjustments were made. Make sure that everything that’s supposed to be in there is.

Then, try to actually use the feature you just built. Do a bit of your own quality assurance, even if that’s supposed to be “someone else’s job”. Click around the product and make sure nothing is obviously wrong.

As an engineer, your job isn’t just to write code, it’s to build a product or add features – and do no harm in the process.

Putting in the extra few minutes to review your work before you show it off will save you lots of embarrassment and help build the team’s trust that you know what you’re doing.

Implementing the First Solution You Think Of

Most of a junior developer’s first few projects will be largely spec’d out for them. They’ll be handed not only “what” to build, but also a list of steps for “how” to build it, at a high level.

But eventually, there will come a time when the team lead decides to trust a new developer to come up with their own technical implementation plan. And while this can be a great chance for someone who is newer to “earn their stripes,” it’s often a place where many falter.

The developer will come up with a plan forward, and stop there. “I’ve got it!”

The reality in software is that there are often dozens of different ways to implement something. Some solutions may reuse existing parts, while others may require new dependencies, abstractions or technologies.

To feel confident about a path forward, a good engineer will think through and then weigh the pros and cons of multiple potential solutions before establishing a path forward.

“We could use this library, but that adds a dependency. Or we could implement it ourselves, but it might take a while and be harder to test.”

When the junior developer presents their plan to the team and the team starts asking questions about it, the developer is often caught off guard, having not really considered where their plan might have some holes in it, or why it’s better than competing ideas.

If you’re putting together a technical plan, try to come up with two or three alternative solutions, and understand when and how some are better or worse than each other.

Think up a list of a few pros and cons for each solution, considering both technical merits as well as business ones (“this would save us time, be cheaper to implement, etc”).

The opportunity to come up with your first technical spec or implementation plan can be a great moment in your career.

To really hit it out of the park, do your research and be ready to defend your recommendations – don’t just present the first ones you come up with.

Forgetting that Code is Read More than it is Written

Most code that gets shipped will ideally live on production for more than just a few weeks. Which is plenty of time for everyone who worked on it to completely forget everything about it.

While it might be written over the course of a few hours or days, it’ll likely be read dozens of times over months and years by other engineers.

Every line of code that’s written should be clear, concise and self-documenting. Abstractions should make sense and be reusable in other contexts. Code should follow a style guide for consistency.

By definition, someone who is new to the profession won’t have experience trying to find bugs or add features to code that they wrote a long time ago.

Hopefully they’ll have some experience reading and working with other engineers’ old code, but they might not appreciate its elegance or clarity (or lack thereof).

One of the most important things you can learn as a junior developer is how to write clear, readable code. While your language’s interpreter might not care if you use confusing, nonsensical variable or function names, your colleagues certainly will.

While doing a code review a few years ago, I saw a javascript function called is_ready() which – from its name alone – would seem to return a boolean indicating whether something was “ready”.

But instead, it returned a jQuery node which resulted in code like var modal = is_ready();. And while that’s valid javascript that any browser would happily interpret, as a human I could make no sense of what was happening here.

After you’ve gotten a new feature working, go back and read through all the code you just wrote. Maybe you started out calling a function one way but then you added more parameters and changed the implementation slightly and now it does something different. Rename it (and update all the places you call it) so that it reads closer to english and makes sense.

Deciding what is “more readable” can sometimes be subjective. But it’s good practice to work on it in your own code and to try to recognize it in other people’s code as well.

Final Thought

If you’re a junior developer who feels like you’ve made some of these mistakes, don’t be discouraged! I decided to write this because I’ve seen so many new engineers who needed help learning about these same issues.

Being a good software engineer is an on-going learning progress – not just learning how to wrangle code, but also learning how to be a productive, effective and well-liked member of your team.