I don't have any magical ability, he said. I look at a problem and if it looks like one I've done before, I think maybe the idea that worked before will work here. Nothing's working out. Then you think of a small trick that makes it a little better, but still it's not quite right. If I play with a problem and after a while, I figure out what's going on. This quote may sound like an engineer you know. It may sound like you, but in fact, this quote comes from the man with the highest verifiable IQ in the world. His name is Terrence Tao. He's a mathematician at UCLA. And in today's episode of Developer Tea, we're going to look at some of the principles of problem solving that you and I as software engineers share with Terrence. This interview was posted on UCLA's newsroom website. It was done back in 2006. And the interview is with Terrence. It talks about his many accomplishments. For example, he began to learn calculus when he was only seven years old. And the former chair of mathematics in this article states that Terrence wrote 56 papers of the course of two years comparing it to his own ability of writing about three papers in two years. By all accounts, Terrence is one of the most intelligent people in the world, if not the most intelligent person. But I want you to take a moment. Take a moment and imagine your perception of how the smartest person in the world might solve problems. It's easy to imagine that the smartest person in the world, Terrence or anyone else really, would be able to see the solution as if it's kind of forming before their eyes. And in fact, that was even Terrence's own perception of how smart mathematicians come to a solution as well. He calls it a eureka moment. But as you'll find out in this episode, that's not how Terrence at least thinks. It's not how he solves problems. Instead, his approach looks a lot like what you and I do in our software engineering work every day. We're going to talk a little bit more about that. Right after we talk about today's sponsor, Square. Today's episode is brought to you by Square. There are millions of sellers across the globe and I'm sure you have used some of these products that these folks are selling. There's millions of these that are using Square to run every aspect of their business. Many are looking for custom solutions. They're deeply connected, easy to use. This is where you, as a software engineer, come in. You can build your business or build an entirely new business, maybe a side business, by extending or integrating with Square using their free APIs and SDKs to build tools for sellers. Again, these are free APIs and SDKs. This will help you build tools that these millions of sellers across the globe can use. To check it out, learn more by going to developertea.com slash square. That's developertea.com slash square. Thanks again to Square for sponsoring today's episode. Here's another quote from Terence Tal. Most people faced with a math problem will try to solve the problem directly. Even if they get it, they might not understand exactly what they did. Before I work out any details, I work on the strategy. Once you have a strategy, a very complicated problem can split up into a lot of many problems. I've never really been satisfied with just solving the problem. I want to see what happens if I make some changes. Will it still work? If you experiment enough, you get a deeper understanding. After a while, when something similar comes along, you get an idea of what works and what doesn't work. If you're listening closely, you can hear a lot of the principles that we learn as best practices in software engineering. For example, not breaking work down too granularly. Don't work out the details. Instead, think about the long-term strategy. Have a plan of where you think you're headed. And then this quote and the quote before it, in fact, multiple times in this article, Terrence talks about using previous problems as a way of thinking about future problems, thinking about problems that are similar, using that experience, using some kind of model of a problem, and applying that model and changing some details about it. This is a very critical part of how Terry works. And then, Terry also talks about splitting problems up. We do this all the time by breaking work down into smaller chunks. He calls these many problems. And then he talks about testing something by changing things. See if it still works. We do this in our testing as software engineers as well. We provide multiple inputs to be able to verify that our software is working like we think it will. He also characterizes his work as a process of, let's try this. That gets me part of the way or that doesn't. Now let's try this. Oh, there's a little shortcut here. You work on it long enough and you happen to make progress towards a hard problem by a back door at some point. And at the end, it's usually, oh, I've solved the problem. If you're like me, this is a little jarring to read. It's a little bit mind-boggling to read that the, potentially, the smartest person on Earth solves problems by trying things. This is iteration at its core, trying things, see if it works, try something else and see if that works. Breaking work down into smaller chunks, using previous works who inform future work, using models and making adjustments or creating variants off of old solutions. These are all things that we learn are best practices in software. But if you're like me, you may have thought that the reason that these things exist are to help fill in the gap, to allow someone like myself who's not the most brilliant programmer on the planet. I certainly don't have a sky high IQ. I'm competent enough to build software, but for the most part, I'm mostly like other software engineers. But this process is not just to fill the gap. It's not to make up for some deficiency in the average. Instead, this is fundamentally a human process. Iteration, trying things out, seeing what works, using comparisons, breaking work down. These are human processes. They enable us not to patch our deficiencies, but instead to maximize our potential. It's important to recognize those kinds of fundamental principles that seem to apply regardless of the intelligence or the mental capacity of a given engineer or a set of engineers team. It's important to recognize those principles are not bound to specific cases. It is almost certain that you will benefit from this kind of thinking, from iterative thinking, from using previous models. It's almost certain that you're going to benefit from breaking your work down into many problems. I hope this UCLA interview with Terrence Tao is as inspiring for you as it was for me. It couldn't help but see so many of the practices that we adopt as software engineers in this interview. I hope that you are energized by this as much as I was. Thank you so much for listening to today's episode. Thank you again to today's sponsor, Square, head over to developertea.com slash square to learn more about building tools for sellers. If you enjoyed this episode and you want to miss out on future episodes, subscribe but also you can get a notification in our Discord community. It's one of the many things that we have in that Discord community. But the most important thing we have there is other engineers just like you, fostering conversations, fostering good questions to help you grow and learn in your career. Don't check it out. That's developertea.com slash discord. developertea.com slash discord. Thanks so much for listening and until next time, enjoy your tea.