Yeah, as a "T-shaded data folk" (have worked as a data analyst, data scientist, data engineer, and machine learning engineer, so I think I'm close to a full bingo care) in data, I agree!

I think the specialisms are really helpful for hiring - data engineering and data science involve a lot of different things so it's a lot easier to hire someone if you don't require skill in both.

That said, I think we have a culture problem in defining our roles narrowly, I've seen data scientists look down at data-pipeline parts of their job, and ignoring model latency and deployment; data engineers be deeply uncurious around what happens to the data after they put it in a warehouse; etc.

The best people I've worked with, within data and elsewhere, are the ones who are curious about every aspect of the stack, even if they mostly focus on one side.

I’ve come to see it as a consequence of the industry’s pivot toward every firm of every size becoming more enterprisey. The enterprise habit of using 3rd-party vendors in particular.

15, 20 years ago, me and my T-shaped skills could get by just fine with a database server, a NAS, and some frank conversations about priorities.

Nowadays it’s not enough to to know how to work with databases and files. There’s also all these platforms: databricks, snowflake, new relic, sentry, datadog, GitHub actions, prefect, dbt, kubernetes, cassandra, elastic, and on and on and on. Each brings a new set of idiosyncrasies, its own terms for things, its own enterprise integration headaches. It’s just a hell of a lot of knowledge to ask one person to cram into their head on top of whatever skills and domain expertise form the actual core of their job.

That makes sense for an enterprise. Enterprises have a lot of bodies to throw at the problem, so they can have an expert for each tool who’s available to support everyone else. And they like to have support contracts and SLAs, which you can get from à B2B vendor but not from the KISS principle. And they don’t mind great heaping piles of unnecessary and mutually conflicting abstractions because that sort of thing is just SOP for a large bureaucracy.

But if you want - need - a system that one person with T-shaped skills can reasonably fit into their head, this is not the way.

> Yeah, as a "T-shaded data folk" (have worked as a data analyst, data scientist, data engineer, and machine learning engineer, so I think I'm close to a full bingo care) in data, I agree!

Me too. There were no data engineers when I was a baby data scientist (15 years ago now).

I think that this was a terrible idea (the splitting out of roles). I remember once being asked in an interview if I was able to pull my own SQL or would I need an analyst. That kind of split always struck me as absurd, given that the only way to build a decent model is to know the data very well first..

> That said, I think we have a culture problem in defining our roles narrowly, I've seen data scientists look down at data-pipeline parts of their job, and ignoring model latency and deployment; data engineers be deeply uncurious around what happens to the data after they put it in a warehouse; etc.

I honestly feel like this is driven by the titles. I will note that most of the unsuccessful/bad data scientists I've met were the ones who only cared about the models. As I always said to people, I can run sklearn in a loop over model families if that's all you bring.

> The best people I've worked with, within data and elsewhere, are the ones who are curious about every aspect of the stack, even if they mostly focus on one side.

This is probably just a good signal in tech in general, some curiosity is really required to be successful in this industry.