Investigation

How to build context fast

Senior engineering series: 3

The Senior Engineer Series is a multipart blog post describing the best practices and lessons I employ as an experienced software engineer.

When you pick up a new problem to solve, you need to build context fast. Start an initial notes document. The purpose of this document is to collect questions, links, notes, code snippets, etc.

At the start, try to write the goal of the project at the top. Can you write it in one or two sentences?

Next, start listing questions you have about the goal. As you write some of these questions you’ll realize that you have some guesses about their answers. Write those down. Other questions will prompt still more questions. Write those down as well. Some questions will make you think, 'I can find the answer to this question!' Off you go.

Start a links section in your doc. As you start looking for answers to your questions, capture the links you visit. When you start opening new files some will be short, easy to read, and obvious in purpose. Others will not. Do not get bogged down reading code that in the end might be unrelated to your goals.

Open an LLM, type - “Explain at a high level what the following code does:” and then paste the code. You’ll get a pretty good answer. From there you can ask more questions like, "Suggest how I might do X in this file." Remember, the LLM is like an intern, you need to double check its work.

Time box your LLM chat. If you exhaust your allotted time, it's a good signal that the file is promising. Make a note. It also might be time to read the file, read its tests, and read files that reference it.

After some time, ideas will emerge from your notes doc. You’ll start inventing solutions. Write those down. What questions would you need to have answers for to assess the viability of the solution? Write those down too.

Do not be afraid to restructure your notes doc at this point. Reorganizing your notes is known as synthesis.

Writing notes enforces a basic discipline: is the thing I’m looking at or thinking about moving me towards a better understanding of the problem I’m trying to solve? It’s hard to write a note when the answer is no. Be mindful of that feeling to avoid falling into rabbit holes.

At the end of one day, review your notes. Pull out the most important blocking questions and list them in a new section at the top of your document. If you know the answers to these questions you’ll be good to go. Start there tomorrow.

Subscribe to Very Normal and follow the Senior engineer series for more insights and strategies to thrive in your software engineering career.