Organizations pay a high price when their software developers do not feel comfortable asking questions of each other and learning from each other. Developers can learn quite a bit from one another and can the free exchange of ideas and solutions can directly and indirectly improve the organization's ability to deliver quality software in a timely manner. In this post, I look at some of the advantages of fostering a culture that encourages the asking of questions as well as some tips for improving this culture.
I have noticed that many software developers go through the same experience curve that I am moving through. When we first start our careers, we feel free to ask some questions because we are the new person, but we are also afraid to ask too many because of the negative impression others might have of us. As we gain experience, many of us are less confident in asking questions because we believe that our greater experience should mean no need to ask questions and that we need to know everything. The best developers, in my experience, grow out of this phase and realize that they provide the best value when they strive to find the correct mix of self learning and asking questions. The best developers have enough confidence to know that asking questions when appropriate is not a sign of weakness.
The Cost of Not Asking Questions
There are many costs associated with not fostering a culture in which developers feel free to ask and answer each others' questions.
Relearning What is Already Known
Most developers will try to learn how to do something new or how to resolve a problem for a short period of time on their own. However, experienced developers understand that there is a period of time past which their individual effort may be much less efficient than simply asking for help. This is especially true when the problems or questions are related to an area requiring deep domain knowledge that is not readily available in public forums. If any organization has developers who have learned something "the hard way," there is often no need to have everyone else expend the same effort and time if they can learn it more quickly from those who have already learned it. In software, we sometimes are guilty of reinventing the wheel and relearning what has already been learned is really no better.
Multiplying One's Knowledge
When a really experienced developer shares his or her wisdom and lessons learned with other developers, there can be many times the productivity of just that single developer enjoyed by the project. This is especially true when a small amount of time sacrificed by the person answering the questions can help multiple people proceed on with their work.
Inferior Solution
If a developer is not comfortable asking questions of more experienced (or even differently experienced) developers, it is more likely that the developer will not come up with the optimal solution. I have seen in my career several times when a developer did something less efficiently or in a non-standard or non-maintainable way simply because he or she did not know there was a better, more efficient, more standard, and/or more maintainable way. Some of these cases have occurred because the offending developer did not want to admit lack of knowledge of what he or she was trying to do. In one example, the developer wrote his own XML parsing code because he could not get the Xerces-C XML parser working. It was a simple matter of making his XML well-formed, but he did not know this and did not ask for help and ended up wasting many hours writing a custom "XML" (mostly) parser.
Frustration and Its Ill Effects
When a developer is trying to do his or her best, but needs help and is unwilling or unable to ask for it, the feelings of frustration can be overwhelming. This can have a direct impact on that developer's confidence and ability to deliver software.
Questions Can Benefit the Answerer
The act of asking questions for greater understanding often benefits the person doing the answering as much as the person doing the asking. This is because the attempt to answer the question forces the person answering it to think about the issue more deeply, sometimes in ways he or she had never thought about it before. So, questions not only make the person asking them more knowledgeable, but can also help increased the knowledge of the person answering the questions, magnifying the benefits to the project.
Questions Can Expose Holes and Gaps
Most of us have heard the expression "thinking outside of the box." Sometimes it is easier to do this when someone who is not already too familiar with that box is asking probing questions that force us to think about something from a different perspective. More than once, my best laid architectural or design scheme that handled the 80% happy path case beautifully and elegantly has been exposed for potentially disastrous weaknesses when questioned by someone who knew less about the situation, but asked the right questions to prompt me to realize the problems before it was too late.
Questioning Disincentives
With all the above benefits (and many more not listed) of an environment that fosters asking and answering of questions, why is this not always done? The reason is that there is also a list of disincentives for such an environment. These vary between individuals and organizations.
Rudeness
One significant disincentive that prevents or reduces good questions is fear of a rude response from the person being asked. Unfortunately, there are some pompous developers out there that no one really likes to ask questions to because of the price paid in terms of humiliation, degradation, and mocking. For example, a colleague told me of the time he asked his technical lead a question and the response was a biting, "RTFM."
Busyness
Another deterrent to asking questions is the perception that the person being asked is already too busy to take the time to listen to and ask questions. This is unfortunate because even though it is often true that those with the most answers are the most busy, it is also true that it is typically more efficient to invest a little of their time in helping others continue making progress.
Unintelligible Answers
Even when a developer has the best intentions of answering questions that he or she is asked, if that developer is not good at articulating answers at the appropriate level, this can be discouraging to those asking the questions. The better and more succinct the answers, the more likely it is that the person asking the question will gain the benefit needed.
There's No Team in 'I'
Many organizations have their compensation and rewards structures set up to measure and reward individual performance with little to no regard for overall team performance. Although I believe there does need to be some facet of individual accomplishment measured and rewarded, it is also true that no amount of individual success makes up for a team failure. It can be difficult for a well-meaning developer to sacrifice his or her ability to meet an individual deadline in order to help someone else meet their individual deadline, even if the latter deadline is more important in terms of overall priority.
Improving the Questioning Culture
Because there are so many benefits to encouraging the free flow of information at odds with so many disincentives for asking and answering questions, it is important to take steps to foster the questions and answers.
Individual Welcoming of Questions
Individuals who have the appropriate knowledge and experience can make it easier for others to ask them questions. Words, body language, and actions can indicate an interest in answering the questions. It is important to really listen to the questions and often a good idea to wait until the question is completely out before starting with the answer.
Reward Team Performance
Organizations that reward team performance in addition to individual performance and stress team goals are more likely to have an atmosphere of collaboration. The idea here is to change the workplace from being a "me against them" environment to a "we're all in it together" environment.
Reward Correct Prioritization
Related to rewarding team performance, an organization will tend to see better performance when it rewards individuals for accomplishing the highest priorities first, even if it means sacrificing their own task's timely accomplishment to make sure that someone with a higher priority task accomplishes that task.
Sharing Goes Both Ways
It can also help to have more experienced developers admit when they don't know something or have learned something from others or from their own mistakes. I have seen repeatedly where a senior, highly experienced software developer has done just this and almost immediately led to a more open, knowledge-sharing culture. If all developers feel they are contributing, they are all more likely to gain the required confidence to more freely admit when they don't know something and to seek out help.
The Questioner Can Help
People are more willing to help and answer questions when they are appreciated and do not feel their time is wasted. Here are some steps that can be taken by those asking the questions to encourage a more collaborative atmosphere.
Find Your Own Answer
This may seem contradictory to this entire blog post, but it is true that one can ask too many questions. As children and as adults, we often need to learn some things for ourselves. As developers, we particularly need to hone the ability to solve problems and to think critically about design, defects, and so forth. The real trick here is to know when to stop wasting time trying to find the solution for ourself when we could be much more efficient by simply asking someone else. Although there is no single answer because it depends on the level of experience and on the question itself, I feel that I have become better at this over the years.
Carefully Articulate the Question
Many developers want to help others, but the performance and other disincentives mentioned earlier make it more difficult to do so. The person seeking new information can reduce this cost to the person answering the question by carefully articulating the question and spelling out potential solutions or answers that he or she has already ruled out. This articulation of potential solutions and why they don't work not only demonstrates that the person asking the question has put some effort into it, but may also jog something in the mind of the person being asked the question.
Avoid Asking the Same Question Over and Over and Over Again
Another way the person asking questions can save the time of the person answering the questions is to reduce the number of times the same question is asked. Taking notes can help with this. I have even been known to e-mail myself these notes or save them to a text file in my home directory so that they are easily searchable later. Another useful technique here is to ask the question when you are ready to make use of it and/or apply what you've learned. If a question is asked before one is ready to use it, it is more likely that the answer will be forgotten before it is used. I find that I remember best what I actually do as opposed to what I read or hear.
Conclusion
An organization that fosters the appropriate level of developer collaboration has a competitive advantage over organizations that do not foster or even discourage such collaboration. There are many things individuals can do on both the receiving and giving end to improve this, but the organization can also take steps to reward behaviors that lead to better knowledge sharing, increased confidence, and more timely delivery of quality solutions.
No comments:
Post a Comment