#publish/featured As a software engineer, you will inevitable need to onboard to a new project that already has had a life of its own. While people won't expect you to become an expert overnight, you are still going to need to take time to get started but eventually become a useful part of the project contributor list. Here are the challenges I run into. 1. **Finding a map of the project** This is an abstract one. A map is the intuitive sense one develops when working on a project. Its that thing that allows you to quickly answer questions such as "what are the candidate causes for the bug?" or "what direction should we look at for implementing this new feature". 2. **Knowing what is critical vs. useful** There are a lot of useful things that you can do on a project, things that bring *some* value. However, there are very few *critical* items, things that the success of the entire project hinges on. If you want to bring the most value to a project, focus on the critical and address the useful last. Now, assuming that your primary mode of contribution is writing code, here is how I have learned to approach each new project I onboard to. 1. **Understand the "why" of the project beyond the initial elevator pitch.** The biggest struggle is finding the "map" of the project, as mentioned above, and a big part of that discovery is to know why we are investing in the project. This ranges from the above board reason of what value it brings to customers, to the business oriented "how much money will this bring in or save?", to the shameful but real "what are the internal politics driving the implementation of this project?". Beyond providing you with guidance on the project, they will also enable you to work and collaborate effectively. 2. **Reliably compile the code from scratch.** If at all possible, reject the tempting offer of "I am finally in a good state and can compile". Instead, become as much of as an expert as necessary to be able to compile your projects repo(s) reliably *every time*. Yes, *every time*. It should be extremely rare that you struggle to compile your project. If you run into compile time issues, *ruthlessly pursue a solution and create a [[TSG]]*. Do NOT make due with "okay" for this. 3. **Unless absolutely impossible, make sure you can setup a local run with _breakpoints_.** Yes, some projects are just so complex and difficult that you cannot have breakpoints but those projects are nowadays rare and few in-between. Unless the stack you are working on makes it impossible, always make sure you understand how. Of course, later, once you are used to the project, even entire stacks are worth rethinking if you can't set a breakpoints and debug line-by-line. 4. **Make sure you can run the tests and know which tests reliably pass.** In a perfect world, every project will have robust tests and every test suite only fails when your test fails. However, most real world projects are not like that. Some test harness will fail or there will be tests for the failure of which the appropriate response from the team is "try and running it again". Make sure you know which is which. And if the project doesn't have tests, then perhaps that is a good first are of investment for you on the project since [[Tests speed up development]]. In my mind [[End-to-end tests|E2E]] tests [[Why I think E2E tests are more useful than unit tests|are more useful]] than [[Unit tests]] 5. **Identify entry points and key locations in code.** For this, you might need the help of someone else on the team. You *could* just read the code but more than likely, a person who works on the project can more speedily walk you through the key locations that you can easily miss in half the time. It lets you know where you should be paying attention when you do the walk-through by yourself. With these steps in hand, you can now go forward and start exploring the project. Once you have a good general understanding (a couple of hours of light reading assuming that you are already familiar with the language and stack), the best way to accelerate your learning is to [[Fixing bugs to understand a project|pick up a bug and dive right in]].