A machine in a factory is malfunctioning. The expert comes in, hits one spot with a hammer, and everything works again. When the manager demands he itemize his $100 bill, he writes, “Hitting with hammer, 25 cents. Knowing where and how to hit, $99.75.”
This joke, a classic in the IT world, seems apropos given the popularity of the “Looking for a Job? How’s Your COBOL?” post we published a few weeks ago. It spawned a lot of interesting discussions, which leads us to believe that the domain vs. technical discussion crops up pretty frequently wherever programmers hang out.
One of the discussions was about the relative importance of “technical knowledge” vs. “domain knowledge.” In other words, some suggested, the value of many COBOL programmers isn’t that they know COBOL per se—the technical knowledge—but because they know a lot about the particular application or field, such as how Social Security or the pension system works—the domain knowledge.
Some commenters said they became programmers because they wanted to program, and if they wanted to learn about business, they would have gotten a business degree. But others argued that no matter how technical a person is, to be effective he or she needs to have some understanding of a given industry or field. “In order to solve a problem, you must first understand the problem,” writes “jmort253,” who said he has both a computer science and a business degree. “You need to get into your users' heads and understand how they think. Whether you're building software for finance, marketing, sales, geology, physics, or whatever field the software supports, you must become a part of that field.”
Of course there are varying degrees of necessary baseline knowledge, depending on the field. “If you're making mobile phone toy games, then the domain is probably not that hard; the harder part is making the program efficient, portable, good-looking, etc.,” writes Joonas Pulakka. “But if you're making a nuclear power plant control program, then it may take years of intensive study to actually master the nuclear physics that your program has to deal with.”
Opinions vary on which direction a person should emphasize in his training to maximize career advancement. Some believe it is better to focus on domain knowledge to become more valuable in your current job, while it’s better to focus on technical knowledge to become more valuable to a potential new employer. Focusing too much on domain knowledge, the thinking goes, makes future employers think you’re too specialized and can’t learn about a new company.
Gaining domain knowledge is also considered important for people who want to progress from being a coder or programmer to becoming developers, project managers, or architects. “Anybody can learn a technology in a week,” writes “Benjol.” “The only thing that is going to mark you out and make you useful to your company is your business knowledge. And the harder it is, the more you'll be worth. If your idea of paradise is hacking together little PHP websites, beware: there will be thousands of script kiddies who are doing that too.”
Research also shows that the people with extensive domain knowledge are considered the most valuable members of a team. “Domain knowledge experts are rare and should be accessible,” write the authors of the paper, The Role of Domain Knowledge and Cross-Functional Communication in Socio-Technical Coordination. “When organizing teams, managers should give particular attention to potential brokers by identifying members that have exceptional knowledge of the particular application domains or components in the system.”
However, are some of the perceptions due to overemphasizing technical knowledge—sometimes very picayune technical knowledge—over domain knowledge? Would it be easier to hire someone who specializes in the domain knowledge of Social Security or pension administration, and teach them the technical knowledge of programming?
Ultimately, there’s no easy, one-size-fits-all answer. It depends on your industry, your temperament, and your career development plans. Only then can you decide where to aim your hammer.
Simplicity 2.0 is where we examine the intricate and transitory world of technology—through a Laserfiche lens. By keeping an eye on larger trends, we aim to make software that’s relevant to modern day workers, rather than build technology for technology’s sake.
Subscribe to Simplicity 2.0 and follow us on Twitter. If what we’re saying piques your interest, head over to Laserfiche.com where you’ll see how we apply the lessons learned on Simplicity 2.0 to our own processes, products and industry.