The Disaster Artist (or how to anticipate No-Code errors)

Some things are just inevitable, so we might as well be prepared.

The Disaster Artist (or how to anticipate No-Code errors)

I'll say it right away. Of course we've had some bugs on our site. I think it's inherent to web development. Doesn't matter if you are going for a coding or no-coding approach. It's something that happens and that helps you move forward.

Some of our errors, our bugs, have led us to some of our most exciting ideas and developments. So I would argue that the first thing you need to think when you are making software is that bugs and errors will happen, that you should embrace them, and that they are a road of opportunity.

But also, they can be incredibly frustrating.

So how can you be prepared for bugs? How can you find them and not be perpetually chasing your tail? Most of the people reading this are probably non-technical and are not familiar with any coding —or even No-Coding— jargon. And that's ok, we'll keep it simple.

Maybe the most important thing is to know properly the tools you are using. Some of you are already doing our Twitter replica course, in which we use Bubble —and if you're not, what's wrong with you my dude? sign up now!—, so let's use that as an example.

Do you have a problem with your conditions? with the workflows? Well, you can check that out in your preview page in Bubble. At the bottom of the screen you have a debugger mode where you can load your problem child step-by-step, slowly or normally. And this can help tons to see where things are going wrong, so yeah, we advice you not to sleep on that feature (maybe this is obvious to our most advanced users but, c'mon guys, a lot of people might be using these tools for the first time).

Also, to make the most out of that, it is very useful to have a mental map or flow of how stuff should work normally. Then, if something goes wrong, you at least know where to search.

Another thing that is very important, not only for bug detection, but for a successful development, is to understand really well "if-then logics", and conditional statements, in general. Many errors can come out of wrong statement's (writing something like 'user' instead of 'current user' or typing an e-mail address instead of something like 'current user's email'), so be sure to understand very well how to compose them.

One that many people struggle with (guilty as charged, here) is the naming and labeling of things when developing software. This one is so easy, and could prevent so much tears and frustration. It's just that: labeling every group, page, and style you create. Why is this useful? I'll tell you, Candace, just hold your horses. It might not seem like much, but if you are using the debugger, for example, and a bunch of stuff just looks like this: asdsfa, lñkj, ueiw, owwer, it will be a lot harder to track where the mistake is hiding. So go on, give some love to naming your elements. Future you will be glad present you did it.

So there you go. Our first batch of tips on how to handle bugs in no-code developments. Maybe as we move along, we might do more of this, in simple, plain, jargon-free language. Does that sounds good? Let us know!