Guest post: What is an engineer? by Chris Gammell
I’ve been having what some would call an identity crisis. How, you ask? I’ve been working on digital electronics.
*GASP*!
I found out that in the early 90s and even earlier, analog engineers routinely switched from working in the analog domain to the digital domain…because it was paying really great. Not only that, most analog engineers had the expertise to do what most early digital engineers were doing (basically stringing together a lot of digital gates in DIP packages). It wasn’t until later that digital engineers started acting more as programmers and VHDL/Verilog experts.
So why do I bring this up? Because I’ve been thinking about the versatility required from engineers in general, not just analog or digital engineers. Routinely engineers are asked to switch modes or tasks or careers in order to get a job done. It’s not that other professions are never asked this; it’s just that the chameleon-like requirement placed on engineers seems to define the profession. Allow me to explain.
What is an engineer?
An engineer puts theories into practice using available devices and elements. They create new products and pass on knowledge through design iterations and trial and error. Their work should be directly applicable to the real world (sometimes in the form of an end-product, sometimes not) and hopefully able to be reproduced successfully in the same form for multiple parties (mass manufacturing). Engineers are often rooted in math and science but require a wide range of skill-sets in order to properly construct an end product.
I think it is important to note that an engineer is different from a scientist, although the line can often be blurred (especially when looking back at the inventors of the early 20th century). In modern times a scientist is usually tasked with pushing the barrier and finding new theories and concepts. This means that the concept will not necessarily be available in product form right away (although this is not always the case), as the product form must be iterated upon and improved for production.
Another interesting point is how the above definition manifests itself in higher education. When I was in school, the focus was definitely on making engineering scientists, that is engineers who are taught to research new methodologies and concepts with the final product in mind. There was much less focus on using existing products (i.e. discrete transistors) to create something new or to solve a problem. I do not think that it is a huge problem, as some of my classmates went on to work on their Master’s degrees or to work in research labs. The rest of us trying to break into industry were a little more strapped on what is expected from an engineer. Let’s go over what some of these things might be.
Engineering is a field I entered because of the myriad things I could work on throughout my career. I did not switch to the digital domain for the money. I switched to digital work because I was asked to and it has been really interesting so far. Programmable logic is something I’ve worked on in the past and something I’m sure will become more prevalent in the workplace as design requirements become more stringent and timetables get shorter. If you are an engineering student or an aspiring engineer reading this article, I would highly suggest the profession (just make sure you note the above points). If you’re an experience engineer, please feel free to leave your experience in the comments. Thanks for reading.
Chris Gammell 24 year old engineer from Cleveland Ohio who publishes
the Chris Gammell’s Analog Life
Related: Open Access Education Materials - Engineers Should Follow Their Hearts - S&P 500 CEOs, Again Engineering Graduates Lead - posts on engineers
Curious Cat Science and Engineering Blog © curiouscat.com 2005-2008 powered by WordPress
Curious Cat Alumni Connections
September 8th, 2008 at 4:19 pm
Chris: I thoroughly enjoyed this article being a hardcore engineer at heart. I am glad you stressed the importance of math knowledge; and this is important not only for electrical engineers but even for metallurgical engineers. I for one was amazed to meet some metallurgical engineers that could not even understand what a fourier transformation is, and did not even know the basics of differential calculus. How does such a person solve complicated problems of fracture mechanics then, which is very much a part of materials and metallurgical engineering? Therefore, I am glad that you brought forth the importance of math skills for the aspiring engineer. There is one other item I would like to bring forth and see if you agree and that is the engineer needs to come up with the lowest cost practical solution to a problem in order for his solution to be of commercial value. Many engineers seem to discount the effect of economics in real life. Anyway, great article. Thank you.
September 12th, 2008 at 12:56 pm
Hi Raj!
Thanks for commenting, I’m always glad when others read the stuff that I write and I was very grateful to John for re-posting this article. In fact, part of my newest post (see the link on my name) take your question into account. I wrote it more about young engineers entering first and second jobs and wanting to shake things up, but not knowing the implications (cost and time). Of course, this is not limited to just the younger engineers. I think a bit of business acumen on the part of all engineers would do many different corporations some good (government contractors come to mind). A little bit of business skills and managing to keep their solutions simple, yet effective can make for a great all-around engineer. Thanks again Raj, hope to hear from you soon.
Chris
October 2nd, 2008 at 3:28 pm
I enjoyed the points above especially with respect to solving solutions in the simplest manner possible. I’m a design engineer who continually has to refine my tool set for evolving problems every day. If I looked for the best solution every time, we would never get the projects finished. It is therefore important to concentrate on the getting to final result rather than the processes involved in getting to the result. I notice this with system architects who design ingenious solutions but are difficult to implement and even harder to maintain