Process Journal

Your process journal (journal.md) has two purposes. It is a reference for your future self, with the key commands and steps you used. It also helps your code reviewer understand your work. The recommended length is 2 to 3 pages. See the sample process journal for an example. Write your journal in your own words.

It should include the following main components, but feel free to structure it how you see best, so long as it is clear to reviewers where each component is:

  1. Comprehension Process: Describe the initial steps you’ve taken to understand its structure and functionality, your code navigation journey, and code understanding process as best as you can to comprehend key files and functions. Try to reflect on how you went about understanding the parts of the codebase that you need to change and how you went about adding the feature. You may choose to discuss:
    • The specific code navigation techniques (search terms used, navigation shortcuts used, etc)
    • Important commands
    • Debugger breakpoints you used
  2. Running and Testing: What manual verification did you conduct? What edge cases did you encounter or consider?
    • What were your expected outputs?
    • Include any errors or unexpected behavior.
    • Useful to think / structure as a Write -> Run/Test -> Debug/Obstacle loop
  3. Obstacles Encountered: List major obstacles you’ve encountered during the development process. Describe how these were overcome through specific resources or strategies such as consulting documentation, using forums like StackOverflow, or discussing with peers, or other resources (using Google, a chat tool for documentation questions, office hours, etc).
    • If you had a specific bug, explain how you overcame it. (If you encounter a similar bug in the future, you will be able to reference back to this note for solution)
  4. Resources Consulted: List any web resources, peers, or other references you used, and summarize what you learned from them. You can have a designated section for it.