What's Your Super-Domain?

Andy Tegethoff started a good discussion with his domain-specific knowledge post, and related comment on the thread for Sarah George's recent professionalism article. I've been mulling the topic over this weekend, and I'd like to offer a take from a different angle.

I agree with Andy's basic premise that employers (and often by extension employment recruiters) can over-emphasize domain knowledge as a factor. Some of these cases, I think, are probably part of a general pattern of ignorance for these employers in the area of hiring and managing technical people--it's a similar impulse to over-emphasizing the need for a rarified technical skill (to use a term I probably lifted from Edward) over a general ability to learn new tools.

But I suspect in many cases that there *are* legitimate concerns in the area of domain knowledge for the person/organization doing the hiring, even if the response to that concern is sometimes misguided. And likewise there are cases where proficiency with a certain tool set is important as a hiring factor. Companies often hire contractors specifically because they don't want to or can't afford to make an investment in someone else's learning curve, so they need a "heavy hitter," as the baseball term goes.

Things get interesting, though, if we generalize the perspective a little further, and consider the context of our position in this debate within a what I'll label as our "super-domains."

By "super-domain" I mean an intersection of technical specialty, system type, and domain. I'll try to parse that out a little more:

"Technical specialty" refers to things like platform, tools, type and amount of data, "closeness" to the hardware, level of language abstraction, and the type and amount of theoretical knowledge (for example, compiler theory, relational theory, statistics, higher math, etc.) necessary to even understand the work.

I wish I had a better phrase than "system type," but I'm trying to capture the idea that there are certain fundamental differences between, for example, the software systems that run Amazon.com and the device driver that runs my car's braking system and a video game like Quake.

Finally, I deliberately use the concept of "domain" as a recursive subset of "super-domain." I think when we define a domain like "medical software" or "flight simulators" or "mobile phone device drivers" we are implicitly and often unconsciously assuming a certain super-domain.

I would classify my own "super-domain" as:

data- and process-oriented systems using high level languages and frameworks primarily for business or government/nonprofit clients

That's about as concise a definition as I can come up with. I could have been more specific about the technology stack with which I work for hire most of the time, but I don't like to box myself in that much. I could also have defined the domain more narrowly, but here I side with Andy.

I see my domain generally as "business process, commerce, and money," irrespective of whether the context is insurance or automobile sales. Most of the time, it's just storing the data in the right format, adding numbers up, pushing data around, and making things pretty and usable on the screen or in a report. (But I'm also careful not to pretend that my knowledge does not have limits, or that my lack of knowledge in a particular area might be a factor in how well or how quickly I could do a project--but that's another discussion.)

Your super-domain might be something like:

simulation and animation code for video games

Or maybe:

military flight simulator instrument drivers written in C and assembler

Or even:

rules engines and "expert systems," primarily for manufacturing assembly line control and robotics

No doubt we could come up with a taxonomy of these super-domains if we wanted to take the time, though I suspect it would be extremely difficult to pin down exact definitions for each one.

I think it's interesting how technical- and domain-specific assumptions are linked, especially in regards to the level of language abstraction and the degree to which mastery of what I would label as "low-level computer science concepts," like compiler design or algorithmic theory is important.

For example, I'll be brave enough to admit in public that I don't have the patience or the kind of mathematically-oriented brain required to make it through Donald Knuth's monumental Art of Computer Programming volumes. I get lost just reading over the list of "Mathematical Preliminaries" sub-sections on the first page of the Table on Contents. (There I admit it; I just have to take other people's word for it when they tell me that these books are brilliant.)

However, given my super-domain, this fact has never gotten in my way of developing a lot of pretty great software that I'm proud of, and delivering value to everyone I've worked for. With the high level tools I use, it's more important for me to master design principles like coupling and cohesion and to know how to design a good relational database than it is to grasp binomial coefficients, which Knuth discusses for almost 25 pages.

Please understand that I do not mean to disrespect this knowledge, and I'm not bragging about my ignorance of it. I don't doubt for a second that I would be deeply and eternally rewarded by working as hard as it took to understand and absorb Knuth's work. In fact, I hope to do just that someday. What I'm trying to get at is that the idea that different super-domains require different kinds and levels of specialized knowledge.

And by extension, its easy for us to get attached to assumptions about what is important based on our super-domain. I can easily imagine a programmer reading this and shaking his head in disapproval at the fact that I don't know Knuth--how in the hell can I call myself a programmer!?

If you wanted to hire me to code in assembler the animation algorithms for your video game engine or flight simulator, I'd agree with this concern. I'd want a programmer who eats and breathes Knuth for that job. But given the type of systems I build and the context in which I build them, you're better off worrying about whether I know how to design a rock solid third normal form relational database, or a scalable n-tier middle tier, or a high-performance ETL process, or a session-management scheme for a web farm. I geek out on theory and extracurricular reading more than anyone I know personally, but it's just different material at a different level of abstraction than what other people might get into.

Going back to the aforementioned domain-specific knowledge debate, it might be really important to know a lot about how airplane steering systems work to code flight simulators whereas it might be less important for me to know (in advance of being hired) a lot about the insurance business in order to come in and automate the claims process.

I think people tend to spend most of (or large portions of) their careers in one super-domain, which naturally creates a set of assumptions about things like what kinds of processes work the best, how much engineering rigor and mathematical formality should be emphasized, what kind of and how much theoretical and tool-specific knowledge is required, and of course what kind and how much general and specific domain knowledge is required. I think this is a sword that cuts both ways.

Our assumptions help us operate effectively within our super-domains, but they can also blind us to the fact that there are other super-domains with different concerns. I believe that many of the "great debates" of software development in large part boil down to people arguing blindly from their different super-domain assumptions.

Thanks for reading,
Dan