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?

  • 2
    Have you ever considered how much of the story you know compared to what assumptions you make on things?
    – JB King
    Aug 6, 2014 at 19:44
  • I edited this slightly to make it more on topic for the site, welcome to the Workplace! You will also find this question useful as it relates fairly significantly.
    – enderland
    Aug 7, 2014 at 4:02
  • In addition to the excellent answers already given by others, maybe you can train yourself in asking socratic questions
    – user8036
    Aug 7, 2014 at 7:20
  • possible duplicate of How can I keep myself from overstepping my authority with co-workers?
    – gnat
    Aug 7, 2014 at 9:06
  • @JBKing: I wish I could put a giant halo on your comment. This is the first question I ask individuals I'm mentoring when they have a problem they can't seem to get past. Aug 11, 2014 at 17:30

4 Answers 4


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!

  • 1
    Well worded response. Welcome to the Workplace!
    – Mike Van
    Aug 6, 2014 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, 2014 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.

  • Wow, thank you very much! I feel I need to review this every morning until it's ingrained! Thank you! Aug 6, 2014 at 18:49
  • 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. Aug 6, 2014 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, 2014 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)

  • I wish I could up vote all of these answers, thank you very much for adding your insight! Aug 6, 2014 at 18:50
  • Anytime, there are a number of excellent resources to provide you this sort of insight from veterans in our industry. I highly recommend doing a search to find the movers and shakers in your particular developer niches (.net, php, Java, etc) Often they can provide you knowledge that would otherwise takes years of banging your head against the wall to learn. (not plugging anyone specific as it's frowned upon here) Aug 6, 2014 at 18:54
  • +1 for the power of questions in particular. Although, I'm not a fan of "did you consider doing this" or "I'm worried" type of phrasing questions. Those still put people on the defensive. The best way to get people to "see it your way" is to get the other person to think it was their idea. In this regard, nothing works better than "What if" and "How could we" questions. Of course your questions should always be leading questions aimed at getting the person to come to the same conclusion as you. But sometimes they come up with better conclusions.
    – Dunk
    Aug 6, 2014 at 22:11
  • @Dunk very good point, I've not really had problems with the "did you consider" but I do think the "What if" and "How could we" are probably more effective in achieving the end goal here. Aug 7, 2014 at 14:14

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .