Passionate generalist conquering the web one project at a time. Whether authoring libraries for node, JS, PHP, or Rust, I am always on the lookout for better solutions to common problems.
Location
USA
Work
Lead Developer & Co-founder at corpscrypt, CTO at REtech
I didn't want to step on your toes, but here is my experience with the approach you are describing:
I have worked on multiple projects where no-code solutions initially looked like a faster way of achieving a POC (including ones where I was personally involved due to the fact that I co-authored the flow/no-code software as I should admit). In ALL cases one of the following happened:
Either it turned out that the wanted outcome ended up exceeding the capabilities of the tools at hand or it actually was sufficient but ended up being a nightmare after change requests came in.
The crux of what you are saying is basically: if the complexity is low enough, then no-code is a faster, less "boring" way of generating logic. But the problem is that if the complexity is low enough, then a scaffolding approach via the right framework is not only still way faster, but actually enables me to build out a stable version without starting from scratch if the concept prevails.
Of course there is the personal preference of what you consider "more fun", as I read between your lines. And that's fine. I don't want to discourage anyone from using what works for them. I also believe we need people that like to work like that in order to get technology to the point where it's convincing in the near future. But all that doesn't change the fact that I am willing to challenge the gist of what you are saying, and your article is the perfect example for that. It simply isn't an easier, faster approach in general - it's an approach that enables people to achieve something they otherwise couldn't. And while I am sure this fact will eventually change, as if now I am willing to bet that an experienced developer can outperform any no-code solution out there - whether the measurement is time, flexibility, stability or functionality as long as using the appropriate tools were allowed.
"But all that doesn't change the fact that I am willing to challenge the gist of what you are saying..."
I guess ultimately I'm wondering why you seem so invested in the need to "challenge" me?
I won't pre-suppose your intent, but your writing comes off very much like gatekeeping.
"...now I am willing to bet that an experienced developer can outperform any no-code solution out there..."
It just smells like the classic FUD response I see in response to no code.
"Well that's not how a real developer would do it".
I fear that puts off people with less experience, who might use these tools and grow into full-on developers later, because they feel like they're not "real" or doing it right.
I just don't see an issue with democratizing approaches like this, even for "experienced" developers.
Passionate generalist conquering the web one project at a time. Whether authoring libraries for node, JS, PHP, or Rust, I am always on the lookout for better solutions to common problems.
Location
USA
Work
Lead Developer & Co-founder at corpscrypt, CTO at REtech
Ok, so apparently I phrased that the wrong way: I don't want to challenge you in the sense that I think a no-code approach is "the wrong way" of going about things. I have just personally come to the conclusion that we are not there yet; meaning that these solutions aren't viable options for people who can actually code. At the same time, I realize that this will eventually change.
What I AM challenging is that this approach is a faster, easier or even more interesting approach in a scenario where you could achieve the same outcome in a "code solution".
And I think what you say about enabling more people to do things is completely accurate (not sure if I would call that democratizing, but let's ignore semantics), I am just under the impression that we need to be honest with the current state of technology:
Yes, when you cannot walk, it's amazing what you can achieve with a wheelchair. And I applaud good engineering in that respect. At the same time, I wouldn't state that a wheelchair is comparable to walking on your own feet. But I am fully aware that one day there might be a exoskeleton that will make using your own legs a less powerful solution.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I didn't want to step on your toes, but here is my experience with the approach you are describing:
I have worked on multiple projects where no-code solutions initially looked like a faster way of achieving a POC (including ones where I was personally involved due to the fact that I co-authored the flow/no-code software as I should admit). In ALL cases one of the following happened:
Either it turned out that the wanted outcome ended up exceeding the capabilities of the tools at hand or it actually was sufficient but ended up being a nightmare after change requests came in.
The crux of what you are saying is basically: if the complexity is low enough, then no-code is a faster, less "boring" way of generating logic. But the problem is that if the complexity is low enough, then a scaffolding approach via the right framework is not only still way faster, but actually enables me to build out a stable version without starting from scratch if the concept prevails.
Of course there is the personal preference of what you consider "more fun", as I read between your lines. And that's fine. I don't want to discourage anyone from using what works for them. I also believe we need people that like to work like that in order to get technology to the point where it's convincing in the near future. But all that doesn't change the fact that I am willing to challenge the gist of what you are saying, and your article is the perfect example for that. It simply isn't an easier, faster approach in general - it's an approach that enables people to achieve something they otherwise couldn't. And while I am sure this fact will eventually change, as if now I am willing to bet that an experienced developer can outperform any no-code solution out there - whether the measurement is time, flexibility, stability or functionality as long as using the appropriate tools were allowed.
I guess ultimately I'm wondering why you seem so invested in the need to "challenge" me?
I won't pre-suppose your intent, but your writing comes off very much like gatekeeping.
It just smells like the classic FUD response I see in response to no code.
"Well that's not how a real developer would do it".
I fear that puts off people with less experience, who might use these tools and grow into full-on developers later, because they feel like they're not "real" or doing it right.
I just don't see an issue with democratizing approaches like this, even for "experienced" developers.
Ok, so apparently I phrased that the wrong way: I don't want to challenge you in the sense that I think a no-code approach is "the wrong way" of going about things. I have just personally come to the conclusion that we are not there yet; meaning that these solutions aren't viable options for people who can actually code. At the same time, I realize that this will eventually change.
What I AM challenging is that this approach is a faster, easier or even more interesting approach in a scenario where you could achieve the same outcome in a "code solution".
And I think what you say about enabling more people to do things is completely accurate (not sure if I would call that democratizing, but let's ignore semantics), I am just under the impression that we need to be honest with the current state of technology:
Yes, when you cannot walk, it's amazing what you can achieve with a wheelchair. And I applaud good engineering in that respect. At the same time, I wouldn't state that a wheelchair is comparable to walking on your own feet. But I am fully aware that one day there might be a exoskeleton that will make using your own legs a less powerful solution.