For years I had a MD as a family doctor, and for most of my life thought that all family practitioners were required to be an MD. He was a perfectly fine doctor as far as modern medicine goes. He’d listen to my list of my symptoms, do a cursory stats check, and pull out the prescription pad… He would be on to the next patient without spending more than 10 minutes with me.
I moved several years ago and changed doctors and was surprised to find that my new doctor was a DO, not an MD.
His approach to health care was very different. He actually spent time getting to know me, what my diet, habits, and work life was like. He felt that having a good understanding of the bigger picture would help provide a more thorough solution to his patients’ problems than simply prescribing a pill that matched the symptoms. His view was that the symptoms are not the problem, they are the result of the problem.
It occurs to me that is what I have become in my field.
I started out as a Control Engineer strictly drawing schematics and writing PLC, servo, HMI, and robot code. But as time went by I found myself intrigued by the business needs of the companies that these machines went into. Just the simple act of installing a large piece of automation creates an astonishing amount of redundant work to accommodate it.
Supervisors spent countless hours in establishing procedures and scheduling work, employees dealt with redundant computer systems and duplicated effort dealing with work orders, managers were struggling to find better ways to gather statistics and generate reports, while IT departments balked at the notion of putting automation on the corporate network.
Clearly there was a hole here that no-one noticed. These companies were filled with brilliant engineers and developers, yet they all sat firmly in their own sandbox. There are no specialists for the no-man’s land between the sandboxes.
The problem is, of course, the fact that different disciplines live by different rules and paradigms. If you’ve ever sat in a meeting between Microsoft developers and controls engineers as they try to work on a project together, you know what I mean. Each type of development has its own set of rules and best-practices that are optimized for their particular sandbox, and anything that does not fit that model is inherently viewed as “wrong” somehow.
My career path took me into database and ERP integration where developing desktop, web, and Windows Services in Visual Studio were the norm. My time was spent equally in SQL Server SSIS package development, reporting, and network traffic analysis as it was building machines.
Somewhere along the way I discovered I had picked up the ability to communicate equally well with .NET developers as I could automation engineers. I could discuss network traffic security without IT looking at me like I was the enemy, and I could sit in a roomful of managers with limited technical vocabulary and get them to understand the technical nuances of a project that used to only get glazed stares.
I had become a holistic software engineer.
Today when I’m presented with a problem, instead of jumping into PLC code and making some quick changes, I ask questions. People have this remarkable ability to work around what they consider a minor nuisance so for every major problem with a machine or process, there are at least half a dozen smaller related issues that are overlooked or unreported.
My job is to ask questions, to find that common root problem, and to craft a solution that not only fixes the main complaint but also addressed those complaints that have not been noticed yet. Because the symptom is not the problem, it’s a result of the problem.
My advice to anyone, particularly in the engineering field is this: step into someone else’s sandbox. Learn to first follow, then understand, then appreciate and embrace their model of the world. It will make you an invaluable resource in more ways than you could ever imagine.