"Coding" is mechanical. "Judgement and decision making", "Critical thinking", "Complex problem solving", the actually difficult parts of doing long-term programming work, are at the top of the list.
You listen to the managers, or are otherwise invested in the inner workings of the company. Using those skills of intuition, you gather the business objectives, and then write code to solve those needs in the manner most appropriate to the environment in which you work. Of course, often you're writing more than just code, and will contribute to documentation, and test with your users to gather feedback and improve your solution.
Good programmers spend less of their time writing actual code, and much more of their time understanding the problems their code is meant to solve.
More seriously, lots of junior developers need to do stuff like that so they don't make mistakes when they move to actually designing things.
You really didn't like the suggestion that the two words aren't synonyms. Sorry about that. I used to have a hard time understanding the difference between the terms "tactic" and "strategy" because there were so many examples where they seemed interchangeable, and perhaps you're feeling the same sort of hair-splitting is happening here.
Here's another way of looking at it. Coding is writing new code or improving existing code (maybe even improving it by removing it). Engineering might, for example, be a decision that it's more cost-effective to buy more hardware and spin up a second instance than to refactor code to enable the safe addition of a cache.
If it continues to frustrate you that different words are used to describe different responsibilities, you're free to call them both the same thing. My personal experience in the industry is that one is a superset of the other.
Understanding business needs and gathering requirements is software analysis. Deciding what components to write to fulfill those requirements is system architecture. Determining the modules, algorithms, and data structures to use within those components is software design. Finally, writing down those algorithms and data structures in a way that satisfies the compiler is coding.
Most of us "software engineers," "software developers," or simply "programmers" wear all of these hats at various points in a project's lifecycle. But to wear the title "coder" is to explicitly mark your position as one with minimal critical thinking, problem solving, or decision-making.
Coding is nowhere near sufficient to create programs that solve complex problems, in the same way that typing is not sufficient to create a novel. If people explicitly designated as coders are making decisions and thinking critically, we should be as concerned as if typesetters were reworking character development.
"Design is not coding, coding is not design" [0].
Because that hasn't existed in a long time, at least since the 70s. Much like typesetter don't exist anymore where designers use programs that allow the, to typeset themselves.
* many of these "coders" like future rear admiral Grace Hopper got fed up with this and did something about it, leading to the first compilers and programming languages.
Which is why it's so strange that people would suddenly rally around this term, rather than "programmer" or "developer" or "software engineer" which encompass the full range of what they're doing, and instead choose to cheapen it by calling out the least intellectually challenging step.
You could argue that source code in a contemporary high-level language is a software design, and compilers/interpreters have grown sophisticated enough to eliminate the need for human grunt work.