My experience (as someone who has almost exclusively worked as a software developer in non-software companies) is that my primary value add is the ability to recognize things that a computer can do easily, versus problems that are not solvable by throwing software at it.

For example, when I was working in a finance team, I'd come across all sorts of situations where someone had a task of "once a week, download this data from this application, apply the following transformations, then upload the results to this other application". Anybody reading this site would think "ah, that's like a dozen lines of code! We should automate that". But that thinking is incredibly rare outside of our field.

On the flip side of that, you'll have the people who think they can simply buy software that will solve all their problems. "No, ma'am, buying a fancy new Spend Management System will not magically make everyone know or care about the difference between 'GL 10754 - Employee Appreciation: Meals' and 'GL 10822: Employee Meals (Discretionary)'".

My take on it is that the ability to recognize automatable problems boils down to 1) having an intuitive understanding of algorithmic reasoning ( this solution comes in 4 parts, the first part can be divided into 3 separate problems, which...) 2) having an up-to-date understanding of the extant capabilities of computers. 3) having the kind of bull-headed hubris that makes someone say "Sure, we currently do it this way, but I can do it better".

And at the end of the day, those features end up meaning you need some sort of engineer.

This is why I have always advocated for getting my software engineers away from code occasionally and out into the field into whatever domain in which we're working.

We need to experience and see how the world actually works, the pain people are actually experiencing. I deeply believe we build better software that way.

Have a software engineer working for a mining company that's a good candidate to drag out into the field for a bit? Get 'em out there, encourage them to ask tons of questions.

Real example: my wife is a nurse who works for an insurance company to coordinate care for injured workers to help maximize their recoveries. I hear a ton about the stuff she has to do, and just having her tell me about how things work has given me a glut of ideas of how I could help her bypass all the administrivia so she can focus on helping the folks she's really passionate about helping. Wouldn't have had any idea about any of this, otherwise. Unfortunately for her, I don't work for her company so can do nothing about it, but the ideas!

I think the best ideas come from people who have both domain knowledge and an understanding of what's possible. Computer science gives you the latter.

If I was going through university right now I'd want to double-major in computer science and something else.