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 3 to 4 pages. See the sample process journal for an example. The sample does not show the driver and navigator roles or the Reflection section. 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. UPDATED Comprehension Process: Describe the initial steps you’ve taken to understand the codebase’s 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. You may choose to discuss:
    • The specific code navigation techniques (search terms used, navigation shortcuts used, etc)
    • Important commands
    • Debugger breakpoints you used
  2. NEW Implementation Process: What major steps did you take to implement your feature?
    • For each step, write what you did and which partner was the driver and which was the navigator. A short list or table is fine.
    • When did you switch roles? How did working in these roles affect the programming experience?
  3. Running and Testing: What manual verification did you conduct? What edge cases did you encounter or consider, and how did you handle each one?
    • What were your expected outputs?
    • Include any errors or unexpected behavior.
    • Useful to think / structure as a Write -> Run/Test -> Debug/Obstacle loop
  4. 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 to look up documentation or explain existing IDLE code, 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)
  5. Resources Consulted: List any web resources, peers, or other references you used, and summarize what you learned from them. If you used a chat tool, say what you asked it and what you learned. You can have a designated section for it.
  6. NEW Reflection: What did you learn from writing this process journal? What will you take away from this experience for future work?