This site will look much better in a browser that supports web standards, but is accessible to any browser or Internet device.

Anomaly ~ G. Wade Johnson Anomaly Home G. Wade Home

October 17, 2004

Domain Knowledge and Programming

Over the years I've been a programmer, there seem to be two distinct areas of knowledge for any project. The first relates to programming. The second relates to the domain of the project. Over the almost two decades I've been programming professionally, I have worked in many domains. Interestingly, I have never started working on a project as a domain expert.

At different times, people have told me that they were looking for a programmer with extensive experience in X (whatever their domain is). I have even seen people go so far as to suggest that they would not hire a programmer who did not have a degree in the domain of interest. This seems completely backwards to me.

When hiring a construction company to build a bank, do we only consider companies that employ bankers? When finding a mechanic to work on an ambulance, would you only talk to those with EMS training? So why would you require a programmer to have a degree in biology to program for medical research?

Over my career, I have come to the conclusion that we programmers should always develop some domain knowledge as part of a project. But, we never need to go too deep. The real need is to understand enough of the domain to be able to translate the real knowledge of the domain expert into a form that the computer can execute. Our real skills come in this translation, not in the knowledge of the domain. More importantly, what domain knowledge we have should match that of the customer. This is only guaranteed if we learn from the customer in the process of doing the job.

As an example, let's say that I went to work for an engineering firm. I have an electrical engineering degree, so this seems like a natural fit. However, my knowledge of the electrical engineering field is now twenty years out of date, and fuzzy to boot. Would that knowledge be a help or a hindrance to any work I might do.

Having some knowledge of a particular domain might be an advantage. Having no preconceptions about the domain might be a bigger advantage. In many of the programming positions I have held, I managed to do some good by approaching the problem differently than the domain experts. The key is to extract the knowledge from the domain experts in a form we can execute. If I accomplish that goal, I consider the project a success.

My field is software development. As such, I need an extensive knowledge of tools, methodologies, and techniques for the development of software. I also need the kinds of skills that are needed to develop software. One of those skills is the ability to stuff information into my head and retain it long enough to make it make sense to a computer. Most of the best programmers I know regularly do the same.

The reason for this rant is a problem I have run into several times in the last few years. I have been talking with someone about a job or a piece of code they want written and they decide either that I can not do the work or that I should be paid less because I am not an expert in their field. I have heard similar comments from friends. One fellow programmer told me how an employer in a medical research institution reduced the amount they were willing to pay him because he did not have a degree in biology. Now, I am pretty certain they had plenty of biologists on staff. But, they were hiring for a programming position, and a biology degree does not make you a better programmer.

I'm not sure what it is about our craft that makes people to think that there is nothing to it. Many seem to believe that they could pick it up if they just expended a little effort. But, of course, their field is something that you need loads of training to be able to do. Not like programming.

Most of the better programmers I've known seem to think about it differently. They assume that most people's area of expertise requires work, knowledge, and years of practice to be good. They also know that it takes similar work, knowledge, and years of practice to be good at what we do. That's why most of the code that I've seen written by domain experts is such a mess. They see code as a minor sideline away from the real work. We see code as the artifact we produce to help other people get on with the work they are interested in.

Posted by GWade at October 17, 2004 02:55 PM. Email comments