We're expected to cover a wide variety of fields for a given project, including mechanical power transmission, electrical circuit protection, servo driven motion control, hydraulics, pneumatics, magnetics, lubrication, optics, and chemical compatibility. That's a pretty diverse list. The term "engineer" is used as a catchall, but it doesn't convey the broad list of tasks and fields we must cover to solve that problem.
What are we, then? We're the multi-talented, multi-skilled tool used to solve problems -- society's Swiss Army knife.
Oh, there may be some tasks needing a larger blade than that found on a Swiss Army knife. Some of us are highly specialized. Some focus on one or two aspects of the problem to be solved. One way or the other, we're going to cut right to the heart of the problem.
Even though National Engineers Week has passed, get the word out -- tell people what sort of knife you are.
So true!! Most of the engineers I work with hate writing and try to avoid it at all costs. They complain when anyone corrects their grammar saying it doesn't matter. They are generally the first to complain when they get a poorly written spec. They don't realize probably at some point the author of the document got similar feedback. As a systems engineer, I write a lot... a lot... and try to always improve on my writing skills (not my area of expertise) which is real important part of my duties.
TJ's post cuts to the root of the problem which plagues engineers--the lack of respect accorded to the profession. I think this in part stems from the fact that there really is no single, clear, agreed upon definition. When an engineer can be described by the many, many hats she or he wears, I submit that there's no single hat which fits comfortably. A doctor cures sick people. End of story. A lawyer fights for his/her client. A baker makes bread and cake. But engineers, well, they do everything. Unfortunately, that's why so many people call themselves engineers, schooled or not. But I guess that's another debate, one we've had many times on this site.
Beth, they're all critical; that's the point. I am reluctant to pin down anything specific. The really good swiss army knife engineer knows he (she!) is a special generalist, and knows his (her!) limitations. Upon hitting a limit, the SAK engineer can either learn to add depth, or call in one of those big badass Rambo knife specialists. The good SAK engineers know when there's time to learn, and when to get the specialist.
Hmmm. I think those letters might look good on a business card.
I'll never forget my interview with Dallas Semiconductor when I was fresh out of school (Dallas Semiconductor is now a subsidiary of Maxim so we are going back a ways). The guy interviewing me wanted to know how I got along with people and if I worked well with others. He informed me that my degree told him I had a good foundation in electronics (not to mention the grueling technical testing that I had endured in multiple interviews, but I wisely kept my mouth shut) – what he needed to determine is if I could work well with others and that I had good oral and written communication skills. I must say over the years those skills served me well. Documentation is my least favorite engineering chore. However, I was often a hero because I actually commented my code as a test engineer which resulted in much faster troubleshooting and modifications then the guys who didn't...I might not look at a test set for years but if called upon – I could quickly orient myself and usually rapidly narrow in on the problem area.
The secret to my success as an engineer has been not knowing everything, but knowing how to get the information I needed...research is an essential skill and it could be as easy as referencing an old textbook or calling a tech support line, or taking the initiative to create an engineering set up (could be anything - I used to work at a company that made hall effect sensors and every product was new so we had to figure out how to test them which first meant designing circuits to drive coils, figuring out what current supplies would do what we needed, learning about magnetic fields and playing with gauss meters etc.) that one can use to experiment with to determine the best approach for the task at hand.
An engineer also needs to be part savvy – selecting components that he will be able to get replacements for, and to know to determine lead times when ordering parts so that the project doesn't get held up waiting for something to come in...
TJ, your question implies a lot, "How do you define an Engineer" and who is an engineer. I think most of us have university engineering Degree and PG certificates. But, how many of us are using the really engineering skills in our day to day professional and personal life. I think only a minimal; personally speaking I have master's degree in engineering and doing draftsman's work in my company.
In IT also most of the engineering graduates and post graduates are doing simple coding works, which can simply manage by a person with six months diploma in same domain.
You raise an interesting point, Alex. Engineering does become the catch-all phrase for a variety of skills, often those not even remotely connected to the discipline we think of classic engineering. Something that just came to mind in reading your comments is "sanitation engineer" and I'm sure we could think of others.
Many engineers do indeed take on many widely varying tasks, but I have not noticed one mentioned that I find quite important.
A good, and especially a great engineer is a true artist. This is the reason machines cannot be programmed to be engineers. Development environments might help take care of many low-level mundane tasks for the engineer, but the engineer creates. Regardless of the product definition (which often comes from the engineer), the engineer is the creative force that makes the design what it is.
The legacy endpoint devices that control our critical infrastructure (utility systems, water treatment plants, military networks, industrial control systems, etc.) are some of the most vulnerable devices on the Internet.
For industrial control applications, or even a simple assembly line, that machine can go almost 24/7 without a break. But what happens when the task is a little more complex? That’s where the “smart” machine would come in. The smart machine is one that has some simple (or complex in some cases) processing capability to be able to adapt to changing conditions. Such machines are suited for a host of applications, including automotive, aerospace, defense, medical, computers and electronics, telecommunications, consumer goods, and so on. This radio show will show what’s possible with smart machines, and what tradeoffs need to be made to implement such a solution.