Most questions are answered by a filter: rows where something is true. Write the condition the way you would say it in English, and check the count after each filter. A filter that keeps everything or keeps nothing is the most common silent bug in analysis.
About 2 min of reading
Before this new lesson, one small question about the lesson you just finished. Recall it, do not look it up.
Filter the fruit rows to counts above 5 and count them.
Write the filter
Before you run it, say out loud what it will print. Then open the answer.
Break the filter on to prove it works
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.
Filtering on a column that is still a string compares text: '9' > '10' is true. Convert once when you load, filter on the real type, and the bug disappears. Convert at the edges, not in the middle of every condition.
Decide what a filter should do with a blank: keep it, drop it, or flag it. Python's None and JavaScript's null compare differently, and NaN is not equal to itself. An explicit rule beats an inherited one.
In Python, [r for r in rows if int(r['count']) > 5]. In JavaScript, rows.filter(r => r.count > 5). The condition reads left to right like the question you are asking.
Print len() after each step while exploring. '412 rows, 89 after the date filter, 4 after the status filter' tells you immediately if a filter is wrong. Without counts you build an answer on an empty set and it looks plausible.
Each filter feeds the next, so order matters for readability but not for the result. Keep each step in a named variable (recent, then valid, then expensive) so a reader can see what each stage means.
Each one is defined here on this site. Open the entry for the full definition and the other words it points at.