Drawing out a solution
"Let's go over it again," he said, and led me into his office. I groaned inwardly, expecting another round of justifying my design, and another lecture on considering all aspects on paper before building.
I had five years of experience with logic and analog design; I knew what I was doing. My boss didn't agree. To him, I was still a neophyte. My current attempt at showing my engineering skills was a system that would retrieve data from ten separate phase-shift-keyed tones sent simultaneously through an 8-kHz channel.
To cut down on disagreements, I had adapted a co-worker's design: digitize the signal, store 'even' and 'odd' bauds in separate memory locations, read and demodulate the tones in the 'even' baud at ten times the input data rate, while storing the next baud in the 'odd' space, switch memory addresses, and repeat. Simple, I thought.
I used many terms other than simple to describe my project during the next week. Sometimes it worked, sometimes it didn't. I used different ICs. I changed the board layout. Nothing helped. That's when my boss told me to bring my diagrams into his office and made it clear that I leave my descriptive terms back at my bench.
One of my boss' favorite tools was timing diagrams. We did ours with pencil and graph paper. (Circuit simulations were done on computers back then, but they took hours for anything with more than three transistors.) We checked my A-to-D conversion, data storage, clock speed multiplication, and demodulator. He agreed the problem wasn't in those places.
"Where's the diagram for the memory?" he asked, frowning. I pointed at a sheet. "Not the schematic—the timing diagram.
"No need for it," I answered. "It's a memory chip, a counter, and a few gates." He shook his head. "Draw the diagram," he said.
I stamped out of his office. Back at my desk, I muttered a new set of descriptions as I drew the timing diagram. I stopped muttering when I looked closely at one section. The data was changing too close to clock edges. Gate delays of a few nanoseconds would violate the setup times for the memory, and I would read either noise or the wrong data. I let out a big sigh of relief, corrected the problem, and then groaned when I imagined what my boss would say.
"Did you find the problem?" he asked me at my bench, as I ran tests. I nodded, cringing as I waited for the rest. "Good. Now you can finish it," he said, and moved on. That was it. I didn't know what to say.
I learned a valuable lesson. Sometimes you have to treat people like animals. I was being a mule, so my boss got my attention by hitting me over the head with his version of a two-by-four: reviewing my diagrams over and over again to make me figure out the problem myself. Then he showed me, an old dog, that I can (and should) learn new tricks, no matter how old (or stubborn) I get.
I've used similar methods on young engineers. I've had to use a larger set of animals as they've ranged from a parrot with a speech impediment to chimpanzees that imagine they're nine-hundred-pound gorillas.
Steve Lubs has worked as an engineer for the Defense Department for over 30 years, learning about circuit and system design and bureaucracy.