3 ms·

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 w

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.

Xophmeister 6y ago
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.
- gregjor 6y ago
  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.
  - Xophmeister 6y ago
    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 :)

Xophmeister 6y ago

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.

gregjor 6y ago
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.
- Xophmeister 6y ago
  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 :)