Growth Synthesis Guide
COMP 536 | Final Project Reflection
What This Is
The Growth Synthesis is the final reflection that accompanies your final project. It asks you to step back and look across the semester as a whole: how your debugging habits changed, how your verification strategies matured, how your computational judgment and AI literacy developed, and what you can now do that you could not do at the start of the course.
This is not a formal scientific report. It should read more like an honest reflective memo than an essay.
Why This Matters
This course is not only about finishing four short projects and one final project. It is about becoming someone who can design, verify, debug, and explain computational models they actually understand.
The Growth Synthesis is where you name that change directly. A good synthesis does not only say, “I learned JAX” or “I got better at debugging.” It shows how your habits changed, what forced those changes, and which practices you now trust enough to carry into future work.
Submission Basics
| Due | Wednesday, May 13, 2026 (11:59 pm PT) |
| Submit with | Your final project repository |
| Recommended length | About 800 - 1200 words |
| Suggested format | Markdown or PDF |
The syllabus defines the Growth Synthesis as part of the final-project submission. This page gives you a concrete prompt structure so you do not have to invent the reflection from scratch.
What Makes This Different From A Growth Memo
Your short-project Growth Memos were project-by-project reflections written close to the work itself. The Growth Synthesis is different. It is the semester-end capstone reflection.
| Short-project Growth Memo | Growth Synthesis |
|---|---|
| focused on one project | looks across the whole semester |
| written soon after the work | written after you can see longer patterns |
| asks what happened on that project | asks how your habits and judgment changed overall |
| supports local reflection | supports transfer to future work |
The goal is not to repeat four earlier memos in compressed form. The goal is to synthesize what those projects add up to.
Before You Begin
Set aside a little time to look backward before you write.
Recommended prep:
- re-read your four short-project Growth Memos,
- skim your earlier repositories or major files,
- glance through your final-project repo with the same eye you would use on someone else’s work,
- jot down a few moments when your habits clearly changed.
The point is not nostalgia. The point is evidence. You will write a better synthesis if you can point to specific transitions instead of relying on vague memory.
Memo Contract
Treat this as a separate final memo, not as an appendix to your report. A strong Growth Synthesis should:
- specific rather than generic,
- honest rather than performative,
- grounded in concrete projects, bugs, or decisions,
- reflective about process, not only outcomes,
- focused on growth in judgment, not only growth in technical vocabulary.
At minimum, your synthesis should name 2 - 3 concrete anchor moments from the semester. A strong set of anchors usually includes:
- one early-semester weakness, misconception, or habit you can now see more clearly,
- one turning point where your approach changed,
- one final-project moment that shows how your judgment is different now.
You do not need polished prose. You do need clear thinking.
Evidence Expectations
Your claims should be grounded in concrete evidence from the semester. Good evidence can include:
- a bug that changed how you debug,
- a refactor that changed how you structure code,
- a validation check that changed what you trust,
- a project moment when earlier course ideas became newly useful,
- a choice in the final project that shows you think differently now than you would have in January.
You do not need to cite commits or line numbers formally, but you should point to specific projects, decisions, habits, or turning points rather than speaking only in generalities.
If you are not sure what counts as enough evidence, start by choosing 2 - 3 anchor moments and building the memo around them.
Recommended Memo Structure
You do not have to use these exact headers, but this is the recommended shape for a strong synthesis.
1. Semester Arc
What is the story of your computational growth this semester? What patterns recur across the short projects and the final project? Was there a moment when something from earlier in the course suddenly became useful later?
This section should usually introduce at least one of your anchor moments.
2. Code And Verification Evolution
How did your code change over the semester? Think about organization, readability, testing, reproducibility, debugging workflow, and the way you structure scientific computation.
Just as important: how did your standards for trusting results change? What do you now check automatically that you would have skipped earlier in the course?
3. Computational Thinking And The Final Project
How has your approach to a new computational problem changed? Compare how you would have attacked a difficult modeling task in Week 1 with how you approached the final project.
What did the final project force you to confront? You might talk about scope, validation, debugging under time pressure, simulator trust, emulator trust, or the relationship between computational convenience and scientific credibility.
This section is a good place to make your strongest late-semester anchor moment visible.
4. The Glass-Box Experience
What did you learn from building algorithms or components yourself before leaning on libraries and frameworks? Which ideas made more sense because you had implemented a lower-level version first?
5. Optional AI Literacy And Collaboration Reflection
This section is optional if you did not use AI and did not have meaningful collaboration beyond normal class interaction.
If AI or collaboration did play a meaningful role in your semester, reflect on it directly:
- How did your use of AI change across the course phases?
- How did your AI literacy change: your ability to judge, audit, distrust, verify, or strategically use AI output?
- What kinds of AI help were actually useful, and what kinds became easier to distrust?
- How did classmates, office hours, or discussion spaces change the way you ask for help or explain your thinking?
- Where did outside help speed you up without replacing understanding?
If this section does not apply to you, it is completely fine to omit it.
6. Looking Ahead
What feels transferable from this course to research, thesis work, independent projects, or industry? What questions or directions are you leaving the course with? What practices from this semester do you expect to keep?
Helpful Framing Moves
If you get stuck, try one of these sentence starters:
- “A pattern I did not notice until Project 3 was …”
- “The biggest difference between my early and late code is …”
- “I used to think debugging meant …, but now I think it means …”
- “The final project forced me to confront …”
- “A validation habit I now trust is …”
- “One place where AI genuinely helped me was …, but it failed when …”
- “The strongest change in how I ask for help is …”
What Strong Syntheses Usually Do
A strong Growth Synthesis usually:
- tells a coherent story rather than answering prompts like a survey,
- names two or three real turning points,
- connects technical growth to changes in judgment,
- distinguishes between “I can do this now” and “I understand why this matters now,”
- ends with a believable sense of what the student will carry forward.
Final Advice
Treat this as a record of your actual learning, not as a performance of how much you think you were supposed to learn. The most useful syntheses are usually the ones that name specific habits, specific mistakes, and specific changes in judgment.
You are not trying to prove that the semester was smooth. You are trying to show that it changed how you work.