Meaningful contributions as a new software engineer

I have worked the last year and a bit as a software engineer at New Relic. My opinions are my own and not those of my employer.

When I started my job at New Relic on my amazing team, I often worried if I was going to be able to make contributions that mattered soon enough. I was on the other end of a very senior heavy team and, to my relief and delight, realized quickly that I could make meaningful contributions right away. It’s now 1.25 years later and I feel like a necessary member of the team and have already been promoted.

While hypothetically pondering if I could get another team to take me in ever, a teammate said that I’m far past the question of “can we help this junior be a decent developer in 6 months?”and am at the“this person is going to contribute to any team immediately” career stage.

It’s that compliment that prompted this post. I figured I could give first time devs some peace-of-mind and a few helpful tips. I’ve broken up how I contribute into four sections.

Asking great questions

I can’t count on my fingers the number of times I’ve asked a question in a meeting and been met with “Oh, Rachael, you’re right!” Somehow I go from being confused to correct and, while it can feel like a special trick, it’s really quite simple.

Having taught English as a second language (ESL) before switching to software, I learned I often get new perspectives on a subject simply by being asked questions. Questions help you know what you don’t know. The way someone else’s brain gets confused, highlights things you haven’t even considered before.

Simply by being the unique individual you are, your questions are going to help the seniors on your team look at things in a new way. The real trick is finding a team, where you feel safe enough to ask questions.

Questions are also great because even if you can’t implement alone what the team is deciding on technically yet, you can still help people reach good technical decisions.

The best questions elucidate details and inspire ideas. Asking about how reliable something needs to be, or if the stakeholders been spoken considered, what the exact goal of the work is, asking for the system to be visualized on a white board as reference for the discussion, are all examples of helpful questions. Ask about tradeoffs! For example, do we really want yet another service, can we wait until the infrastructure team has this new feature in place, is there a team that perhaps would be better suited for this interrupt work, what are the differences between tech A and tech B? Tradeoff conversations are fascinating because you learn so much from those discussions!

Train Stopping & Forest Spotting

Unfortunately as a beginner you don’t have all the answers and ideas yet. Fortunately as a beginner you don’t have all the answers and ideas yet.

While working through solving a problem as a group there’s a place people talk about known as “solutionville”. The group shouldn’t really go there until the entire group understands the problem first. Luckily for you, empowered by your mad question skills, you can pull the brakes and ask to stop and understand the problem first. After the entire group is actually caught up, and the setting is appropriate (NOT DURING STANDUP) enjoy the journey to solutionville! You can even volunteer at the whiteboard (this is different than sitting and taking notes — they shouldn’t ask you to take minutes of meetings!!!) to capture tasks and ask for specifics on points you find confusing. Pick a task that looks fascinating to you and ask to pair! You’re about to learn so much!

A manager once told me I could see the forest through the trees and that this was a good thing. I think I am able to do this because I ask so many questions. Because I ask questions I can see the larger picture of our work, and be aware of what tasks/steps we need to do for our current subset of work. Experts can easily come up with 100 different things that could be done, but sometimes have a harder time staying within the scope of current work because they see so many things to improve everywhere. On my team it’s always been appreciated that I can gently guide us back to the original problem/solution at hand. When you do this, be kind and don’t squash enthusiasm. Ask them to capture those ideas so the team can use them later if there’s stretch time. Ask to pair on those tickets!! They’re usually great learning opportunities.

Teammate-ing

If you’re like me, you came to tech after trying at least one other career path. What you’ve learned before you get to bring with you. For me I got to use my previous job experience to teach my teammates how to teach me, which benefitted all of us.

Are you good at tough conversations and can you give critical feedback kindly? These are always handy skills. The expert/beginner pairing can be hard. Learning to work with and spend 8 hours a day with several complete individuals can be hard. If your space is safe, confronting conflict/tensions with compassion rather than letting things fester can be a real value add. Taking what causes conflict and suggesting process improvements makes the environment happier for everyone.

Teching

Do code reviews. You do not have to be an expert to give good code reviews (but I’d recommend watching Derek Prior’s talk on doing them well). Ask about things that don’t make sense to you.There’s a decent chance if it’s confusing to you now it’ll be confusing to anybody who’s on-call and paged for it at 3 am. If a pr has lots of unfamiliar code in it — asking the author for a walkthrough helps you learn the finer points of your language and on occasion can help the author spot a bug!

If you learn something new about the system you’re working on and you think… Hey! I should write that down… Write it down but where everyone can get read it! Encourage others to write stuff down. Remember, even though you’re the beginner on the team, capturing & sharing knowledge is something anyone can do.

You are technical enough for this job. Say it with me, “I am technical enough for this job!” Yes, you might be starting at square one… but if you’re fortunate to have the team I’ve had you’ll be looking back one year later and think… Wow! I’ve learned so much! I am definitely absolutely technical enough for this job!!