Back to Top
Learning to Be an Engineer

Download PDF

By Adam Harding

 

A new engineer’s career with NASA usually begins by being tossed into the deep end. You are immediately handed real-world engineering challenges and face the overwhelming data, procedures, and calculations needed to solve them. There are mentors and training opportunities along the way to help adjust to the relentless pace of learning to be an engineer at NASA, but there isn’t much time during these formative years to pause and reflect on the evolution of your career or formulate potential advice for those about to follow in your footsteps. This is exactly the opportunity afforded me as a member of the “Developing New Engineers at NASA” panel at the 2011 PM Challenge in Long Beach, California. As a panelist, I was to appraise experiences that either promoted or detracted from my development and then share these perspectives.

Airmen of the 23rd Equipment Maintenance Squadron make preparations to inspect for cracks within the wing frame of an A-10C Thunderbolt II, or “Warthog,” model. The risk of structural damage to wings of A-10 models was discovered at Hill Air Force Base, Utah.

Airmen of the 23rd Equipment Maintenance Squadron make preparations to inspect for cracks within the wing frame of an A-10C Thunderbolt II, or “Warthog,” model. The risk of structural damage to wings of A-10 models was discovered at Hill Air Force Base, Utah.
Photo Credit: U.S. Air Force/SrA Javier Cruz

Unlike the four other members of the panel, I didn’t begin my career with NASA. That allowed me to provide some comparisons with another government agency that hires and trains many aerospace engineers: the U.S. Air Force.

After graduating with a BS in mechanical engineering from the University of Utah, I accepted a position at Hill Air Force Base to support the A-10 “Warthog.” I spent my first year learning about military aircraft, designing repairs to jets damaged by enemy fire, and learning how to maintain an aging aircraft. Fortunately, I was placed on a team with a good mix of greybeards and newer engineers.

I had many experiences working for the air force that helped me develop as an engineer, including some notable mistakes. Part of becoming successful in a profession is being given the chance to fail. Making mistakes is part of becoming a good engineer. As Niels Bohr said, “An expert is a man who has made all the mistakes which can be made, in a very narrow field.” One memorable mistake that helped me better value my own contributions and appreciate the insight of experts occurred when I had been working for only a few months. Being the new guy, I was assigned easier projects like repairs on damaged bolt-holes. While not the epitome of engineering glamour that is dreamed of in college, it was nonetheless critical to airworthiness. I began to notice a pattern of damage in the wing-attach fitting area and decided to compile a summary of all documented repairs for this fitting over the past fifteen years. The end product was a reference table allowing quick turnaround on repair requests for any hole in this critical fitting that held the wing on the aircraft.

Several of the experienced engineers took note of my increased efficiency and started to talk with me about it. I proudly showed them my summary of all the previously approved repairs. Instead of praise for the new guy’s accomplishment, they showed concern as they recognized a major flaw with my approach. While any single hole could be enlarged to the respective “clean up” diameter, only one hole in that particular fitting could be enlarged to that degree. If another hole on the same fitting required repair, it could not safely have that maximum diameter due to serious fatigue issues, something I was unaware of.

Finding the flaw in my summary led to a fleet-wide evaluation of these basic repairs. My branch supported about thirty aircraft located at three different air bases at any one time, and there was no cross-check on this repair among the fifteen engineers who carried it out to ensure that multiple hole repairs weren’t being done on the same fittings. Soon this issue was resolved with an updated technical order that included a new summary table of the limits for each hole as they related to other damaged holes on the same fitting. I was not the one who engineered the solution; I was just the engineer who made the biggest mistake and highlighted the problem in the first place.

This experience taught me two principles that have helped me in my career. The first is how important the big picture is, and that I needed to rely on those with enough experience to see the big picture. Sometimes the solution to one problem creates new problems that you won’t see if you don’t have that broad vision. The second principle is, if an answer comes too easily, ask experienced engineers to evaluate the solution. It’s true that the right answer is sometimes the simplest one, but not always, and the simple right answer is not necessarily the easiest to find.

The air force allowed me to return to graduate school to earn a master’s degree in engineering after my first year. This additional schooling was very valuable to my development as an engineer. I had spent a year learning from mistakes and interacting with experienced engineers. That gave me a different perspective when I returned to the classroom. I appreciated the fact that most great engineering solutions are not pounded out individually, but through collaboration among team members. I had seen firsthand how things are built, broken, and rebuilt.

Testing the Orion crew module using air bearings.

Testing the Orion crew module using air bearings.
Photo Credit: NASA

Following graduate school, I returned to the maintenance hangar and tried to apply what I had studied in class. Although my job was inherently technical, the greatest challenges for me would be better classified as learning how to apply research skills to understanding the engineering already in place. Essentially, I was fixing problems that required an engineering degree to understand the proper contextual background for established technology but not for direct application for research or new design. The real engineering had already been done. Despite this, I still experienced a high degree of job satisfaction.

In 2007, I accepted an offer to work at NASA’s Dryden Flight Research Center. NASA’s mission is oriented toward research-based engineering. I was coming from an “end-user” focus on established engineering and, to a degree, felt like I was starting over with a greater technical emphasis. Instead of focusing on A-10 fleet maintenance, I was now working on research and development of the Orion crew module.

My initial assignment was to the structures team. I had responsibility for the mass property testing of the crew module. This involved developing test equipment capable of manipulating the crew module in a variety of positions and attitudes while inducing oscillations and recording precise measurements to determine the center of gravity and moments of inertia (a measure of an object’s resistance to changes to its rotation).

These measurements would directly influence the success of the launch. I had not worked on anything like this in my five years with the air force. Fortunately, I had access to seasoned engineers who had information dating back to similar testing done during the Apollo era.

Even though NASA’s culture and mission were different from the air force, the principle of learning by trial and error still held true. The simplest of oversights on one of our center-of-gravity tests emphasized a great lesson: always read the owner’s manual.

However, the greatest contributor to the success of these tests was a young engineer named Claudia Herrera, who had only been out of school for a couple of years. She had experience with the mass property testing of airplanes at Dryden, but not space capsules. Claudia tackled the technical and programmatic challenges head-on. As I worked with Claudia, I saw that the few years of hands-on experience at NASA had really given her an edge in continuing her development as an engineer. While I had already experienced some mental atrophy on principles taught in school, Claudia had been able to catapult ahead in her development thanks to the challenges of working at NASA.

Even though NASA’s culture and mission were different from the air force, the principle of learning by trial and error still held true. The simplest of oversights on one of our center-of-gravity tests emphasized a great lesson: always read the owner’s manual. We were using air bearings to provide a near-frictionless interface for our test fixtures. These allowed us to tilt the crew module to various angles for measurements. We had received on-site training by the manufacturer, who stated that our concrete floors were adequately smooth to interface with the air bearings. However, during our initial testing, the crew module caused the air bearings to drag despite weighing only a fraction of the system’s capacity. Due to schedule constraints, we didn’t have time to solve the problem and decided to retest when the next window opened in the schedule.

Six months later, as we prepared to retest, we moved to another hangar with smoother concrete. As we began testing we noticed the same dragging problem. Our team was stumped. A mechanic recommended reviewing the owner’s manual, which we had previously only skimmed. A careful reading revealed a suggestion to use sheets of aluminum to improve performance. We did this and finally had the results we needed. This time, the answer was easy to find—it was right there in black and white—but our team took a long time to find it.

If asked by a recent engineering graduate whether to accept an offer to work at NASA or the air force, I would recommend NASA. Here’s why: NASA engineers are directly responsible for cutting-edge research, testing, and publication of flight data. This makes NASA a premier training ground for new engineers. A new engineer develops best by building, testing, and breaking, and learning from the process. My development as a new engineer has accelerated since joining NASA. The maintenance environment at the air force was purposefully designed to reduce opportunities to make mistakes. That inherently reduced opportunities for growth. Despite this, I still found ways to mess things up there, too.

My evaluation of what benefited me most as an engineer is that trial and error taught me more than reading and research. Exposure to the technical accomplishments of others is no substitute for experiencing failure yourself. My advice to new engineers is to volunteer for the challenging assignments and don’t be afraid of the mistakes that will happen along the way. Keep in mind that these mistakes are necessary steps to success.

 

About the Author

 

Adam Harding Adam Harding is an aerospace engineer in the Aerostructures Branch at Dryden Flight Research Center. He is currently supporting the Environmentally Responsible Aviation project.

About the Author

Share With Your Colleagues