Citizen developers are rapidly becoming the vanguard of corporate digitisation

There is the "this doesn't change." In many other jobs you can bend the thing you are working with to your will. Bend that pipe or apply just a bit more force here. Having plumbing being off by a little is often good enough for the tolerances.

Math, you can't do that. There is no way to push a bit harder and make one value a different value. Yes, there are ways to manipulate systems of equations - but at the heart of it, you have to submit and match the mental model of math rather than being able to impose your will on the material.

Carpentry? The wood doesn't bend the way you want it to? You can blame the wood, throw it out and start the process again. It may be costly over time, but doing the same thing may have different results the next time.

Software development and math - if you do the same thing again, it doesn't change.

The second part of this is the how you approach a very large problem and apply an algorithmic approach to breaking it down into smaller and smaller problems until they are solvable.

That isn't a "you can't use that approach on carpentry or plumbing" (and it is often that you do), but rather that it is necessary to do this in math and software development.

The knack for math is more about the acceptance of the inflexibility of numbers and computers along with the nature of the tools used to solve those problems. That said, some of the tooling for one or the other may be difficult to get your mind around. Calculus and derivatives and matrices... they are things that the tools to solve them and I go blank with them. I also know a sysadmin who was a math major who is proficient in PowerShell, but the parts of strongly typed larger codebase and he appears to have similar distain for it that I do for matrices and calculus.

> Most of the time the elegant software solutions come not from writing brilliant code, but from reframing the problem so that simple code can solve it.

This is also at the core of solving the harder math problems.

I just don't buy the argument that visual programming tools are inherently more creative or imaginative than text-based programming tools because at some point, you are going to be constrained to the UI, which always comes with tradeoffs.

I recently used a visual programming environment for a work project, and I went into it thinking that it would be a fun and interesting way to program and very quickly turned to hating it. The visual aspect of the tool constantly got in my way and I quickly found myself wishing I could accomplish what I was trying to do in my text editor instead of this godforsaken web UI.

The error messaging in the tool was so bad that I wound up just intercepting the necessary HTTP calls and debugging those instead because it was so much simpler and informative than trying to navigate this "Disney World" UI that looked great with a trash UX.

I'd be OK with a visual programming tool that gives users the option to go straight to the code layer if they choose, but I've worked for so many software companies in my career that I'm just not confident that most companies would be able to ship anything with a dev UX that comes close to working with code directly. You can't get away with "happy path"-ing a visual coding tool, which is how so many companies build software these days.

This brings up a great counter-argument to visual programming tools, which is vendor lock-in. We talk about this a lot on the cloud architecture side, but surely this also becomes a concern if a commercial visual programming tool becomes an integral part of one's core business domain. And if the solution to this problem is some sort exportable code, then what's the point?

Because there are no examples of it is precisely why it’s hard to do. Those who try either end up with something too application specific to be extended, or something too abstract to be used.

Take UML, it took the abstract route. It has many diagrams, it even has flow charts. It was big in the ‘90s and never amounted to much. Turns out that to implement something in UML is harder than just writing the code it maps to in the first place.