“When you discuss languages it almost becomes like a
religious argument. But really a language is just a tool.
It’s like arguing, well, which one is better: a hammer or a
screwdriver? You tell me what you want to do with it and
I’ll tell you which one is better.”
But isn't this comment from a time, like 1984, when programming languages were quite domain specific. Can we not have coherent discussions about General Purpose languages, where we can actually say some languages are better than others, and while specific use cases should be taken into account; that it isn't quite like arguing which is better a screwdriver or a hammer? At this point a pipeline built on top of Stitch / Fivetran /
dbt is far more reliable than one built on top of custom-
built Airflow tasks.
I'd be curious if anyone who has used or integrated these products into their infrastructure could verify or comment on whether they are as effective as the author seems to suggest. If you hire a data engineer who just wants to muck around in
the backend and hates working with less-technical folks,
you’re going to have a bad time.
I'm not sure this was the intent, but I found this somewhat dismissive. I think communication skills are indeed important and being able to effectively explain technical considerations to less-technical parties (or parties whose technical expertise is not aligned with Data Engineering), but I have encountered in my own experience an active disregard for those considerations by data scientists as orthogonal to their needs at best or at worst, details for which they cannot be bothered. This is underscored by the notion that we, as Data Engineers, "muck around in the backend." We do, and we have to, and it helps to like it. 1) Machine Learning Productionization
2) Being a source of data expertise (consulting) with other
developers (working on services or the main product) in
the organziation
Regarding 1, while the author seems convinced that the ELT/ETL tooling and ingestion pipeline building can be taken off-the-shelf, I don't if it is as likely that there is the same kind of mature tooling for machine learning model deployment/integration. Though, I believe that is changing, slowly. Issues around the performance of Python and programs
written in it have far wider consequences than startup
time. During all the time any Python program is running,
its host machine is consuming power that typically depends
on pumping CO2 into the atmosphere. If most of that power is
wasted, the effects go far beyond extra money to buy
it, or to operate extra servers, or users who wait a
little longer. The carbon footprint of a Python program
that runs throughout a data center, or many data centers,
adds up.
There was an article earlier on HN about the energy consumption pattern of Bitcoin/Ethereum and presumably any blockchain that implements a proof-of-work protocol/scheme, and between that article and this comment - I've started to notice a growing unease (I am probably waaay behind on the uptake) about the "world-eating" capacity of software.