[beningrad]

> translating algorithms to a programming language is not the hard part of programming

I agree with this bit, but often struggle to verbalize what is hard. I'm curious to hear your take.

I usually say, in a hand wavy way, that structuring large logical processes takes a lot of deep concentration, but that doesn't quite capture it.

[gregjor]

You might know the old joke about the factory that breaks down, costing thousands of dollars an hour. No one can figure out what's wrong. A consultant is brought in, he spends a few minutes analyzing the problem, then pushes a button and the factory starts back up. He presents a bill for $10,000. The owner balks -- $10,000 for less than an hour of your time? The consultant says the time is $1, the other $9,999 is for knowing which button to push.

When someone hires me to solve a business problem with software they aren't paying for my knowledge of Javascript or C++ syntax, or how to implement a linked list, or call an API. They are paying for a solution to a problem, and solving that problem means I need to understand it and draw on my experience and expertise. Sure, anyone can learn Python in a couple of weeks and get "Hello, world" to work (I've taught teenagers Python programming myself). But there's a big distance from there to solving actual problems with software, and adding value to an organization with programming skills.

Anyone can learn how to sum a column of numbers or take a blood pressure reading in a few hours. That doesn't make them accountants or doctors.

Different problems and business domains have varying degrees of difficulty. In general the hardest problems are:

- Defining requirements as completely and unambiguously as possible.

- Breaking requirements down into tasks suitable for estimation and implementation.

- Deciding on appropriate data structures, i.e. a relational database schema.

Inexperienced developers (which would include much of the target market for low-code/no-code tools) often make obvious mistakes: failure to test adequately, missing edge cases, not understanding security, implementing fragile and low-performance solutions, etc. They also usually have no idea how to approach debugging a problem, or even describe a problem -- anyone who has worked a help desk or had to respond to trouble tickets knows that.

Excel is a classic no-code/low-code tool. If you have ever had to review and debug spreadsheets put together by non-programmers you have seen what happens. The tool itself is very powerful and non-programmers can get a lot working, but on inspection you find formulas with errors, poor performance because of ad-hoc organization and data types, hard to reproduce bugs, etc.

I have worked with a lot of WordPress sites put together by small business owners and marketing agencies. WordPress is a low-code/no-code tool -- almost anyone can get a basic site up and running using a hosting provider, and install any number of themes and plugins to add functionality without any coding. But as soon as something goes wrong, like incompatible plugins, or some integration is needed like pushing sign-up forms to a CRM, the amateur developers are stuck.

No doubt there's lots of low-hanging fruit. I don't have a problem with non-programmers using tools like Excel or WordPress to solve their business problems, or even writing small Python scripts to automate something. That's not really what I do, and I know they will hit a ceiling pretty fast where they get in way over their head with how to define a problem, decompose it into tasks, algorithms, and data structures, implement in an organized way, test, debug. I can get so far with working on a car or motorcycle with my limited mechanic skills, but more often than not I need a professional with the right tools, expertise, and experience because I quickly get in over my head.