Food for thought
For me, on a normal day at the office, I usually take my coffee, I have my current project's standup and I get to work on the features; out of this, in my "free" (pomodoro) time I like to stand up, walk and get closer to my colleagues from other projects, just to see what are they doing and how can I help.
Similarly, I ask for help in the revision of a pull request or a problem I can not solve and sometimes someone with a trouble comes looking for some light into the darkness of their problems. In the end:
In a healthy software engineering culture, team members engage their peers to improve the quality of their work and increase their productivity. They understand that the time they spend looking at a colleague's work product is repaid when other team members examine their own deliverables
But, how can I ask a question if I have any trouble? or how can I really help my colleagues with their problems without compromising my duties and obligations and thus remain effective and efficient? Well, my advice is:
"Whenever you ask a question, please, do put some effort on it."
You should at least:
- Provide background and give enough details:
Let me know what's happening. What's your problem about? be specific, be on-topic. -
Give context:
Is it a blocker? curiosity? Why should I invest time on answering or helping you answering your question? -
Search and research:
Share your research, If you didn't do any research; go back and do some: try the solution and, if nothing works, came back and ask. Help me to help you. -
Be an open mind:
The answer to your question may not always be the one you wanted, but that doesn’t mean it's wrong. A conclusive answer isn’t always possible. When in doubt, ask people to cite their sources, or to explain how/where they learned something. Even if I don’t agree with you, or tell you exactly what you wanted to hear, remember: I'm just trying to help.
And ... what about the Rubber Duck?
Although it's not a new concept, "Ask the Duck" is of great help when solving not only software problems but any kind of. The main idea is to ask thorough and detailed questions, even if you end up throwing the question away because it was a "dumb" mistake.
What if I don't have a Rubber Duck?
Well, it could be metaphorical, you could talk to the monitor, or your own hand or even better, try to find a coding buddy, someone you trust (no need in expertise).
Ultimately, what does matter is to speak out loud the problems as it will help you on:
- Clarifying your thoughts
You must clarify and state the problem in objective terms. You're forced to organize all the information and making the problem explicit freeing it from psychological noise like the anxiety or frustration of not being able to solve it. -
Uncovering hidden assumptions
Explaining the problem to someone else whom you assume has no knowledge helps you focusing on what you DO know instead of figuring out a solution. -
Engaging different parts of the brain
Saying the problem out loud engages many more areas of the brain than merely thinking about it.
Conclusion
The healthy part is that, regardless of who is asking for help or answering questions, everybody is willing to help. What can backfire is the lack of clarity in the questions and the time taken to resolve them, plus the time to solve the problem of course.
So do not waste your time or make other wasting time and first: analyze, research, test and question.
Questions, comments and suggestions are always welcome:
twitter: mumoc | github: mumoc | skype: mumo.carlos
