Take the 2-minute tour ×
The Workplace Stack Exchange is a question and answer site for members of the workforce navigating the professional setting. It's 100% free, no registration required.

I am not new at what I do but I still have a lot to learn. When people ask me for help I am generally really happy to share my insight. When people critique my work it's hard for me to swallow but getting defensive at people for pointing out my flaws wont make me a better person or win any friends so it's something I work at taking with grace.

Specifically I just joined a new team and still getting used to the way people do things. I've learned that listening can be my secret weapon and I should use that liberally. But when I find something that I feel is really wrong and would like to talk to people on my team about it they are generally very defensive and it's been hard to keep myself on their good side.

With all that said how do I approach others and ask for help / critique others work without making them defensive?

share|improve this question
2  
Have you ever considered how much of the story you know compared to what assumptions you make on things? –  JB King Aug 6 at 19:44

4 Answers 4

up vote 11 down vote accepted

There's a few questions in here, really :) Let me try to break them out and address each one:


How do I avoid being defensive when people are critiquing my work?

I don't have a great answer for this one; but some observations about cases when I feel defensive about my work:

  • You've but days/hours/weeks/months into a project, and someone shoots most or all of it down.

    • This is usually your fault: You should have reviewed the idea with your team very early in the process.

    • Sometimes, teams/clients will change their mind throughout the dev process. Oh well; at least you were frequently reviewing your work with them, right? They understand that your previous work was valuable, but that tradeoffs had to be made.

  • You've latched onto an idea, and are having trouble accepting alternatives.

    • Stop. Take a breath. Accept that you may be wrong, and try to figure out what information you are lacking.

How and when do I ask for help?

Frequently, but not too frequently.

  • Don't ask for help every time you become stuck: This tends to end up in a situation where you are dependent on a team mate to get your work done. This is bad for you (not learning to problem solve), and bad for them (time sink).

  • However, don't chew on a problem for too long without asking for help.

General rule of thumb: Spend an hour trying to dig into a problem; try to gather as much information about it as possible. If you are still stuck, ask pointed questions from your team mates.

Instead of "I can't figure out <thing>. Help?", go with "Anyone run into <thing> or similar?". (asking for debugging help is an exception to this rule)

How do I bring up concerns with the team's tech?

This is really just the other end of the first question.

You need to take great care to not let your team mates feel the need to be defensive when bringing up such concerns. Some hints:

  • Assume that you are lacking some important piece of context (you almost always are).

  • Rather than bluntly proposing alternative solutions, probe around. Ask questions that lead your team mates to the same conclusions as you.

  • Leave your ego behind. Don't be bothered when/if someone circles around to agree with you, but thinks it was their idea (and fails to give you credit). Instead, rejoice that your tech is now moving in a direction that you are more comfortable with!

share|improve this answer
1  
Well worded response. Welcome to the Workplace! –  Mike Van Trufflebutt Aug 6 at 18:45
1  
Good points. Regarding asking for help: Start by writing down exactly what the problem is, and anticipate what their followup questions would be. This process will very often give you the answer you need. See also Rubber ducking: en.wikipedia.org/wiki/Rubber_duck_debugging –  Fredrik Aug 7 at 8:08

When I've run into a situation or setup that seems odd, I'll ask someone else by saying "Can you give me some background on why we do X in Y manner?" That asks for the explanation of why things are done this way, while acknowledging that sometimes (okay, often, esp. in corporate situations), one has to make do with a less-than-optimal situation:

  • legacy code
  • 'business needs' that seem odd, but are some higher-up's pet project
  • a less-than-perfectly efficient plugin that has some functionality that's very relied upon, and so it can't be replaced
  • no time/budget to step back and fix things

That lets your team members give you background without feeling like they have to justify why they, personally, haven't stepped forward and fixed some particular mess. Especially if they're a team that's regularly dumped on, or given little resources and regularly expected to accomplish miracles, they're probably already in seige-mentality. Framing your questions in a way that explicitly places blame outside the group (or at the very least, not inside it) takes a lot of pressure off of them, to justify some extreme pretzel-logic or not-best-practice coding standards.

share|improve this answer
2  
Even the best devs wind up with messy code from attrition and circumstance. We all try to start with clean code, but tight deadlines and frequent changes can turn even the cleanest code into something cringe worthy. Far too often the "best" approach isn't good for "right now". It's worth noting many languages support the #hack tag to mark these particularly cringe worthy places in code for revisiting on a later day to clean those gremlins out before they come back to haunt you. –  RualStorge Aug 6 at 18:49
1  
And remember in older code bases, what looks bad now might not have been a poor choice at the time it was written. People don't replace working code just because a new way to do it comes along. –  HLGEM Aug 6 at 19:49

The best way to do a critique someone's work is to make sure you keep this about the code, develop understanding as to WHY you should do X instead of Y in a situation.

The power of questions

No one likes you saying, "that's wrong", "don't do it that way", etc. Even if you offer an explanation you've started by questioning the quality of their work and are likely going to put them on the defensive. (Once they are on the defensive the whole process grinds to a halt)

A better way is to say "Hey, did you consider (other option), I'm worried we might (reason why the method the went with isn't advisable) here." Example, inline CSS. "Hey, did you consider putting these in a class? I'm really worried as our project expands it might be hard to maintain the styles on all these separate divs."

This way your not attacking their work, instead your discussing options and providing a reason to consider the other option. In some cases the individual could have a very valid reason why their approach is more appropriate in this particular case, by opening this way you give them a chance to explain this and you both have a potential to learn and expand your knowledge.

NEVER use words like Right, Wrong, Better, Best, Worse, Worst, etc. These immediately imply what someone did was of poor quality, whether or not that's the case. In addition, there are cases where what my normally be considered bad practice is warranted, and cases where things that are considered best practices are actually really bad ideas.

As long as you keep it a discussion about working as a team to improve your code things will generally go well. (by all means from time to time their will be flare ups, in those cases let tempers cool and get the conversation back on track to figuring out what makes sense for the particular case covered)

(everyone should consider this when critiquing, explain this to people you feel are attacking your code)

share|improve this answer

Be respectful of other people's time, and don't interrupt unless it is critical. Try and setup time to ask questions since you are new. This can be a set time or maybe team members have preferential times for questions (First thing in the morning, right after lunch, etc). On some projects, the workload may be cyclical. In Agile, right at the end of a sprint may be a bad time. This way, you can accumulate a set of questions and ask the correct person.

Take notes. No one wants to explain the same things to you over and over again. Some of these notes may be important when an additional person is added to the team. No reason they have to go through the same learning pains you are if it can be avoided by some simple documentation.

When you work with people one on one, they are less likely to get defensive. Many people will react negatively if you question them in front of the group. You're learning who those individuals are on your team. Make sure they understand that you're learning and you have a different approach to something they recommended. Once you understand decisions in context and restrictions, you may learn why they've made certain choices.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.