Mixing
How do I learn without being annoying to the people around me?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
10
down vote
favorite
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?
software-industry learning
edited Aug 7 '14 at 4:02
Elysian Fields♦
96.9k46292449
asked Aug 6 '14 at 18:11
Jonathan Stanton
534
suggest improvements |Â
up vote
10
down vote
favorite
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?
software-industry learning
edited Aug 7 '14 at 4:02
Elysian Fields♦
96.9k46292449
asked Aug 6 '14 at 18:11
Jonathan Stanton
534
2
Have you ever considered how much of the story you know compared to what assumptions you make on things?
– JB King
Aug 6 '14 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.
– Elysian Fields♦
Aug 7 '14 at 4:02
In addition to the excellent answers already given by others, maybe you can train yourself in asking socratic questions
– Jan Doggen
Aug 7 '14 at 7:20
possible duplicate of How can I keep myself from overstepping my authority with co-workers?
– gnat
Aug 7 '14 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.
– Joel Etherton
Aug 11 '14 at 17:30
suggest improvements |Â
up vote
10
down vote
favorite
up vote
10
down vote
favorite
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?
software-industry learning
edited Aug 7 '14 at 4:02
Elysian Fields♦
96.9k46292449
asked Aug 6 '14 at 18:11
Jonathan Stanton
534
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?
software-industry learning
edited Aug 7 '14 at 4:02
Elysian Fields♦
96.9k46292449
asked Aug 6 '14 at 18:11
Jonathan Stanton
534
edited Aug 7 '14 at 4:02
Elysian Fields♦
96.9k46292449
edited Aug 7 '14 at 4:02
Elysian Fields♦
96.9k46292449
edited Aug 7 '14 at 4:02
Elysian Fields♦
96.9k46292449
96.9k46292449
asked Aug 6 '14 at 18:11
Jonathan Stanton
534
asked Aug 6 '14 at 18:11
Jonathan Stanton
534
asked Aug 6 '14 at 18:11
Jonathan Stanton
534
534
2
Have you ever considered how much of the story you know compared to what assumptions you make on things?
– JB King
Aug 6 '14 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.
– Elysian Fields♦
Aug 7 '14 at 4:02
In addition to the excellent answers already given by others, maybe you can train yourself in asking socratic questions
– Jan Doggen
Aug 7 '14 at 7:20
possible duplicate of How can I keep myself from overstepping my authority with co-workers?
– gnat
Aug 7 '14 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.
– Joel Etherton
Aug 11 '14 at 17:30
suggest improvements |Â
2
Have you ever considered how much of the story you know compared to what assumptions you make on things?
– JB King
Aug 6 '14 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.
– Elysian Fields♦
Aug 7 '14 at 4:02
In addition to the excellent answers already given by others, maybe you can train yourself in asking socratic questions
– Jan Doggen
Aug 7 '14 at 7:20
possible duplicate of How can I keep myself from overstepping my authority with co-workers?
– gnat
Aug 7 '14 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.
– Joel Etherton
Aug 11 '14 at 17:30
2
2
Have you ever considered how much of the story you know compared to what assumptions you make on things?
– JB King
Aug 6 '14 at 19:44
Have you ever considered how much of the story you know compared to what assumptions you make on things?
– JB King
Aug 6 '14 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.
– Elysian Fields♦
Aug 7 '14 at 4:02
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.
– Elysian Fields♦
Aug 7 '14 at 4:02
In addition to the excellent answers already given by others, maybe you can train yourself in asking socratic questions
– Jan Doggen
Aug 7 '14 at 7:20
In addition to the excellent answers already given by others, maybe you can train yourself in asking socratic questions
– Jan Doggen
Aug 7 '14 at 7:20
possible duplicate of How can I keep myself from overstepping my authority with co-workers?
– gnat
Aug 7 '14 at 9:06
possible duplicate of How can I keep myself from overstepping my authority with co-workers?
– gnat
Aug 7 '14 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.
– Joel Etherton
Aug 11 '14 at 17:30
@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.
– Joel Etherton
Aug 11 '14 at 17:30
suggest improvements |Â
4 Answers
4
active
oldest
votes
up vote
13
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!
answered Aug 6 '14 at 18:36
Nevir
24615
1
Well worded response. Welcome to the Workplace!
– Mike Van
Aug 6 '14 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 '14 at 8:08
suggest improvements |Â
up vote
8
down vote
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!
– Jonathan Stanton
Aug 6 '14 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.
– RualStorge
Aug 6 '14 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 '14 at 19:49
suggest improvements |Â
up vote
5
down vote
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)
answered Aug 6 '14 at 18:37
RualStorge
9,5372231
I wish I could up vote all of these answers, thank you very much for adding your insight!
– Jonathan Stanton
Aug 6 '14 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)
– RualStorge
Aug 6 '14 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 '14 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.
– RualStorge
Aug 7 '14 at 14:14
suggest improvements |Â
up vote
1
down vote
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.
suggest improvements |Â
StackExchange.ready(function ()
$("#show-editor-button input, #show-editor-button button").click(function ()
var showEditor = function()
$("#show-editor-button").hide();
$("#post-form").removeClass("dno");
StackExchange.editor.finallyInit();
;
var useFancy = $(this).data('confirm-use-fancy');
if(useFancy == 'True')
var popupTitle = $(this).data('confirm-fancy-title');
var popupBody = $(this).data('confirm-fancy-body');
var popupAccept = $(this).data('confirm-fancy-accept-button');
$(this).loadPopup(
url: '/post/self-answer-popup',
loaded: function(popup)
var pTitle = $(popup).find('h2');
var pBody = $(popup).find('.popup-body');
var pSubmit = $(popup).find('.popup-submit');
pTitle.text(popupTitle);
pBody.html(popupBody);
pSubmit.val(popupAccept).click(showEditor);
)
else
var confirmText = $(this).data('confirm-text');
if (confirmText ? confirm(confirmText) : true)
showEditor();
);
);
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
13
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!
answered Aug 6 '14 at 18:36
Nevir
24615
1
Well worded response. Welcome to the Workplace!
– Mike Van
Aug 6 '14 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 '14 at 8:08
suggest improvements |Â
up vote
13
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!
answered Aug 6 '14 at 18:36
Nevir
24615
1
Well worded response. Welcome to the Workplace!
– Mike Van
Aug 6 '14 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 '14 at 8:08
suggest improvements |Â
up vote
13
down vote
accepted
up vote
13
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!
answered Aug 6 '14 at 18:36
Nevir
24615
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!
answered Aug 6 '14 at 18:36
Nevir
24615
edited Aug 11 '14 at 16:07
answered Aug 6 '14 at 18:36
Nevir
24615
answered Aug 6 '14 at 18:36
Nevir
24615
answered Aug 6 '14 at 18:36
Nevir
24615
24615
1
Well worded response. Welcome to the Workplace!
– Mike Van
Aug 6 '14 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 '14 at 8:08
suggest improvements |Â
1
Well worded response. Welcome to the Workplace!
– Mike Van
Aug 6 '14 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 '14 at 8:08
1
1
Well worded response. Welcome to the Workplace!
– Mike Van
Aug 6 '14 at 18:45
Well worded response. Welcome to the Workplace!
– Mike Van
Aug 6 '14 at 18:45
1
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 '14 at 8:08
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 '14 at 8:08
suggest improvements |Â
up vote
8
down vote
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!
– Jonathan Stanton
Aug 6 '14 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.
– RualStorge
Aug 6 '14 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 '14 at 19:49
suggest improvements |Â
up vote
8
down vote
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!
– Jonathan Stanton
Aug 6 '14 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.
– RualStorge
Aug 6 '14 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 '14 at 19:49
suggest improvements |Â
up vote
8
down vote
up vote
8
down vote
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.
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.
answered Aug 6 '14 at 18:24
user22432
Wow, thank you very much! I feel I need to review this every morning until it's ingrained! Thank you!
– Jonathan Stanton
Aug 6 '14 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.
– RualStorge
Aug 6 '14 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 '14 at 19:49
suggest improvements |Â
Wow, thank you very much! I feel I need to review this every morning until it's ingrained! Thank you!
– Jonathan Stanton
Aug 6 '14 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.
– RualStorge
Aug 6 '14 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 '14 at 19:49
Wow, thank you very much! I feel I need to review this every morning until it's ingrained! Thank you!
– Jonathan Stanton
Aug 6 '14 at 18:49
Wow, thank you very much! I feel I need to review this every morning until it's ingrained! Thank you!
– Jonathan Stanton
Aug 6 '14 at 18:49
2
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 '14 at 18:49
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 '14 at 18:49
1
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 '14 at 19:49
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 '14 at 19:49
suggest improvements |Â
up vote
5
down vote
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)
answered Aug 6 '14 at 18:37
RualStorge
9,5372231
I wish I could up vote all of these answers, thank you very much for adding your insight!
– Jonathan Stanton
Aug 6 '14 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)
– RualStorge
Aug 6 '14 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 '14 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.
– RualStorge
Aug 7 '14 at 14:14
suggest improvements |Â
up vote
5
down vote
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)
answered Aug 6 '14 at 18:37
RualStorge
9,5372231
I wish I could up vote all of these answers, thank you very much for adding your insight!
– Jonathan Stanton
Aug 6 '14 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)
– RualStorge
Aug 6 '14 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 '14 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.
– RualStorge
Aug 7 '14 at 14:14
suggest improvements |Â
up vote
5
down vote
up vote
5
down vote
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)
answered Aug 6 '14 at 18:37
RualStorge
9,5372231
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)
answered Aug 6 '14 at 18:37
RualStorge
9,5372231
answered Aug 6 '14 at 18:37
RualStorge
9,5372231
answered Aug 6 '14 at 18:37
RualStorge
9,5372231
answered Aug 6 '14 at 18:37
RualStorge
9,5372231
9,5372231
I wish I could up vote all of these answers, thank you very much for adding your insight!
– Jonathan Stanton
Aug 6 '14 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)
– RualStorge
Aug 6 '14 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 '14 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.
– RualStorge
Aug 7 '14 at 14:14
suggest improvements |Â
I wish I could up vote all of these answers, thank you very much for adding your insight!
– Jonathan Stanton
Aug 6 '14 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)
– RualStorge
Aug 6 '14 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 '14 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.
– RualStorge
Aug 7 '14 at 14:14
I wish I could up vote all of these answers, thank you very much for adding your insight!
– Jonathan Stanton
Aug 6 '14 at 18:50
I wish I could up vote all of these answers, thank you very much for adding your insight!
– Jonathan Stanton
Aug 6 '14 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)
– RualStorge
Aug 6 '14 at 18:54
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)
– RualStorge
Aug 6 '14 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 '14 at 22:11
+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 '14 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.
– RualStorge
Aug 7 '14 at 14:14
@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.
– RualStorge
Aug 7 '14 at 14:14
suggest improvements |Â
up vote
1
down vote
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.
suggest improvements |Â
up vote
1
down vote
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.
suggest improvements |Â
up vote
1
down vote
up vote
1
down vote
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.
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.
answered Aug 11 '14 at 17:03
user8365
suggest improvements |Â
suggest improvements |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f31960%2fhow-do-i-learn-without-being-annoying-to-the-people-around-me%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
2
Have you ever considered how much of the story you know compared to what assumptions you make on things?
– JB King
Aug 6 '14 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.
– Elysian Fields♦
Aug 7 '14 at 4:02
In addition to the excellent answers already given by others, maybe you can train yourself in asking socratic questions
– Jan Doggen
Aug 7 '14 at 7:20
possible duplicate of How can I keep myself from overstepping my authority with co-workers?
– gnat
Aug 7 '14 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.
– Joel Etherton
Aug 11 '14 at 17:30