In engineering school, we are taught that our discipline is about solving problems. We learn proven, methodical approaches to problem solving, and we work to gain the experience and expertise we need to look at a set of requirements and create a solution that most efficiently and elegantly satisfies those requirements.
Our profession is part art and part science.
As engineers, we do not follow the scientific method, but we reap rich bounty from its application. As a painter applies pigments of known color to canvas – creating something that transcends the materials and media in which he works, the engineer applies the elements of science to real-world problems – creating solutions that are elevated above the principles on which they are founded. In considering the difference between art and science, Einstein is reported to have remarked “…even had Newton or Leibniz never lived, the world would have had the calculus, but that if Beethoven had not lived, we would never have had the C-Minor Symphony.”
If we look at Einstein’s observation from a different angle, we see that engineering is often closer to art than science. Our engineering creations are not like basic principles of physics and mathematics – waiting patiently in the ether for us to come along and discover them. They are instead unique and imperfect systems – cosmic compromises that may exist for only a moment – ready to be replaced by more efficient or more relevant machines.
In engineering school, we memorize rough sketches of solutions. We learn and practice the gestures that will later serve us as we tackle unexplored and unsolved challenges. Our pedagogy is like that of the martial artist – repeatedly exercising defenses and counter-attacks to anticipated enemies still unknown and unseen – with the faith that our eventual assailant will bear at least some of the traits for which we trained.
As students, our passion for engineering is driven by the desire to create new things – to tackle the universe and force it, however briefly, to submit to our designs. We hone our powers of problem-solving in controlled isolation before being unleashed on the real world – where friction cannot be assumed to be zero.
What engineering school does not teach well is that we will do our engineering in the world of politicians, accountants, soldiers, and parents. The technical challenges for which we have trained will often be the least of our worries. It is a rare engineer who has the luxury of a requirement like “Get this information from point A to point B as quickly and reliably as possible.” In the real world, even the simplest of design tasks begins with a budget, a boss, and a background. Designing the widget is easy. Doing it in a way that meets schedule, cost, and political constraints can be a thousand times more difficult.
In FPGA design, for example, we constantly advise engineers to maintain a diverse suite of implementation tools. The synthesis software that gives the best results on one design may be the one that utterly fails on the next. We could spend weeks tuning one tool to finally get that last timing path out of negative slack, while the other tool might avoid the problem altogether. While design tools may seem expensive to the uninitiated, they are an absolute bargain when compared against the engineering time and effort they replace. If a $40K “backup” synthesis tool could consistently save a week or two of engineering time per year, or better yet – could allow us to build our design with a cheaper speed grade or smaller FPGA, the savings in BOM, time-to-market, and engineering expense would pay for the tool many times over. Really, if you are doing professional FPGA design for products that will be produced in even modest volumes, you should probably own every synthesis tool on the market.
Bean counting doesn’t work that way.
The tool budget forks away from the payroll budget at a very high level. Even though the fundamental reason for buying tools is to increase productivity, corporate accounting structures make it almost impossible to do the fundamental trade-off of tool cost versus engineering expense that would begin the act of properly balancing those factors.
Saving engineering time is just the beginning, though. If a better tool will let us design a more efficient solution, we might be able to use a smaller battery, a cheaper FPGA, a smaller form-factor – the list goes on and on. If we could produce a better, cheaper product – the financial implications could be enormous. Just a slight drop in the BOM of a high-volume device could pay for a lifetime of term licenses on a decent EDA tool.
Let’s also not forget the advantages of getting the design done sooner. Getting our product to market even a few weeks ahead of our competitors can result in dramatic increases in revenue. Revenue which, ironically, is what the bean counters are there to measure and control in the first place. Bean counters don’t get this, and their influence on decision makers is considerable.
Interestingly, what bean counters cannot counter is fear. While all the “productivity” arguments in the world cannot pry a coin from the cold, dead hand of the typical corporate controller, a “fear” argument works almost every time. If you need a particular tool to reduce the risk of a multi-million dollar ASIC re-spin, the checkbook pops open with a decisive report that echoes throughout the accounts payable department. As engineers, we may find this illogical, but that’s where our technical training lets us down.
Engineering is simultaneously solitary and massively collaborative.
While much of our “real” engineering work is done in quiet solitude, it is a rare project that is the work of only one person. In today’s world, most technology is the product of complex organizations with people of many motivations, temperaments, and talents. While we tend to anthropomorphize companies and ascribe “personalities” to them, it is important to remember that a company is really a collection of individuals – each operating with his or her own biases and goals. At the macro scale, the sum of all those separate behaviors and motives often leads to the swarm moving in the general direction that favors the financial interests of the shareholders. But, like any NP-complete problem, the algorithm is subject to foolery from local optima.
One might conclude that our profession is one that benefits more from people skills than from technical prowess. However, it is easy to demonstrate that this is not the case. A friend of mine who owns a consulting company claims that an “excellent” engineer is worth, in his estimation, forty “average” engineers. Yep, that’s not a typo. “forty.” We don’t want to believe that, of course. It would be nice if the engineering-world value of the person in the next cubicle with two years less experience than you and one less degree was somehow linearly less than yours in a way that fit nicely into corporate salary matrices. Human Resources has spent decades teaching us that this is the case, and the bean counters most certainly want it to be true. But line up two engineers with similar qualifications and have them independently try to solve the same problem and you’re likely to find an enormous difference in performance. Engineer #1 might easily design something with forty times the commercial value of engineer #2.
In the world of bean counting, we don’t want to compensate engineer #1 forty times engineer #2, however. Our sense of social equity in professions like engineering doesn’t mirror, say, our valuation of sports heroes. In sports, we understand the importance of the “franchise player.” In most modern high-tech companies, engineers are valued within a much narrower band. Sure, the founder in an engineering-oriented start-up who happens to be an engineer may garner the same kinds of multiples in compensation that one would expect based on contribution to the bottom line, but such an effect is seldom seen in engineers hired into a pre-existing, functioning company. If you want to earn the big bucks, and you want to be an engineer and not an entrepreneur, your options are severely limited.
But, fear not, fellow engineer. The counting of the beans is not the reason we chose the discipline of engineering from life’s menu of options. While it is true that the lively legume of finance is the fuel that feeds our passionate pursuit of the perfect problem, mere cash is a hollow victory. It is not the monetary rewards that truly drive us to press on in the midnight hour when the last of the Mountain Dew has left the cooler and the flutter of fluorescent sunshine over the empty sea of cubicles makes our eyelids heavy. We are driven by a moment and a feeling. We crave that fleeting second when the LED first blinks on, when the stepper motor initially engages, or when a fuzzy image finally emerges from the darkness. That is the moment when we know that our idea will work. That is the moment when we know we have – however briefly – reversed entropy and shaken our finger in the face of cosmic certainty. That is the moment that nourishes our engineering soul. No scientist can ever know that feeling. No bean counter can ever measure its worth.
