Categories
Analog Electronics Learning Life Work

What is an engineer?

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.

  1. Flexibility — This could be a theme of this article. Engineers have to be flexible and think on their feet. Again, I’m not saying scientists and other professions do not have to do this, only that it is required for many engineers. I went into my first job (working in a fab) as an electrical engineer student and ended up looking at chemical reactions and doing process engineering. The company I worked for didn’t want an electrical engineer, they wanted and engineer, someone they could teach their methods to and who could pick up the nuances as quickly as possible. I think it’s also important to note that they didn’t just hire engineers, they also hired scientists (don’t worry, I like scientists).
  2. Science and math knowledge — No surprise here, you have to know the basics in order to really get going in the field. However, I think that the interesting thing is that the basics is usually the majority of what you need. I used Ohm’s Law more often in practice than I use the knowledge of how to do the third integral of a sphere.
  3. Design re-use and not trying to re-invent the wheel — This was actually the reason I wanted to write this post, to point out that engineers often enter the field thinking they will be designing every piece of a system from the ground up. First off, this is irresponsible. The industries would never have standards if every engineering firm was trying to redesign a buck-boost converter everyday. Instead, engineers use optimized solutions available from vendors. Not only does it help standardize, it saves time.
  4. KISS — This directly relates to the above point. You have to keep it simple, because there are only 24 hours in a day. I have claimed to be a system designer before (or at least will be). To design a full system, you have to look at the simplest and fastest solutions because they are often the best and most elegant solutions. Not only that, if you don’t do it as fast and simple as possible, someone else will, and then you’ll lose out on a customer, contract, etc.
  5. Learning is pain — Even though continual learning is one of the main reasons I got into engineering, it’s not always fun. It’s not a great feeling when someone asks you to do something and then you have to slink away because you have no clue how to do it. Hopefully you’re slinking to go learn about it and not running away, but that is dependent on the person. The point is, learning is a difficult process and we really learn the most when we’re in situations that stretch us to the limits. In my experience, I always learned more in classes where I worked to get a C than in the ones where I breezed by and got an A.

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.

By Chris Gammell

Chris Gammell is an engineer who talks more than most other engineers. He also writes, makes videos and a couple podcasts. While analog electronics happen to be his primary interests, he also dablles in FPGAs and system level design.

8 replies on “What is an engineer?”

I agree with you Chris, this is a great article. Although I didn’t learn much in the classes where I got a C, those are some excellent points. Since I’m in somewhat of a specialized field, we reinvent everything, even when we claim we are going to use “proven” designs. I guess that is life though, if we weren’t busy reinventing everything, I probably wouldn’t have a job. Lets all take a moment to appreciate this unusual situation where I appreciate inefficiency…

Ok, now that that’s over, good post!

Hey Chris… good post, and I wanted to add a few things. Because of our technical knowledge, us engineers are in a unique position within our companies to interact with customers. Where I work, because I know all of the details on how to use the equipment and supplies we sell (I actually use the stuff every day!), customers and potential customers call ME for help. In this capacity, I must be very good in customer service, with a touch of salesmanship as well. I also must work with our marketing department, because they don’t know what kind of features on the equipment to highlight in advertisements, or the proper way to set up a machine to snap a good picture. I have been exposed to a wider variety of roles once I started working than I ever thought I would, even knowing as an engineer I would have to be flexible.

[…] C coding — Sorry to all you analog purists out there, but at some point as an engineer, you need to know how to code. Furthermore, if you’re going to learn how to code, my personal preference for languages to start with is C. Not too many other languages have been around for as long nor are they as closely tied to hardware (C is good for writing low level drivers that interpret what circuits are saying so they can talk to computers). I’m not saying higher level languages don’t have their place, but I think that C is a much better place to start because many other languages (C++, JAVA, etc) have similar structure and can quickly be learned if you know C. Even though the learning curve is higher for C, I think it is worth it in the end and would love to see some college programs migrate back towards these kinds of languages, especially as embedded systems seem to be everywhere these days. […]

Comments are closed.