Switching Domains

In my new role I have been pouring my brain into a new domain (industry) for the past 2 weeks.

For the years I have been writing code, moving from one language to another has never a big issue. ie, from Pascal to Modula-2, C to C++, Perl in the middle, Java from the dawn of ages, dabble in C#, poor over XML and become a quasi-guru in XSLT's. So when a new language comes about, it's a matter of learning a new language construct or few (expansion of the language domain) and then give it a crack. Being bi-lingual is not too difficult. It is probably because not a lot of things have been written under the sun recently that bend the brain.

For the most part, the "spoken language description" or nomenclature of the languages is the same ie: objects, methods, procedures, closures, fucntions, instance variables, parameters etc. So only when someone bakes up a new "thing" and gives it a name, do you have a learning exercise. This is to exclude the obvious of learning a new feature or third party system which is ever-on-going.

For those who have been coding for many years in many languages you will know what I mean. It's fun looking at new languages and it's not long before you are proficient. For ths most part, coding in another language is only slowed by the environment in which it has to operate, so OS, execution platform (JVM, native) the IDEs, no IDE, dynamic, compiled etc.

So .. how about switching the domain in which you are coding for? This, I have not done often. I have currently side stepped from funds management and trading over to insurance. I knew there would be challenges and yes there are. Insurance is another whole industry unto itself, there certainly are links and in the FM and Trading game you come across these links a bit.

It's not so much the concepts of insurance, they are easy, or easy enough, but it's the nomenclature that is used and when it applies, and who owns what. My view point is that I MUST be proficient in understanding the business before I can really code. Sometimes you won't have that luxury, perhaps due to time pressure. But if you work for an ISV or interact with a department, not being able to speak their language gives you no credibility and also makes you untrust worthy. The business domain experts will instantly pick up on this.

I am studying insurance like it's a new degree for me.

.. it's real Domain Driven Design back again (for me). It's fun. It's fun because it's forcing me to think outside the square and, as an outsider (at the moment) see how things work and then twist my brain around it to understand how it hangs together.

A policy, quotations, indications, endorsements, declines.. the list goes on. and to write a system I first have to understand the domain.

It reminds me of 7 years ago when I was first cutting systems for fund management. What a battle in the brain that was. I am finding this new domain a bit easier now than then. Perhaps because I know the right types of questions.

I think working with business people who are amenable to your plight (lack of knowledge) helps, of course :-)

So.. I encourage anyone who faces new domains, often or not often, study it, learn it. You will be noted as a good developer simply because it shows you actually do care. And, BTW, this goes for not only coding, but Systems support and DBA's and everyone.

We are like Vets, we have to know a lot in order to do our job.