111–120 of 144 posts
Earlier quoted context omitted.
no, this is routinely cited in introductory remarks these days, but ignores some practical aspects of the competitive context, among other things.
what is "this"?
And of course, there are hard fields outside of science. Being good at any kind of art is hard.
Just because some people believe they are good at something (because Dunning Krueger effect) doesn't mean that field is easier than ML. They assume ML is harder because they happen to know a few bits in a particular field and nothing about ML. Then, the same kind of people will learn some superficial bits on ML and think it's easy.
Any human endeavor done properly means time, sweat, critical thinking, determination. And lots of it.
Earlier quoted context omitted.
In software engineering you can test things in something on the order of seconds to minutes. Functions have fixed contracts which can be unit tested. In ML your turnaround time is days. That alone makes things harder. Further, some of the problems I listed are open-ended which makes it very difficult to debug them.
> In software engineering you can test things in something on the order of seconds to minutes. Functions have fixed contracts which can be unit tested. I think this only applies to a certain subset of software engineering, the one that rhymes with "tine of christmas". Implementing bitstream formats is an area I'm very familiar with, and I dance when an issue takes seconds to resolve. Sometimes you need to physically…
What?
Earlier quoted context omitted.
But aren't all science basically like this? If you know your hypothsis works before you do the experiments, it's not science anymore.
You are right. That's why you want to avoid doing science, when you can. Ideally, you want to be solving engineering problems instead.
I used to work on an ML research team. In addition to what the author mentions, there is an entirely separate issue: whether or not what you're attempting to do is possible with the approach you've chosen. Consider making an iOS app. For the most part, an experienced software engineer can tell you if making a given app is possible, and they'll have a relatively clear idea about the steps required to realize the idea.…
I used to work on an ML research team. In addition to what the author mentions, there is an entirely separate issue: whether or not what you're attempting to do is possible with the approach you've chosen. Consider making an iOS app. For the most part, an experienced software engineer can tell you if making a given app is possible, and they'll have a relatively clear idea about the steps required to realize the idea.…
You nailed where I currently stand. At my company I've been a jack of all trades but mostly software/dba work. My boss and I were very excited about ML when the hype cycle was taking off several years ago and completed a successful project. Fast forward to today, I got loaned out to another team that lost their data scientist, and for the first time in my career I'm having to say - "I don't think we can do what you w…
In general these are model identifiability issues.
Earlier quoted context omitted.
> In software engineering you can test things in something on the order of seconds to minutes. Functions have fixed contracts which can be unit tested. I think this only applies to a certain subset of software engineering, the one that rhymes with "tine of christmas". Implementing bitstream formats is an area I'm very familiar with, and I dance when an issue takes seconds to resolve. Sometimes you need to physically…
> rhymes with "tine of christmas". What?
Earlier quoted context omitted.
Here’s an example of something similar. Say you have a baseline model with an AUC of 0.8. There’s a cool feature you’d like to add. After a week or two of software engineering to add it, you get it into your pipeline. AUC doesn’t budge. Is it because you added it in the wrong place? Is the feature too noisy? Is it because the feature is just a function of your existing features? Is it because your model isn’t big eno…
All of these hypotheses will take on the order of days to check. OK, but you can check them, right? How is that different from a regular software bug?
Moreover, this kind of issues are usually related to the mathematical aspect of the model, meaning that you need to understand the theoretical motivation of things and check all operations one by one. Just this week for example I was dealing with a bug there where we were normalizing on the wrong dimension of a tensor.