I was going through some old links I had saved for later and I came back to this tweet (it’s never X and thus never a post) from Derek Comartin of CodeOpinion.com. While I’m partial to Comartin’s position (effectively domain knowledge is more valuable than experience with a particular framework/tool/library), there was a surprising amount of disagreement in the replies. Part of this is because Twitter is a bad place for adding qualifiers (like both sets of skills are important, and both can be learned on the job in any job), but the prioritization was revealing about both how a lot of people seem to think about their jobs in tech, how they think that fits into the bigger picture, and forces some uncomfortable observations on whether or not that’s true.
Again, both knowledge about the technical stack and understanding the problem space are important. The question in the scenario is about which is generally easier to pick up. In my experience, learning new languages, frameworks, and tools have always been doable on the job, and generally quicker to get “productive” in (mastery still take years, but being able to write code that can be safely run in production typically takes much less time). It seems like a significant contributor to the debate in the replies was people getting fixated on React (the specific technical skill) and the insurance industry (the problem domain), and not treating them as essentially variables in the equation, leading to a lot of noise in the discussion about the relevant difficulties and complexities on a particular piece of technology, instead of the actual point.
The most interesting comments were largely around the extent domain knowledge actually factors into development these days, and those comments certainly resonated with my personal experience. If you’re in a Scrum shop, you probably have a product manager whose job it is to write user stories with a list of requirements (or “acceptance criteria”), make sure you don’t have any questions, and that’s that. There’s rarely more context (mostly enough to give you the same information you’d get from the epic name) around the problem at hand. Without that problem context, there is a very good argument to make that domain knowledge isn’t really adding anything – all that kind of decision-making is handled by product owners and business analysts. The developers are just there to churn out 1’s and 0’s and not think about the “business stuff.”
That last bit is helped by a seeming apathy from developers to the “business” side of things (I’m guilty too – I don’t care about earnings, P&L, and all that stuff, but there are still important things to consider from the perspective of people actually using the software). I was always taught during college that computer science is the study of solving problems, and that we just happen to use computers to do it. The problem with the “let the business people worry about the industry/problem domain – you just type up that code” philosophy is that it takes people who, if skilled, are geared towards problem solving, and effectively benches them.
The trouble with acquiring domain knowledge is that at a lot companies, the only real way to get serious exposure to the business issues a company is trying to solve is to get into meetings that, for most developers, could be more efficiently delivered through another medium. This is especially true when you remember developers aren’t being asked their thoughts on how to solve these problems, just being handed stories and told “code this.” It’s that attitude that makes it seem so valuable to tell developers to focus on mastering their tools and not worry about the the problem space.
Favoring business knowledge over toolset knowledge means you have developers that can implement all the unwritten requirements that go along with stories. You know, the ones that are so ingrained in the minds of people that have been working in this field for a while that they don’t think to include them in the acceptance criteria. Business and domain knowledge lets you think about end-to-end systems, including the portions that aren’t managed by your team. That can let you raise questions that catch or avoid issues early in the process, before they actually manifest as things not working.
Having a broad swath of technical knowledge makes you more valuable as a developer, but so does having a broad swath of business knowledge. The main difference is that while having a wide range of technical knowledge lets you contribute towards the back-end, front-end, database, and/or infrastructure, having a wide range of business knowledge lets you understand how what you’re doing fits into the fundamentals of how the business operates. That’s where the whole using IT for lowering costs and improving efficiency thing comes into play. To borrow from the given example, understanding that the insurance industry prioritizes not spending a bunch of money on claims (for better or for worse) means you know want to be be focusing on getting details that differentiate fraud claims from legitimate claims, and that you want to make sure the front-end you’re building focuses gathering details that help determine whether or not a customer’s policy covers the scenario in question without having to do a lot of follow-up. That informs the types of questions you can be asking about the acceptance criteria that drive the implementation in good directions for the business.
Given that businesses don’t really spend a lot of time and effort on training these days, it does make existing technical knowledge seem more valuable, especially in non-startups with established domains and products, where the “business stuff” has dedicated people already. As mentioned by Comartin responding to a comment on the original tweet, the less established the project, the more important domain knowledge becomes. The problem is that as developers, we’re generally seen as code monkeys more so than builders. As a result, it creates the impression that domain knowledge is wasted on developers. I’m not sure how to really solve for that part, other than to start your own software company (which seems a little flippantly dismissive of the problem). The reality is if any company, regardless of size of established products, hits an open-ended problem, the developers that get pulled in to figure out what the solution is are going to be the ones that have best big-picture of the business.
These days, developers with strong domain knowledge seem a lot like good insurance, businesses hope (and oftentimes act as if) they don’t need them, but it turns out they’re really important to have when things don’t go according to plan. Unfortunately, it seems like that’s a skill (and knowledge) set that’s increasingly less valued, and a lot of workplaces seem to be adjusting to that lower value on (developer) domain knowledge. While I want to agree with Comartin (and really do believe developers with strong domain knowledge are more valuable to organizations in the long run), the reality is the usefulness of domain knowledge is directly proportional to developer involvement in actually designing what the software does and how it works. For most of us, that’s probably not as much as we’d like to think.