28 ms·

> Either learn a new technology or a new domain. Don't try to learn both I like that one, I'd never heard of it. Thanks! Is this attributed to someone in parti

> Either learn a new technology or a new domain. Don't try to learn both I like that one, I'd never heard of it. Thanks! Is this attributed to someone in particular? Where did you come across it?

danielmarkbruce 5y ago
It's similar to "take technical risk or product risk, not both" with respect to starting a company. It's incredibly stupid to take both risks.
chrsig 5y ago
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.
- selcuka 5y ago
  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.
  - mattkrause 5y ago
    The trick is that you should learn either enough ML or enough Python first, so you can identify where the problem lies.
  - chrsig 5y ago
    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.

> Either learn a new technology or a new domain. Don't try to learn both I like that one, I'd never heard of it. Thanks! Is this attributed to someone in particular? Where did you come across it?

danielmarkbruce 5y ago

It's similar to "take technical risk or product risk, not both" with respect to starting a company. It's incredibly stupid to take both risks.

chrsig 5y ago

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.

selcuka 5y ago
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.
- mattkrause 5y ago
  The trick is that you should learn either enough ML or enough Python first, so you can identify where the problem lies.
- chrsig 5y ago
  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.