Don't learn machine learning

Daniel Bourke argues that aspiring machine learning practitioners waste time choosing tools instead of picking a concrete problem first. He contrasts product-oriented work like building a real-time license-plate reader with research, showing they feed each other. Start with a clear goal, then learn the tools you actually need.
Chapters
Don't Learn Machine Learning. Pretty provocative title, right? You know, I read an article the other day. SK sent it to me from Twitter. So very, thank you very much, SK. And the article was titled with the same name, Don't Learn Machine Learning. Learn machine learning to build software products or something along those lines. That was the subtitle. The title was Don't Learn Machine Learning. Now, an important point to note is that at the top of the article, which is beautiful, I think this should almost be done with a lot of things. And I'm going to do it too. So that's why I want to bring it to your attention that the author notes that he builds products to, that allow you to use ML in software products. It's the, the don't ask the barber if you need a haircut problem, which is what I want to sort of get you to think about at the start of this video is because the don't ask the barber if you need a haircut problem is you have to be aware that all advice is going to be a little bit, even if it means well, and I'm sure all of it always means well, is it's gonna be a little bit tainted by the person delivering it. And so that's, you should know about me, is my disclaimer is that I'm someone who runs a business from a bedroom. I make videos, I write articles online, I use machine learning. My goal is to use machine learning in future products. So, that's the caveat. That's my background from there. Now that you know that, let's dive into the article. I'm not going to read it verbatim. I'll leave a link in the description so you can check it out for yourself. But there are a few points I'd like to just riff on because that'd be fun. It's a good article. Let's just put it that way. Let's put that first and foremost because I like reading these things. There's a little bit of confirmation bias from my end. But the entire article could be products or research? So, that's the question you need to ask yourself. Now, I get a lot of emails from people with a donkey problem or from donkeys. They have donkey syndrome. And now, I don't say this to be mean or malice. I say this with empathy because I have been in their position before and I also find myself in that position even though I know about the problem. Now, you might be wondering, what is the donkey problem? Well, let me tell you the kind of emails that I get. I go, Some people go, should I learn TensorFlow or should I learn PyTorch? And the other questions are, should I learn R or Python? And other questions are, hey, I want to get into machine learning, but should I learn all of the math and all the statistics and, and everything else and all the theory before I start to code? And of course it comes down to, to each individual's choice and necessarily neither is better than the other in terms of should you learn Python or R or TensorFlow or PyTorch, whatever. Learn whatever you need to allow you to get to the next stage of where you want to go. And this is the donkey problem. Have you ever heard the story of the donkey who was looking to the left at a bucket of water and looking to the right at a pile of food and then looked back to the left at the bucket of water, to the pile of food? And you know what happened to the donkey? The donkey died of thirst and starvation because all it did was just look, am I thirsty? Am I hungry? Am I thirsty? So that's— and where does this all relate back to the article? Well, the point in the article is products or research, and it goes to say, do you want to build products using machine learning such as an application that uses machine learning? Maybe something— the example, one of the examples in, in the article is a real-time license plate reader. So this car is driving and it's using machine learning, computer vision, probably a little bit of text processing, I'm not sure, to read the, the numbers on license plates. Who was that helpful for? That could be helpful for, for police. So do you want to build things like that where you use machine learning to solve some sort of problem? Or do you want to go to a university and research different ways to advance the underlying algorithms that, that are allowing that computer vision to, to, to take place. Because although they are one and the same, like one enables the other, and this is a big, big, big point, right? Uh, there is no real right answer. It just comes back to what do you want to do in terms of the, the computer vision to identify numbers on a license plate couldn't have occurred if it wasn't for the people researching to find ways to do that. And vice versa, when someone needs a product to be created that uses some kind of machine learning, it requires— if that product, that need comes about, it requires someone to research and find ways to do it. So you see here is this is where it's not— it's— you might be thinking that it's a trade-off, but really One implies the other. They both require each other to exist. Let me give you an example of where I've been stuck before, bouncing back and forth. I've wondered, I've considered, should I go back to university and learn, learn all the math behind machine learning? Should I dive deep into it? Or should I use machine learning to build some sort of product? And you, you don't understand, or probably maybe you do, maybe you can relate, how much effort I wasted Being a donkey, just back and forth, back and forth. Terrible, terrible waste of time. I should have just chose one and then adjusted as needed. When you break down a machine learning problem or project, I'm working on one right now. So this is like 60% of it is data collecting and making sure that the— creating data, making sure you have some sort of dataset. So a majority of it is that, like having some sort of dataset ready. 30% is writing code to sort of prepare and manipulate that dataset. And then 10%, maybe even less than 10% is building a machine learning model. Like I'm working on a 42-day project right now to replicate one of Airbnb's machine learning use cases. And most of it has been preparing the data, getting it ready to use machine learning. I'm using Detectron 2, which is a computer vision framework to do all of the backend machine learning behind it. Because why? I'm coming from the aspect that if I had, if I was Airbnb and I had some sort of problem to solve, such as when someone takes a photo of their room and uploads it to Airbnb, how can I detect the pieces of furniture, aka amenities, in that image and automatically list those amenities on that Airbnb room listing? So, that was Airbnb's problem. They thought, okay, yes, we have images being uploaded, I'd like to— we'd like to get some information out of those images. So the machine learning was a tool to solve that problem. But if we come back to breaking the project down, that problem would have never arisen if they didn't have the images being uploaded to their platform prior. And then of course you can't just upload an image and have the machine learning algorithm just do its thing straight away. You need to build— write some code to have the image uploaded. You need to write some code to have it stored in a certain way. Then you need to write the infrastructure to have the images loaded into a machine learning pipeline. Pipeline, then you have to have some code that, well, that's where your machine learning is, right? It's just that little, little model that you can call model.fit. In Detectron 2's case, you can just call trainer.train once you've loaded the data, that is. Then you need some code to load whatever the model predicts back into the application that the customer sees. So yeah, as you can see, there's a lot of different pieces of the puzzle going on here with any sort of machine learning project. It's not just the machine learning aspect of it. And that brings us into the, the second major point I wanted to bring up is the— well, that the article brings up as well, and I really love this point. As I said, there was— this article was a healthy dose of confirmation bias— is to learn by building. Now, if you're an engineer like me, you probably have the engineer's disease, which is learning tools for tools' sake. And I've been suffering from this illness for a long time. Well, I haven't really even been an engineer for that long, a couple of 2 and a half years, but I caught it really quickly. You know why? Because learning new tools is fun. But what happens is when you learn, say for example, a new machine learning framework comes out, like I've just— a whole bunch of stuff just got released with TensorFlow 2.0 and PyTorch, and I want to learn them all, frankly. There's TensorFlow.js for web, there's TensorFlow for Swift, there's everything, like all these new frameworks, and I'm just like, yes, yes, yes, give me frameworks. Yes, just, just absolutely frothing at all the new stuff coming out. But do you think— how, how have you gone when you've tried to learn everything? I can tell you I've gone terribly, right? So that's the engineer's disease, is learning tools for tools' sake. So what happens is if you're learning tools for tools' sake, what you, what you become is a a hardware store. You have all these tools on offer, like, anything you want, whatever you need. You need a 25-inch shovel? Yep, we've got that. You need a 15-pound sledgehammer? Yep, you got that. You need, you got a 300-pound hammer drill? I don't know where I'm pulling all these tools from. My tool is a keyboard. But you become this hardware store of just a collection of tools that are all waiting to be used, waiting for their potential to be fulfilled. Rather than an artisan's workshop in the backyard. Somewhere where in your workshop you've got a small amount of tools, you've got what you need, you've got a few things. In this case, it might be just one deep learning framework, it might be one programming language, it might be one database language. So, you just combine those three and you've got some sort of problem. Like, if you're working in your little workshop in the backyard, it might be to to fix the broken chair leg, that chair that your mother sits on for dinner, and it's been broken, and you're like, well, I'm going to take it to the workshop and use my tools that I know to fix it, rather than just circle around the hardware shop looking at everything, just trying to go, hmm, I wonder if I could use that 6-burner barbecue to fix my mum's chair. No, that's silly. You'd never use a barbecue to fix a chair, right? And so, it's the same thing. Or maybe you go to your workshop and you decided you want to build a little boat to take your lady friend rowing down the river. If you had too many options, you wouldn't choose any and you couldn't take your lady friend down, down on a nice riverboat trip. It's the same thing going— and now, I say this because I suffer from it too, this disease. I suffer from this illness too. I just want to learn everything rather than building something with it. So I mentioned the real-time license plate identifier, but there's also a radiology— this is what makes me disgusted in myself, is saying examples like this. So use me as an example. Use me as an example to work on your own projects. That's something I need to change. So there you go. You can use me as an example. Don't be like me. Don't be a donkey. The radiologist— there was an example on a blog post, on a different one, I'll leave that in the description as well. A radiologist from the Philippines built a machine learning application to identify— so a radiologist looks at x-rays, and he built a machine learning application that's a web-based one, so you can access it on your smartphone, which is amazing. That's where the world is going, right? Because everyone— more and more people are getting smartphones, they need to have access to to these things on their device that they have. And he built this machine learning application so you could identify, classify different types of X-rays. So if it's a broken arm, you go, "Oh, well that image," you upload that X-ray and it goes, "Oh, well that image, that kind of looks like a broken arm." And that, I love, love, love seeing. There is nothing more that I love than seeing that. And you know what? You know how he built the prototype? Not with some advanced coding technique or the latest framework. With— he built it with TensorFlow— no, Teachable Machine. I was about to say TensorFlow, but Teachable Machine. It might use TensorFlow behind the scenes, but requires no code to get started. You upload your data and labels in a fashion that is ready to be used. It's some sort of problem. His problem was, I'm looking at all these X-rays and my colleagues are looking at the same ones all the time, and I'm identifying a similar X-ray a lot of the time. So if I could train up, if I could use machine learning to help train up one of my colleagues or a new colleague and go, hey, well, we've seen, let's put our knowledge of what we know about X-rays into this application. Let's loop back. The whole, this, this, everything in this started from products or research. Now it's This is the— and avoiding the donkey problem. What I mean by that is being stuck between an abundance of options and choosing none. So, essentially just looking left, looking right, and going, "Huh?" The better way to do things is not necessarily products or research. It's to follow your own curiosity. Figure out, okay, is there a need of some customer or is there some problem that I can go and figure out? Rather than the engineer's disease of trying to learn every single tool and having a bunch of solutions that are just looking for a problem. Look for a problem first. For example, my current inspiration is I'm reading a book called Food Fix. You're going to hear me yap on about— I've yapped on about food and health in past videos. But I'm reading a book called Food Fix and I'm starting to realise, okay, there's a lot of issues going on in the world of how we get food. With all the technology innovations that we're doing, it's like people seem to forgot that we need food to exist. So, I'm starting to think, I'm using— again, it's not there yet, but the inspiration is there coming from the book is like, oh, could I try something? And what holds me back is going, Oh, I don't want to dedicate this effort if I know it's not going to work. But that's another part of the donkey problem, is looking at something and not trying it out of fear that you could be wrong, or that fear that your effort will be wasted. I get a lot of emails as well asking, if I do this, will my efforts be worth it? That's very— can you answer that question? Just try to predict what's going to happen, what you're going to do in a week. Were your efforts in the last week Worth it? Very hard to predict those sort of things. You must, you must know 99% of effort is wasted. So to wrap this all up, the question I'm gonna, I'm gonna leave you on is, or the takeaway from this, is if you're learning machine learning, figure out a what, then figure out a how, rather than in the reverse, because there's a lot of hows, but they're all looking for a what. So, one way to avoid the donkey problem is to go, "You know what? I'm gonna try this." This, whatever this is. It might not work, but I'm gonna try it out anyway. Then, the beautiful thing about it, if it doesn't work out, you know what doesn't work. One way you can do this and what I'm doing now, just as a little bit of skin in the game, and as I said, reminder, is I'm disgusted in myself I haven't built something that someone else can access like the like the doctor from the Philippines. So use me as an anti-role model in that case. But one project I'm working on right now is replicating Airbnb's amenity detection, and I'm spending 42 days doing it. The benefit of that is I spent 42 days doing it, I learned a lot, it's a lot of practical, a lot of hands-on. I'm trying to replicate or improve what they actually built in terms of using machine learning for a product. Worst case scenario, at the end of it, it's only 42 days. And if I wanted to keep going, well, I could go, well, I'm going to do it for another 42 days. So this is, this is what we're best at. We're best at exploring things, building toys, and seeing if eventually those toys become useful. So that's what I'll encourage you to do. What toy can you build that might one day become useful? The toy that's going to ignite your curiosity. How can you avoid being a donkey in terms of learning machine learning, learning anything? How can you Learn what you need to learn when you need to learn it. And the final question is, leave a comment below. What currently don't you know about machine learning? And how is that holding you back? So leave a comment below. Again, thank you SK for sending me the article. It was, it was a very good read. As I said, a lot of healthy confirmation bias. So take anything that I've said in this video as a grain of salt. If you do read the article, leave your favorite point below. And if you have anything similar to that sort of article, if you do read it, if you do check it out and you wanted to send it my way, you want to see one of these videos being made on it, please let me know. You can find any link in the description, all, ah, you'll be able to contact me. But as always, keep learning, keep creating, and I'll see you next time.
More from Daniel

Small Language Models (SLMs) Are the Future: Fine-Tuning AI That Runs on Your iPhone

Introducing Sunny - A MedGemma-Powered Skin Health Tracking App (Kaggle Competition Entry)

Benchmarking: NVIDIA DGX Spark & NVIDIA RTX 4090 | Part 4 - Comparing the results

Benchmarking: NVIDIA DGX Spark & NVIDIA RTX 4090 | Part 3 - Running LLMs on the RTX 4090

Benchmarking: NVIDIA DGX Spark & NVIDIA RTX 4090 | Part 2 - Formalizing the tests

Benchmarking: NVIDIA DGX Spark & NVIDIA RTX 4090 | Part 1 - Creating a series of tests

Local Multimodal RAG on the NVIDIA DGX Spark | Part 4 - Publishing our demo to Hugging Face

Local Multimodal RAG on the NVIDIA DGX Spark | Part 3 - Putting it all together


