I'm a dev and I see my job very much in contrast to what you've described. My job is to solve business problems, typically using code, but it all the things around it like requirements gathering etc.
It also definitely includes trying to solve business problems by not writing code; by saying "this is a business problem not a technical one, how about trying <some non-coding approach>"
I don't disagree, but saying my job isn't to write code is like saying a surgeon's job is not to fix people up, or a bricklayer's job is not to lay brick.
Anyone's job can be described as "solving a business problem" or "adding value", but that's not usually the best way to describe it unless you're in a room full of MBAs. (And even a bricklayer's job goes beyond "merely laying bricks".)
IMO, it goes (or should go) without saying that my work output is valuable, and that I do what I do for a reason, and that "writing code" does not encapsulate everything there is to know about the job.
I once solved an urgent business problem (related to interfaces FYI) by realising there must have been a 3rd party solution. A quick search and I found it. It went onto client sites soon after.
To be fair, the problem had to be solved using code anyway (why I was originally brought in), so another team wrote that, but it took several man-years. My interim 'fix' bought the company a lot of time.
This isn't a great example as the code had to be written anyway, but you get my point I hope.
I do, and oftentimes as a professional, not taking action (or taking some alternative action, or referring to another professional, etc) is the best thing you can advise a client.
A good surgeon will also very often advise a patient that surgery is not indicated.
> saying my job isn't to write code is like saying a surgeon's job is not to fix people up
A surgeon is a perfect example against your argument -- the surgeon's job is to achieve a positive patient outcome, not to cut someone open. Sometimes achieving the first is best done by cutting someone open, but when it is not then it is the surgeon's job to say that a different approach is needed.
Frankly, I see it as my job to write code. That this code happens to solve business problems is a lucky coincidence.
Of course, this attitude may be a reflection of the fact that I have never written software for a domain in which I have expertise. Maybe if I were working on a product that I myself used, I would be able and happy to help solve business problems. As is, that is better left to a SME, and I am happy to solve technical problems.
It also definitely includes trying to solve business problems by not writing code; by saying "this is a business problem not a technical one, how about trying <some non-coding approach>"
Not to disagree with you, just giving a contrast.