Last week, Luke Posey published an opinion piece called Machine Learning Engineers Will Not Exist In 10 Years. The punchline is that machine learning (ML) will transition to a commonplace part of every software engineer’s toolkit, and that eventually, software engineers will — essentially — do the work of today’s machine learning engineers. However, it’s hard to imagine a world where software and machine learning engineers merge, and I’ll unpack why in this blog post.
Before getting to the main point of disagreement, it’s worth saying that Luke makes some great points with which I agree, particularly when it comes to the variety in job titles and in responsibilities of the role of machine learning engineer.
Across Dataiku, we interact with hundreds of data professionals across all kinds of industries and organizations, and it’s true that the differences we see in job function between companies for people with essentially the same job title are often staggering. To be fair, given that many enterprises have only started seriously ramping up machine learning efforts in the last five years, there’s still a lot of volatility and overlapping, so we see this with lots of job functions — i.e., it’s not unique to ML engineers. For example, it’s also true for data scientists as well as data architects, who increasingly in some companies are so specialized that they are more likely called ML architects.
The trend for specialization will continue to go on with this ML ramp up. Indeed, even if unicorns with wide and deep sets of skills exist and have key contributions, organizations do not scale with unicorns.
And yes, at the end of the day, machine learning engineer — just like data scientist or any other title — is only that: a title. However ...
Software Engineers Will (Probably) Never Be ML Engineers
At many companies, software engineers play a role in the machine learning lifecycle already. For example, they often integrate machine learning models into the company’s applications and systems or ensure that machine learning models work seamlessly with other non-machine learning-based applications.
So I do think that all — or at least a large portion of — software engineers will likely need to have some exposure to or experience with machine learning models in the future, and conversely, ML engineers will have to master part of the DevOps methodology of software engineers. However, I truly don’t believe that software engineers will completely replace or outmode ML engineers in practice for two reasons:
- ML engineers are oriented toward operations in a way that software engineers are not trained to be, simply because the operation of ML models requires more monitoring.
- Software engineers fight against non-determinism; that is, by nature, they want complex software that can be used in many different ways to run in a predictable way, with invariants. On the other hand, even if ML models have a simpler interface, ML engineers have to embrace the fact that they only have statistical invariants; so in a way, it’s harder to check that the model behaves as expected.
The Subtle Nuance Between Software and ML Engineers
As Luke addresses in his counterpoint section, machine learning is, indeed, a relatively nascent field when it comes to its maturity in the enterprise. Today, the vast majority of companies have less than a handful of machine learning models in production, so it may be hard to imagine why the monitoring portion (also known as MLOps) of the ML engineer role is so important.
However, in 10 years, it’s feasible that companies will have hundreds — perhaps thousands — of machine learning models in production. At that point, it becomes critical to ensure continued quality of those models that someone (likely an ML engineer) is continually monitoring and adjusting for performance.
So while yes, software and ML engineers do have many overlapping sills, I think their subtle differences are important enough — and things like model monitoring critical enough, only to become more so in the next 10 years — to warrant a separate, focused role.