Lesson 1.1: What the Engineering Notebook Is Actually For
Technical Context
A notebook loses much of its value when one person reconstructs it near the end of the season. The writer misses details, the team forgets why decisions were made, and the final document no longer reflects the work as it happened.
Write entries throughout the season and have the students doing the work contribute to them. That creates the record your team needs and gives judges evidence they can follow.
Two Audiences, Both Real
Your team, three weeks from now. Record why the intake uses a 1.4 inch spool instead of a 2 inch one. When the team replaces or revises that part later, the original calculation and test result will still be available.
Judges. In FTC, notebook-driven awards are among the most prestigious available, and they are decided largely on documented process. Judges are looking for evidence that the team engineered the robot rather than assembled it.
The two audiences want the same thing, which is convenient: a record of decisions and the reasoning behind them.
What Judges Look For
Judges are not grading handwriting. They are looking for a small number of specific things.
| They look for | What it looks like on the page |
|---|---|
| Iteration | Multiple versions of the same mechanism, with what changed and why |
| Evidence | Numbers from tests, not adjectives |
| Reasoning | Alternatives considered and the criteria used to choose |
| Ownership | Student voice, student sketches, student handwriting |
| Honesty | Failures recorded, including the ones that were not fixed |
Include failures as well as successful tests. An entry such as "the slide bound at full extension three times out of ten. We traced it to the third stage flexing and changed the support" shows the test, diagnosis, and response.
Record what failed, the conditions, what you measured, and what the team concluded. These entries often contain more useful design information than a routine success and make the iteration easy to follow.
What Belongs In It
- Design decisions and the reasoning, including rejected alternatives
- Sketches, with dimensions and annotations
- Test data: dates, conditions, trial counts, results
- Calculations, including the ones that showed a design would not work
- Meeting notes that record what was decided, not just what was discussed
- Photographs of prototypes, with captions explaining what is being shown
- Failures, root causes, and fixes
What Does Not Belong In It
- A narrative written after the fact to look organized
- Pages of pasted vendor catalog text
- Attendance logs and unrelated administration, unless your team's format requires them
- Screenshots with no caption explaining why they are there
Judges cannot tell what a photograph is meant to show. Every image needs one sentence: what it is, when it was taken, and what it demonstrates. "Intake v2 mounted on the test chassis, 11 Oct, showing the funnel angle we increased from 20 to 35 degrees" is a caption. "Intake" is not.
Paper or Digital
Both are used successfully. The format matters far less than the habit.
Paper is faster for sketching and harder to fake after the fact, since entries are dated in sequence. It is also easy to lose and hard to search.
Digital is searchable, shareable, and can hold photographs and CAD screenshots naturally. It is also easy to backfill, which is exactly the temptation to avoid.
If you go digital, timestamp entries as you write them and avoid silently rewriting old pages. Add a dated correction or follow-up instead so the sequence of decisions remains clear.
- Award descriptions and judging criteria are published each season: FIRST Tech Challenge Game and Season Info
Fill-in-the-Blank Practice
- A notebook entry describing a test should contain numbers rather than
__________. - Judges consider a notebook that records only successes to be less credible because it lacks documented
__________. - Every photograph in the notebook needs a
__________explaining what it shows and why it is there.
Show answers
- adjectives (subjective descriptions such as "fast" or "reliable")
- failures (or iteration, problems encountered)
- caption
Exercise
Open your team's current notebook. Find the most recent entry and ask: could a new team member, reading only this page, tell what problem was being solved and what was decided? If not, rewrite it. That rewrite is your first entry in the format the rest of this module teaches.
Ready to move on?
Only mark complete if you genuinely understand the material. Your progress will be saved in this browser.
Stuck on this lesson?
Ask about anything on this page. It can see which lesson you have open and which part you are reading.