4 responses to “Taking Criticism”

  1. GEARS

    I think, in the end, we all take everything a little bit too personally. I know from other people working in industry that there is a good chance that the engineer wasn’t fully privy to the entire problem. I remember a meeting that I had where (not to toot my horn) I was the expert on the subject and that’s the only reason I was there. And we proceeded to have a 3 hour discussion and agreed – then disagreed – then agreed – and then… the bombshell.

    They added another constraint where they thought (not know enough) that was totally critical in the end. So I, during the course of this, looked like a fool for the “disagree” parts but in the end, they didn’t give me sufficient information to do my job.

    My feeling is this is how most of these situations arise. There wasn’t enough information traded and management got what they asked for. If they wanted something different, then the specifications should have been clearer. It seems that if there’s something that make your design undesirable and its because of something they didn’t tell you, then it’s there fault and I can totally see how someone would take it personally.

    And with that, get back to re-designing 😀

  2. Alexandru Lazăr

    I think it depends on the ability of those who criticize of formulating their ideas so as not to sound like complete assholes. Our egos are typically the size of small planet, but it is inevitable to take things personally if the criticism is formulated in personal terms. There’s a long way from “Are you sure you don’t need a decoupling cap here?” or “I think you forgot the decoupling cap” to “[bored tone on] oook, first problem, where’s your decoupling cap?”.

  3. An old engineer

    One thing I have learned in my engineering career is that if you give the same project to 3 different engineers, you will have 3 different solutions to the problem. They may be similar, but they will be different.

    I call it a variation of the Tower of Babble biblical story.

    Everyone learns by mimicing what they see from other people. A young engineer will learn from a more experience person and add in influences from other sources. Since we all have different influences in our lives, each person will do things differently.

    The key is for a more experienced engineer to teach a young engineer is why you do things the way you do. The reasoning behind it. That comes from experience. Some engineers are on a ego trip (“do it my way”) and don’t understand why they do what they do. If you’re comfortable in your own skin, you explain to a less experienced person why you did what did. Teach them.

    Note that I didn’t say “older” or “younger”. A younger engineer might be more familiar with computer simulations or CAD design. A older engineer, seeking to keep to date, might need some help in understanding the Solidworks command hierarchy.

  4. Fluxor

    One of the first things my colleagues told me when I first joined FluxCorp is to throw stones at their designs. The best idea wins, they tell me, and they’ve lived up to their words. No ego trips in our local office here. This makes it easy to both criticize others as well as receive criticism. But I don’t forget my manners. As Alexandru Lazăr pointed out, how you word the criticism is very important.