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 have to be honest: I always wondered about the usefulness of "no-code" flow tools. Either they are too primitive to be versatile, or too complex to save time. I therefore see them in the realm of "when you can think like a coder but can't code" target group. And looking at your example, I cannot help but wonder: if I run a cron and use a dev.to SDK to trigger the API to drop data into a simple file-based database, wouldn't I achieve what you showcase here much faster?
I therefore see them in the realm of "when you can think like a coder but can't code" target group.
That seems like a fairly reductionist take on the utility of these tools. There are plenty of examples of career "coders" taking advantage of the fast-iteration loop they offer.
if I run a cron and use a dev.to SDK to trigger the API to drop data into a simple file-based database, wouldn't I achieve what you showcase here much faster?
Well, sure, maybe. But how do you define: "faster"?
Faster by a few minutes? Hours?
Is it only faster because you have the tacit knowledge to quickly deploy distributed cron systems?
I can code too(Python, Go, Bash, and a little Node), and yes I could absolutely set up an API Gateway -> Lambda -> SimpleDB, or 100 other variations of "Cron 2.0".
But I don't.
Because it's just not interesting.
When I'm prototyping MVPs, building products, trying things out, making small bets, I want the fastest feedback loop I can possibly manage.
Spending a lot of time on boring business logic and low-ceiling automation just is not interesting or inspiring work.
This podcast is a great take on a coder using no code tools to be productive while saving effort to work on actually interesting things: indiehackers.com/podcast/149-greg-...
I'd rather spend a few hours on a weekend quickly building an MVP that fails fast, rather than spending time coding up everything by hand only to delay receiving the same data.
If an MVP gains traction, then you can start porting no code to code, if it actually makes sense or needs to scale.
At the end of the day, I'd rather save my energy for interesting problems, and deal with low hanging fruit quickly and with absolutely minimal technical complexity.
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 have to be honest: I always wondered about the usefulness of "no-code" flow tools. Either they are too primitive to be versatile, or too complex to save time. I therefore see them in the realm of "when you can think like a coder but can't code" target group. And looking at your example, I cannot help but wonder: if I run a cron and use a dev.to SDK to trigger the API to drop data into a simple file-based database, wouldn't I achieve what you showcase here much faster?
That seems like a fairly reductionist take on the utility of these tools. There are plenty of examples of career "coders" taking advantage of the fast-iteration loop they offer.
Well, sure, maybe. But how do you define: "faster"?
I can code too(Python, Go, Bash, and a little Node), and yes I could absolutely set up an API Gateway -> Lambda -> SimpleDB, or 100 other variations of "Cron 2.0".
But I don't.
Because it's just not interesting.
When I'm prototyping MVPs, building products, trying things out, making small bets, I want the fastest feedback loop I can possibly manage.
Spending a lot of time on boring business logic and low-ceiling automation just is not interesting or inspiring work.
I'm not solving any new problems, I'm not designing anything new or novel. I'm just creating more code to manage that doesn't actually have anything to do with core functionality.
This podcast is a great take on a coder using no code tools to be productive while saving effort to work on actually interesting things: indiehackers.com/podcast/149-greg-...
I'd rather spend a few hours on a weekend quickly building an MVP that fails fast, rather than spending time coding up everything by hand only to delay receiving the same data.
If an MVP gains traction, then you can start porting no code to code, if it actually makes sense or needs to scale.
At the end of the day, I'd rather save my energy for interesting problems, and deal with low hanging fruit quickly and with absolutely minimal technical complexity.
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.