2 ms·

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 you

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.

rezonant 3y ago
> 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 haul a vendor's equipment to the lab. In broadcast we have this thing called "Interops" where tons of software and hardware vendors do just this, but in a more convention-esque style (actually is often done at actual conventions).
- rjmunro 3y ago
  > rhymes with "tine of christmas". What?
  - rezonant 3y ago
    line of business
p1esk 3y ago
I've been an ML researcher for the last 11 years. Last week I spent 3 days debugging an issue in my code which had nothing to do with ML. It was my search algorithm not properly modifying the state of an object in my quantization algorithm. Individually, both algorithms worked correctly but the overall result was incorrect. Looking back at my career, the hardest bugs to spot were not in ML, but in distributed systems, parallel data processing algorithms, task scheduling, network routing, and in dynamic programming. Of course I also had a ton of ML related bugs, but over the years I developed tools and intuition to deal with them, so usually I can narrow down an issue (like impacted accuracy, or training not converging) fairly quickly. I don't think these kind of bugs are fundamentally different from any other bugs in software engineering. You typically try to isolate an issue by simplifying the environment, break it down into parts, test on toy problems, trace program execution and print out or visualize values.

rezonant 3y ago

> 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 haul a vendor's equipment to the lab. In broadcast we have this thing called "Interops" where tons of software and hardware vendors do just this, but in a more convention-esque style (actually is often done at actual conventions).

rjmunro 3y ago
> rhymes with "tine of christmas". What?
- rezonant 3y ago
  line of business

p1esk 3y ago

I've been an ML researcher for the last 11 years. Last week I spent 3 days debugging an issue in my code which had nothing to do with ML. It was my search algorithm not properly modifying the state of an object in my quantization algorithm. Individually, both algorithms worked correctly but the overall result was incorrect. Looking back at my career, the hardest bugs to spot were not in ML, but in distributed systems, parallel data processing algorithms, task scheduling, network routing, and in dynamic programming. Of course I also had a ton of ML related bugs, but over the years I developed tools and intuition to deal with them, so usually I can narrow down an issue (like impacted accuracy, or training not converging) fairly quickly. I don't think these kind of bugs are fundamentally different from any other bugs in software engineering. You typically try to isolate an issue by simplifying the environment, break it down into parts, test on toy problems, trace program execution and print out or visualize values.