As far as I know, I coined it for myself. It's possible I read it somewhere that I've forgotten and am not properly attributing it.
It's something that I've had to learn the hard way, but has recently really been instilled in me. For a long time I'd jump to trying to learn a technology designed to work in a domain (e.g., learn erlang to try and write a distributed system), and I'd wind up just spinning my wheels, because I'd be trying to figure out too much all at once.
Somewhat recently however, I wanted to get into ray tracing, and decided to use Go for my first attempt (a language I'm very familiar with, but not necessarily the best for the domain...though, it did make some parts of it easier!)
If I'd jumped right into trying to use cuda, I'd never have gotten anywhere with it, because I'd just be lost in trying to figure out all of cuda's idiosyncrasies.
Instead I was able to get pretty far with go, making a bvh tree, triangle meshes, textures, area lights, convolutional filtering. Once I'd gotten pretty far with it, I wanted to get some experience with k8s, and so I modified it to be able to run an arbitrary number of worker pods and send samples to an aggregation pod.
Now that I've gotten some good experience in the domain, I've started to rewrite it in c++/cuda, where I can now make some more educated decisions, because I spent the time learning the domain first -- I know roughly what I'm building.
Long winded way of saying I arrived at the saying because it's the only thing that's been effective for me.
That's the source of many questions on Stack Overflow: "I want to implement a [insert ML task here] but I don't understand [insert Python syntax here]".
Sometimes it is inevitable though, as in the example above. If you want to start with ML it makes more sense to start by learning Python.
I don't think that's strictly true. There are books/projects that one can do in other languages to get acquainted with ML -- there's nothing that _strictly_ ties it to python, at all.
Would it open doors? sure! -- and it may make more sense to invest in learning python first. But it probably makes sense to do that learning in some domain that you already know, so you can gauge how effective/correct you're being.
I'm sure there's some adversarial combination to be found where the mantra doesn't apply, but in practice, it's done me a world of good.
It's something that I've had to learn the hard way, but has recently really been instilled in me. For a long time I'd jump to trying to learn a technology designed to work in a domain (e.g., learn erlang to try and write a distributed system), and I'd wind up just spinning my wheels, because I'd be trying to figure out too much all at once.
Somewhat recently however, I wanted to get into ray tracing, and decided to use Go for my first attempt (a language I'm very familiar with, but not necessarily the best for the domain...though, it did make some parts of it easier!)
If I'd jumped right into trying to use cuda, I'd never have gotten anywhere with it, because I'd just be lost in trying to figure out all of cuda's idiosyncrasies.
Instead I was able to get pretty far with go, making a bvh tree, triangle meshes, textures, area lights, convolutional filtering. Once I'd gotten pretty far with it, I wanted to get some experience with k8s, and so I modified it to be able to run an arbitrary number of worker pods and send samples to an aggregation pod.
Now that I've gotten some good experience in the domain, I've started to rewrite it in c++/cuda, where I can now make some more educated decisions, because I spent the time learning the domain first -- I know roughly what I'm building.
Long winded way of saying I arrived at the saying because it's the only thing that's been effective for me.