I am a structural analyst with two years’ experience as an analyst and two years’ experience as a design engineer. Recently I completed an analysis, wrote the report and sent it to the internal customer (design engineer). He thought that there must be a mistake in my FEM representation of a connection, because he thought the stresses were unreasonably high. The high stresses were going to force a design change which, although small, would be frustrating for the external customer. I kept telling him that the way I modeled the connection was consistent with our typical practice. He kept making the same comment. This was irritating to me, as I was pretty confident that I was in the right. Also, the way he worded his comments was pretty condescending. My model and post-processing had been checked, and so my boss took my side, and overruled the design engineer.
For various reasons, this particular report sat for over a month before it was going to get signed off. Since I knew it was going to sit for a little while, and since I had a little down time this week, I decided to go back into the model to see whether making one small change to how the connection is modeled would affect the results. It was not a change that he suggested, but it was an idea that came to me and I figured I’d give it a try. In looking at the model with fresh eyes, I realized that I actually had made a mistake - not in the way I modeled the connection, but in the material property assigned to the connection. It was a simple, dumb mistake. I fixed the material property, and sure enough, the stresses came down to more reasonable levels.
Looking back, I realize that I should have been much more receptive to his insistence that there was something wrong. He is a far more experienced engineer than I am. I was irritated by the way he made his comments, and the sheer volume of comments he made to my report that were not technical, many of which were simply wrong (note - I pride myself on being a decent technical writer, and he was making many comments that were simply grammatically incorrect. I add this note to head off the comments to the effect that I probably am just a poor writer who needs lots of correction).
Anyways, I spend a decent amount of time on these forums, and have learned quite a bit - both technically and about office interpersonal relationships. I have noticed, though, that many of the threads on the eng tips forums follow this pattern:
1. OP explains the predicament they are in.
2. People comment that they wouldn't have made the mistakes the OP made to get into that situation.
3. People give examples of times they were in a similar situation, but they made better choices than the OP, and it all turned out ok.
Certainly not all threads follow this pattern, but many do. There is nothing wrong with people sharing the good decisions they have made. We all can remember times that we made the right decision under pressure, and things turned out well for us. It can be very helpful to learn from each other's successes. However, I think we can all admit that we have made mistakes in our careers, some serious, and those can be as helpful or even more helpful to learn from than our successes.
What are some of the biggest mistakes you have made in your career - either technical mistakes or interpersonal mistakes. What was the outcome of the mistake? What did you learn from the mistake?
Since the first mistake I shared did not have any serious consequences (fixed before the document was finalized), I'll share another mistake that did have consequences.
Before I worked in analysis, I spent a few years working as a design engineer. In this company, the typical practice was to throw you into the deep end and see if you drowned. I actually prefer this approach, because it is a great way to learn things really quickly. The very first project I worked on was with two other engineers – an engineer with one year of experience and an engineer with about 30 years’ experience who was a few months away from retirement. This was a relatively small project, but had very tight deadlines. The deadline for the first drawing happened to coincide with a long vacation that the younger engineer went on. The older engineer, who had pretty much mailed it in at this point, also went on a surprise vacation at this time. So I was left to complete the drawing and get it out to meet the deadline. I really did not know what I was doing. I had little to no understanding of GD&T, and didn’t even know how to put together a bill of materials. However, I told myself, “If my boss trusts this job to me, I must be capable of completing it, and so I’ll just do my best and then hand it in. Any mistakes will be caught when it is checked.” It didn’t get checked. I sent it to him, he briefly looked it over and sent it out (which is a violation of our company policy, but we’re focusing on my mistakes here, not his) in order to make the date. Our customer immediately caught several of the glaring mistakes in their own review of the drawing, which made us (me) look pretty bad. Even worse though, a year later one of the mistakes showed up when they were trying to build the product. This cost quite a bit of time, money and frustration. It was a relatively small project, and so the time/money/frustration was proportional to the project size, but it wasn’t insignificant. It was definitely painful for all involved. The main things I learned:
1. If I am not comfortable with my work, I should NEVER pass it off as finished, assuming that someone else will adequately check it. In fact, I now assume that no one is going to check my work.
2. The later in the game that mistakes come out, the more money, time and heartburn it takes to fix them.
3. Finally, I learned that I should never ever send something out just to make a schedule. Schedules are important, but product quality is much much more important. When you are about to miss a date, everyone is mad at you. If you are weeks, or even a month or two late, the pressure intensifies. However, once you get the product out (at least at my company), all is forgotten with regards to the date. At that point, all that matters is the product quality. So it is much better to take your licks for being late and just work steadily to complete a quality product than to get a hastily finished product out the door on time, briefly look like a hero, and then spend months/years paying for the mistakes.
Alright, now it’s your turn. If possible, I’d especially like to hear from some of the more experienced engineers who I am sure have some significant battle scars. Thanks for reading and in advance for sharing.
For various reasons, this particular report sat for over a month before it was going to get signed off. Since I knew it was going to sit for a little while, and since I had a little down time this week, I decided to go back into the model to see whether making one small change to how the connection is modeled would affect the results. It was not a change that he suggested, but it was an idea that came to me and I figured I’d give it a try. In looking at the model with fresh eyes, I realized that I actually had made a mistake - not in the way I modeled the connection, but in the material property assigned to the connection. It was a simple, dumb mistake. I fixed the material property, and sure enough, the stresses came down to more reasonable levels.
Looking back, I realize that I should have been much more receptive to his insistence that there was something wrong. He is a far more experienced engineer than I am. I was irritated by the way he made his comments, and the sheer volume of comments he made to my report that were not technical, many of which were simply wrong (note - I pride myself on being a decent technical writer, and he was making many comments that were simply grammatically incorrect. I add this note to head off the comments to the effect that I probably am just a poor writer who needs lots of correction).
Anyways, I spend a decent amount of time on these forums, and have learned quite a bit - both technically and about office interpersonal relationships. I have noticed, though, that many of the threads on the eng tips forums follow this pattern:
1. OP explains the predicament they are in.
2. People comment that they wouldn't have made the mistakes the OP made to get into that situation.
3. People give examples of times they were in a similar situation, but they made better choices than the OP, and it all turned out ok.
Certainly not all threads follow this pattern, but many do. There is nothing wrong with people sharing the good decisions they have made. We all can remember times that we made the right decision under pressure, and things turned out well for us. It can be very helpful to learn from each other's successes. However, I think we can all admit that we have made mistakes in our careers, some serious, and those can be as helpful or even more helpful to learn from than our successes.
What are some of the biggest mistakes you have made in your career - either technical mistakes or interpersonal mistakes. What was the outcome of the mistake? What did you learn from the mistake?
Since the first mistake I shared did not have any serious consequences (fixed before the document was finalized), I'll share another mistake that did have consequences.
Before I worked in analysis, I spent a few years working as a design engineer. In this company, the typical practice was to throw you into the deep end and see if you drowned. I actually prefer this approach, because it is a great way to learn things really quickly. The very first project I worked on was with two other engineers – an engineer with one year of experience and an engineer with about 30 years’ experience who was a few months away from retirement. This was a relatively small project, but had very tight deadlines. The deadline for the first drawing happened to coincide with a long vacation that the younger engineer went on. The older engineer, who had pretty much mailed it in at this point, also went on a surprise vacation at this time. So I was left to complete the drawing and get it out to meet the deadline. I really did not know what I was doing. I had little to no understanding of GD&T, and didn’t even know how to put together a bill of materials. However, I told myself, “If my boss trusts this job to me, I must be capable of completing it, and so I’ll just do my best and then hand it in. Any mistakes will be caught when it is checked.” It didn’t get checked. I sent it to him, he briefly looked it over and sent it out (which is a violation of our company policy, but we’re focusing on my mistakes here, not his) in order to make the date. Our customer immediately caught several of the glaring mistakes in their own review of the drawing, which made us (me) look pretty bad. Even worse though, a year later one of the mistakes showed up when they were trying to build the product. This cost quite a bit of time, money and frustration. It was a relatively small project, and so the time/money/frustration was proportional to the project size, but it wasn’t insignificant. It was definitely painful for all involved. The main things I learned:
1. If I am not comfortable with my work, I should NEVER pass it off as finished, assuming that someone else will adequately check it. In fact, I now assume that no one is going to check my work.
2. The later in the game that mistakes come out, the more money, time and heartburn it takes to fix them.
3. Finally, I learned that I should never ever send something out just to make a schedule. Schedules are important, but product quality is much much more important. When you are about to miss a date, everyone is mad at you. If you are weeks, or even a month or two late, the pressure intensifies. However, once you get the product out (at least at my company), all is forgotten with regards to the date. At that point, all that matters is the product quality. So it is much better to take your licks for being late and just work steadily to complete a quality product than to get a hastily finished product out the door on time, briefly look like a hero, and then spend months/years paying for the mistakes.
Alright, now it’s your turn. If possible, I’d especially like to hear from some of the more experienced engineers who I am sure have some significant battle scars. Thanks for reading and in advance for sharing.
![[smile]](/data/assets/smilies/smile.gif "[smile] [smile]")
![URL]](https://res.cloudinary.com/engtips/image/fetch/w_800,c_lfill,q_auto,f_auto,g_faces:center/[URL unfurl="true"]http://hi-tecdesigns.com/images/pictures/Footwell%20Animation%20Tiny.gif[/URL])
![URL]](https://res.cloudinary.com/engtips/image/fetch/w_800,c_lfill,q_auto,f_auto,g_faces:center/[URL unfurl="true"]http://www.bloomertool.com/images/890.JPG[/URL])
