[markmiro]

I like to think of the no-code stuff like this:

- People who are into this stuff know there's something to it, but as a movement, we don't know exactly what it is.

- My personal feeling is that any no-code tool should be useful enough that I would use it. I want some no-code to make me feel for my career a bit.

- The "threat", I think, is very real. For example, whenever I see myself following a set of rules to write software and not thinking, I start to wonder if some abstraction is lurking in there. Maybe the solution is a programming library, but increasingly, I think there's opportunity for this stuff to be more visual.

Why visual?

- UI programming is necessarily visual, and a visual tool for building interfaces makes sense

- Tools around managing software development. GitHub is IMO a no-code tool. VSCode is. Many IDEs are.

Why not visual? Algorithms and business logic. Like the author, I'm unconvinced that flow diagrams will provide enough flexibility to be useful for all but the simplest cases.

I guess my feelings aren't that different from the author's but I think the difference is I'm optimistic that the movement will be generative.

[jimbokun]

I don't think your career is any danger from better tools. (At least short of full-AI, which would put every career in danger.)

All kinds of amazing visual interface building tools have been created, that are very easy to use, easy to teach, easy to get started, and are very powerful. I'm still not sure that a better UI development tool than Hypercard has been invented yet.

So why do professional programmers still exist? Because most people don't want to do even that level of software development. Either they find it beneath them, find it boring, get frustrated when they want to do something that stretches the tool's capabilities, don't want to be responsible for fixing bugs and maintenance, etc. etc. etc.

It's not that most professionals are not smart enough to be programmers. It's that they dislike it enough to pay someone else to do it for them, or would just rather focus their time doing other things they enjoy more or believe to provide more value.

[scroot]

> So why do professional programmers still exist? Because most people don't want to do even that level of software development. Either they find it beneath them, find it boring, get frustrated when they want to do something that stretches the tool's capabilities, don't want to be responsible for fixing bugs and maintenance, etc. etc. etc.

I'm not so sure about this. Hypercard was extremely popular among non-programmers in its heyday. It is not their fault that Apple, who had no idea what to really do with the software, let it die on the vine.

Computer companies have inclucated a computing culture that places a sharp perceptual divide between users and programmers, leaving little room for anything in between. My belief is that this has happened for wider structural/economic reasons (contemporary emphasis on consumerism, short term thinking, etc) rather than any general distaste for "real computing" among regular people.

If we do not provide regular people with "Hypercard-like things" and instead give them shrinkwrapped solutions, we will of course have the perception that they have no interest in what we call -- for lack of a better term -- end user programming.

[hinkley]

We had a lead who wanted to do front-end code but hated HTML. He really, really wanted us to use something where he could pretend he wasn't writing HTML. But AJAX was the big thing, our app required a lot of interactive HTML, and CSS3 was just on the radar.

He would mark stories as done that had tons of layout problems. He just couldn't be arsed to dig into it, because you actually had to stick your whole arm into the guts to get things to work. Between me and another guy who were doing 60% of the interactions and north of 80% of the bugfixes we finally browbeat him into going back to real HTML templates. He retreated to writing mostly backend code from then on, which honestly reduced our workload by itself.

Pretending you have a different set of core problems than you actually have has never ended well for me, and I'm convinced it has never ended well for anyone else either. Don't abstract away your problem domain, and don't kid yourself about what your problem domain is.

[markmiro]

I think layout is a big hurdle for no-code tools. I also think it's going to get solved. But until then, I think you really gotta dig into HTML and CSS and understand them well to get things to work properly.

"Don't abstract away your problem domain"

I dunno. I tend to think of it as getting good at what you do, then finding the rules, then taking those patterns and making a company out of it where those patterns are built-in to the product.

[coffee]

> I want some no-code to make me feel for my career a bit.

It sounds like your career is software engineering, if so...

> My personal feeling is that any no-code tool should be useful enough that I would use it.

Someone who's a software engineer is not the litmus test.

These tools, from what I've seen so far, are NOT for software engineers.

So you wouldn't need to use them.

Instead, from what I've seen so far, these tools are primarily for those folks who:

- Cannot write software - Do not want to learn how to write software (gasp!)

But DO want to put their (software) ideas out in the world, have control over them, without:

- Spending the money to hire a software engineer - Partner with a software engineer

[markmiro]

You're right, most successful no-code tools are for non-programmers, and programmers shouldn't be the ultimate litmus test.

I also believe that if a coding tool will make me more productive, I'll use it, even if it's not a library or a language. Right now the visual tools are limited, but it doesn't have to be that way.

I've used Flash, Windows WPF apps, those visual tools for making apps in xCode, and others. I think there's something to having visual tools for building apps. I think it's clear that UI doesn't need to be in code. Maybe state machine logic shouldn't be written in code either. Maybe high-level software architecture constraints shouldn't be in code.