Recently trends like no-code or low-code are coming into being. Slogans such as "Develop applications rapidly and intuitively through visual modeling" and "Making it surprisingly easy, fast, fun and impactful." As much as I like to see people taking part in the software building endeavor, I don't think that this trend is a guaranteed win solution. What is so alluring to no-code? Well, I think people have this misconception the only thing developers do, is generating code. By solving the code part, we can save time, money and frustration.
As a developer, I face challenges daily. The thing is, not all challenges can be solved with code. I think being a developer is more about problem-solving then crunching code.
For instance; When a client comes to us with an idea. We don't just execute it immediately without thought. Instead, we try to get the full picture first and ask the right questions. When all is digested, we can offer a better solution or a plan to realize it. This calls for the analyst in me. No keyboard was struck developing any code.
On other occasions, we have analyzed the problem, defined our boundaries, created code, released the solution, tested it and put it through quality control. The solution appears to be working at first but then an error arises from production; a user couldn't perform the designed task. By tracing back the steps of the user, we discover more about the problem. It seems they executed the task with an oversized unnatural input. The code was working correctly but the assumptions on the input were wrong. Hence, it turns out that the error wasn't in code, but in the specification to the user and assumption on the input.
The Team Player
Lastly, a developer should be a team player. Not only with a multidisciplinary team of designers, front-end developers and project managers. But also, with the client. The glue between those blocks should be empathy. As a developer not understanding the (business)problem you are trying to solve is risk number one. By working closely with your team, you can spot thinking errors. Again, no code was involved.
So, by communicating, analyzing and having empathy; solutions can be created as well. Using code wasn't part of that work. Only if we want to put a design into realization, we use code. By using practices like Test Driven Development or Design Patterns we already have building blocks and tested outcomes.
It's only a tool
Code is only a tool and like any other tool, it's only as good as the one that wields it. I've seen people create wonders of graphics with C (yes, the grandmother of all procedural languages) and I've seen people doing horrific things with C#. It goes back to the debate on which programming language is better than the other overall, without taking into consideration which one is best suited for the task at hand. The same goes for a no-code platform as a tool, do you use it because you know how to use, or because it's the best-suited tool for this particular project you're working on?
Finally, I think there could be a need for "visually modeling" and the rapid development of a dynamic application. But please understand that no-code doesn’t mean no-challenges. By putting a hard line between developing code and no-code, readers might think that no-code is a guaranteed win, but code is only a fraction of developing worthwhile solutions.