A cartoon panda is presenting important data science findings to a group of colleagues. MidJourney 5
Today we are finishing our notebooks and sharing our final results.
Use the morning to finish your analysis and polish your figures and notebook. We will have presentations in the afternoon. You should avoid starting up new analyses in the morning: if you find yourself digging into new idea and analyses that you have not considered before today, you probably want to put a pause on that and go back to finishing up the stuff you have already started.
Todayβs agenda
| When | What |
|---|---|
| 10:00 to 11:45 | Step 10 and the write-up. Polish your figures and notebook. |
| 11:45 to 12:00 | Restart and run everything one last time, then push to GitHub. |
| 12:00 to 1:30 | Lunch. The notebook should be 100% done before lunch! |
| 1:30 to 1:40 | Settle, and get the first notebook on the projector. |
| 1:40 to 3:00 | Presentations, first half |
| 3:00 to 3:15 | Break |
| 3:15 to 4:15 | Presentations, second half |
| 4:15 to 4:30 | Close |
The morning: what βfinishedβ looks like
The list below is in order of value, and each item is worth more than the one after it. If you run out of morning, finishing the first three items properly beats starting all five items:
- Restart the kernel and run every cell from the top. Do this at the start of the morning, not only at 11:45. A notebook that runs only in the order you happened to write it is a notebook that will fail in front of the class, and you want to find that out at 10am.
- Step 10, Visualize. Take yesterdayβs figure and make it show the claim. Axis labels with units, a title that states the finding rather than naming the variables, and a legend if you used
hue=. Refining one figure beats starting a new one. - A markdown cell under every one of the ten workflow headings, which are listed on the final project page. Where a step was genuinely not needed, the cell says so in a sentence. An empty heading is the only thing here that reads as unfinished.
- The claim, near the top. Two or three sentences: what you asked, what you found, and what the finding rests on. Somebody who reads only that and looks at your figure should understand the project.
- Delete the wreckage. Every project accumulates cells that were a good idea on Thursday. Remove them. Your notebook is easier to present when it contains only the path you took.
The full description of the deliverable is on the final project page.
Handing it in
The notebook is due when you push it, before lunch on Friday. Leave yourself the last fifteen minutes of the morning for it, because this is the step that goes wrong under time pressure. There is nothing to submit after class.
- Put the project notebook in its own repository, not in your coursework repository.
- Keep the outputs. The advice in the GitHub session does not apply here:
nbstripoutremoves figures and printed output from every commit, which is right for coursework and wrong for a notebook whose figures are the point. Do not configurenbstripouton this repository. - Add a one-paragraph
README.mdnaming the team, the dataset, its source URL, and the question. - Push, then open the repository in a browser and confirm the notebook renders with its figures showing. GitHub renders
.ipynbfiles directly, so this takes ten seconds and catches the problem while you can still fix it. - Submit through the course form, also linked under Handing it in on the final project page. One submission per team, signed in with your UCSB account. It asks for the repository URL, an export of the notebook, and your slides if you made any.
Do not lose the notebook to a merge conflict on the last morning. Download the .ipynb from Positron, email it to me, and sort the repository out afterwards. The work is the thing that matters; the repository is how it travels.
The presentations
Twelve minutes per team, then three for questions. I will keep time and I will be strict about it, because the last team of the afternoon deserves the same twelve minutes as the first.
Present from your notebook. Scroll through it and talk. You have already written the structure, and rebuilding it as slides on Friday morning is work that teaches you nothing. If your team has already made slides and would rather use them, that is fine, but do not make them for the sake of it.
A twelve-minute walkthrough that works, every time:
| Minutes | What |
|---|---|
| 0 to 2 | The dataset. Where it came from, what one row is, how many rows, and why you chose it. |
| 2 to 4 | The question, and the two questions you set aside. |
| 4 to 7 | What the data needed before it could answer it. Cleaning, filtering, transforming, and anything surprising. |
| 7 to 10 | The figure. Talk the class through the axes before you talk about the finding. |
| 10 to 12 | The claim, what it rests on, and what you would do with another week. |
Everybody on the team speaks. On a team of three, one person can drive the notebook while the other two talk, and then take a section of their own.
The most interesting minute in most of these presentations is the one where a team says what went wrong. A column that turned out to be text, a grouping that produced a group of one, a question the data could not answer. Say those things. Everybody else hit the same wall and thinks they were the only one.
- Do not say βsignificantβ. You have not been taught a hypothesis test and you are not expected to have run one. Say a difference is large or small, and show the counts it rests on.
- Do not apologise for your project. Every project in this room was built in two days by people who learned pandas eight days ago. Present what you found.
After the last presentation
That is the course. You arrived on August 31st, and in nine days you have imported, explored, cleaned, filtered, sorted, transformed, grouped, aggregated, joined, reshaped and visualised real data, and then done all of it again on a dataset nobody chose for you.
Everything on this site stays where it is. The cheatsheets in particular are written to be returned to, and you will return to them.