I have been reading ‘The Clean Coder’ by “Uncle Bob” Martin and a section on knowing your domain has recently struck home for me.

I have started working with a development team on a proper project (rather than one of my previous trainee ones) and have had a very steep learning curve of the products that this program handles. More so than that I have had no knowledge of what the customers are using the products for or even how they are using them.

It is the responsibility of every software professional to understand the domain of the solutions they are programming. If you are writing an accounting system, you should know the accounting field. You don’t have to be a domain expert, but there is a reasonable amount of due diligence that you ought to engage in.

(Martin. R. The Clean Coder, pg 21)

This became very apparent to me when I was given my first PBI to work on. It was modifying existing functionality to work with an additional product type. One of the functions was outputting a report on the users valid holdings and the other on the users cancelled/replaced holdings.

Simple enough until I compared what products were actually in these reports and saw missing ones on the cancelled/replaced. Due to my lack of knowledge of the domain I had no clue what these products even were and why they were not included. As soon as I asked someone and found out it became obvious.

I should have researched beforehand and understood what products this program was dealing with and it would have saved wasting my time. I now have a list of acronyms concerning the products and client tools and a much greater understanding of the products and services being provided. Although I will continue growing my knowledge base.