I wish someone would write about that.
What is an expert?
What is a domain?
How do I become a domain expert?
Am I an expert at something I take for granted?
I love Paul Graham's essays but there's a lot of implied logic and jargon. Maybe he should have a few non-startup, non-business people proof read them too?
For example, I maintain an e-commerce system. More specifically, I maintain an e-commerce system built for a cosmetics company. E-commerce is a field, cosmetics is a field, cosmetics e-commerce is specifically the domain I need to become an expert in. The more I can differentiate cosmetics e-commerce from other kinds of e-commerce, the more well-tailored I can make my app. And the more well-tailored I can make this app, the better I'll be able to understand the more general case of making custom e-commerce systems for other industries.
The more I go through this process of understanding the specific needs of the industry, the more domain expertise I'm building. Domains can subdivide as much as industries subdivide. Say the cosmetic industry started to split along product lines, then I might start gaining insight into how lipstick companies operate, and be able to tailor a product offering straight to them.
The domain doesn't have to mean commercial industry. You might have domain expertise, say, in XML parsing. Then you could wax poetic on the differences between Nokogiri and say, Chrome's internal parser.
So, essentially, it just means "expertise". More specifically, the type of expertise that allows you to customize a software system around it. Which can be in practice quite different from normal expertise. The guy who devises our makeup formulas is definitely an expert.
But he can't design the system to actually manufacture it. The guy who writes those systems might not understand the actual formulas, so the two types of experts have to work together.
When startups talk about the need to be a domain expert, it means getting out of just pure programming and into the actual meat. Rather than hire an expert, to become one yourself. This not only allows you to reduce staff, it also makes it easier to make better, more custom solutions. The Soylent guys have to make the system to manufacture their product, but they also must understand nutrition, food, the regulatory environment of the food market.
So as soon as there's money to hire programmers, I'm getting out of the coding biz and hiring others to do it. I want to focus on working with my customers, understanding their needs better than I already do, and guiding programmers to build for those needs.
I would even go as far to argue some level of domain expertise is almost required to make solutions. Even with perfect requirements (oxymoron I know), a programmer still has to make a ton of tiny domain driven decisions while writing a piece of software.
As you mentioned, software on its own isn't very useful. A programmer who learns even general business is much more useful.
A set of disciplines, or majors, other than computer-science (or alternatively something other than core programming/software-engineering skills). The word is typically used in CS/sofware-engineering circles.
An (arguably crude) example:
Think of who designed an mp3 encoder/decoder? A programmer? Does becoming a good programmer and/or getting a typical 4 year CS degree, sufficient to come up with an audio encoder/decoder?
No. You have to understand audio signals, their properties, learn how to analyze them, etc. That requires knowledge from the disciplines of physics, and electrical engineering (e.g., digital signal processing), maybe even some biology of sound. And if you learn that, you become a part-programmer, part-acoustic-engineer. That "acoustic-engineer" bit is your "domain expertise", i.e., something you need to know beyond CS to get your work done.
You might say, "why do I have be an acoustic engineer? why can't I, as a programmer, work with another guy, who is not a programmer but an expert acoustic engineer?". Yes you can. In that case, you're being the software guy, and he's being the domain-expert.
Sometimes collaboration between a software-engineer and a domain-expert works. Sometimes it helps if the software-engineer himself develops domain-expertise (so one guy playing two roles).
Domain expertise is not limited to one domain only. It could be no-domain (a pure CS programming, like database, web-development etc, although you could call them domains within CS), or a domain consisting of multiple disciplines (audio-processing comprising physics, DSP), or multiple domains (acoustic-engineering plus submarine-engineering, for example), and so on.
More:
What is an expert: Someone or something recognized as such by other recognized experts and trusted by a significant number of those who are not.
What is a domain: A limited area of human knowledge small enough that it can fit in one person's memory but wide enough that when applied it solves multiple useful problems.
How do I become a domain expert: By doing. First learning. Then making. Finally advancing. Unless of course you are creating a new domain which skips to step 3.
Am I an expert at something I take for granted: No. Most US adults know how to drive and do it semi-(un?)consciously. They are not expert drivers.
expert is used in the sense of the standard definition in any English dictionary
one could be an expert at programming, and though that's a valid topic and craft to have expertise in, its not a domain in the sense of "domain expert" you're asking about
Ok its sucks if English is a second language for you but that is what dictionary's and thesauruses are for.