Ask for help #
At Axelerant, we don’t expect you to know everything. We hired you for your strengths and put you in a team where other’s strengths complement yours. Use your strengths and ask for help often.
Internal Support #
Axelerant has long built a strong ethic of internal support within teams and between them. If you find yourself stuck on a problem for 30 mins, it is highly unlikely that you will figure out a solution soon, no matter what the next Google search will bring. It’s time to ask for help.
First, ask for help within your team. They have the most context and will be able to readily help you. If this doesn’t work, it’s time to ask #internal-support.
Asking for help #
You have spent a lot of time working on your task, getting stuck, and then trying to figure out a problem. You have probably spent hours on that and the problem statement might feel obvious. But it’s not obvious to others. Besides, others are busy with their own task and they would probably have to step out of their zone to help you. So, follow these guidelines to be productive in asking for help.
- Remove any irrelevant context from the problem statement. Assume the reader won’t know anything about the project or what exact problem you’re facing. They wouldn’t. But don’t waste their time writing the entire RFP in your question. If they have trouble reading it, they won’t be able to help you.
- Add relevant context to the problem statement. What is it that you actually want to do? What approach are you taking? Where are you seeing the problem (on your machine, CI, hosting server)? Are there any errors or warnings? Have you checked the logs? Hint: Error messages are most useful in solving a problem, yet often forgotten.
- Keep it one message. The #internal-support channel is on Slack and we often use the thread feature to reply. If you have split your question in multiple messages, threads lose the context.
- Don’t tag
@channel
. Really, don’t.@here
is fine but don’t wake up everyone from sleep to solve your problem. - If you found the solution elsewhere, do share it on the thread. People have invested their time reading and trying to help, even if they ultimately couldn’t. Do them a favor and let them know what worked.
Other approaches to problem solving #
Not all the problems are solved by others. There are times when you have to solve a problem yourself. Here are some of the other approaches.
Take a walk #
It’s often said that the best debugging tool is taking a walk. Physical exercise has been proven to increase mental activity and getting away from devices and into nature gives us another perspective. A 10 minute long walk could solve a problem on which you spent hours.
Rubber duck it #
Explain your problem to a rubber duck. Do it aloud, not in your mind. These magical plastic creatures solve the most challenging problems.
Write a POC #
Build a small separate POC to replicate the problem. Besides giving you a fresh perspective, a POC would be able to easily ask for help from others by letting them reproduce the problem quickly.
If you can’t reproduce the problem in the POC, you’re one step closer to solving it. Look at what else is interfering with your system.