This site will look much better in a browser that supports web standards, but is accessible to any browser or Internet device.
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 a 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 commentsWhen I read this article, several things came to mind.
One is the interdiciplinary nature of programming itself. For instance, I know enough sql to make querries, build, and even design databases. However, there are books published on SQL that are "thick as a brick". As a more-or-less sensable person, this tells me that there is far more to know about this dicipline than my limited scope of knowledge.
I have yet to meet a SQL guru that was also an outstanding programmer, let alone a systems architect. I believe this is because their particular dicipline is so rich that the majority of thier time is spent on the requirements of their project, training for thier field, and the general day-to-day business of being an SQL specialist. I am sure there may be some exceptions of course, but they are rare.
The other thing that comes to mind is the feeling I get when I look at the want adds. I see requirements that just floor me. The sheer number and variety of disciplines *required* by a prospective employer just amaze me. Most *programmers* would be lucky to have a smattering of the skillsest they require. What they don't seem to realize is that expertise, the kind where a developer can function autonamously, requires a great deal of study and practice. This basically just reiterates what you are saying in this article, but I would like to emphasize what a disservice they are doing to themselves and even the devolper looking for employment.
The first problem is that if they manage to find someone that responds to the add with a miraculous skillset, the chances that they are lying about thier expertise are pretty good. I have been in the hiring chair and most of the effort spent to find an employee is weeding out the liars and the idiots. In an ideal world, an employer would like to chat with a prospective employee at a fairly in depth level on a limited scope of skills. This is pretty much impossible to do (without lots of interview hours) if your *requirements* span mutilple disciplines.
The second problem is the job seeker who is an amazingly talented programmer might not even attempt to apply for the job. Everyone looses in this scenario.
>>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.
I have noticed a trend in software where the folks building the languages, platforms, and applications are expending a huge effort to make it easy for non-programmers/software pros, to produce results "like the pros". Flash is one such platform. What ended up happening, in my opinion, is they produced 2 camps. One camp, the coders and tool (component) makers. The other camp, the users of the easy-to-use tools and design time goodies. Time and time again, the non-programmers find it difficult or impossible to expand upon what the component makers left out or just plain "got it wrong". Perhaps it is in the nature skilled programmer to make things easy. In doing so, we make it easy for the up-and-coming to "join the ranks" with no foundation to draw from when the problem space changes. Is this a good thing? Some would argue yes, but what you get are employers with buckshot requirements, and prospectors who learn the buzzwords and "just enough" to get past the looser scrutinity that results from the kind of interview dilution I mentioned above.
Posted by: Ian at October 18, 2004 02:06 PMOh and one last thing. I was just thinking of another example to illustrate the point of this article.
One does not need to know how an MRI works, or how to operate the machine in order to write programs to manipulate the Data that an MRI produces.
Posted by: Ian at October 19, 2004 09:05 AM