Domain Training

When I think back on the software development jobs I’ve had it’s been across the following domains:

  1. Utility software network outage monitoring systems
  2. Dental insurance
  3. Private equity
  4. Financial data collection
  5. Credit risk assessment (I was purely on the operations side for this one so domain was irrelevant)
  6. Merchant marketplace
  7. Smart meter management

And with the exception of number 5, which was not relevant, I have never, not once, recieved any official training on the domain. At best I was pointed at a shared folder with a handful of out of date, barely relevant documents and told to get on with it.

In every company, I’ve learned about the domain from co-workers, looking at the code, bug-fixes and just ‘picking it up as I went along’. Eventually after about 3-6 months I’d have a reasonably coherent model of how things should work and then a business analyst comes over and says “Oh no, we don’t do it like that at all”.

Of course, the people who actually know how things work are too valuable to waste their time on something as irrelevant and trivial as basic, entry-level documentation.

When you think of how much time is wasted by new joinees (not just developers) learning how things should work, it does seem like a false economy.

It feels a little bit like the situation, when, as a new developer you have to set up your development system for the first time and you can end up spending a week (or more) getting everything ‘just right’. Whereas, any sane office has a standard development VM image and just rolls that out as needed.

So, free money saving advice for any managers out there. Write some entry-level documentation.

This entry was posted in Development. Bookmark the permalink.

Comments are closed.