Before any analysis, spend two minutes describing what you have. Row count, column types, and a few sample values catch a wrong file or a broken column before they corrupt a conclusion. Skipping this step is the most expensive shortcut in analysis, because the error it hides is invisible later.
About 2 min of reading
Describe the fruit rows before computing anything.
Count and sample
Before you run it, say out loud what it will print. Then open the answer.
Check the key is unique
Before you run it, say out loud what it will print. Then open the answer.
Read the first example one line at a time. A line that prints shows what appears on screen; the rest set things up quietly.
Before the first look, write the row count and the columns you expect. Comparing expectation to reality turns the description into a test. Without the expectation, everything looks normal and nothing is checked.
If one row should mean one thing, the key column should have no duplicates. Count distinct values against the row count. A mismatch means duplicated observations, and duplicates double count every total you are about to report.
Print len(rows), the first three rows, and the last three. That is enough to see the shape, the ordering, and whether the file is truncated. It takes ten seconds and it catches most file level mistakes.
For each column, print the type of one value and whether every value parses as the expected type. A column of IDs that is sometimes blank or sometimes text is a bug you want to find now, not after the grouping.
Min and max per numeric column. A percentage that goes to 400, an age of 1970, a date in the year 1026 all show up here as absurd ranges, and each one is a data entry bug worth finding before the average is published.
Each one is defined here on this site. Open the entry for the full definition and the other words it points at.