4 ms·
That's just it; the article focuses exclusively on low code/no-code solutions. The author cites examples describing business people putting together functional
by garren 5y ago
That's just it; the article focuses exclusively on low code/no-code solutions. The author cites examples describing business people putting together functional systems without writing a lick of code (let alone understanding the math underlying such systems.) The whole point of the article is /not/ having to learn to code.
The idea is that these people are in the thick of a business problem, and given the right tools, they're likely to come up with a helpful solution. They don't need to express or communicate anything to anyone. They're able to provide a solution on their own.
I agree with this somewhat, having built and maintained more than a handful of the kind of apps that these low / no-code solutions target, i.e., line-of-business apps. These tools have a place. I've worked with trainers and consultants that, I firmly believe, would have thrived with these kinds of tools had they been available at the time.
Incidentally, I can't entirely agree that math is important because it encourages the appropriate thought process for constructing these systems. I've worked with more than enough technically inclined (if not remotely mathematically inclined) people who have managed to put together solid systems for themselves or their teams. I'm convinced that curious people excel in these cases, the ones that find a shortcut or an interesting path and just follow it.
- jacquesm 5y agoWe already have this distinction: engineers vs bricklayers and plumbers. And it also works that way in software. Plenty of CRUD programmers would not be able to implement quicksort. But they sure are able to use it.
- orev 5y ago> They don't need to express or communicate anything to anyone. My point about communication is not so much the need to actually tell something to someone, but that in order to be able to communicate something, they need to know how to break down a problem into all the various components. That’s what’s missing for many business people, so whether they are communicating the problem to a developer, or to a no-code platform, it won’t work. There will always be business people who can do this just fine, but there are far more who see themselves as the people who give commands that others just follow and have no interest in actually doing that type of thinking.