How do I learn without being annoying to the people around me?

Question

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?

Answer 1

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!

Answer 2

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.

Answer 3

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)

Answer 4

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.