Top 5 tips on joining a new company remote as a software engineer

A little bit of background before we begin. 3 months ago I left to join a life insurance startup in Leicester called DeadHappy. It was a pretty scary jump to go from a company of 600+ engineers, to an engineering team of 6. Nevertheless, it was a challenge that I felt up for and that excited me!

One thing that has made it more tricky than a traditional job change is the fact that most of the tech world in the UK is working remotely right now because of the ‘rona. So it can be even harder to make the good impression you want to, making sure you hit the ground running and start feeling productive, especially in a small team.

I feel like a lot of people may be in the same boat right now or thinking about moving during this time (TLDR: 100% worth it!) so here are my top 5 tips that have helped me over the last 3 months, enjoy!

1. Go all in on the domain

For me, this could start before you even join your new gig. I was once told by someone wise somewhere, or I read it in a book maybe so don’t quote me on this but…

“The best way to know your product is to be a customer…” - Someone clever

Now this might not be applicable to all business, but for me it certainly was. I took out life insurance with DeadHappy before I started and it was a great way to get to know the product end to end. While you are doing this, make notes! Make notes of your initial reactions, what you found confusing, maybe ideas of what you think could make this product easier or better for customers.

Your new team mates will definitely appreciate this, as sometimes as engineers, we can be blinded to nuances in our product and a fresh pair of eyes is always handy.

Once you are “in the building” so to speak, then explore the services. Ask one of the tech leads to walk you through the architecture. This will take time but explore how things hang together, which services talk to which services. I am very much a visual person so seeing things in diagrams or in Miro boards really helped me on this.

Finally, researching and learning the data structure of the domain will really help you get off the ground running. If you are using GraphQL for example, explore its schema. Look at what data sits where and how you access it. Take a look in the database if you can or ask someone who has access to the development database to walk you through it. Look at where things are stored and how things are hung together. It will surprise you down the line how much this will help you when building features.

2. Throw yourself into the deep end

Now this one may be tricky, especially if you are not that way inclined to put yourself out there, but the hard facts are most people are not going to know anything about you or your skillset at your new place so it’s a necessary evil in my book.

One of the best examples of this I have found is start presenting and volunteering for things. Whether it be running your team’s sprint retro this week or in my case completely thrown under the bus by a colleague and running the company all hands meeting on week 2.

You are going feel great afterwards and it will do wonders for getting your name out to the business and letting people know who you are. If it doesn’t work out then at least you will have learnt something for next time and grown as an individual.

3. Environments Setup/Request Access

A concept that we will be familiar with as software engineers when we join a new place is the sometimes uphill struggle to get local development environments setup. This has got drastically better for me personally over the last few years but there is still private npm packages or private modules that you need access to.

What helped me here was getting setup on the environments that others in the team maybe did not or were reluctant to. Then if you are happy to put the work in, they will come and pair with you on changes in this project as you are the one that has it running.

Also, if there are specific tools that your business uses like password managers or analytics tools, request access right away when you start using them. Seen it before where you can be 6 months’/a year in and people still haven’t got access sorted for themselves for a particular tool they need. Be on the ball, go get it sorted early doors, you will thank yourself later when you can help someone who doesn’t have access.

4. Data, Data, Data

Data runs the world and this can be especially tricky to get close to when you are not in the office. You miss those little conversations where the product mangers talks about conversion at the desks, or updates like we have seen a spike in an area for example.

If someone talks about a report in standup, ask them if they could share the link of that with you. Request permission for the report if you don’t have access to it and bookmark it (more on that below).

Build up a collection of these reports every time you see one posted in slack or pair with someone to build a new report for the feature you are working on.

Make it part of your morning habit for example to start cycling through these reports and look for trends. The possibilities are endless here but if you notice something that is taking a dip or looks off, then look into why that might be and or suggest ways you think we could shift this trend the other way.

At the end of the day if you are making suggestions to improve conversation that is going to be cold hard cash you are bringing into the business.

5. Bookmarks, bookmarks, bookmarks

Last but not least and one that got laughed at when I suggested this to other people but for me this have been a lifesaver. But it is simple, bookmark everything.

I mean everything you think is handy… get them in your bookmarks bar in Chrome with folders the works, really went into shortcut overdrive here. All jokes aside, it will really supercharge your workflow.

These are a few of the categories or suggestions for bookmarks:

  • Quick link to see all available open pull requests in your company so you can start reviewing easily and adding comments.

  • Notable notion pages or other documentation pages your company may have that you can easily jump back to.

  • Zoom Rooms! This one is sick, bookmark the link to the zoom room with the password in the url so you can easily dive into rooms in one click for meetings or pairing sessions.

  • Links to your repos for every one of the services you may be working on (add new ones as you go) but it is super handy to be able to dive into a project without having to search for it on Github etc if someone asks you to go there.

  • Environments, links to all of your services in each of their respective locations e.g. dev, staging or production.

  • Reports, following on from tip number 4, bookmark all of those data reports you have been collecting so you can easily jump back to them.

  • Monitoring Tools, those Grafana graphs, when shit is hitting the fan with incidents you will be thankful to have these there.

If you have made it this far then cheers! Let me know on Twitter if you have anymore tips. I’d love to know things you have found that have helped you out.

See you next time.