1 March 2002 Becoming an Engineer
Author Affiliations +
This PDF file contains the editorial “Becoming an Engineer” for OE Vol. 41 Issue 03
O’Shea: Becoming an Engineer


First of all, let me say, I do not have an engineering degree. But then I have met some people with engineering degrees who were not engineers. So the series of circumstances by which I came to appreciate what engineers do and to begin to do optical engineering myself was as haphazard as the progress I have seen in the generation of some of my designs.

During one of the Kennedy years as a second-year graduate student in physics at Ohio State, I went to work as a summer hire at the General Dynamics Division of North American Rockwell in Downey, California. There, I got an apartment and a small Honda motor scooter, went to work, and amused myself as best I could for a summer. It was my first taste of California living and I must say I enjoyed it for the most part. What I didn’t enjoy was being a continent apart from my bride-to-be, who was in the OSU Nursing School back in Columbus. A good fraction of the summer was taken up with writing letters to her. Each afternoon I would race back to the apartment to see if there were any letters from her. Oh, for the immediacy of e-mail!

I worked on the Polaris Inertial Guidance Accelerometer, in short, the PIGA. This was a component of a three-axis guidance system that detected acceleration using a capacitive pickoff from a suspended rotor. This information was transmitted to a small (at that time) computer and was used to update the submarine tracking data so that the path of the sub could be determined without external sun or star fixes—a necessity for travel below the Arctic ice cap during the Cold War.

The problem I was given was to see if I could determine why the rotors on the PIGAs, which were maintained in suspension by oil flow around it, seemed to “bottom out.” Now this was not the kind of problem I had been assigned in any of my undergraduate or graduate physics courses. The question was: “What am I to do with this?” I don’t remember whether the project engineer, Stan Zedeker, pointed me toward the library, or whether I found it myself, but in the space of a few weeks, I taught myself the elements of fluid dynamics from a textbook. My physics came in handy, since this fluid dynamics system could be modeled as a simple electrical circuit.

After a few more weeks and working from the blueprints of the PIGA chamber and rotor, I had put together a respectable model. It was then that I learned from Stan how to do checks to see if the model worked in simple circumstances and if the values found were of the right order of magnitude. Each new simulation would take me a day or two of calculation and plotting. Thinking back, an electronic spreadsheet would have been ideal for what I was doing. But that wonderful engineering tool was 20 years in the future.

After a few more iterations I turned the results over to Stan, who told me the next day that it looked good and they were going to modify the vanes and build a test version. For minute I was first puzzled, then scared. This wasn’t like homework! They didn’t know the answers and I wasn’t just going to get a grade on this work. It was at that point when the caution that hovers over engineers found me. Once the results of my work affected more than a homework score or a course grade, I became a lot more critical of my methods. You never look at a problem casually again.

But that doesn’t mean you don’t sometimes get careless. Once that happened when I was working on a prism array that remapped the output of a high-intensity light into a light pattern providing even illumination over a substantial area and considerable depth. After some preliminary studies, I calculated a list of call-outs for machining the apex angles of the prisms. Because the check was done through a set of simulations in a spreadsheet, the results appeared to give us exactly what we needed. But in making the conversions for the call-outs, I subtracted an angle when I should have added it. They cut one segment of the new piece and it was evident immediately that something was haywire. For an engineer, that has got to be the worst feeling in the world. I had quite a few sleepless nights and really didn’t feel good until the revised call-outs generated the pattern we had been designing for.

That’s one of the differences between science and engineering. The consequence of one’s scientific research is not too different from handing in your homework. If your work is important enough, someone will “grade” you by trying to reproduce your data or theoretical results. If you are wrong, they will let you know it.

In engineering, much of the work may be done away from those who might be able to provide the best criticism, so you are dependent on your colleagues, your own sense of correctness, and your ability to test the results in as many ways as possible. But, in many cases, deadlines and budgets require that you go with what you have and commit to a prototype or alpha-version. Sometimes that can be daunting.

Luckily, the optical engineering that I am doing now permits me to build satisfying prototypes on small breadboards and perfect the design with few compromises on performance. And because it’s being done in a research environment, I can publish and get graded. But for those engineers toiling in development labs, the grade comes when you turn on the source or analyze your data. I know what you must be feeling. Good luck.

© (2002) Society of Photo-Optical Instrumentation Engineers (SPIE)
Donald C. O'Shea, "Becoming an Engineer," Optical Engineering 41(3), (1 March 2002). https://doi.org/10.1117/1.1462033 . Submission:

Back to Top