People come across no-code development to build software of any kind even without proper programming skills. And yes, much can be without knowing servers, back-end programming languages, APIs and front-end frameworks.
But the more complex product you build, the more you need to think like a programmer. There is a misconception among non-programmers about what programming is what it’s not. Three years ago, my thinking was along this way: as a programmer, you learn programming languages, and you use it to write the app.
Yes, you need to know the syntax and rules. But it is more about concepts and way of thinking. What were the most important findings for me?
Computers are stupid. And you have to think for them. And think for all the possible ways it can incorrectly interpret your instructions. It is so dumb you won’t believe until you try. An example – imagine you see a number 5. But the computer does see only a string. No matter what’s your no-code tool stack, it is still built on top fo computers.
Every job the software does must be divided into the smallest possible steps. Otherwise, you can’t find a solution. Sometimes the solutions are both stupid and brilliant. Want an example?
In one of the last projects, I needed to get data from external API for each day between two given dates. It sounds like a single step, but you end up with five tasks after thinking it through.
When building something new, deconstruct the main task into the smallest possible instructions as if the computer was utterly dumb (see the first finding above). This law holds in the land of code as well as no-code.
In the code world, there’s a design principle called “separation of concerns”. It says that software should be modular. And to be modular, one part of the software should always do only one thing.
This concept is tied to hard-coding things in the software, which I understood as a bad programming habit. What is an example of hardcoding something in the no-code app?
In my Ninox CRM integration with Asana, I have multiple stages in the projects pipeline. Each stage in Ninox has its counterpart in Asana as a Project Section. At first, you might find it easier to create, e.g. a switch condition in the Integromat scenario. But I find it better practise to separate the list of stages into a table outside of the scenario. Here is the list of stages and section IDs stored separately in the database (here Airtable).
What are the pros? You can reuse it in other Integromat scenarios (or even in other parts of your no-code software). If you want to change the stages’ names, you change it once, and it will change for all future runs in all related scenarios.
Are there any cons? Yes, but it depends. The first one comes to costs. Any extra lookup will cost you Integromat operations. It is not a fortune, but it can add up, especially if your scenarios are not optimized. The second is a bit philosophical and is related to complexity – another tool in the stack makes the system more complex and therefore, more prone to errors.
As with everything, you need to balance the pros and cons.
Many times, if you hard-code something in your app, you need to repeat yourself (Don’t repeat yourself or “DRY” is another programming concept). If you need it just once or move fast in the prototype phase, I assume it’s perfectly fine to hard-code it.
When I started with no-code projects, I was feeling like cooking the no-code spaghetti. There is Airtable as a database or even handling some back-end logic. You have a Webflow, Wix or WordPress website that displays the data. You send emails as notifications. And Zapier or Integromat serves as a brain that holds the logic of the app.
Do you find it messy? Before having my little experience with code, no-code spaghetti made me uncomfortable. If you feel the same, get lost in reading about microservice infrastructure, Kubernetes or Single Page Applications (SPA). Seeing this in live projects made me confident about the viability of no-code infrastructure.
Switch, if clause, arrays, its functions and looping, error handling and so on. There so many concepts that would fit into programming 101 that is used in no-code development. You don’t need to know it before you dive into your no-code adventures, but your life will be brighter and software more resilient if you do.
I think the “code or no-code question” is not binary. There is space in between. Call it low-code or find a different fancy name, from what I am seeing, those two worlds are two sides of the same coin. And even though no-code is my way of doing things, I will benefit from having tools from the other side.
When building a project, how important is the tool stack? I believe that it will be less important in the future if your project was built with no-code tools. And we should acknowledge that now.Read more
In this article, I want to show that it is helpful to know programming concepts even if you plan to use only no-code tools. In the end, those are two sides of the same coin.Read more