Domain expertise isn’t just a “force multiplier.” It makes you more likely to understand the problems and deliver useful solutions without someone telling you what to do step by step. Remember that failing to understand requirements is the most common cause of expensive software development mistakes.

Imagine two taxi drivers, both equally skilled at driving a car. One knows the city intimately, the other doesn’t. Which driver offers the most value, the most likely best route to your destination? Which driver can avoid traffic problems, or suggest a popular restaurant?

Domain expertise makes you more valuable to your employer, less replaceable. It also shows future employers you have some commitment to the business, not just in your own technical interests. It lets you contribute at different levels. There’s more to programming than writing code.

In my own work as a freelancer, domain expertise and taking an interest in the customer’s business, not just in their code base and technical problems, literally separates me from the hundreds of thousands of technically competent programmers who could do the work. And it helps me retain customers long-term, and get referral business, thereby reducing my need to constantly find new customers — a big non-billable and stressful drain for a lot of freelancers.

Thanks.

I agree that having some knowledge is beneficial and, I guess, the more the better. Does that knowledge really look good on paper, to future employers though? I’ve recruited my fair share of people in the past and, anecdotal data notwithstanding, it’s not something that comes up much. We’d be far more interested in the skills required, as — as I say — the engineering and science cohorts within the team are orthogonal; we don’t really interact (if anything it’s the engineers helping them, rather than the other way around). I do agree with you in the general case, though.

I suppose it depends on the domain and the job. But I do think a resume looks better with accomplishments that refer to business value rather than technical details. For example “Saved $200,000/yr by developing a more efficient inventory management system” vs. “Wrote 30,000 lines of Javascript code and made 325 git commits.”

As a former hiring manager I would shy away from programmers who only wanted to code and didn’t seem to care about the business. That could indicate immaturity and inexperience, or an autism spectrum condition, but it most often indicates someone who puts their own technical interests above their job. It would make me wonder how well that person would fit with a team, and the overall organization.

When personal tech interests and the job mesh well everyone is happy.

As a freelancer I see extreme examples of this: programmers who tell the customer how they should run their business and try to fit requirements into their preferred tech “stack.” They want to rewrite everything their own way, disregarding cost, risk, and any larger considerations of the business so they can do things their own way.

I see your point and, yes, I do agree. Someone who is pathologically “all about the code” — unless the domain was something really niche like PLT — would definitely one to avoid. Thanks :)

I think this is very dependent on the environment and how the group works, and at the end also to the involved personalities and how your boss thinks the group should work. And I think this is something to ask about: why do they expect you to have more domain knowledge, and why do they think that's more important to prioritize?

How would they describe your "promoted role" in what you do? Is their expectation that you'll work with less input from domain experts because that's what they see as the bottleneck (do they want those domain experts to focus on other things? do they think you are taking to much of their time? ...)?

Does the institution literally have a rule about domain qualifications being needed for advancement? (in scientific labs even credential requirements for non-science roles are not uncommon)

Do they just think your software skills are good enough and if you improve it should be on the other side?

Thanks.

Our/my setup is very much the latter of your scenarios: I have the tech skills, so they’d like me to increase the science skills. I believe you’re right that the reason for this is because the manager wants to move in that direction. That brings me back to my apprehensions — in the sense that it’s leaked information that suggests engineering is not as highly valued — and therefore, whether in fact it’s time to move on...