What Learning to Code Taught Me About No-Code Development

05. 01. 2021 by Honza Pav

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.

Within the last three years, I started to learn PHP, later JavaScript and co-founded Nautie – an online research app built with code (made with Angular, Express/Node.js, MongoDB and I am not the one doing the programming). I have learned that programming is entirely different.

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?

1 – Computers Are Dumb. Deal with it.

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.

2 – Start with the Smallest Possible Task

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.

I counted the number of days between the dates. Assume it was 10. I created a loop function that ran 10-times. Every time, I took a started date and added the number of days based on the current iteration (in 7th iteration, I added seven days). In each iteration, I have saved the new date to an array. Afterwards, I iterated through the array and got the data from API for each day. 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.

3 – A function should only have a single function

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.

4 – The Modern Software Infrastructure is not a Monolith

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.

5 – Many fundamental concepts are the same in both worlds

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.

—

These were my findings from the code world that are very helpful in the land of no-code. Do I continue learning to code? Yes and no. I am more interested in the principles and thinking than specific languages. I would still love to master JavaScript, not only because of Nautie.

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.