July 2018 - Edition 01, What is an Engineer

Introduction

This is the inaugural newsletter for Sigma Expert Solutions. The intention is to discuss all manner of topics from the perspective of an engineer. Usually that engineer will be me (Demetrius Siachames), but I may insert other perspectives at my discretion. In this initial edition, I will briefly discuss my intentions on what this newsletter will be, or more precisely, what it won’t be. In future editions I will not rehash the newsletter intent. There will be no common engineering subject area for all newsletters, as I believe a good engineer has knowledge of all areas and knows how to connect them. Engineering lingo will be held to a minimum (as well as can be avoided). There will be no attack on the opinions or ideas of others. This is not an advertisement for Sigma Expert Solutions. The views and opinions expressed will be “pure” and unadulterated. No attempt will be made to placate an alternate viewpoint by softening the opinions. Comments and suggestions are greatly appreciated in this process, and can be directed to newsletter@sigmaexpertsolutions.com.

Demetri's Corner

Every newsletter, I’ll start with my reflection on the time since the last newsletter. In this edition, the elephant in the room must be addressed. The reason this is the first newsletter is because this is the first week in which SES has been in business. As sole proprietor, this is a thrilling and scary time. I moved from being part of an established engineering consulting company where work was plentiful, clients readily available, and infrastructure in place to having none of that safety net. I have just the contacts I’ve made as an engineer, my personal relationships, and a cheap computer. So needless to say, the future is uncertain. Someone I recently spoke to likened it to skydiving. I like that comparison. At this point I’ve stepped out of the plane, gotten through the initial disbelief that it happened, and am enjoying the experience, with the ever-constant knowledge that my chute may not open. It’s a process I’ve been wanting to go through since college, but my sense of responsibility is higher now that I’m an “adult”.

So on to the good stuff!

Today's Subject - What is an engineer?

The question is so fundamental. Yet if I were to put 100 engineers in a room and ask them to write it down, I’m certain I would get around 20 different answers. They would probably range anywhere from someone who knows a lot of math and science, to a technical expert in a field, to something related to manufacturing or process control. In my opinion, all of those answers may be all correct, or completely wrong. They completely miss the point. So here is my definition.

Engineers are people that solve problems by finding the optimal balance of competing factors under specific constraints using incomplete information.

I really let you down on that one. It’s punchy, but what does it mean? And I don’t see any mention of math, or science, or technology, or data processing, or programming… Well, there lies the problem. We think about what engineers DO rather than what they ARE. I use tools, which is clearly a characteristic of something humans do, but that doesn’t define me as human. The critical feature that sets an engineer apart from analysts or scientists is the ability to make complex decisions without being fully informed balancing competing factors. Sounds fun! Basically we get to make it up. There is a catch – we are responsible for the consequences of being wrong. So anyone willing to make consequential judgements based on incomplete information can qualify.

But perhaps we should narrow our focus to the application of the definition to the more classical engineering disciplines, because if we don’t, pretty much any problem solver could be considered an engineer. To do that in this construct, we need to consider the bound of knowledge and expertise which we will consider within the purview of the engineer. I find that rather hard to define, so I would rather consider the tools used to solve the problems the best definition. That brings us back to math and science as the primary tools used by an engineer in their problem solving endeavors. But this is extremely broad – much broader than people realize.

In today’s world, much of the technical aspects of engineering are mostly figured out. It’s mostly either a matter of putting the pieces together in a novel way to solve problems, or coming up with new applications of past solutions. So much of what was in an engineer’s toolbox – and still is coming out of college – is mostly useless or will be quickly supplanted by different tools. Why would I hand calculate the efficiency of a steam turbine given process conditions when I can quickly code a simulation of the whole cycle and measure the output? There is certainly value in understanding the core principles, and they should be revisited often. But when it comes to providing a solution where the consequences are real, the best tools should be leveraged, and rarely does that involve someone figuring out complex math on a sheet of paper at this point.

So what has engineering become? Is it dead? Could computers completely replace engineers? I would argue the exact opposite. Go back to the original definition, and specifically the aspect of “incomplete information”. This is where the value truly lies. It is also the aspect which is the hardest to teach or judge capability, therefore hundreds of times harder to code into an algorithm. The world has too many unknowns and variables to be properly calculated by a defined algorithm. Computers and robots could easily replace much of what people think of as engineers, such as design calculations, drawing reviews, system interaction analyses, etc. But that’s not engineering.

Of course this opens the door to Artificial Intelligence, but I would claim that it will be centuries before this is anything more than fancier algorithms better at collecting and processing data at higher rates of speed. This may simulate some aspects of what an engineer does, but will never replace them for the foreseeable future. Not to mention, it’s a lot harder to “hack” an ethical engineer than a computer system, so for really critical things, engineers will still be the final word.

OK, so now that we’ve established that the tools we all leave college with are relics, what do we need to know? That answer will be different at every moment and for every situation. So what are we to do? This is where engineers need to have a realization that continuing education is our only salvation. But that doesn’t necessarily mean learning the latest and greatest version of the latest ASME code, or boning up on your ANSYS skills. It could mean learning how to use P6 so that the complex interactions between a design are captured and the project doesn’t go off the rails. It could mean learning how to analyze electrical circuits even though you’ve been doing ANSYS analyses for the last 10 years. Basically, it means being able to quickly become “dangerous” in a subject, and then “being dangerous”.

That sounds bad. And risky. And scary. But that is why engineers are needed. Somebody has got to do it. As a wise woman once told me, “If it was easy, everyone would be doing it.” (thanks Mom).

Dose of Aphorisms

I am well known (and despised) for my regular use of aphorisms. So to continue that tradition, I will be forcing this audience to hear a few every once in a while. If I know that someone else came up with them, they will be credited. Otherwise all complaints can be directed at Demetrius Siachames.

Accept that as an engineer you will always be wrong. It’s your job to be less wrong about the important stuff.

Explanation of Fields in the SMARRT form submission

Reference Scenario Inputs:


Number of People Infected – How many potential members of the gathering are infectious. The simulation starts when they enter (time=0).

Type of Activity – Impacts the number of particles spread as aerosols per respiration. More strenuous activities result in more viroid particles being released.

Air Changes per Hour – This is the air exchange rate with fresh air for the volume of air being breathed by the gathering. If you use forced air exchange, you can calculate the number of air changes per hour for your specific situation.

Space Floor Area and Ceiling Height – These are used to calculate the total space volume.

Duration Infectious Person is Present – This is how long the infectious person stays in the space after their initial entry. For the reference scenario, this defines the end of the simulation.

Gathering Scenario Inputs:

See the reference scenario for all inputs up to Time of space entry.

Time of space entry and exit – These values represent when you enter and leave the space referenced to the infectious person. For example, if you show up fifteen minutes late, but stay an hour after the end of a one hour party, the Duration Infectious Person is Present is 60 minutes, the Time of Space Entry 15 minutes, and the Time of Space Exit 120 minutes