Posted on Oct 10 So you made it through the interview process and got the job. Congratulations! But now what?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.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.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.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.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.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: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? 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!Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well Confirm For further actions, you may consider blocking this person and/or reporting abuse Gregor Ojstersek - Aug 30 Naomi Chopra - Aug 30 ByteHide - Aug 28 Zeeshan Haider Shaheen - Aug 19 Once suspended, Wraith will not be able to comment or publish posts until their suspension is removed. Once unsuspended, wraith will be able to comment and publish posts again. Once unpublished, all posts by wraith will become hidden and only accessible to themselves. If wraith is not suspended, they can still re-publish their posts from their dashboard. Note: Once unpublished, this post will become invisible to the public and only accessible to Jake Lundberg. They can still re-publish the post if they are not suspended. Thanks for keeping DEV Community safe. Here is what you can do to flag wraith: wraith consistently posts content that violates DEV Community's code of conduct because it is harassing, offensive or spammy. Unflagging wraith will restore default visibility to their posts. DEV Community — A constructive and inclusive social network for software developers. With you every step of your journey. Built on Forem — the open source software that powers DEV and other inclusive communities.Made with love and Ruby on Rails. DEV Community © 2016 - 2023. We're a place where coders share, stay up-to-date and grow their careers.