Solve the Hardest 5% of Your Technical Challenges

Having the right mental model is really important for success in building really anything. But I think particularly in the world of no-code, low-code, where often we're doing things we've never really done before. And I think that when we're doing things we haven't done before, it becomes very easy to get frustrated. And that frustration is something I encounter a lot when talking to people about the hardest 5% of their projects. Usually the hardest 5% is something that is driving them up the wall. They've been stuck for days on it or what have you. What I have found about this psychologically is that the most important thing for us to do when we are feeling frustrated and we are pushing ourselves away from the desk and saying this thing isn't working, it's terrible, what have you, is we need to reverse our opinion. We need to ask, huh? We need to say how interesting this is. There's a wonderful book called The Game of Tennis which talks about, you know, needing to love the ball because that's something that brings it closer to you. And I think that the best way to express this idea comes from a classic Ted Lasso episode where he is playing darts, he's hustling darts, and he talks about a sign he once saw that he attributes to Walt Whitman, which says, "To be curious, not judgmental." And I think it's when we're curious that we start to look closer. And looking closer is really the most important thing I think we can do to be making progress, particularly when we're getting stuck. It needs to be not, oh, this thing is terrible for not working, but this thing is so interesting for not working. Why is it working this particular way? What is causing it to do this? And that curiosity really carries us forward to be able to then make progress because frustration makes us lean back. We create distance between ourselves and the problem. And that distance means that we don't want to solve it. We want it to go away. We want it to not exist anymore. But of course, it's gonna keep on existing absent our efforts. But when we're curious, we lean in. When we are interested, we move closer to the problem at hand. And when we move closer, we are able to make a lot of progress. And I think there are a few ways we can look closer in particular that help us make a special progress. And the biggest one I talk to people about is looking at inputs and outputs. I'm not really a coder by training. I'm more what some folks call a data scientist. And that means I think about data first. I look at what's going into a process and I look at what's coming out of a process. So I might look at, you know, okay, who's clicking and then what is actually happening? I would look also at if I were diagnosing something, I don't know, like this very Miro board, I would bring up developer tools. And I can, you know, let's see, do, and if I bring up developer tools, I can see inside what's going on with this particular application. I can find out what is attached to the window. I become curious about like what's, what's the context in which we are operating. And that curiosity of both looking at inputs and also finding out what's coming out front of the system of both what people are typing in, what the code is thinking about, and I'll talk a little bit more about that and using console.log in just a second, but also looking at not just like what the code's doing but also what the network tab is doing to find out what the communication is between this particular application and the server, because that often is the real input/output. What are we receiving from some other system and what are we sending to it? When we take this approach of looking at inputs and outputs, we start to string together simple things as opposed to one big complicated thing that's very hard to work with. And as a result, we get this series of Legos that we're working with. And the question is, how do they assemble? That can get us really, really far. We can think about each of these Legos as having an input and having an output. And that starts to shrink, right? We start to get our arms around it. It's not one big giant boulder. It's actually made of a bunch of pebbles. But sometimes there's a pebble, and that pebble is the problem. That pebble is like the key thing we're finding. And so how can we look inside either the boulder or the pebble? And there are tools that are available to us in all of these no-code, low-code platforms, but also there are tools that are available to us that, like the browser or the environments that we're in, allow us to make use of. So one of those is to do something like being able to insert somewhere along the way a little bit of custom JavaScript that might do something like, I don't know, I'm going to click on console here and I'll say alert. That did work well, right? And be able to get, start speaking back to us and creating events as we go along. But also to be able to identify things like, you know, what have I got for this particular button? And I can see this is a share and I have a button here, the type of button. And then I might find out, is there anything sort of interesting about it that I can work with in order to start to dial in, right, to how a page is working, to understand why it's doing what it's doing. And I don't mean to get too lost, like, in the technical details of it. The important thing is to find what are the tools that let you look inside to find out how it is thinking and what is the changes in the data as, as it moves through a given process or one of these Legos. If I were to look at, say, Xano, which is a backend tool that I use quite a bit. I can also look for like, what are the tools in here that allow me to see what the thing is thinking about at a given point? I will often tell people that when I'm using Xano, my favorite tool in all of Xano is this one that's called Stop and Debug that allows me to immediately see, like, look at a variable or look at an input or what have you, and it will just sort of stop and tell me what that value is. That can make a tremendous difference in terms of the speed at which I can diagnose things because it puts me in a position to be learning more about what's going on inside. Of course, there are more advanced debuggers that are also available inside, you know, XAML, many of the other tools you're using, but you don't need to use the most advanced ones. You just need to start looking. I find that to be the most important part. Now, we talk about inputs and outputs, we talk about looking inside these particular pebbles, but we can also look outside. And particularly when we have error messages, I totally recommend looking it up. I have been told that my 3 favorite words are "look it up." I'm saying it very frequently. I say it to my children, I say it to my colleagues, because I find that it puts us in a position to be gathering more more facts. And as we see errors that are happening, particularly as we started opening up like the, the dev tools like I was just talking about, or what have you, we start seeing those red lights, hey, something's not quite working. We can copy and paste that error message and drop it, you know, right into your address bar, and that will bring it up like straight into Google so we can look things up. So when we have an error of some kind, right, so if we have, you know, an error that's sort of sitting on here, we see an error blocked by client. What does that mean? I am curious about it. I will copy it and then bring it over to another tab and paste it. And now we can learn more about that particular error and be able to sort of drive down. You can see this is probably caused by like an ad blocker I've got. But the, but the idea is the more of those messages you paste in, the better it'll do. I'll say that Google's actually better at this than it was even a few months ago because since they started integrating Gemini into more of their search requests, as they're the responses they get from searches. They were able to summarize in ways that could synthesize more pieces of that error message. So even if there's no one page that knows about all of the error message, they could put things together and give you a few different resources that can be pretty helpful and then give you some ideas. The other thing that's available to you that wasn't available to me when I was working on trying to bone up on this is of course ChatGPT and other chat-based resources. This is where like Claude from Anthropic comes into play. This is where Gemini comes into play. You know, use whatever it is that is going to work for you. To do, but you're going to find that if you dump in something that's not working, dump in an observation, dump in a screenshot, you can often make some pretty good progress here. Now, the other aspect of all this is you can go ask someone else as well. You don't need to be just doing it yourself. You can also be asking for help from others. And I've made another video about how to ask for help, and I would encourage you to go down that particular road. But in the meantime, the biggest thing I can encourage of you is to be curious, right? To say, ah, this thing isn't working, and come back with, how interesting. Come back with, this is fascinating. Come back with, there's something weird here, I'd like to understand it. Here is a puzzle for me to solve. Most of this stuff is mechanical and can be solved. Some of the stuff is relatively novel and takes more creativity because you're actually breaking some relatively new ground. And you know, sometimes the exact route you're taking wasn't possible, and by being more curious about what you have, you're able to discover some sort of new path either yourself, together, or with the help of our good friend ChatGPT. But one way or the other, if we start by being curious, or rather if we respond to our frustration by being curious, we will make a heck of a lot more progress and we will be able to create more remarkable technology products. We'll talk again soon.