When I was in college taking freshman year chemistry I wanted to have a leg up on my finals. Chemistry wasn’t my thing, but I wasn’t horrible at it. I was getting Bs and Cs. So, I set out to write a program for my TI-92 graphing calculator that could look up chemical elements from periodic table, draw orbitals, and balance chemical equations. I called it “TETRIS” so that a teaching assistant checking my calculator at the exams would think I just have a game on it. By the time I perfected this program I not only knew the entire periodic table by heart, I could draw an orbital model of any element and balance chemical equations in my head without even using a piece of paper.
At my last job I worked on high frequency trading and I had to get FINRA Series 7 registration. On top of technical knowledge I had to become a domain expert in US equities trading. I don’t think there was any point in my career where I did not have to develop an intimate understanding of the business area my application was in.
I often see non technical people throw their hands up in the air and give up on things like SQL, Json, git, some advanced Excel features. I took a class on asset securitization a few years ago for my job. We had to come up with a mathematical model that represented an auto lease securitization prospectus we were given and could show anticipated investment returns under different scenarios. I saw expert financial analysts fudge their models half way through their spreadsheets to make the numbers match the prospectus because they couldn’t write an Excel macro! Meanwhile, as a software engineer I took a technical approach to the problem and came up with a mathematical model that required no tweaking regardless of the conditions – because I wrote my model in Python. No wonder our economy collapsed in 2008 – the very people entrusted with building the right investment models fudge their spreadsheets to make them look right.
The reality is that in order to build quality products software engineers have an additional burden of having to become domain experts. On the other side of this coin, business people who think they can shy away from technology really could benefit from expanding their skill set to run better businesses. But in the meantime, give software engineers in your company some credit where it is due – they are not just experts in technology, they could probably run your company better than you can.
2 thoughts on “Software Engineering and Domain Area Expertise”
Comments are closed.