You Don't Need a Math PhD for Data Science — You Need to Stop Skipping the Boring Step

A developer argues that data science success depends less on advanced math and more on disciplined data preparation, citing examples where vague questions, silent row loss in joins, and inconsistent data types led to flawed analyses. The post emphasizes checking row counts, data types, and assumptions before modeling.

Ask someone switching into data science what worries them and it's almost always the same thing: do I know enough math? So they spend weeks on gradient descent derivations and eigenvalues before they've ever wrangled a messy CSV. Then the job starts, a real dataset lands on their desk, and it turns out the model was never the hard part. The hard part is everything upstream of it. Framing a vague question precisely enough to answer it. Checking whether the data can actually support that answer. Noticing the assumption that breaks silently instead of throwing an error. None of that needs research-level math — most of it doesn't need statistics at all, just the discipline to check before trusting. It needs the willingness to slow down exactly when it's tempting to jump to the model, because the model is the part that feels like progress. Three moments from a fairly ordinary analytics project show what that looks like in practice The question shows up vague, and STAYS vague A stakeholder asks "are our customers happy?" — which is a request for a feeling, not something a query can return. Happy compared to what: last quarter, a competitor, what they expected at signup? Which customers — everyone, or just the ones active in the last 90 days? Measured by what — a survey score, a churn rate, or support-ticket volume, which could reflect a product bug as easily as unhappiness? The junior move is to pick a metric and start coding. The useful move is rewriting the question until two different analysts would agree on exactly what to compute — same population, same comparison point, same metric — even if their pulls differ by a rounding error. Nobody drills that rewrite explicitly; it doesn't sit next to "regression" and "clustering" in a syllabus, but it decides everything that follows it. Somewhere in the pipeline, rows disappear and NOBODY notices Say the next step is joining an orders table to a customers table: merged = orders.merge customers, on="customer id" print len orders , len merged 48,201 → 44,987 Three thousand orders just vanished — every one with a customer id that didn't find a match on the other side. They might be test accounts. They might be guest checkouts. They might be exactly the segment the analysis was supposed to describe, quietly deleted by an inner join before anyone got to look at them. merge doesn't warn either way; a silently biased dataset and a clean one produce the exact same "no errors" console output. The only defense is checking row counts before and after every join and being able to explain any drop. Data type problems hide the same way. A column named signup date sounds unambiguous right up until .dtype returns object instead of datetime64 , and a sample of five values turns up '2024-01-15' , '01/15/2024' , '2024-15-01' , and 'Jan 15 2024' sitting in the same column — three years of manual entry, a spreadsheet import, and an API migration, never reconciled. 01/15/2024 alone is ambiguous between January 15th and an invalid 15th month, depending on which locale wrote it. Parse that carelessly and some rows land on the wrong date, quietly skewing any monthly bucket or tenure calculation downstream. Catching it costs about five minutes: check .dtype , then eyeball a random sample of raw values before trusting what the column name implies. Skipping it costs a wrong number that someone else finds later. Say the next step is tagging orders with any promo code they used, to break out revenue by month: revenue by month = orders.merge promotions,on="order id" .groupby "month" "revenue" .sum reported total: $1,284,000 — actual total: $1,061,000 If even a handful of orders matched two promotion rows instead of one — a coupon logged twice, a duplicate entry from a batch re-run — the merge doesn't collapse them, it repeats that order's revenue row once per match. The total comes out $223,000 too high, and nothing about the output looks wrong: no error, no null, just a bigger number than reality. The fix costs nothing statistical — it's checking that the row count and the total after a join still match a number you trust from somewhere else, before either one gets reported. None of these three moments required anything past intro-level statistics — most required none at all. Each one involved noticing something easy to miss and choosing to stop and check it rather than push on to the modeling step, which is the part that actually feels like work. That's closer to the real shape of an entry-level data science job than most course outlines suggest — the algorithms are documented, implemented, and one import away in scikit-learn; the dropped rows, the ambiguous date format, and the inflated total are not, and they're what a hiring manager is actually screening for whether or not the posting says so. For anyone building toward a first role, that argues for a different practice list than "learn another algorithm": None of it is glamorous, and none of it shows up as a line on a certificate. It's also the difference between an analysis that survives a second question from a skeptical stakeholder and one that quietly comes apart the first time someone re-runs it on next month's data. SophiArch's Intro to Data Science course https://lms.sophiarch.com/courses/intro-to-data-science?utm source=dev.to&utm medium=referral&utm campaign=boring-step-data-science is built around exactly this — not another pass through the algorithm list, but deliberate practice framing questions, auditing data, and catching this class of mistake before it reaches someone else's desk.