4 Things You Can Do to Stand Out as a Junior Developer (That Have Nothing to do with Coding)

Let’s face it. The majority of us who write code for a living won’t be the next Kyle Simpson. Even within our own teams, there are those members who just seem to write the kind of code which you envy. They’ve been programming since they were 12. Maybe they actually are a genius.

You pore over their code, hoping to glean some wisdom from them, only to realize it may be years before you reach their level of mastery.

However, technical proficiency doesn’t always parallel career trajectory in software. As it shouldn’t. At the most basic level, software teams are groups of humans building products with details and requirements often dictated by other humans that will be eventually released to, you guessed it, more dirty humans.

With all these non-machines in the mix, you’d better bring more to the table than an ability to write sexy code. Luckily, there are 4 ways to stand out on your team even if you aren’t a code wizard.

1. Contribute to Discussions

We’ve all been in one of those technical planning meetings where one voice is more present than others. It’s likely the senior developer explaining the library or approach they would use to tackle the issue at hand. Linda suggests the team write their end to end tests using Selenium to mimic user behavior and DOM interaction.

Erica has heard of a Javascript framework, Cypress.io, which sounds like it might be a better fit for their needs but she doesn’t say anything. Everyone silently nods in agreement. Linda’s been here for 5 years and has written the majority of the front end tests. She must know what she’s talking about.

Don’t assume the most senior person on your team is inherently correct! Oftentimes, their voice is the loudest in the room because there is an unspoken expectation that they at least offer an opinion or suggestion.

Personally, I feel really relieved when there is some discussion around my suggestions. Sometimes, this results in a change of course that makes everyone happier and our code better. Ask that question!

2. Run Towards Fires

The VP of Engineering posts a cryptic comment in the Slack channel that only full-stack developers use:

"Can someone check out what's going on with our endpoint to fetch customer data? Seems to be really slow and we're getting some emails regarding it."

You stare at the comment. Your heart races a bit faster as you mentally replay all the scenarios that could be contributing to the issue. We recently deployed a change to the middleware used to fetch user information. Perhaps more servers would help decrease the load. Is that something DevOps can do…

"I'll check it out and see what's up", writes Dennis. Your heart settles and feel thankful that he’s checking out the issue. An hour later, the issue just sort of disappears. Dennis reports his findings, or lack thereof and the VP moves on to more important issues. We’ll keep an eye on it, Dennis reassures.

Dennis didn’t really do anything. The VP will remember his effort though. He stood up after a few minutes of awkward Slack silence to take lead on an issue that he likely didn’t know how to resolve himself.

Practice saying Yes to fires. You won’t always know how to solve them but you will learn a lot about working under duress and get a much more intimate familiarity with your codebase. This may actually be one of the most crucial aspects to getting promoted as a developer.

3. Onboard New Members

One of your coworkers hit the two year mark on your team and promptly left for greener pastures. Such is life. Alan starts on Monday after next and needs an on-boarding buddy. Dennis and Linda are the top prospects for pairing with Alan but you know how those super-senior developers are…. you know.
Before your manager thrusts the responsibility on them, you raise your hand to volunteer. Now they are the ones silently thanking you.

On-boarding new team mates is incredibly important as it will either set them up for success and allow them to quickly contribute to the team or leave them feeling unsure of their decision to join your company and confused about how to write the sexy code you need for your mission critical application: a food truck finder.

Teaching others how your various processes, apps and ceremonies work reinforces your own understanding and can often lead to new discoveries with a fresh perspective. Why does this work like this? your mentee asks. Good point, perhaps this custom API client can be replaced with a library like axios. You make a note.

If your team is in a high growth stage, refining the onboarding process can lead to tangible results. The faster and easier developers are able to get set up and begin contributing, the better for morale, retention and velocity. Managers love velocity 😉

Checkout the Taro masterclass about onboarding here!

4. Teach What You Do Know

Linda and Dennis have been writing Javascript since the beginning of time. They’ve contributed to open source projects and frameworks that are widely used not in just your organization but around the world. What are you going to teach them?

Well, probably not much about Javascript but perhaps you went to a bootcamp where you were exposed to Ruby, Python, Heroku or AWS. If your company hosts show and tell sessions where developers get to share expertise across domains then offer to present on a topic you’re familiar with. If your company doesn’t have any forum for developers to learn from each other then you need to make one.

Having a space for developers to learn from one another helps everyone’s career trajectory. Show off that new React UI library you used last weekend on that project you’re never going to finish. Maybe you’ve discovered a code editor that is not VS Code that you think would make the team’s lives collectively better.

These presentations don’t need to be the most technically advanced to be useful. Bonus points if you spearhead the effort to begin monthly or bi-monthly knowledge sharing sessions.

You Are More Than the Code You Write

While you will be judged largely on the code you produce; the scrutiny over your choice to use a functional or object-oriented approach will likely go unnoticed by your managers and customers. To have a larger impact on your organization, look at other areas where you can contribute to make your life and your team mates lives just a bit better.

I'm Brian, an engineering manager and mentor who writes about how junior devs can accelerate their careers. Grab some free resources on my site and connect with me on LinkedIn and say hi 👋