[zerogvt]

That is a naive opinion IMHO. In all but the core SW roles you would merely be a simple cog being told what to do. If for example you'd be coding for an archaelogy department you would be the code monkey of the professor heads. Even worse you would have to battle their ignorant views on SW. My guess is that you'd hate playing that role and that you would run as fast as you could back to a SW house doing fragmented work with people that at least understand a bit of software.

At least that's my experience of venturing into a non-hardcore SW field (health sector).

[dagw]

I've worked both ends of this 'spectrum' several times in my career and your experience doesn't match mine at all. I've rarely had the problem of domain experts treating me as a cog, and certainly not more so that in a 'normal' SW house. If you come in humble, ask a lot of questions and listen to people you'll quickly become a respected member of the team.

The important part is to understand, enjoy and respect the domain you are working in. Then working with domain experts to use software to solve problems you both care about can be both fun and rewarding. And

You are right that you will have to 'battle' their ignorant views of SW development. But those battles are rarely hard to win if you're a bit diplomatic, because people don't care to much. They might not have any version control in place when you start and might not see the need for it, but I've never experienced anyone forbidding me from using version control. Most of the time they even come around to it as being pretty good idea.

[jimcsharp]

From my experience, with a bit of back and forth I'm helping these non-SW departments systemize things in ways they might not have thought of. Through the power of my business ignorance and having conversations, I'm rubber ducking these people to good systems.