When I first started working for VT Griffin (my first real programming job) I had a tough time trying to determine when to ask a question and when not to ask a question. Like most things there is no definitive answer, but there are some things that can help guide you. Here are some tips based on my experience.
- Asking questions is a great thing. How else are you going to figure out the obscure process that was created in the dark ages of your company.
- Can this question easily be answered with a web search? Do a little research before asking or just think about it for awhile.
- Are there a number of different interpretations? A user will see something different then a software architect.
- Don’t take one person’s word for it. Become a journalist. Talk to a number of different people that have experience related to the question. This goes back to number three.
- Get an outsiders point of view. A uncontaminated source should always be helpful.
- Take notes. Even if the notes are unorganized, the fact of writing the information down should re-enforce it.
- Build relationships. If you want to get information from people be nice. If they need help with something even if it is not work related help them.
- Think about the question before you ask it. Make sure it will make sense to the person you are asking. Using technical terms with a client my not be the best idea.
- Read people. If someone is busy, not in a good mood, or just seems not ready for a question wait for another time or find another resource.
- Do not become a nuisance. There is a thing as asking to many questions and asking dumb questions.
Following these guidelines could help lead to good things. By asking good questions, building relationships, gaining a reputation, and being thorough will help managers see your potential.
Asking questions will allow you to better understand your company and the people that keep it running. Understanding these things can only be beneficial and help you work up that latter.