Joining a New Project

 

My process for owning a new project or becoming an expert on an unfamiliar platform:

  1. When you first start, write down everything anyone has told you about the project or platform in a quip or google doc. Write down a basic explanation you would give to a friend elsewhere in the org.
  2. Get a point of contact about the project and have a 30 minute sync-up. Ask them to confirm that your explanation is correct. Ask for every existing document and codebase on the project, and especially videos. Ask them to add the links to your google doc.
  3. Explore the links that you have. Write down a brief summary of each resource in your document. Videos are usually the most important as they contain a lot more information than the author intends, and that info is very helpful to beginners (i.e. where do go when navigating a codebase, how to call APIs, website format, etc.).
  4. For codebases, write down all the APIs. If you don't understand what they do, guess. Call your point of contact for another 30 minute chat. Ask your point of contact if your explanations are right. It's much easier for a point of contact to correct someone who is slightly wrong than it is to write an explanation from scratch.
  5. Ask your point of contact which APIs matter the most and do a deep dive on each one. Keep going until you find the hard-working most important code for that API. Write down all the classes you found along the way and what they do. Add more links to your document.
  6. Remember, above all, that you should ask every question you need help on. It's okay to ask questions you're embarrassed that you don't know the answer to. In fact, you should try to ask them first because they're usually foundational and important.

If this is an existing service or codebase:

  1. Set up the existing code in your IDE.
  2. Get everything working for running the server locally and running integration tests. You'll probably need to talk to your point of contact to do this. After you do this, boot up your server and run the integration tests.
  3. Set up the debugger and try running unit tests from your IDE. Debugger access and running UTs from your IDE will save you a lot of time.
  4. Use the UTs on important classes to figure out what they do and how they work.
  5. You can also debug when doing ITs -- this will give you an end-to-end understanding of a codebase.

Finally:

  1. Ask for a task that will help you get a good introduction to the platform or project. Preferably, it should be small and interact with a fairly important API. From then on, it's mostly about repeating the above steps with more knowledge to build off of and with more detail.
  2. Make your documentation available to other people who will work on this project in the future.

Comments

Post a Comment

Popular posts from this blog

Using Kanban Boards to Stay Organized and to Stay Motivated

I often work with Trello or Notion as Kanban boards. I maintain tasks for everything that I do. This helps me keep organized when I'm working on a large number of tasks, or especially if I have ideas for tasks that I am not actively working on. It creates a clear, constant document of the state of the tasks I'm working on. And more than anything, it shows to me what I've accomplished and lives on as a constant motivator for me. Why Kanban Boards Matter for You and Your Team One best practice that anyone working on a large project should adopt is to have at least one Kanban board task they're working on at any given time. Kanban boards are a visual way to track progress on tasks, enabling you to see the status of each task and its associated details. By consistently updating your tasks on a Kanban board, you'll reap several benefits: Greater personal efficiency : As you wrap up your day or put a project on hold, having detailed information on your Kanban board task h
Read more

Low Level Design Part 1: Reading and Gathering Information

Start out your document writing day 1 with a long list of open questions. As you read documents, you should slowly grow a longer and longer list of open questions. Maintain this list and keep adding to it while you write the doc. Questions are often more important than answers as they represent unknowns you need to disambiguate. You will need to ask people for most of your open questions. This is okay and most engineers are very happy to answer such questions. In general, people will feel more complimented rather than inconvenienced when their expertise is requested. If you can't find an answer to something and don't know who to ask, ask your manager or a senior engineer on your team. What if no one knows in your team? Formulate your question into something brief and meaningful and post it in your org or company-wide chat. If your question is technical, ask it as a stack overflow question and link it in the chat along with your question. Link to everything as hyperlinks in the
Read more

Low Level Design Part 3: Estimates

You should include your task breakdown and estimates in the low level design in the appendix if it's available. Design your project with the idea of disambiguating hard questions in mind. Frontload as much ambiguity in the project as possible. Changes in estimates months in advance are preferable to ones right before the deadline universally. Usually, the best way to do this is to write a thin vertical of your project first and then start fleshing out the functionality after that. If you haven't worked with a library, platform, language, etc. your estimates on that topic will have low accuracy due to unknowns. You can reduce this effect with additional reading, especially of code, or by writing code using that library yourself. Call out everything that you don't know.  Low accuracy estimates almost always take more time to complete rather than less . If you estimate a task as a week, the shortest it can be is an hour. The longest it can be is infinity. This asymmetry means
Read more