#13 - Not Alone
Make sure you leverage the team around you to help you grow!
Sometimes it can feel like it’s you against the world and you’ve got to pull yourself up from your bootstraps. But that’s rarely the case. There are always people who can help out.
When you’re a junior engineer, you’ll be drinking from the firehose of jargon and learning. It can feel overwhelming as you scale the learning curve.
But you don’t have to go it alone. There are three groups of people who can help:
Other Junior Engineers
Let’s see how.
Your manager is juggling a lot.
Put yourself in their shoes for a moment. They probably have anywhere from 4 to 20 reports, and need to consider the unique talents and desires of everyone. They also work with product managers and multiple levels of “higher ups”. That’s dozens of people to keep happy, while making sure a handful of projects ship. It’s tough.
You can make your manager’s life easier by being clear on what you want. It can be as simple as “I want to learn how we do security” or “I’m interested in working on payments”.
Most junior engineers have generic interests that are not actionable (i.e. “I want to learn machine learning” on a team that doesn’t use machine learning), or have no interests (i.e. “I’m ok with working on anything”). The last one is particularly hard to manage because you can put that engineer on a random project, but there’s a good chance they won’t like it and they’ll sulk (which means you have another problem on your hands).
Here’s an analogy - when you’re with a group of friends, it’s better to be someone who is opinionated (“I want Pho!”) as opposed to someone who thinks they’re flexible, but is actually just as picky as the first person (“I’m ok with anything” - but actually wants Mac N Cheese).
The truth is - everyone is picky, so let your pick be known!
The first order of business you need to perform when working with senior engineers is to choose who you want to emulate.
In my opinion, the best way to do this is to look around and ask “Whose code do I want my code to look like?”. You’ll need to think about this starting with your very first Pull Request.
Skipping this step means you’ll be influenced at random - and not all senior engineers are the same. Some write excellent code, but often build the wrong thing. Others ship excellent products, but their code leaves a lot to be desired. Some are senior because of seniority. Others are senior because they’ve shipped important projects for the company, but are still developing their technical skills. Some are good at X and Y, but not Z.
Just ask yourself, “If I picked up 25% of this person’s habits in 1 year, would I be happy with that?”.
Once you identify the engineers you want to emulate, ask them questions like:
Can I send you a code review? I’d like you to focus on readability.
I was reading through the design doc for feature X and wanted to see if you had any thoughts on the architecture.
And if you find someone who you really want to learn from, ask your manager to work with them!
Your fellow junior engineers are one of your best resources. They’re the least intimidating to talk to and their explanations are more digestable (although sometimes incorrect). You’ll grow together, and as one of you learn, all of you learn.
Early on, it’s important to set that tone of collaboration and sharing. Otherwise, silos can form, and you’ll miss out on any benefits of having a peer group.
One of the best ways to do this is to produce documentation.
Learn to use a new technology? Write a cheatsheet. Work on a new area of the codebase that other juniors haven’t touched yet? Write a “gotchas” guide. Don’t know how to do something? Ask a fellow junior how they did it and produce a how-to doc.
At my first job, it took a couple months before I became friends with an engineer named William. We would later go on to form a duo that would deliver successful project after successful project. But in the beginning, we never had the chance to work together.
The collaboration began with documentation. I remember asking him “Hey, you’ve worked on transactional emails and I have no idea how it works. Can I ask you about it for a document I’m writing?”
Documentation scales in a way that few other mediums can. And it gives you an excuse to form closer bonds with your fellow junior engineers. It’s one way juniors can add value to a team from day 0.
Being a junior engineer is hard. But there are people all around you who can help you get to the next level.
With your manager, be upfront on what you want to work on
With your senior engineers, find your role models (who might become mentors)
And with your fellow juniors, conspire on some documentation, before you collaborate on a project
You don’t have to do it alone!
Until next week,