Asking Questions and Giving Advice
A study conducted at Harvard University found that while individuals see themselves as less competent when asking questions the advice giver see them as more competent for asking. The main caveat being that the quality of the questions is related to the perception of the person being asked.
Good questions come in many forms. Many people will say to only ask open ended questions however this is a closed minded view on the efficacy of closed ended questions. Good questions are planned questions.
Closed Ended Questions
A closed ended question is one that has a single word response such as yes/no, either/or, or an identification. As mentioned in the episode this can be highly useful information especially when one is looking for the correct term or phrase for a concept in order to do further research on the subject.
Open Ended Questions
Open ended questions require more than a single word response. These are designed to dig deeper and open a dialog. With these leave the scope open by not adding in assumptions or opinions. Beyond identification and initiation of conversation most questions asked when seeking advice will be open ended.
Before seeking advice attempt to solve the problem and be able to describe what you have done so far. This shows that you respect the other persons time and are actively working toward a solution. Move from general to specific questions and expect to ask follow up questions for clarification, but focus your inquiries to one subject or one issue at a time.
When giving advice remember you are dealing with another developer that is just not as far along as you. They will screw up and it’s your job as a mentor to show them how to get better and apply that beyond just the issue at hand.
Focus on What You Know
Also remember that you may not know everything and your answers may be wrong. Or there may be a better way of doing something than what you currently know. In this light don’t do the task for the junior developer. Tell or show them how and then have them do it for themselves. They will build confidence in their skills and learn better by doing it. If it can be avoided do not give hacky answers.
After giving advice follow up with the junior developer after they have had time to implement your advice. Don’t be upset if they didn’t use your advice if they solved the problem. You may have pointed them in a direction that lead to a better solution. Finally, remember the goal is to push them to the pit of success.