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.
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.
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.
I really like the Swiss Army Knife definition and agree with the commenters who've said that engineers must be writers, which is especially true for those engineers who must write specifications. As for the detective, that has been proven over and over again in our Sherlock Ohms columns, and never better-evidenced than by today's story about hairballs. No definition other than "detective" could amply describe the engineer who solved that problem.
Hopefully I got everone, but, the prize for vocabulary must go to LOU! That is the first time Ihave ever seen the word phenomenologist used correctly in my life! You all may want to consult (a new) Webster's to select exactly what part of the defination you prefer.
In the any case the single most appreciated definition of a good engineer, I believe, has to beTEACHER. Only when one is proficent in ones own discipline can one teach, in depth to others, the multiplcity of talents needed to be proficent as a multifacited engineer; as I also believe most DN readers are.
With patent law and regulatory needs, writing continues to be even more important to the engineer. The regulatory needs is becoming incresingly important in medical, aerospace, and civil engineering fields.
The "hands-on" stuff is the most fun, but the project management, financial, computer skills, and good communication continues to be a greater part of the job. I think PLC programming knowledge continues to become a more valuable skill.
The higher math has largely been replaced by less intuitively-elegant computer numeric methods. Thankfully some of the newer representations provide graphical outputs that again provide more intuitive insight.
It seems more common that you work collaboratively on all projects. If you have other engineers in the facility, it pays to network and know the specialized skills and knowledge of each. Then you can pull in the right consultant for advice that corresponds to their in-depth knowledge.
More and more, engineers are also managers coordinating a wide range of activities and specialists to get specific projects done. While it may take some away from hands-on work they do themselves, engineering leadership and oversight is an important role. Engineers in management may seem to be an oxymoron to some, especially those who have taken Dilbert too seriously over the years.
Good writing skills are absolutely essential as an engineer. Well-written reports, specifications, and other documents are indispensible. It's important to be able to communicate technical ideas effectively to both technical and non-technical audiences. And "effective communication" means more than PowerPoint slides.
Are they robots or androids? We're not exactly sure. Each talking, gesturing Geminoid looks exactly like a real individual, starting with their creator, professor Hiroshi Ishiguro of Osaka University in Japan.
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 discussion will examine what’s possible with smart machines, and what tradeoffs need to be made to implement such a solution.