A dog leaves a house, runs through the garden, and beams into a starship. The starship traverses space to a far-off planet, where an alien senate watches the ship land. The dog gets out and removes its dog costume, unveiling that it, too, is an alien. The senate then asks the returned alien what it has learned. After a moment of silence, it says, “Whassup?” and the whole alien party joins in. Back on Earth, a scientist hears the alien "Whassup" choir and concludes, "We are not alone!"
Maybe you remember this storyline from a Budweiser ad. What has it to do with software development and testing? We may or may not have alien dogs, but we’re never alone. Whenever we run into a problem, we can reach out to the help that is available. For example, think about the last time you couldn't keep your automation code up to date with changes done to the production code. Or, consider the last time you felt that unit testing the production code was nearly impossible. Or, remember the last time you had to fill out a form for your session report but didn't know what to put in. This article explores these situations and explains what to do about them, where to reach out for help, and how to ask for help and receive it.
When to Seek out Help
Foremost, it is vital to know when to seek help. A programmer may code herself into a dead end with an unfamiliar technology. A tester may become hopelessly lost when trying to pinpoint a particular bug during manual testing. Therefore, knowing when to seek help means knowing when something is wrong. Constraining the time spent on certain activities may help you become aware that you are on the wrong track. Taking a step back and reflecting every thirty or ninety minutes will help you notice dead ends before they waste your time.
Time‑boxing your efforts also works on a larger scale, such as when agile development teams use short iterations. The team focuses on an agreed-upon part of the project and delivers it in one to four weeks. After that, the team reflects over the work. After gaining the relevant insights, the team agrees on actions for the next time‑boxed iteration and continues to improve the process. Time‑boxing smaller efforts and reflecting over a few hours’ work helps us see when we need to reach out for help on a particular difficult task. Just as agile teams reflect and adapt to the situation, we can learn when it might be time to adjust the overall process.
Where to Seek out Help
The developer stuck on a particular bug fix may want to ask an expert in the technology or the underlying code for help. Asking the tester for a broader picture on her code changes may also be worthwhile since testers usually have a holistic overview over the application they are testing, and can expose problems in the solution very quickly—even before you wrote a single line of code.
A tester who gets stuck on a piece of test automation code may want to ask a programmer for help on the design. When stuck on a complicated business rule, the tester may also reach out to the business analyst or consult the customer. In summary, asking the nearest expert for help provides the fastest form of support and feedback. If you are unable to consult a nearby expert, get in touch with a distant helper.
How to Ask for Help?
There are polite and not-so-polite ways to ask for help. Of course, the more politely you ask for support, the more likely you are to receive it. One way to ask politely for help is to start the conversation with small talk on a topic that is of interest to a potential helper. It also may be polite to get in touch with your helper first by telephone or instant messaging. By doing so, you express your respect for his time and avoid interrupting coworkers. However, in-person greetings should be your preferred way to interact in that you can react to facial expressions and gestures. If that is not possible, you can call them up before writing an email or submitting a message to some asynchronous exchange system like Twitter or Skype. It helps to know your helper’s preferences so that you may approach him first using his preferred form of communication.
After initiating the communication, you may want to show appreciation to your helper for his knowledge. He may notice that you're seeking help at this point, so it's fine to ask for help right after this appreciation.
You should know what you want to achieve. Make sure that you can point out all the things you have tried while working on the problem. This will show that you have made an effort and may save your helper from wasting time. Make sure that you’re in the mood to accept critique on the approach you took. For example, if your approach to unit testing involves using mock objects, there may be some uncertainty when it comes to plugging these classes together. Have you thought about these gaps in your code base? If so, you shouldn't become upset at your helper when he asks you about them.
It is also vital to engage yourself in the help you receive and to understand why you need help in the first place. If you don't do this, your helper might get upset when you approach him for the third time with the same question. He may even refuse to provide help again. To counter this, listen carefully and ask follow‑up questions about your helper’s proposed solution. As you learn from this experience, you will add another piece of knowledge to your repository of abilities.
Of course this approach may not work in stressful situations where the expert is already heavily overworked. So, don’t expect too much, and be open to receiving a polite no. If that happens, ask your helper when would be a better time to consult, or seek another expert.
We Are Not Alone
We are not alone when we get stuck at work or when we face a troublesome situation. Reflect regularly on your course of action after fixed time intervals and take the appropriate counter‑actions when required. Seek a nearby expert to provide support. If you do not immediately find help, stay calm and keep looking.
