Comment by lofatdairy | Hacker News Reader

Comment by lofatdairy | Hacker News Reader

I think no code/low code solutions certainly have a place, but the way they're currently designed is not necessarily helpful (I've worked on replacing integromat and automate.io solutions in the past). Those solutions are fine, for the most part, but they're main flaw is that in order to get anything done you have to integrate them with other tools/software, which means that you're limited by what parts of the api the developers exposed to the no-code. That and the abstractions they produce on the UI end can be confusing and difficult to navigate. That's less their fault and more of an outcome from being a shiny new tool trying to do everything, but it results in a solution that doesn't really work for the people who would go for a low-code solution in the first place.

A good model in my mind is Excel. The amazing part of Excel is that it can be used as a no-code tool, a low code tool, and extended with code macros. Even self-described non-coders who would otherwise be intimidated often use to extreme productivity. It's extremely visual, straightforward, and self-contained for the most part. The fact that it's so well documented as well is also hugely important. The no code solutions I've seen and worked with usually are fairly lacking in this regard, but excel has fairly clear documentation, the famous f1 key, and a support line[^1] which makes it a more default choice. The only problem is that integrating it with your other tools relies on either 3rd party plugins, a coder, or integrating specifically w/ other ms software.

[^1]: I had a professor state in a comparison between MATLAB and Python that the reason to choose MATLAB was that they had a customer support line. This wasn't a CS professor, so you shouldn't underestimate how much value is placed on talking to a human rather than RTFM by non-coders.

Can't believe I had to scroll this far down to see the first mention of Excel. I'm an Excel wiz turned junior dev. My biggest limitation usually was integrating with other software/systems, but power query actually covered a lot of use cases. Excel dominates that liminal space between software engineers and end users

Excel wizards who consider themselves non-programmers, end up with what I would consider programming skills.

And this is the rub with low/no-code solutions. To use them effectively, you have to have some programming skills already.

They are perfect for lazy programmers, but less so for "Citizen Developers". At least, I haven't come across any I was really impressed with as a "Citizen Developer" platform. I would happily take references to any I should check out that might succeed at enabling non-coders to build production solutions.

Honestly, I might be wrong, but in my experience the target consumers for no-code/low-code aren't the people completely intimidated by computers or navigating software in the first place. However, someone who wants to build a tool for themselves or someone else are not necessarily experienced enough to build it using code, and these seem to me to be the ones who are more likely to turn to a low-code solution. In the sense that using software someone else wrote, that has a UI and operates in a familiar way, is a lot more easier for many than writing code from scratch.

If you were trying to write a simple Python program, you'd need to know how to run it in the first place. This means you'd need to install Python (if you're on Windows then you need to add it to PATH which an entirely new issue). Then to edit the program you need an editor (thankfully Jupyter has made this a lot more trivial). If you want to do anything outside the standard library, you need to learn to use pip (hell you need to know what is considered standard and what's outside of that scope in the first place). Coding to me seems to some extent to be more than writing logic, but also experience with programming environments. Low-code solutions seem to be just a lower on-ramp. You still have the logic, but everything is self contained so you don't need the environmental experience. You're therefore limited by whatever is provided in that self-contained environment.

So while I may not have met enough people to really say, a lot more people can "code" than can write programs in the sense that they fundamentally can abstract the necessary logic, but are intimidated by the unfamiliar work flow. Citizen developers can be born from this demographic of people, but the problem is that the tools available are often too limited to stick with and don't allow for production solutions.

I'm not sure we're talking about different things.

> in my experience the target consumers for no-code/low-code aren't the people completely intimidated by computers or navigating software in the first place.

These tools are definitely not for them, I agree.

> Low-code solutions seem to be just a lower on-ramp.

Agree.

> a lot more people can "code" than can write programs in the sense that they fundamentally can abstract the necessary logic, but are intimidated by the unfamiliar work flow.

Not quite sure what you're getting at here. But - the way people talk about "Citizen Developers" is, it's the people who know the business logic really well, they know their tools really well also. Spreadsheets, web forms, even some databases perhaps. But not "coders" per se.

So you start with a person like this. They want to automate something using a no-code solution. Sooner or later, they're going to have to parse some input file, hopefully something structured like JSON or XML. They have to learn about parsing such files, which is by any measure a programming skill, even if they're using a no-code tool for it. They need to learn the principles of it to make it work for them. And thus:

> Citizen developers can be born from this demographic of people

At that point you're training a developer.

> the problem is that the tools available are often too limited to stick with and don't allow for production solutions.

This is also my experience. But if we imagine evolving all those tools out there to be production reliable, and flexible enough for whatever task... You still have to take on the journey of training a non-programmer to be a programmer of some stripe. You don't end up with the dream of non-programmers intuitively building production apps out of thin air.

Visual Basic I believe was born from the same idea, of making more intuitive tools so people could focus on the business logic, and less the fiddly bits of coding. But make no mistake, Visual Basic produced programmers, and not business people who built apps.

I think we're basically saying the same thing, but I suppose the confusion is mostly semantics.

>At that point you're training a developer.

I don't think this is necessarily the case, or even if it is, I see this as not a problem and even a perfectly acceptable situation. The goal overall is simply to take someone who wasn't originally hired to code, or someone w/ institutional knowledge but no traditional background in programming and empower/enable them to build production applications or tools. Whether in doing so they learn to write code or not is not really an issue one way or the other.

>They are perfect for lazy programmers, but less so for "Citizen Developers".

This was in your original comment and to what I was mostly responding. It seems to me that low-code solutions like Excel do indeed enable people who don't consider themselves programmers to build tools. To a certain extent no-code/low-code solutions like Squarespace do a similar thing, where someone without ever knowing what HTML or CSS is can still build a website, but obviously someone with additional experience would be able to make even better use of the tool. Basically my issue is that I think low-code solutions can actually be pretty decent and useful, but there are a lot of bad solutions out there and I obviously don't see them displacing coders. However, I wouldn't go as far to say that you need to train someone to program in order to make use of low-code solutions.

100%. Key thing is finding the right abstractions where the tool does enough to provide real value, but slots neatly into your existing workflow without requiring a bunch more work to actually integrated.

Reply on news.ycombinator.com