i-am-charmander

That's why you go through the process of validating your model (in the example you provided, checking for multicollinearity), remedying any issues, and then using the model.

Modern software often adds very useful layers of abstraction onto existing processes and patterns. This is especially the case in the realm of machine learning software. Libraries like scikit-learn, Keras, and many others are outstanding pieces of work, and make it very easy to rapidly build and deploy ML models. However, this ease-of-use can actually be a detriment, especially to ML newcomers.

In particular, it is so easy with these types of ML libraries to do something like `from sklearn.linear_model import LinearRegression; model = LinearRegression(); model.fit(Xtrain, ytrain)`. This is great if you're trying to scalably test many different algorithms and configurations to see what predicts best. This is not so great if you're looking to test and validate some of the statistical assumptions of your model, especially with linear/logistic regression models. As an example, Python's StatsModels library will automatically warn you if certain assumptions of a linear/logistic regression model are violated/close to being violated, which could led to inappropriate conclusions/inference from the model. scikit-learn does not do this. If you have massive multicollinearity in your model (a phenomenon which can affect the reliability of individual-coefficient t statistics and the signs, positive or negative, associated with the coefficients), scikit-learn won't tell you that, and it will be on you to recognize the potential for multicollinearity occurring and remedy the issue.

Not to pick on scikit-learn, but their linear_model regression classes also don't provide p-values and standard errors associated with each predictor, common things that basic statistical modeling packages usually provide. But note that scikit-learn's goal is to provide an easy interface with which to do machine learning - not traditional statistical modeling. The ML community is known for placing emphasis on raw predictive performance of models and forgetting about validating the statistical assumptions associated with those models.

A culture with a major component being the consumption of alcohol does not escape advertising, FWIW.

A family member of mine basically smoked away her future, in a sense, throughout middle and high school. She wasn't always the brightest candle in the box, but the heavy marijuana use certainly didn't help. She has the cognition and mental maturity of a 14-year old, now at 30 years.

Seeing how it affected her prompted me to "take a hint" and I've avoided the stuff since. That's not to say I avoid alcohol at all, however, but my family seems to handle the latter much better.

Edit: this is complete anec-data - I don't have any hard-and-fast evidence of long-term impairments like I describe above. Just what I've seen.

"Production notebooks" should not be a thing... Unless prefaced by a bold RUN ALL.

I understand that, but my point is good luck doing a lot of that "statistics-based data science" using just SQL.

Comments like this reinforce the idea that data science is too broad a term. Everything data-related is thrown into the "data science" bucket.

You describe what I'd call business intelligence or even advanced analytics. SQL jockeys (not a pejorative) really slicing into the data and presenting it in meaningful ways. There's usually exists some science behind these exercises.

Then there's machine learning, which also gets clubbed into the data science camp. Try capturing a convolutional neural network in SQL - you might go bald from pulling your hair out. It's totally not the tool for the job.

While perhaps any half-decent software engineer could maneuver his/her way around the great ML libraries out there to produce a CNN (or something of the like), I would hesitate to give them a project that involves true science (bring out your pitchforks). Experimental design, hypothesis testing, etc. While being a SQL expert could help turnaround time and enable you to test more interesting hypotheses, I wouldn't leave most DBAs to develop and carry out an experiment.

So I guess my point is "data science" is too broad and overused a term to be meaningful.