How to be Successful in a New Software Engineering Role

Sun Feb 02, 2020

software engineering career development

The first several months of any new job are critical for establishing credibility, building relationships, and setting yourself up for success at a new company. I’ve held a variety of software engineering jobs, both in a contracting and full-time capacity with companies ranging from startups to Fortune 100 companies, and I’ve realized that no matter what the particulars of the engineering role are, there are some general things that are critical to pay attention to in the first several months. My experience is largely working remotely for companies, where these first couple of weeks and months are even more critical to building trust with your employer, but these guidelines are applicable regardless of remote or on-site positions.

Local Development Environment

Often times an employer may allocate to you a half day or day to “get things set up”. Barring issues outside of your control, e.g. waiting to get access to certain systems, it should absolutely not take you half a day to set up your local development environment. This may seem like a small thing, but this is something completely within your control and if you can get your local environment set up and configured the way you like it within an hour, you can talk to your manager or team mates and tell them you’re ready to start pulling down repositories, learning the codebase, reading documentation, or generally do something more productive with your time.

My suggestion on how to do this efficiently is to keep an ongoing and up-to-date list of exactly how you would set up a new environment and to put your dotfiles into source control. I maintain this in a gist, with exact commands of everything I like to have installed, symlinks to set up dotfiles quickly, curl commands to download packages, etc. Knowing how to set up new SSH keys to use with Git or other systems is also important.

Expectations and First Task

You’ll likely be meeting with your manager within your first day or two of starting a new job, and it’s important to establish expectations and to start asking about what small task you can take on immediately or very soon, preferably within your first week. Some places are more formal than others, for example, you may be provided with a 30-60-90 day plan outlining what the expectations are for you at each of those benchmarks. It also may be more casual in which case you should have a very candid conversation with your manager about what they are expecting from you in terms of knowledge gain and work output early on. This is worth driving home — if you don’t have clear expectations set, you cannot exceed the expectations.

Getting through a first task is the first step to establishing credibility — it shows you can get up to speed on an unfamiliar codebase well enough to make a small change. First tasks will generally come in the form of bug fixes or small feature adds. It matters little what it is, more that you push to get assigned work quickly and get it done.

Obviously jumping into a brand new codebase can be intimidating, overwhelming, and challenging to navigate. It’s absolutely okay, expected, and good to lean on your team mates early on to rapidly gain an understanding of the code base and make an effective early contribution. Pair with your team mates, and begin asking a barrage of questions.

Asking Questions

This seems like it should go without saying, but too often I have seen new engineers hesitate to ask “dumb” questions. When you start a new job, you have to push your ego under the rug and ask every question you can think of, to whoever might be able to answer it. It does not matter whether you are a senior engineer asking a junior engineer on the team how something works, it matters that you understand it and don’t have to ask it in six months from now when you should already know it.

Your manager and team do not expect you to have expert levels of understanding of the intricacies and idiosyncrasies of their work, and so you have somewhat of a grace period for the first several months to ask as many questions as possible. The important thing here is to pay attention to the answers so you don’t have to ask again.

It’s also great if you can find supporting documentation for your question before you ask it. Either you may find an answer to your question on your own, or you can frame your question in a superior way: “I noticed we have some documentation about X doing Y, but what I’m seeing is that X actually looks like it does Z, can you help me understand what’s going on here?”. This helps to establish you as someone who is self-sufficient, and has exhausted their own level of knowledge prior to asking for help — this is key to gaining larger responsibilities later on.

Participate in Code Reviews and Planning

It can be intimidating to comment on code reviews early on when you have very little context of what the changes are for, what the code does in general, and when you don’t know the people writing the code very well yet. However, getting involved early in the code review process is a fantastic way to learn, ask more questions, and potentially show your expertise if you see something you don’t agree with. It’s totally fine to comment on a code review with just a question, clarifying what something is doing in the code base. When asserting that something should be changed, it’s best to leave strong-held opinions at the door, and preface assertions with something like “In the past, I’ve seen this done more like …” because there may very well be a good reason for that strange bit of code that you are not privy to yet.

It’s also critical to participate early on in work planning sessions, whether these are sprint planning or some other flavor of work management. Again, asking questions and offering gentle suggestions based on past experience is the way to go here. This is also a great place to start understanding how your team fits into the broader architecture of the company.

Architectural Understanding

The degree to which you need to understand the broader architectue of the system you are working on varies drastically with your role, e.g. a junior engineer is not going to be expected to have the same level of understanding of the entire architecture as a senior engineer. However, regardless of your role, having a high-level understanding of the overall architecture is crucial as you begin taking on larger tasks and pushing for more responsibility.

There are a variety of ways to do this. Documentation is a great place to start — some companies will have more detail than others, but this is often a reasonable starting point for other conversations. Generally you will need to reach outside of your team and talk to people that work on varying parts of the architecture and pick their brain. If your manager can help you identify the right people to talk to and make introductions, that is ideal.

Going through code repos, particularly infrastructure or deployment repos is also a solid way to get exposure to the broader system. Sometimes going through infrastructure repos is more time-consuming than it’s worth, however. Looking at what is physically deployed is also great — for example, if your company uses AWS and if you have access to the console, go through the UI and see what’s actually deployed and how it’s configured.

Knowing in detail how your team fits into the broader architecture is also key. Here you absolutely should have a deeper understanding of everything your team is responsible for, regardless of what level engineer you are. Know all the repos and services that fall under your team, read through as much code as is prudent and generally try to equip yourself well enough that you would have at least an idea of where to start if someone came to you with an arbitrary feature request.

Becoming Self-Sufficient

At some point in roughly the first six months, you’ll fade out of the grey area where it’s still reasonable to ask basic-level questions and start being expected to be largely self-sufficient. This is not to say that you shouldn’t be asking questions after this point, but asking questions like “How do I get access to X repo?” when you have already gone through this doesn’t necessarily reflect well on you. Before reaching this point, it’s great to understand who does what within the company and find go-to people for certain things.

For example, knowing who to talk to if you have an infrastructure-related question, or a network topology question. Learning which Slack channels are helpful and which can be ignored. In general, learning what the communication channels are, and who you can lean on to help you when you encounter issues.

Taking on Larger Projects

Hopefully at this point you’ve established some street cred and can push yourself past onboarding expectations and ask your manager to start taking on larger bodies of work and more responsibility. If you’ve managed to prove that you can get up to speed quickly and can be self-sufficient in task completion, then this should not be an issue. Taking on a larger body of work is the next step in proving yourself and setting yourself up for success.

What other things do you focus on when you start a new software engineering role? Get in touch, I’d love to hear from you.