Everything I Ever Wanted
Engineering was never something that I intended on doing. In college, I didn’t know what I wanted to do, but I was good with math type stuff. During my soul searching phase of my freshman year, my girlfriend at the time said, You should be an engineer! I did a little bit of research and looked at all the different types of engineers, saw Electrical/Computer and thought to myself Yeah, I like computers and I had fun in physics, that could work! So I signed up, first for Electrical Engineering - later signing up for Computer Engineering after realizing it wasn’t hard to double degree.
After a few semesters of classwork, I had the stereotypical thought of what I wanted to do. I was going to get a job where I would be making widgets…or something…maybe components which would go into some kind of product. I didn’t really care about the details, but I knew that is what I wanted to do. I was sure of it. As I was currently a Master of the Custodial Arts at that time, I figured the best way to get to where I wanted to go, would be to get a technical job. After a few jobs here and there, I finally landed an embedded software engineer position at a small, local business which produced solar powered refrigeration solutions. I was finally doing it! Developing for the control circuitry which would go into products. As an aside, I still talk to the owner of that company, and he says how they are still using the code I wrote in some of their products, that’s such a cool feeling.
The Unseen Turn
The company had solar panels, connected in large arrays, which provided the power for the products during development. They didn’t have too many other solutions as far as power went, so that’s what was used. As can be guessed, using solar power was not the most reliable way of doing things. The biggest problem being that we were unable to forecast or count on the weather conditions (i.e. our test conditions) for any day. Or more specifically, we were limited by the power output of the solar array at the exact time we were running things. This severely limited our ability to test how the system would respond under some set conditions. So if we wanted to test something, we’d have to wait for a similar day to come around, and hopefully we’d be able to test at that time.
I ended up creating a solar array simulator using some programmable power supplies they had lying around. It could run through different events in a typical day, different cloud coverings, random dropouts in power, etc. It took a while to develop, and to work out all the different ways that we could exercise the product to see how it performed. The best part, everything would behave exactly the same, every time. No more waiting for a day that looks like it’d be as sunny as yesterday, or having to redo a test because an afternoon storm came in and ruined everything.
This project also led me to work on a few other projects the company was working on, in which they needed to make sure everything worked right, or how they could get some characterizations done better. Again, I’d tell myself, I’m just trying to get all of these products out, and if I have to write a little code, and focus on the testing side of things for a little, no big deal.
Believing the Lie
Cut to a few years later, I was working at another small company which mainly did subcontracting in the defense industry. My first project at this company was to work with a team who was developing an engine controller for large ships. Specifically, I would mainly be testing out with building an automated test setup for running the engine controller through it’s paces, without needing to attach it to an actual engine - or for debugging faulty controllers which were behaving oddly while attached to engines.
I was creating a product which would probably get shipped out to customers, not in high volume, but still would get shipped out. If not, the company would keep the products and use the automated test setups for doing repairs or failure analysis on returned devices. All in all, I say I was still going down the road I had originally set out on. I was building widgets for customers, if I blurred my eyes a little and squinted funny at it.
Coming into Focus
Cut to my undergraduate graduation, my girlfriend at the time got a job in a different city. I decided to move with her, and look for a job in the new city. I had a few friends who had moved to the same place, so I reached out to them to find a new job.
When I started talking with one of my buddies, he had said he worked as a software engineer. I thought Perfect! I had experience doing embedded work at my previous positions, so I’d be a great fit! After sending him my resume though, he came back and said that I would probably fit in with the validation group. What?! Validation Group? I was a embedded software guy, and an electrical guy. What did he mean validation? My buddy was the type to forget to follow-through, and with his recommendation, I didn’t mind that he forgot.
After talking to another friend of mine at a different company, I got some interviews for a Product Engineering job at a big semiconductor company. I wasn’t quite sure what a product engineer did, but during the interview it started to be pretty close to validation/test. While they were explaining what this all entailed, it hit me that it was exactly what I had been doing for some time now. I actually was a good fit for validation, so I took the job.
I began understanding the intricacies involved with testing products. Things like repeatability, reliability, accuracy, or precision, all the problems which have to be tackled. Hard problems. Rather than figuring out how to get an OpAmp to work, we had to figure out how to ensure it worked as specified and with enough confidence in our measurements that we could still produce a level of quality our customers had come to expect.
With new products coming out all the time, we had to constantly be looking for ways to push the limits of our setups, and if necessary build better ones. We also didn’t have unlimited resources, so figuring out the best way to automate things was another large endeavor. There were/are lots of problems which need to be solved in the validation/characterization stage of things, which can prevent bugs in hardware - which cost much more to fix.
One benefit from being a part of all this, was that my group ended up knowing the products better than any other teams involved. The design team had an understanding of how things should work, they have their simulations and any one person involved worked on a portion of the product. Simulations are based on models, and models are best guesses of reality, and are therefore flawed. Their work on the project only inflamed the designers' hubris, and led to many fights about whether a test was broken, or the design itself (spoiler, the design was usually flawed)
Puzzle-mania!
As I tend to be on the younger side of my work groups, I tend to be the one selected for going to university career fairs for recruitment, or interviewing intern/new college graduate candidates. Every time that I talk to someone who is fresh to the workforce, I am looking at a younger version of myself. I see the same questioning look when I ask if they know what test engineering is.
I usually start off with asking them what they want to do, or what type of job they can see themselves working on in 5/10/25 years from now. There is the typical kiss-ass response that I get, but when they are actually speaking truthfully, it ends up being I want to do component design! (or something to that effect). I hear this and just laugh a little to myself, and start telling them that there’s more to engineering than that, many different avenues which they can explore.
I then start to give an overview of the product design life-cycle (at least at the company I work for), and how marketing and architecture come up with new ideas, then design implements it, then test takes it through the ringer. We are the first ones actually using the part, the first ones who get to see if/how things are working. We have access to the circuit design and Verilog code (as well as the physical layout), so if we do find something wrong, we don’t just kick it back to design, we look at what’s causing the issues.
Every day is a new puzzle, and there’s no googling the solution. There is no solution until you make one. You are constantly treading on new terrain, and discovering how the newest technologies behave when brought to life. This endless exploration leads to constant doubt, not just about the thing being tested, but also about the tests itself. You need to constantly ensure that the environment you’re using is working to level needed. Since the behavior of the new product is unknown, any irregularities could arise from inconsistencies of your setup.
A lasting change
No matter what I’m working on, I always have that voice in the back of my mind asking, How will this break? I am looking out for edge cases, or fallacies in the assumptions made when coming up with project requirements. I spend a lot of time trying to pre-test the system, or at least give myself or my team avenues to test the inner workings, as I know that it will become necessary later on.
Maybe that voice was always there, telling me what to do. That would explain why the positions I held pushed me in a direction I wasn’t aware of. I always said I wanted to build components, robots, widgets, or whatever. However, I always did testing and validation.