HN user

mattexx

7 karma
Posts1
Comments12
View on HN

The best-case outcome of many efforts of data scientists is an artifact meant for a machine consumer, not a human one.

I posit this outcome is absolutely necessary for any data science project to be worthwhile in any organization.

In the case where the project produces a report and goes no further, you still need the data and code for reproducibility, one of the main principles of the scientific method [1].

In the case where the project gets handed off to engineers to re-implement, reproducibility is even more critical, since the engineers best effort to reproduce the code will almost certainly not be successful the first time, and you will need to validate many versions of the production model. Doing this by hand even once it wasteful, doing so many times is tragically so.

In the case where the data scientists can produce a service worthy of production use, kudos!! But understand the caveat that in truly big data or big compute flows, this outcome remains highly unlikely.

[1] https://en.wikipedia.org/wiki/Reproducibility

+1. We review pretty much all code at Climate Corp (even science code) but code review seldom reveals design flaws. I still think code review is incredibly useful. It makes all of us better coders. It just isn't everything.

There were plenty of RVs on Duboce under the 101 in the Mission when I worked there ~2010. And on International Blvd when we left Oakland last year. I'm sure there are plenty of other undesirable neighborhoods around the bay area. Not that I'd recommend it...

Peer review is a huge part of our culture here at Climate. It's often unreasonable to expect a single reviewer to review a complex paper, so we sometimes address this by assigning each reviewer a domain.

Something like:

Reviewer 1: Review scientific theory (domain expert)

Reviewer 2: Review scientific methods and conclusions (senior scientist)

Reviewer 3: Review code for scientific accuracy (senior programmer)

Try Three Times 11 years ago

I agree that using exceptions as flow control is b-a-d. This is an easy fix in this case, set `:throw-exceptions false` in your http call and check the status code, rather than catch exceptions.