111–120 of 327 posts
I think the biggest problem with this approach is at some point, they necessarily reach a level of complexity that it takes the same amount of time to learn how to use their "no-code" tools than it does to just learn how to code.
Can someone help me understand the no-code movement and what supposedly has changed in the last few years? I know Microsoft tried to allow non-developers to create apps without developers, and they have been trying for decades. But failed! They built an app that allowed you to drag and drop blocks, and they tried a visual query builder(not sure what the exact name was) for SQL. They added a workflow builder to ShareP…
I feel the view of ‘no code / low code’ is a bit primitive here. It used to be like that but last 3/4 years, the entire thing paradigm has changed fundamentally.
I think the biggest problem with this approach is at some point, they necessarily reach a level of complexity that it takes the same amount of time to learn how to use their "no-code" tools than it does to just learn how to code.
It works best for prototyping and rapidly testing ideas. I joined a startup that didn't have any deep coding skills - but had a great idea and vision for a product. They had made a pretty decent prototype with Bubble and could quickly implement suggestions from the beta testers. When I joined I instantly suggested re-writing it in a "real" stack. But when I dived into it, there was a lot of built in features of Bubbl…
I'm guessing many people would get this right up until the last step and see how much juice they could squeeze out of the prototype which I would imagine could be fatal in many cases.
I still wouldn't suggest this route for anyone.
Earlier quoted context omitted.
People (especially the kind that hangs out in HN) dont seem to understand that there’s a vast ocean of fairly smart people, much smarter than the average (or even above average) programmer, who are unable to build what they can imagine because of the coding bottleneck. I know many, and it’s not for a lack of significant effort that they are not able to learn to code in a way that’s meaningful. I suppose there’s somet…
In life sciences the people are smarter than any developer but software is IT-captured so all they can work with is Excel. No code is meant for these people. Software developers will never deliver what life sciences needs without no code.
Let me guess, you are one of the brilliant ones.
I've met some dim people in science research tracks.
I think the biggest problem with this approach is at some point, they necessarily reach a level of complexity that it takes the same amount of time to learn how to use their "no-code" tools than it does to just learn how to code.
Well, learning how to code is not the only issue. Tooling installation, deployment etc is, at least for me, even after having written code for almost 40 years, a huge annoyance. I want to think about problems and logic; I couldn't care less about what editor I use or any of that and I care even less how it's deployed. As long as it's up and fast, I don't care. And this is still not that simple still, after all these…
A vast majority of our day is spent focusing on the business end.
Earlier quoted context omitted.
People (especially the kind that hangs out in HN) dont seem to understand that there’s a vast ocean of fairly smart people, much smarter than the average (or even above average) programmer, who are unable to build what they can imagine because of the coding bottleneck. I know many, and it’s not for a lack of significant effort that they are not able to learn to code in a way that’s meaningful. I suppose there’s somet…
In life sciences the people are smarter than any developer but software is IT-captured so all they can work with is Excel. No code is meant for these people. Software developers will never deliver what life sciences needs without no code.
That's not really proving your point about them being "smarter than any developer". Lots of developers are smart enough to build their own tools.
I think the biggest problem with this approach is at some point, they necessarily reach a level of complexity that it takes the same amount of time to learn how to use their "no-code" tools than it does to just learn how to code.
How does it work for Excel?
I think the biggest problem with this approach is at some point, they necessarily reach a level of complexity that it takes the same amount of time to learn how to use their "no-code" tools than it does to just learn how to code.
It works best for prototyping and rapidly testing ideas. I joined a startup that didn't have any deep coding skills - but had a great idea and vision for a product. They had made a pretty decent prototype with Bubble and could quickly implement suggestions from the beta testers. When I joined I instantly suggested re-writing it in a "real" stack. But when I dived into it, there was a lot of built in features of Bubbl…
I believe no-code is incredibly underrated by many early stage startups. Rewrite only once you found your PMF and there's a real performance issue (or other technical reason), just you like you did.
One of the best thing about no-code is that you avoid painful, timewasting continuous refactoring while trying to iterate on your products the first months. It's much easier to design & structure the code to be as close as possible to the business (DDD-style) when you write it from scratch after reaching PMF.
Being able to iterate fast early on is such an important part of startups. I think code is not great at this.
The name is a good representation of times we live in. I wonder if this is a sign we are nearing the top of the current bubble.
I think the biggest problem with this approach is at some point, they necessarily reach a level of complexity that it takes the same amount of time to learn how to use their "no-code" tools than it does to just learn how to code.
So if you don't know if a particular task will grow to that level of complexity, it is probably better use of resources to use a nocode/lowcode solution until it is clearly insufficient, and then take the pain of migrating to code.