Jeff Washington - Chief Engineer, LabVIEW Research & Development at National Instruments
When I was in first grade, my grandfather, a tinkerer, built me a fancy train set with switches, houses, and mountains. A few weeks after he gave it to me, I completely disassembled the entire set! This was the first sign of my future career in engineering.
A few years later, my parents bought me a Commodore 64 computer, and my fascination with programming and debugging programs began. I remember using a plug-in cartridge to run a disassembler. That’s just how things worked back then!
In seventh grade, I built my first simple circuit board to use the parallel port of a Commodore 128 to control a modified Radio Shack Armatron robot arm.
In high school, my mother bought me a $400, twenty-five year old, Ford Mustang. When I took the car on a test drive, the hood fell off, flew up in the air, and landed behind the car. Yes, we still bought it. Over the next three years, I rebuilt every mechanical system. During my first test of the brake system, I drove through the back wall of my parent’s garage. Through this single experience, I learned that a tiny cotter pin plays a very important role.
In my role, the most important piece of hardware that I use is simply a flat screen LCD. I prefer to use one that is large enough for an effective use of parallel machines. Ideally, a single screen can fit sufficiently sized windows for source code, debugging, and the application itself.
Remote desktop capabilities allow me to use multiple machines in parallel. Invariably, one machine is busy- thrashing the hard drive, rebooting for some OS patch, or just otherwise unavailable. Because I have so much work to do, I hate to wait on my machine.
Once, over a five month period, I had a background task to track down a mouse-handling bug that would occasionally show up. The bug was not serious, but I could not let it go! While out at conference and performing a demo for thousands of people, the bug (of course) showed up. The audience did not know anything was wrong, but I immediately recognized my old nemesis. At that moment, I stopped my well-rehearsed presentation and took a few seconds to catalog my actions. I made a comment about killing the bug and continued the demonstration. After the conference, I returned to work and killed the bug using the information that I silently gathered during the presentation,
On my bookshelf, you will find books on parenting, marriage and Christianity. I consider all of these topics more challenging than engineering! Engineering is relatively easy in comparison.
I am able to look at a bug report as a challenge instead of a drag. I am very driven by a need to understand. I love to solve puzzles and any good challenge. When I view important aspects of my job as boring, I don’t have as much fun or perform as well. But, when I tell a bug that I will “CRUSH IT,” I am much more motivated. Having a positive attitude is an important trick for facing any life challenge.
In my quest to analyze, disassemble and assemble, I’ve been shocked, burned and bloodied too many times to count. Thankfully, my job was not the source of these injuries.
Sometime over the past year, I was underneath my car on my back. At one point, I misjudged the distance between the back of my head and the concrete floor. I felt what seemed to be an out-of-body experience as the conscious thoughts in my brain contemplated the sensation of my brain physically and literally sloshing around inside my skull.
We live in a world where algorithms are more complicated and compute intensive, and hardware platforms are much more parallel. The difficulty of designing, simulating, testing, debugging and deploying solutions with higher performance requirements and complexity has significantly increased for engineers.
The age of the single desktop CPU consistently doubling in speed appears to be over. This produces a heavy burden on engineers as we seek to deliver increased performance to our users. We want to help them achieve efficient parallel implementations without being burdened with onerous implementation details.
My current job is to enable our tools to aide users through the design flow- from algorithmic concept to hardware deployment.
In high school, I told my mother that I wanted to design super computers.
Over twenty years later, I help other engineers run applications on heterogeneous hardware targets containing massive, parallel FPGAs and multicore CPUs. This is not that far off from my original career aspirations!
Computers continue to be difficult to use. Recently, I walked my son through the task of adding a graph to display his data into a different presentation application for his science homework. I cringed as there were so many hurdles for him to overcome. Over my lifetime, this task has become easier but is still not as accessible as it needs to be.
I spent my scholastic career despising anything related to English class. My constant refrain was, “I’m going to be an engineer. I don’t need to write.” My internal chronometer now reminds me to annually call my grandmother and thank her for forcing me to practice writing. I have to write all the time! An idea that cannot be communicated in writing is diminished and may never come to fruition.
Two simple things: humility and confidence. These two traits have revolutionized my career and life.
I am humble when I’m ready to ask, listen, receive correction, and work well with others. Now, I come to expect that there are others who will have better ideas than me. As engineers, we should use the best ideas.
Having confidence means that I am not afraid to ask questions, look stupid, or fail at a task. I also understand that I may not be the best choice for a particular role.
Wisdom and insight gained from experience are valuable. It took me too long to learn this truth. There is an experienced and humble engineer in my life who constantly reminds me that my fast, skilled, efficient efforts can easily produce worthless results if I am ignorantly working in the wrong direction. He has made my jaw drop as he calmly and quietly arrived at a solution while I sped through an issue missing the root problem. I have learned to think, listen and ask before unleashing whatever degree of “ninja” coding skills I possess. Over time, I have learned to respect the wisdom, experience, and age of others.