5 Tips for Starting a New Job

I just started a new job this week I’m super pumped about at Commonwealth Fusion Systems! The first day was a whirlwind of learning new things and asking all the questions just like it has been every other time I’ve started a new job. But this time was a little different, and not just because this is the first time in 5 years I’m going back into an office. This time the questions involved things you totally deal with every day like superconducting magnets, cryogenic temperatures, supercritical helium, and 50,000 amp currents. Luckily I don’t have to fully understand all those things to do my job but it’s always good to understand where you fit in at a new job and how the whole process works at a high level.

Today I wanted to talk about the top 5 things I always try to do when starting a new job outside the routine “watch the training videos, set up your machine, get the code running, open your first ticket” instructions that come with every new software job. Writing these down is a good way for me to not only organize my own thoughts but also think critically about them and set some goals for myself. Hopefully when it comes time for your next role these will be helpful for you too!

1. Build Relationships#

As I mentioned before, building your relationships and network is the best thing you can do in your career in my opinion. And that’s not at all just for the benefits after you leave a company. Knowing the right people to talk to and having a good relationship so they want to help you out as much as possible is crucial for being successful at your job. These are the people who you’ll be turning to for help, helping in return, asking for their time, and more importantly, advocating for you when it comes time for a promotion. Meet as many people as you can, exploring your way through the branches on the org tree and really get to know the people, not just the employee.

2. Build your Context#

One of the differentiating factors (for now) between human software engineers and AI is the ability to effectively build all the context you need to work on a codebase optimally. AI is obviously getting better and better at slurping up and sending large chunks of code as context if you let it, but what you need to build goes beyond that. You do need to start with the current state of the codebase, what the patterns, norms, libraries used, and immediate problems are. But, more importantly, you need to learn how the software solves the human problems it exists for in the first place. What are the current limitations? What features are being used now? What’s being asked for? Plug into the product leader mindset.

This one takes the longest out of all the points, and arguably just keeps on going, but the goal should be to start triaging which context is most important to learn first and become effective as soon as possible. There’s no shortcut to this one, just read lots of code, docs, PRs, and ask lots of questions.

3. Keep a List#

As you’re building your context in #2 by reading through the code and diving into using the product really, you’ll inevitably have questions about how something works, or why X, Y, & Z are done that way, or even ideas for new features. Get in the habit of writing them all down on a list somewhere. As you get answers either on your own or by asking a coworker check them off (and write down the answer if you think you’ll forget in the beginning info overload). This is not only to keep organized and remind you to ask the questions, but also there will inevitably be some questions that don’t get answered right away that are still good to keep track of. Come back to your list after a month or so and first (hopefully) be impressed by how far you’ve come with your understanding and then see if there are any open questions you need answers to or features that you still thing make sense.

You only get the fresh eyes of a new user of the product once. After you’ve been working on the same thing for a week (let alone, months or years) you become blind to all sorts of confusing behavior and bad UI as your muscle memory builds. By being the new (very attentive!) user yourself and writing down all the stumbling blocks, bugs, and frustrations you can really help out the product team by sharing your findings and hopefully be a part of fixing the issues that real users will also be facing.

My advice is to also keep any really large feature or refactoring work you notice to yourself and on the list for the first month. You really just don’t have enough context yet to know if those things make sense to do yet (or ever) and if you come out of the gate swinging with all these drastic changes you’re just going to give a bad impression and look like you don’t know what you’re talking about, because you probably don’t yet. But if after waiting a month you still think they make sense, bring them up with your manager and see what they think.

4. Improve Onboarding & Documentation#

This should be a bit of a no-brainer but the easiest first task and PR is to update the README and documentation for setting up the repo and local development environment. That section is the most likely to get out of date and break since it’s run so infrequently and usually dependent on other machine setup steps happening in the right order. If the whole thing works flawlessly the first try with no one coaching you through it be sure to personally thank the last person who touched that section of the README. I can count on one finger the times that’s happened for me :)

Part of #2 should also be looking for up to date architecture diagrams. These are also a rare commodity since they so often don’t get updated as the architecture changes. An early value add for the company you can do is to take it upon yourself to update the diagrams while pairing with someone who knows the architecture well. This helps you learn and helps the next person that needs to reference them.

5. Document the TLA’s#

You obviously should know that a TLA is a three letter acronym 😉. Every company has tons of industry and domain specific jargon that is also gonna take some time to wrap your head around. If you’re lucky someone will have already set up a glossary page that defines the commonly used ones. But just like architecture diagrams they’re often incomplete, or the definitions need further explanation. Once again, take it upon yourself to help the whole company out and improve (or create) the glossary for the next person as you discover the meanings to the FLAS.

Finally#

This will be the 8th company I’ve worked for in my career which is a little wild to think about. Maybe you’ve also been around the block a few times these tips are old news to you. If that’s the case, help us all out and leave a comment with your favorite tips!

A good first impression goes a long ways so do your absolute best in the beginning and it will pay off. Hope your next new job experience is great too!