Folks often ask me what I do for a living. My pat answer is usually something along the lines of, "I design weird electronic gizmos, mostly for phone companies", or just, "I'm an engineer." If talking with some geek I might say, "I design and write multi-threaded, real-time, embedded firmware". If talking with someone who has money to spend I might just as easily reply, "I'll do anything for a buck."
All of these answers are pretty accurate.
When I tell my relatives I'm an engineer, I think many of them walk away convinced that I drive a train for a living. So, maybe it's about time I describe what I really do here hidden away in my little office.
Many engineering projects spring from the minds of salesmen (or, salesholes, as I affectionately call them). Salesholes seem to be infinitely better at selling things that don't yet exist than they are at selling products already sitting on your company's shelf. Sometimes, salesholes will even go so far as to actually accept a purchase order for a product that doesn't yet exist. We engineers like to call such products "vaporware". An engineer's job is to transform vaporware into real hardware or software before the customer wises up to the saleshole's trick and calls his lawyer.
At the start of every engineering project, the first question always asked is, "How long will it take?" Engineers are often asked this question by their boss's boss's boss while standing at the urinal. Rookie engineers will often make the terrible mistake of actually answering this question midstream. The rookie might say something like, "We need a week or two to study this problem to come up with a realistic estimate. But, I imagine 12 guys could probably get it done in around 18 weeks."
The experienced engineer knows the only portion of this statement that will ever be remembered are the words, "18 weeks". He also knows that the fate of his continued employment may hinge upon such an off-the-cuff estimate, even if he's given only one guy to work on the project, and that guy is already busy juggling three other projects. Yes, the well-seasoned engineer knows better than to casually answer such a question. Instead, he will feign stomach cramps, run to the nearest bathroom stall, and make vile sound effects in an attempt to run his questioner out of the room.
On big projects, someone's usually deemed "Project Manager". This is often the boss's idiot nephew who couldn't engineer his way out of a wet paper sack given a box full of titanium knives. Since real engineers don't want him actually touching anything important, Project Manager is a good assignment for him. He usually spends most of his time trying to figure out how to run Microsoft Project. He finagles numbers in this program to print out important looking, 20-foot long Gantt charts, showing the project is right on schedule. He'll do this even when all the real engineers are screaming that the project is months, or even years behind schedule. In order to get these "pessimistic" engineers to have a "positive attitude", he'll schedule more and more meetings and progress reports until finally all the engineers are spending 100% of their time working on the schedule rather than the project itself. As you might imagine, this is not a guaranteed formula for success.
I firmly believe that Microsoft Project, in the hands of idiots, is one of the primary reasons Microsoft Windows 2000 is still not finished in 2004. The only program more dangerous is Microsoft PowerPoint in the hands of a saleshole.
Even sincere efforts at estimating the time it will take to complete an engineering project sometimes fail. Engineers, on the whole, are a pretty bright lot. So, you'd think they'd over-estimate, then revel in being congratulated for finishing a project ahead of schedule. But, they never do. They always under-estimate. Always. I think this may have something to do with the fact that most engineers have competitive, self-confident, almost cocky personalities. They like to show off their skills and trick people into thinking they know what they're doing. This inevitably leads to them under-estimating the time it will take to complete a project.
At one of my previous jobs, I created quit a stir by assigning each of our engineers an "O-factor" ("O" for optimism). An O-factor of 2.5 means it will usually take the engineer two and a half times longer to complete a task than he estimates. My bosses loved my O-factors. They made for uncannily accurate time estimates.
Most engineers' O-factors fall somewhere in the range of 1.5 to around 3.0. I've never met a single engineer with an O-factor of 1.0 or lower. Never.
I worked with one giddily over-optimistic engineer named Gary. Gary was a sharp engineer. But, ask him how long it would take him to design the Space Shuttle, and he'd confidently estimate around 4 months. I assigned Gary an O-factor of 6.0, and nicknamed him "Doctor O". The nickname stuck with him for years.
By the way, my O-factor is a respectable 1.2. Maybe the wisdom that comes with experience may someday allow me to whittle this down to a perfect 1.0. No. Wait. Who am I kidding? I'm way too cocky to ever get my O-factor down that low.
Once a bureaucracy large enough to slow the project's pace to a crawl has been established, and people have staked their careers on a schedule, it's time to figure out exactly what the new product is supposed to do. Now, I know what you're thinking: Shouldn't you figure out what the product is supposed to do before committing to a schedule? Oh, that would be so very nice. However, in the engineering world, you often don't learn what the new product is really supposed to do until a week or two after its scheduled delivery date.
One of the engineer's primary responsibilities in the early days of a project is to introduce a dose of realism into the saleshole's vision of the new product. For example, a saleshole might have a Bright Idea for a new car that goes something like this: Our new car should traverse backcountry trails like a Hummer, but corner like a Porsche. It must look rugged, like a Dodge truck, but cute, like a VW bug. It should be able to tow a 14-ton trailer, get 78 miles to the gallon, and sell for $7995. And, we must have it ready in three weeks or else the world as we know it will cease to exist.
The engineer, through his training and experience, must present sound reasons for why the saleshole will have to give up some of his Bright Ideas. The saleshole's dreams are sometimes crushed in the process. This is just an unintended bonus for the engineer.
I remember once sitting in a room full of Big Wheels as a new project was being discussed. As the salesholes dictated various features for this new product, I quickly ran some calculations. As I had suspected, one of the salesholes' Bright Ideas required that electrons move faster than the speed of light. I attempted to explain to the Big Wheels that Mother Nature would not allow me to do this. They claimed that an engineer with a "positive attitude" would find some way around this "little problem". They went on to accuse me of having a "bad attitude". In my defense, I explained that I had a very positive attitude. I argued that it was, instead, my calculator that possessed the bad attitude. No matter how I pressed its keys, it kept insisting that their Bright Idea was not possible. After lengthy debate, I finally volunteered to remove my offending calculator from the room.
Bar napkin schematic.
Eventually, after months of the original 18 week schedule have slipped by, the engineer might finally get to do the one and only thing engineers are good at - design something. In my business, this process usually begins with the drawing of a "schematic". A schematic is simply a drawing that shows how individual electronic components are to be wired together. My best schematics have usually been drawn on the backs of bar napkins. Remember, by this point I'm already months behind schedule, and in need of a good, stiff drink. A good draftsman can take a bar napkin drawing and produce a professional looking schematic. A great draftsman will do this plus buy you drinks at the bar.
A portion of a schematic after a draftsman has prettied it up.
There are thousands and thousands of electronic components to choose from. So, you might wonder how an engineer knows which parts to use in his design. He figures this out by reading the "Data Sheets" for various components. Data Sheets are the most boring, complicated, torturous amalgams of words, drawings, and numbers ever devised. I should know. I've written plenty of them. But, in fairness, even Hemmingway would have a difficult time making the life of a quarter-inch square of silicon sound exciting. (I invite you to read some Data Sheets for yourself at places like AMD or Dallas Semiconductor. However, you should probably warn your friends before doing so, just in case you lapse into a coma.)
Most Data Sheets contain dozens and dozens of diagrams similar to this:
Timing diagram.
A rookie engineer, with eyes glazed over from days of reading Data Sheets, might easily overlook the details of this diagram. But, the devil is in the details! This diagram tells the story of how well this little piece of silicon gets along with other little pieces of silicon. It says that this component asserts electrical signals on its pins for only 7 nanoseconds. (That's 7/1,000,000,000ths of a second.) If you overlook this little detail, and wire this component to another component which expects these signals to last for, say, 8 nanoseconds, Bad Things will happen.
Usually, the Bad Thing plays out like this: When the first prototype hardware is built, you'll get a freak 8 nanosecond part that actually manages to keeps pace with the 7 nanosecond part to which it is wired. Thinking your design is flawless, you'll then tell the Big Wheels to go ahead and produce a manufacturing run of 10,000 of these boards. Out of these 10,000 boards, not a single one of them will work. Unless the Big Wheels share your sense of comic irony, this Bad Thing can potentially lead to other Bad Things, like standing in line at the unemployment office.
I've spent an entire career sweating over nanoseconds. So, you can probably imagine how fidgety I get when someone wastes many, many of my nanoseconds by showing up late for meetings. When I schedule a meeting between eight people, I only buy seven doughnuts. This is my way of shamelessly imposing my respect for the nanosecond upon others.
The most complicated Data Sheets are usually those written for microprocessors. Early in my career, I often used Intel's 8085 microprocessor in my designs. Its Data Sheet was around 30 pages long. I had it memorized. But, time marches on, and people, especially salesholes, expect more of electronic gadgets than an old 8085 can handle. The latest hardware design I worked on used an AMD ElanSC520 microprocessor. Its Errata Sheet - that is, the document describing the mistakes they made in the original Data Sheet - is 364 pages long. I have not memorized this document.
Me, using both reading glasses and a magnifying glass in an attempt to put a scope probe on a tiny electronic component.
In what seems an ironic and somewhat cruel twist of fate, electronic components have shrunk in size as my eyes have weakened from decades of reading lengthy Data Sheets in dimly lit bars. My old friend, the 8085, was about four inches long, and only had 40 pins for electrical connections. I could easily connect wires to its pins. The modern-day ElanSC520 is about the size of a dime, and has 268 tiny, tiny little pins. At least that's what I've been told. God knows I've never actually seen these dinky pins with my own eyes.
On the left, mounting pads for the hundreds of tiny pins on a modern-day microprocessor. On the right, my old friend, the 8085. I can actually see its pins.
Fortunately for me, as my eyes have grown weaker, components smaller, and Data Sheets more complex, computer monitors have actually gotten larger. I took this as a sign. Over the years, I've managed to slowly shift my career away from designing electronics with those little, tiny components and more towards writing software on big, giant computer monitors.
Many of the people who think I drive a train for a living also claim they will never, ever use a computer. They are wrong. I can glance around any room and point out dozens of devices that, unbeknownst to their owners, contain a microprocessor. Your telephone, your microwave oven, your car, your stereo, and your television (including its remote) all contain microprocessors, and are stuffed full of software. That's what I do most of the time for a living - I write the software that transforms these devices from lifeless boat anchors into useful gadgets.
So, while the Project Manager is busy finagling dates, and the guys with good eyesight are busy building hardware, I hide in my office for weeks on end writing the software to make the gadget tick.
Over the years, I've written software in dozens and dozens of different software "languages". However, the language I find myself using most often is called "C". (C might seem like a dumb name for a language. But, if you study the history of C, you'll learn that its name makes perfect sense. You see, C is the descendant of another language. That language was named "B". Honest. I couldn't make this stuff up.)
C was the brainchild of Brian Kernighan and Dennis Ritchie - two old Bell Labs guys who I consider heroes. I've grown a long, grey ponytail in an attempt to look just like them. In case you didn't know it, all the world's greatest programmers have long, grey ponytails.
Software written in C looks like this:
That's the kind of stuff I type into my computer all day long (and sometimes, all night long, too). The last project I worked on was pretty typical. It contained around 90,000 lines (about 1,300 pages) of this gobbledy-gook. This may be one of the reasons the ponytails of Kernighan, Ritchie, and me have all turned grey.
Sometimes, after months of feverishly writing code, I actually begin dreaming in C. Software permeates my sleep. The code in my dreams can look something like this:
Dreaming in C can be quite embarrassing if you're also prone to talking in your sleep.
After months of writing code, the engineer's O-factor will usually begin to raise its ugly head. The engineer will be forced to admit that, despite working 100 hours a week, he is a tad behind schedule. For example, he may need around 16 more weeks to complete a task he originally estimated would take 12 weeks. But, fear not! The Project Manager, along Big Wheels, always have a solution to this problem: Hire more programmers! This solution is roughly analogous to thinking that if one bartender can make a drink in 30 seconds, then 100 bartenders can make the same drink in three-tenths of a second. Again, this is not a guaranteed formula for success.
Eventually, the time will come to "integrate" the software and the hardware. This means powering up the hardware for the first time, loading the software into it, and seeing what happens. Integration Day always causes all the participants in the project to gleefully gather around the lab bench, all flush with excitement and high expectations. I don't know why engineers always do this. No conglomeration of virgin hardware and software in the history of engineering has ever worked first try. Not once.
At best, the circuit board will just lie there lifeless, inert, and doing nothing it was intended to do. This happens as 15 highly skilled, expensive engineers stand over it slack-jawed and scratching their heads. More likely, due to some decision one of the engineers made months ago at 3:00 in the morning, the board will explode with a mighty bang, its electrolytic capacitors spewing flame and metallic shrapnel like some high-tech pipe bomb.
Knowing this propensity of circuit boards to explode, my buddy Mark Walker - an exceedingly bright engineer - passed down to me an Integration Day Tradition. As some rookie engineer prepares to power up a circuit board for the first time, Mark and I stand quietly by light switch. I have a heavy binder of Data Sheets at the ready. Just as the rookie engineer switches on power to the circuit board, Mark switches off the lights, and I drop the heavy binder onto the floor. Our Integration Day Tradition has been the source of countless dry cleaning bills, several shoving matches, and at least one Workman's Compensation claim.
Me, as a young, rookie engineer, posing with one of my first "babies".
Despite the schedule pressures, the complexity of the work, and the endless parade of shiny-shoed doofus salesholes, I truly love my job. I love designing stuff. I honestly believe I was born to do it. Truth is, I'd probably write software at home for free had fate not landed me in this profession. (But, I'd appreciate you keeping this a secret from my employer. I also enjoy getting paid.)
To me, there is no greater satisfaction than turning an idea into a bar napkin sketch, then turning that sketch into a living, breathing, working electronic gadget. I've been so proud of many of my designs that I've secretly sneaked into the lab early in the morning to take photographs of my babies. To me, engineering is like childbirth, but without all the mess.
However, both involve a lot of screaming.
So, there you have it. I'm an engineer. That's what I do for a living.
But, if you've got enough money, I'd be happy to drive your train.
Me, doing what I do best.
Direct comments, questions, compliments, and death threats to fred@DumbSoutherner.com.
Copyright © 1996-2004 Fred D. Bean
All rights reserved.
