A big welcome to all the new subscribers out there. As I mentioned the previous week, there was a large spike in new subscribers recently. Paid subscribers grew by 23% in the last month. That's pretty good. If the growth stays consistent, the newsletter will have a billion in revenue in no time at all.

I wasn't initially planning on this being a list article. I do like list articles (I just find them easy to read), but this wasn't written as one. However, I finished writing, and I was working on the headline for the article. Headlines sometimes take me a while because I'm trying to avoid clickbait titles, while making them attractive enough to encourage reading. Clickability is a tough balance to maintain. Anyway, while trying variations on the headline, I counted the sections below and realized there were exactly 10. Accidentally. That just felt like a sign that I needed to number the sections. So, that's what I did.

Today's topic is at the request of a few readers. While I regularly talk about interviewing, and ramping up at a new position, my articles often are targeted towards more senior employees. Instead, I'm going to chat for a bit today about how junior engineers can have increased growth and job security by being great junior engineers.

Most of this certainly applies to junior employees who are not engineers, but I have a few items in there which are relatively specific to engineering. So I kept the headline specific.

One - Get to know your co-workers.

As a junior engineer, your main job is typically to write code.

This doesn't mean that you can sit quietly in your cube (or home office), typing. We all work on teams. You may not be a major participant in setting future priorities, or designing the next system. However, you'll never be a part of the more interesting work if your co-workers don't know who you are.

They need to know who you are so that you're comfortable asking for help (see below). They need to know who you are, so that your inevitable mistakes are more accepted. In general, it's nice to know the humans you work with.

As a future highly valuable member of the team, you must know (personally) your teammates, product partner, QA partner, project management partner, marketing partner, or anyone else your team might interact with regularly. A simple 30-minute meeting can make a huge difference in your long-term success.

Two - Ask for help.

You should be independent and figure things out. For a few hours. Maybe a day, depending on the task.

However, spending a week reading documentation on the internet about how to resolve a problem with your development environment is a terrible waste of time. Politely get your co-workers to help you when you get stuck so that you can keep adding value. Don't worry about looking dumb. It looks more stupid to waste a week on an issue than simply admitting you need a little help.

Batch the help you ask for. Don't ask for help every 3 minutes. Move on if you get stuck, get a list of things you need help with, and then ask them in a single discussion. It'll make things more efficient for your co-workers.

If no one has done it for you, sometimes it's helpful to identify a specific co-worker who is experienced and receptive to helping, and ask them to mentor you for a while until you get comfortable. Asking dumb questions from a single co-worker can feel less stressful than regularly asking all your co-workers dumb questions.

Three - Be a good teammate.

Empathy goes a long way. It's a huge factor in how many people want you on their team in the future.

Be polite, even if a co-worker isn't being polite. No one ever wins with snappy comebacks.

Be patient, even if a co-worker makes dumb mistakes. No one improves more by being told that their mistake was ignorant.

We once had a new engineer join our organization. Shortly afterward, we had a team hike together. During the hike, the new engineer kept loudly complaining that many people were too slow, and we should ditch them to go faster. Not a great career move.

Four - Don't fall victim to good enough.

Hacking up stuff is fine in an internal test script you're playing with.

Hacking up stuff in production looks unprofessional.

We often say that junior people slowly degrade systems, and senior people slowly improve systems. Work your way towards senior employee by ensuring that your code, documentation, and designs improve your systems over time.

A simple example. When I first joined Facebook, during my bootcamp, I made a simple code change, and pushed a code review out. An engineer saw the review, and asked me to refactor the API I was editing because the API was pretty ugly.

I thought about objecting because I was making a quick 2 line code change, and the API was multiple pages of code. But I realized that it was my job as a senior employee to ensure that I was cleaning up the surrounding code, regardless of what my personal work was. I was wrong to leave things ugly.

Be a good citizen, and keep a high bar.

This post is for paying subscribers only

Sign up now and upgrade your account to read the post and get access to the full library of posts for paying subscribers only.

Sign up now Already have an account? Sign in