Being a New Hire is a Super Power...Don't Waste It
Tags: career, development
Published: 2023-10-10 13:32:15

So you made it through the interview process and got the job. Congratulations! But now what?

![A blue question mark on a pink background.](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/9vb1qukw1225nz2wuw1c.png)

When you start a new job, you're in a unique, but *temporary* position to look at things with fresh eyes before you adapt to the new situation you're in, and things become "normal". Take advantage of this limited time perspective because it can bring with it a LOT of benefits.


## Onboarding...Take Notes!

![A a pen resting on top of a notepad with the word "Notes" written on it.](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/iyqnsnav4enwlt2ldxks.jpg)

You'll more than likely only ever onboard to a company once. After that, you learn the ins and outs, the people, and you lose that "new" view. Over time you forget the little things that were interesting and/or challenging in the beginning, which makes it difficult later to empathize, understand, and anticipate what new employees will need. So as the new hire, you're in a unique position to make the company's onboarding process better, right out of the gate, in your first few days.

Take lots of notes about the onboarding process. The things you learn, the things that go unexplained, things you're told but aren't documented (also called "insider knowledge"), and also your questions. As you continue through the first days or couple weeks, try to keep these notes up to date. You can then use your notes to help update the onboarding process for the next person!

This has the great benefit of kicking off your first couple of days/weeks with the company in a positive light, showing you're a go getter and a team player.


## Update the Setup Docs

![A terminal and code editor open on a computer screen](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/bopyc7if30qrpni7gndl.jpg)

As engineers, we often have many tools and technologies that we have to install or configure in order to get up and running on a new project. But once it's done, we likely won't do it again for years (probably not until you get a new computer). Hopefully your new team has the setup process documented...(if not, looks like an opportunity for you to write it!). But as time goes on, things change, technologies evolve, and bugs are introduced. So as you're going through the process, be sure to notate any issues you encounter, or changes you had to make. When you're done, go back and update (or write) the docs based on what you had to do. You'd be amazed at how much this adds for a team!

This is also a great opportunity to assess how up to date the project and team are. Are they using versions of things that are 2 major releases behind? If so, are these things that could potentially be updated? Are there security issues to be concerned about? Are there better tools that it might be worth switching to? All of these are at least worth discussing. Even if the answer is "No, let's keep things as they are because...", it's still valuable to have the conversation, and shows you're thinking at a larger scale than just your own code.


### The Code

![A screenshot of some code open in a code editor on a computer screen](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/rwebttc4i70c6qwje6rg.png)

Like the old adage says, "you only have 1 chance to make a first impression", you only have 1 chance to view a codebase with new eyes. Take advantage of this by noting things that stand out to you in your first few days of looking through the code. Was there something there that made understanding the code easy or difficult? Was there anything that didn't make sense until you had "insider knowledge"? These are very good indicators that some documentation needs to be written about certain areas.

As a bonus, offer to write that documentation yourself while it's new and fresh in your mind! This also shows you're a team player, and that you understand the importance shared knowledge plays on a team.

### Fresh Eyes and New (Code) Smells

![A dog wearing a mask with a big nose](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/sf9ur7z4connxxq5h6nl.png)

As you're getting to know the new codebase, you may start to see things you would want to fix or update. Maybe you see duplication, use of deprecated APIs, or the use of anti-patterns. Be sure to take rigorous notes on these things, because it's very likely you won't remember them. Or even better, check Jira, or GitHub, or Monday, of wherever the team is tracking work and see if there are already tickets for these items. If not, write the tickets yourself! The first step to tackling tech debt is tracking it, and this helps the team do just that.


### Keep an Eye Out for Opportunities

![A man looking through a magnifying glass](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/f3kx8887z56yu03hhpqo.png)

Sometimes, people get set in the way things are done, and just end up leaving them as they are. But with new, fresh eyes, you have a unique perspective where you may be able to save members of your team time, or help increase the quality of the teams work by keeping an eye out for manual or inefficient processes that could potentially be automated. A couple examples:

- Templates for tickets and PR descriptions.
- User snippets in VSCode (or whatever other editor you use) for commonly used boilerplate, like the skeleton of a functional component in React, or a new set of tests.
- Writing scripts to pull information for a data analyst to report on (or building an internal tool for even more ease of use).

This is easily my favorite thing to look for when I first start a new job. I love building automations, or tools that make a process more efficient. Maybe it's something as trivial as creating a PR template in GitHub to increase standardization. Perhaps it's wrapping up the dev environment in a Docker container to reduce issues between the different environments your team is working in. Or it could be something larger, like building a CLI to handle creating large amounts of boilerplate for a new feature.

This can add a LOT to team.

And don't just look for these opportunities within the engineering team! There are likely pain points across the company that could be solved with a simple tool (it doesn't always have to be built internally). So make it a point to reach out and talk with people on the other teams. Find out what it's like for them to do their job. What tasks take a long time? Which ones are blocked by someone else? Is this something that could be improved? 


## Conclusion

Starting a new job puts you into a very unique and valuable position to view things through "new" eyes, but it only lasts a short time, so make sure you take full advantage of it.

Take lots of notes. Not just of the things that are shared with you, but also the questions you have, the process you go through, and the things you notice. You're about to be bombarded with information, and it's unlikely you are going to remember every single thing...so write down as much of it as you can so you can refer back to it later.

And keep an eye out for opportunities to make things better. No process is perfect, so look for opportunities. Not opportunities for change, opportunities for improvement.

Good luck with your new job! And until next time, Happy Hacking!