Junior Devs, Stop Doing Only What You’re Told to Do

First of all to clarify, following instructions is a prerequisite to being recognized as a good employee. I am not trying to imply junior devs should start an anarchy, do whatever they want, and scream hashtag YOLO.

However a lot of times, entry-level and junior devs make the mistake of doing ONLY and exactly what they are told to do. The reason it’s a problem is because the person giving direction, whether it be a lead dev or a project/product manager, is usually only in the idea phase when they thought of the requirements. Sure, they may have spent a lot of time planning as best as they could but the idea still hasn’t been put into practice.

Punched in the Mouth

Mike Tyson famously said “everyone has a plan until they get punched in the mouth” and this definitely rings true even in creating software.

As the developer implementing the idea, you have the experience of figuratively getting punched in the mouth. You are the first in line for putting a plan into practice.

Often, the person giving direction will not be able to anticipate all the issues that may come up as the idea gets fleshed out into a real, working product. As a junior dev, doing only exactly what you’re told without regard for whether the requirements make sense or not will result in unnecessary churn the further along the project goes in the software development life cycle.

Why should you care?

Well for one, the longer a project takes than necessary, the worse it looks for everyone including the dev who worked on it. Also if following instructions is a prerequisite to being considered a good employee, making someone’s life easier and anticipating their problems is a prerequisite to being considered a GREAT employee.

If you’re proactive in identifying issues that come up during implementation and start a conversation about them, it will do wonders in making everyone’s lives easier. And of course, being part of several projects that go better than expected will bode well for your career.

Note however that this does not mean you should take matters into your own hands. Rather, the aim is to bring awareness to things that couldn’t have possibly been anticipated during the idea phase. Additionally, opposing ideas in particular still have to be communicated with tact.

Here are common issues you can look out for when ideas are turned into practice:

• user interface/workflow/design requirements that ends up being a terrible experience for the user
• requirements that end up making the product very slow
• requirements that end up being very difficult and/or time-consuming to implement
• requirements that seem different from what you originally heard about

If you want to stand out from the crowd, don’t do only and exactly what you’re told to do. After all, there are plenty of people that can do that and for much less than you’re getting paid.

But there are fewer that can go above and beyond to anticipate problems, think outside the box, and make everyone’s lives easier. Those are the type of devs that companies want to hire and reward to stay around.