My Tips for Starting At a New Job

I’m a month into a new job and I wanted to recap on some things I thought have helped me settle into my new workplace while they’re still fresh in my mind. I hope that my experience can be helpful for anyone else out there who may be nervous about starting a new job, or maybe feeling a little unsettled in a job they’ve just started.

Starting a new job can definitely be scary. You might have a new commute, a new building, a new team, and very likely a new code base. This can be a lot to take in and I want to talk about some of the things I’ve done to make my transition period as pleasant as possible.

Become part of the team

A new team is a big change to become accustomed to. You are essentially infiltrating what could be a very tight knit group of people and that can make you feel like a bit of an outcast in the beginning. Thankfully in my experience everyone has been incredibly warm and welcoming; offering plenty of help, invitations to sit with them at lunch, and asking if I would like to come along to their Friday team lunches out.

Make the most of these invitations as soon as possible as I have found they will be what cements your relationship with your team in the beginning. If you chose to sit alone or avoid team lunches you miss out on a great opportunity to learn more about your team, and you may find it more difficult to connect with them later on.

It can be difficult but try to make the effort to spend time with your team away from the work. I don’t mean you need to see them outside of office hours, but you can always ask if anyone wants to step out for a coffee or even tag along for a walk to grab lunch.

Ultimately I think putting in the effort to become part of team as soon as possible is a sure fire way to settle in faster. It will always be a little awkward and uncomfortable at first, but the more effort you make the easier it will get. Before you know it, you’ll be able to talk to the team like they’re old friends.

Read As Much Documentation As Possible

You might find that after starting at a new job you might not have a lot to do. I’ve waited days for hardware, and even longer for right access and software to do my job. I like to make the most of this inevitable downtime by reading through as much documentation as possible.

Hopefully your new company or team has a habit of writing down all (or at least most) of the important things into a wiki or simmilar. Reading through documentation can give an insight into how projects work, how the architecture has been built out and how certain problems have been dealt with.

Old spike documentation is a great example for getting to know what kinds of problems have come up over the course of a project as well as what and how the team chose to solve them. Not only is this a great insight into the team and the technical side of the projects but it can be an opportunity to learn something new. I like to keep a note pad with me while I read through documentation to write down any technologies that I haven’t seen before as well as make notes about problems I may have solved differently.

And be sure to check out any README.md you come across! There is all sorts of good information stuffed into those things that are there to make your life easier. And if you find out later on that something is missing, you can take the initiative to add it in!

Look At Pull Requests

Similar to above, I like to look at old pull requests. They’re a great way to get a look at the code and how it works, as well as how it’s evolved over time. Seeing what has changed, why it changed and how paints a great picture of the codes flow.

I also like to keep track of anything I think might be important that I see in a pull request. You never know when you might pick up a ticket that is similar to or relevant to an older change. Having a few notes like this can help make up for the lack of knowledge you have of the code base, or at least help shorten the time it takes to learn it.

Don’t be afraid to ask your team mates if they have done anything similar recently and if they can direct you to a pull request. I’ve had people offer to talk me through changes and even give me pointers and tips on how I can move forward.
I also find it interesting what things get pointed out. I’ve learned a few tricks from comments made on pull requests.

Don’t wait for people to make the same comments on your own pull requests, have a look and see if there is anything useful that’s been said before.

Dive into the code

The best way to learn a new code base has got to be diving right into it with no reservations. The more time you spend watching how things work and actively breaking them (locally!) the more faster you’ll learn.

Don’t be afraid to refactor either. If you see some messy code or something that not quite as good as it could be, make en effort to see what you can do to improve it. If there is a good suite of unit tests you can be more confident making changes and validate that you understand what the code is doing.

Pair programming is great. If you can get somebody to sit with you for your first ticket or two make sure to ask as many questions as humanely possible. Don’t worry too much about seeming dumb or unequipped because you question everything, everyone around you has a wealth of knowledge and they’d likely appreciate being able to unload some of it. The next time somebody asks the same question, maybe you’ll be the one who is available to answer it.

Thanks!

There is so much more I could have written down but these things have made the biggest impact on me during the last month of my new job.

Thanks for reading. I’d love to hear your thoughts on what I’ve talked about as well as any of your own tips and/ or insights!

Cover image courtesy of Dylan Gillis at Unsplash.