I think a big difference between ML and regular programming is how the components at scale make the systems viable. When I was learning computer science, it seemed quite intuitive to me that you would start out with assembly, then go to a C like compiler, then abstract that to a JIT/dynamic type language, and go from that to the UI. I could see how each step in the layer added value and presented its tradeoffs.
Contrast that to ML and even though I have done a large amount of work in it (in both university and in industry), I still can't fully appreciate how the building blocks interact to form an entire system. I find that I use intuition from other systems I have read about or implemented (e.g. decision trees and tabular data, ReLUs and images) to reason about the results in new systems and guess at better configurations and architectures.
Might say more about me, but I always found ML was a "start big and go backwards" deal whereas computer science was a "start small and go forwards" deal.
When building models it is useful to spend some time finding out what you already know about the problem. Things you yet don't know you know. This kind of knowledge will greatly simplify the model.
I see newcomers making this mistake very often. In industrial vision, for example, the newcomers like to create very complicated models. I then show them that the "box" you trained a entire model to recognize will actually always be there in this position for the camera, because it sits in a conveyor belt which restricts its lateral movement. The problem can simply be solved with simple image processing. Stuff like that happens all the time.
When I was working on a pet project to teach myself how to build a scoring model based on analysis of images on mobile I went down a whole rabbit hole on how to detect where the image is in a photo to draw a box around it and then compress to 500x500.
In reality, if I'm using a phone,I can just create a square frame for the user to center the image in and then compress.
Sometimes the simplest solution is the one you don't get to till after you slog through the harder approach. I'm glad I learned a bit about image processing with Pytorch along the way.
You let newcomers dick around for months with a net on an industrial vision problem? This stuff was solved two decades ago. Why didn’t you just tell them?
They usually don't take months. Would be optimal if I could catch them at the get go. Not what happens most of the time. When that happen most of the times you will se a manager who is not technical leading a group selected by "professional" recruiters. There is a lot of waste out there.
Many developers also mistakenly think their mighty dev super brain genius powers make them capable of accurately evaluating and critiquing any profession. I’ve had many developers try to explain design to me, even knowing I’m an experienced, educated professional designer. I can see why some might roll their eyes.
While I can understand your point, I don't think it was fair to assume that my case is like that.
This wasn't an issue of design. It was an issue of them not making decisions without good information. Trying to throw an fconv network at a task that clearly requires positional invariance (convnet was appropriate). They had never done ml before and didnt know anything about it.
Another one was going crazy with docker, and costed them a good year and a half. Idk why the boss insisted everything be behind docker. and i mean everything. He just thought containers were a selling point
Contrast that to ML and even though I have done a large amount of work in it (in both university and in industry), I still can't fully appreciate how the building blocks interact to form an entire system. I find that I use intuition from other systems I have read about or implemented (e.g. decision trees and tabular data, ReLUs and images) to reason about the results in new systems and guess at better configurations and architectures.
Might say more about me, but I always found ML was a "start big and go backwards" deal whereas computer science was a "start small and go forwards" deal.