Except it is easy. In fact, it was designed to be easy by the language architect. Unlike engineering where you're dealing with unchangeable laws of physics, computer languages are designed to be written by people.
Well, writing something in a programming language is the easy part, but it's not sufficient and not the main part of being a programmer.
If you can write in plain but exact English what exactly do you want the system to do and how to do it; and what you wrote actually solves the problem that you intended, then you did 90% of the programming work and have 90% of the required skills. Yes, you'd still need to code that in a particular programming language so that "the computer would understand", but doing that takes a tiny portion of the total work time and learning the skills to do that also is simple and fast compared to learning how to do the first part properly.
On the other hand, if what you described actually describes something slightly different from what you wanted (which is very likely) and doesn't describe the behavior in a bunch of things that you didn't think of (which is even more likely) then the skills in that computer language or the "design by the language architect" won't help. And fixing issues like that take up the majority of programmer-hours in any nontrivial software project.
Programmers are still dealing with the laws of physics. This is why you get 10,000 asynchronous communication platforms all generally failing to result in massive improvements in usability and parallelization. Most programming problems are communication problems, and most communication problems are a result of physical limitations.
While, yes, you can't run CERN on a raspberry pi, the performance limitations of the underlying CPU are a fundamentally separate problem (unless you're developing for a microcontroller). Going out and writing code (any code!) is a purely mental exercise that's unaffected by the outside world. Don't like the syntax? Use another language! Want a feature that's not currently there? Import a library! The point is that code was meant to be written, whether it relies on a physical processor or not. You have lots of different options that each try to make it easier for the programmer.
That's not entirely true either. Computer programming is largely performed using text in a 2d grid, and there are a good deal of problems not suitable to being represented that way. Language designers have to deal with this when deciding what syntax to support, and how that maps to the desired semantics. This is one of the reasons for the proliferation of so many different languages in the first place.
> where you're dealing with unchangeable laws of physics
The language of mathematics is also designed to be written and understood by people, and is used to describe the laws of physics. I, personally, find writing mathematical statements be comparable to writing code (and also Latin).
If you can write in plain but exact English what exactly do you want the system to do and how to do it; and what you wrote actually solves the problem that you intended, then you did 90% of the programming work and have 90% of the required skills. Yes, you'd still need to code that in a particular programming language so that "the computer would understand", but doing that takes a tiny portion of the total work time and learning the skills to do that also is simple and fast compared to learning how to do the first part properly.
On the other hand, if what you described actually describes something slightly different from what you wanted (which is very likely) and doesn't describe the behavior in a bunch of things that you didn't think of (which is even more likely) then the skills in that computer language or the "design by the language architect" won't help. And fixing issues like that take up the majority of programmer-hours in any nontrivial software project.