Something I've learned is there's a (rough) inverse relationship between how hard something actually is to implement in software development and how easy non-technical people think it will be. I think it's partly because the kinds of things that are easy for humans are hard for computers and vice-versa. A non-technical person might think, how hard could it be to list all records of type A that meet conditions X, Y, and Z. But you as the technical person understand that "record type A" doesn't really exist on the back end, it's a combination of separate tables and trying to filter for conditions X, Y, and Z at the same time while avoiding duplicates or false-positives/negatives is a whole thing. The inverse would be assuming it will be hard to implement some known formula to be applied to a given field from a single table. That's usually very easy to do, but non-technical people might assume it's going to be hard because the formula itself is complex and calculations are hard for humans to do. I've even seen non-technical people be wary of asking for a simple change to a label in the front end. I'm glad they were wary and open to the answer that it would be hard, but from a software dev's perspective it's kind of funny because obviously it's easy to just change a piece of display text (and if it's hard you've screwed up somewhere up the line).

Non-technical people don't learn how to think like a computer, which is what software engineers/developers have to do.

The other issue, and I've said this a million times and I'll say it a million times more, is that it actually is very easy to write code. What is hard is writing code that doesn't blow up down the line in some unforeseen and/or expensive way and that meets the nit picky needs of the business. A lot of non-technical people are now seeing LLM-generated programs that seem impressive if you don't have proper context for how that thing was trained and how easy it is to have a program that works before you start introducing more real world requirements. I remember the LLM demos from a bit back where they'd ask it to generate a Pong clone or something similar. So many people thought it was amazing because it would just generate code for this working arcade game in seconds. But that's a silly example because first, there's a million pong clones out there and the AI is just regurgitating some version of that known code. Second, Pong is not that really that complex (especially now that we have libraries that make graphics display and user input straightforward), and it exists independent of the real world and preexisting code. It doesn't need to map to data representing real world users, states, and business practices, and doesn't need to integrate with an existing code base. So it's easy to make something that works in a vacuum. And third, oftentimes the request made to the programmer is not as straightforward as "Pong clone". They might want some process X implemented, without understanding that really it's not the process that they want but the outcome Z. Being able to discern the difference between what someone is asking for and what they actually want is something that requires technical expertise, general familiarity with the business/industry and existing processes, and how to communicate with humans in way that doesn't just take everything they say at face value.

Once you get past all those caveats, the code itself might still be pretty simple and straightforward to write. It's just that non-technical people don't see all the intellectual labor that goes into refining and determining those requirements before you sit down to the write the code. And they also don't see the necessary labor of testing that code from a million different angles no matter how sure you are that it'll work and you understand what needed to be done.