A Software Engineer's Playbook for Starting a New Gig

If we can trust a quick Google Search, the average software engineer stays at their job for 1-2 years. That also means every 1-2 years, developers need to set themselves up in a new project, with a new team, computer, and tech stack. For contractors and freelancers, that period might be even shorter.

The first weeks at a new gig can be a bit daunting and intimidating. You want to leave a good first impression, get ready to contribute as soon as possible, all the while insane amounts of information are thrown at you from all sides.

Let us, therefore, look at a few ways you can make your life easier and onboard like a pro. ⛵

Content Overview

• Get Your Dev Environment Ready
• Understand the Release Process
• Ask All the Questions
• Document Everything
• Schedule Lots of Coffee Chats
• Shadow Your Peers
• Get Involved in Support Tasks ]
• Take on Small Impromptu Tasks
• Do Code Reviews

Get Your Dev Environment Ready

The sooner you have your development environment set up, the sooner you can jump into the code and start making meaningful contributions. Building and running the software locally on my machine is usually the first goal I set for myself when starting a new job. Depending on the complexity of the setup and the number of meetings and intro sessions you have, this might take a day or a couple of weeks.

To make things easier, I’d recommend keeping a list of tools you use in your day-to-day work (not on a company laptop, so can you can check the list when you start a new gig) - this should include your favorite IDE, terminal, build tools, API clients but also email clients, office programs, internet browsers, clipboard tools… Whatever tool or software you use that does not come pre-installed, put it on your list.

Next, ask your co-workers what tools they use. You’ll usually need some extra tools for each specific project and tech stack. Also, make sure you get access to shared collections for e.g. API clients.

Finally, a big time-saver is syncing your IDE settings with a non-company account, so your IDE settings and keybindings will work exactly how you like them on a new machine. I sync my VS Code settings with my personal GitHub account. That way, whenever I need to set myself up on a new computer, all I need to do is log in to GitHub, and my IDE will look and feel exactly how I left it on the last computer. My VS Code color scheme is a work of art, I won’t risk losing that. 🎨

Understand the Release Process

Every company (and sometimes even every team within the company) has its own release process. Before you push changes to the main branch for the first time, you want to understand what exactly happens afterward.

• Will your changes be deployed directly to production?
• Do you need to deploy a feature branch first and get the product owner’s approval?
• Is there a deadline by which you need to merge your changes for them to be included in the next release?
• When does the release happen and how?
• Do you need to provide release notes or a change log?

If your team has CI/CD in place, make sure you understand the steps of the pipeline. If your team doesn’t have CI/CD in place, you’re doomed and should hand in your letter of resignation immediately. 🥲 (Just kidding, of course. There are still valid reasons for a manual release process. I think.)

Ask All The Questions

People say there are no stupid questions but let’s be real here, if a developer asked which database the project uses after having worked on the backend team for two years, they wouldn’t exactly come across as the smartest.

However, when you are just joining a new team, there really is no question too dumb to ask. Everyone knows you’re new, and it’s in their best interest to get you up to speed as quickly as possible. Whenever there is anything you don’t understand, ask your peers - and make sure you write down the answer.

Document Everything

The first few weeks on a new job can be exhausting and you’ll be bombarded with new information constantly, so don’t rely on your brain to remember everything.

Instead, document everything, from the steps necessary to build the software to how the team does sprints and code reviews.

Ideally, you won’t have to start from scratch and there will already be documentation available. When you work your way through existing documentation and How-To guides, make sure to update any information that might be outdated or unclear. These documents go out-of-date quickly, so your first contribution can be improving them.

If you run into any sort of problem while you’re setting up, make sure you document the issue and the solution (which you found, hopefully) and share it with the team. You might be the first person facing a particular problem but you probably won’t be the last one.

Schedule Lots of Coffee Chats

Whether you work in an office or remotely, whether it’s a small start-up or a big corporation, make sure you get to know your peers. Even if most processes should be streamlined in any company, there will always be cases where pinging Jose from Accounting or Sarah from IT might significantly speed up your request. Make sure you know who does what in the company.

I would also recommend getting to know people from as many different departments as possible. Chances are, you will bond with your dev colleagues over an intense pair programming session sooner or later. But being a new joiner is the perfect opportunity to talk to your non-tech colleagues and get their perspective on what’s working well and what could be improved in the company. If you dare, ask them how they like collaborating with the engineering department and if there is anything that could be improved.

Shadow Your Peers

Ask your peers if you can shadow them for whatever they are working on. It’s a great way to learn and even though it might slow down the other person in the short term, long term it will take some load off their shoulders. Onboarding a new team member requires time and should be considered when planning capacities. Don’t feel bad about asking other people for their time.

Get Involved in Support Tasks

Most software engineers need to do some sort of support shift every once in a while and it’s usually no one’s favorite thing to do. Depending on the setup, taking over the support shift might not even require deep knowledge of the code base. The sooner you are up to speed with the support process, the sooner you’ll be able to make your colleagues’ lives a bit easier. I would recommend shadowing the person doing the support shift for a few weeks and then switching seats, so you’d take over the support shift with someone in the background who might give you additional context and answer any questions.

Take On Small Impactful Tasks

I’ve seen teams where it’s common for new engineers to take weeks, if not months, before they open their first Pull Request. That’s usually the case when the code base is very complex or the engineer is completely new to the tech stack. But I guarantee you, in every team, there will be smaller tasks that you can tackle without knowing the code inside and out. While you get onboarded onto the project, maybe you can fix some linter warnings, upgrade a library to the latest version, fix typos, or increase the test coverage. These tasks can have a big impact but are often neglected in everyday work. Your team members who are busy finishing features and fixing bugs will be grateful and you’ll feel amazing if you’re able to open your first Pull Request after a few days - even if all it does is change accuontNumber to accountNumber.

Do Code Reviews

It’s tempting to neglect to do code reviews at the beginning because you feel like you don’t know the code well enough to leave suggestions. I’ve certainly been guilty of that in the past.

However, reviewing Pull Requests is a great way to familiarise yourself with the code. No one will expect you to get involved in discussions on the business logic in the first days but you might be able to catch some careless slips.

You will also get an idea of how your team does Pull Requests - how big are the changes usually, how many reviewers get involved, which quality gates have to be passed, what’s the tone like in the comments?

I hope these tips will help you when starting your next job or project. Please leave a comment with anything you do to make the first few days a success!

You’ve got this, and I’m rooting for you. ✨Now go build things. 🚀